为什么在做微服务设计的时候需要DDD?

标签: 微服务 设计 需要 | 发表时间:2020-02-02 22:56 | 作者:JetLee
出处:http://weekly.dockone.io

记得之前在规划和设计微服务架构的时候,张队长给了我一个至今依然记忆深刻的提示:『你的设计蓝图里为什么没有看到DDD的影子呢?』

随着对充血模型的领域认知的加深,我越加感觉到DDD的重要性。但是DDD内容繁多,是不是要深入去了解呢,我觉得不必入坑太深,个人浅见,它最核心的一点就是针对贫血模型的不足而设计,把原先传统的贫血模型里的业务逻辑层拎出来,融入到Domain层,这样面对复杂业务的规模化变更,我们只需要专注于Domain即可。

回到主题,我们要了解的是微服务和DDD到底有什么关系呢?

因为在互联网时代,软件所面临的问题域比以往要复杂得多,这种复杂性来源于不断扩展的问题域自身,也来源于创新变化,以及这种规模性增长所带来的挑战。

然而一个人一个团队,他对复杂的事物的认知是有极限的,面对这种复杂问题唯一的方法就是分而治之。分主要考虑的是如何去分;治意味着分出来的每一个部分要能够独立的运行,能够互相的协作,完成整体的目标,能够一来应对外部变化所带来的冲击。

微服务的缺陷

微服务架构在分和治两个方面都给出了很好的理论指导和最佳实践,那微服务是不是解决复杂问题的银弹呢?其实不然,很多团队在应用了微服务架构来构建他们的系统以后,发现并没有完全解决这种复杂性问题,甚至还带来了一些其他的问题。比如:
  • 服务并没有解决复杂系统如何应对需求变化这个问题,甚至还加剧了这个问题。
  • 当一个需求变化了,需要花大量的精力去识别这个变化影响到了哪些微服务,这些服务的多个团队之间,需要通过无休止的扯皮去决定哪个服务多一些,哪些服务少改一些。
  • 然后测试团队还需要做昂贵的这种联调测试
  • 即便如此呢,开发团队依然不放心,还要通过一系列的开关控制,小心翼翼的去做切流,去做灰度发布。


从业务层面来看,微服务架构没有避免这种散弹式的修改。甚至反而加重了他,这是为什么呢?一个重要的原因是微服务架构在分的这个纬度考虑的并不全面。

DDD功用

当我们去做分的这种工作的时候,具体拆分详见我的另外一篇文章《 微服务的拆分姿势》,需要考虑哪些维度呢?我觉得我们至少要考虑三个维度:
  • 功能纬度
  • 质量纬度,比如性能,可用性
  • 工程纬度


微服务对第2个给出了很好的指导,对第3个也给出了一些建议。但是,对第1个功能纬度只给出来非常有限的指导,就是为什么随着微服务的流行,领域驱动设计(DDD)又被重新重视起来的原因。

DDD弥补了微服务在功能划分方面没有给出很好指导的缺陷。所以他们在面对复杂问题和构建系统时候是一种互补的关系,在系统拆分的时候可以很好的协作。

只是他们看待系统拆分这个角度是不同的。微服务当中的服务所关注的范围正是DDD所推崇的六边形架构中的领域层。

拆分案例

接下来结合DDD和微服务来拆分一个复杂系统。

关于领域

我们称企业的业务范围和在这个范围里进行的活动为领域,和软件系统无关。领域会分成多个子域,比如我们一个电商系统,会有:
  • 商品子域
  • 订单子域
  • 库存子域等等。


在不同的子域里,不同的概念有不同的含义。所以我们在进行领域建模的时候,必须要有一个明确的领域边界,也就是DDD里称做的限界上下文,它是系统内部的一个架构边界,决定了这个系统架构。

划分系统内部架构边界

架构简洁之道这本书里边就说过:『系统架构是由系统的内部架构边界以及边界之间的依赖关系所决定的,与系统中各个组件之间的通信和调用的方式是无关的』。我们常说的微服务的服务调用本身只是一种比函数调用方式成本稍高的,分割应用程序行为的一种形式,系统架构无关。

所以,复杂系统划分的第一重要的是要划分内部的架构边界,即划分清楚这个上下文,以及明确他们之间的关系,这对应于我们之前说的功能的维度。这正是DDD用武之处。其次我们才考虑基于非功能的维度如何划分,这是微服务能够发挥其优势的地方。

举个例子,我们把系统分成ABC三个个上下文,三个上下文的代码可以在一个部署单元里运行,通过进程内调用来完成操作,这就是典型的单体架构;

也可以各自在一个独立的部署单元里运行,通过远程调用来完成操作,这就是现在流行的微服务架构。

边界清晰的好处

我们更多的是两种架构模式的一个混合,比如A和B一起是一个部署单元,C是另外一个独立的部署单元,这种情况往往是因为C非常重要,他并发的访问量非常大,或者它的需求变更比较频繁。将C拆分出来的有以下几个好处:
  • 资源倾斜
  • 使用弹力设计模式:比如重试,熔断,降级
  • 使用特殊技术:比如Go语言
  • 具备独立代码库:有独立团队和运维人员,和A和B的运行期做到隔离不互相影响


这四点正是服务架构所关注的,它是基于非功能纬度的视角来看待拆分这件事情的,他关注的不是系统架构的逻辑边界,更多的关注的是应用程序行为的分隔。

那为什么不把A和B都拆成一个独立的部署单元?

这会带来更多的好处,也会带来额外的成本,架构应该是可以演进的,在业务发展的早期,应该关注系统架构的逻辑边界,保持逻辑边界的清晰和关系的正确,随着业务量的增加,逐步在做拆分,这是组合应用DDD和微服务架构带来的最大的好处。

在单体架构中,保持架构逻辑边界不被突破是有一定难度。如果逻辑边界不清晰,在需要服务器拆分的时候,就未必能拆得出来了。另外没有人一下子就可以把逻辑边界定义正确,即使这个上下文定义的不太正确,在DDD聚合根这个概念可以保障我们能够演进出更适合的上下文。

DDD界限上下文内部通过实体和值对象来对领域概念进行建模,一组实体和值子对象归属于一个聚合根。那按DDD要求:
  • 聚合根用来保证内部实体规则的正确性和数据的一致性
  • 外部对象只能通过ID来引用聚合根,不能引用聚合根内部的实体
  • 聚合根之间不能共享一个数据库事务,它们之间的数据一致性需要通过最终的一致性来保障


有了聚合根,基于这些约束,未来可以根据需要把聚合根升级为上下文,甚至拆分成微服务都是比较容易的。

另外想要知道如何合理的拆分微服务,可以参考我的另外一篇文章《 微服务划分的姿势》,今天就给你介绍到这儿,希望对你有所启发。

原文链接: https://www.cnblogs.com/jackyfei/p/12089123.html

相关 [微服务 设计 需要] 推荐:

为什么在做微服务设计的时候需要DDD?

- - DockOne.io
记得之前在规划和设计微服务架构的时候,张队长给了我一个至今依然记忆深刻的提示:『你的设计蓝图里为什么没有看到DDD的影子呢. 随着对充血模型的领域认知的加深,我越加感觉到DDD的重要性. 但是DDD内容繁多,是不是要深入去了解呢,我觉得不必入坑太深,个人浅见,它最核心的一点就是针对贫血模型的不足而设计,把原先传统的贫血模型里的业务逻辑层拎出来,融入到Domain层,这样面对复杂业务的规模化变更,我们只需要专注于Domain即可.

[译] 微服务设计指南

- - IT瘾-dev
本文为翻译发表,转载需要注明来自公众号EAWorld. 作者:Thilina Ashen Gamage. 原题:Microservices Design Guide. 原文:http://t.cn/EAvCCMb. 全文5949字,阅读约需要10分钟. 2018年,每个人都听说过微服务. 微服务是当今软件工程师的一个热门话题.

[转]实施微服务,我们需要哪些基础框架?

- - 互联网 - ITeye博客
实施微服务,我们需要哪些基础框架. 作者  杨波 发布于 2015年12月1日 |. 微服务(MicroServices)架构是当前互联网业界的一个技术热点,圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设,他们都有相同的疑问:一个微服务架构有哪些技术关注点(technical concerns).

基于DDD的微服务架构设计

- - ITeye博客
DDD领域驱动设计(DDD:Domain-Driven Design).     现有的架构设计实在受不了,业务的反反复复地变化,导致代码圈复杂度之深让人恐惧. 之前的微服务架构经验让我更加彻底点,采用DDD领域驱动设计进行整个改变.     随着经过几个月的努力,确实慢慢地体会到ddd的架构设计的优势,聚合根设计能够协助我们整个服务改造,开发起来越来越迅速.

微服务开发中的数据架构设计

- - ITeye资讯频道
GitChat 作者:陈伟荣. 原文: 微服务开发中的数据架构设计. 关注微信公众号:「GitChat 技术杂谈」 一本正经的讲技术. 微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性. 为业务创新和业务持续提供了一个良好的基础平台.

微服务化的数据库设计与读写分离

- - 行业应用 - ITeye博客
数据库永远是应用最关键的一环,同时越到高并发阶段,数据库往往成为瓶颈,如果数据库表和索引不在一开始就进行良好的设计,则后期数据库横向扩展,分库分表都会遇到困难. 对于互联网公司来讲,一般都会使用My SQL数据库. 我们首先来看Mysql数据的总体架构如下:. 这是一张非常经典的Mysql的系统架构图,通过这个图可以看出Mysql各个部分的功能.

设计师需要的知识体系

- - 博客 - 伯乐在线
产品设计师面对复杂、庞大的制造业系统以及多元化的市场,其知识体系要同时具备广度和深度. 设计是循序渐进、不断深入的过程,因此我们面对的是交错的学科体系,以及深入的技术探究. 当国内工业设计教育界还在热烈地争论设计是艺术还是技术时,不妨退一步思考,设计本身既融合又独立,既有依附性又具有本身不可替代的意义.

大数据需要好设计

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
  越来越多的企业开始意识到优秀的设计之于数据的重要性. 优秀的设计可以让枯燥乏味的数据变得更加直观、友好,从而帮助顾客理解数据的意义,让企业与顾客建立更好的关系,从而更好地发挥作用.   许多公司一直相信大量囤积数据的好处,现在他们正在寻找能利用这些数据造福顾客的方法. 大数据给各行各业的企业提供了一个变得更加透明、更值得信任,并在竞争中脱颖而出的机会,而且能让他们的用户在产品和服务上获得更加个性化的体验.

微服务的4个设计原则和19个解决方案 - 晓晨Master - 博客园

- -
微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活、更能适应现在需求快速变更的大环境. 本文将介绍微服务架构的演进、优缺点和微服务应用的设计原则,然后着重介绍作为一个“微服务应用平台”需要提供哪些能力、解决哪些问题才能更好的支撑企业应用架构.

UI设计需要什么软件—UI设计常用软件盘点

- - 酷勤网-挖经验 [expanded by feedex.net]
 来源:365UCD   2012-01-04. UI设计,即用户界面设计,是对软件的人机交互、操作逻辑、界面美观的整体设计,UI设计不是单纯的美术绘画,他需要定位使用者,使用环境,使用方式并为最终用户而设计. 本文将为大家盘点一些UI设计的常用软件,供初学者参考. Photoshop并非一个单纯的图像编辑软件,它的应用领域涉及图像、图形、文字、视频、出版等各个方面,非常广泛.