「轻阅读」为什么在做微服务设计的时候需要DDD?

技术小白 2020-01-03 16:27:30 ⋅ 423 阅读

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

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

                          https://www.cnblogs.com/jackyfei/p/12089123.html

       回到主题,我们要了解的是微服务和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来引用聚合根,不能引用聚合根内部的实体

  • 聚合根之间不能共享一个数据库事务,它们之间的数据一致性需要通过最终的一致性来保障

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



全部评论: 0

    我有话说:

    阅读为什么越来越多系统服务化?

    脱离业务实际情况架构都是耍流氓,所以不是所有系统都必须服务化,也不要为了服务化而服务化。

    「转载」使用DDD指导业务设计一点思考

    领域驱动设计DDD) 是 Eric Evans 提出一种软件设计方法和思想,主要解决业务系统设计和建模。DDD 有大量难以理解概念,尤其是翻译原因,某些词汇非常生涩,例如:模型、限界上下文

    阅读」“完”和“好”区别

    工作中,“完”和“好”虽然仅一字之差,但前者只是完成了某项工作,而后者则不仅是完成了工作还有一个好

    阅读」Dubbo 如何成为连接异构服务体系最佳服务开发框架

    要实现异构服务体系间共存或迁移,关键点打通异构体系间协议与服务发现,得益于 Dubbo 自身对多协议、多注册模型支持

    阅读」分布式事务四种解决方案,成长需要尝试

    分布式事务指事务操作位于不同节点上,需要保证事务 AICD 特性。

    老板逼你上服务了吗?

    “ 这些年软件设计规模越来越庞大,业务需求也越来越复杂,针对系统性能、高吞吐率、高稳定性、高扩展等特性提出了更高要求。   图片来自 Pexels可以说业务需求是软件架构能力

    阅读」聊一聊6种常用架构设计模式(上)

      许多现代应用都需要企业级规模上进行构建,有时甚至需要互联网规模上进行构建。这些应用都需要满足可扩展性、可用性、安全性、可靠性和弹性需求本文中,我将谈论一些设计模式,这些模式

    阅读」如何设计移动端屏适配方案

    众多移动设备中,前端开发人员如何不同屏幕大小,不同程度高清屏下去百分百还原设计稿,从来都不

    DDD 服务落地实战

    PS:让我们把DDD思想真正落地,从数据库设计到代码实战演练,从电商、在线订餐 到智慧医疗全方位展示如何运用DDD 服务+人工智能、嵌入式+物联网项目中进行业务建模、系统规划与设计实践。

    阅读博推荐架构演进

    博两个核心基础点:一是用户关系构建,二是内容传播,博推荐一直致力于优化这两点,促进博发展。

    阅读」阿里云-开放平台高级技术家教你搭建服务架构四大金刚利器

    孔凡勇,花名云狄,阿里云-开放平台高级技术家,对高并发、高性能、高可用、可伸缩分布式系统架构设计有丰富经验,Cloud Native坚定拥护者,坚守开发一线打磨匠艺架构师。

    阅读」4大服务注册发现技术对比

    架构设计 CAP 和 BASE 理论

    【开源资讯】JWCloud 专业版 v1.0.0 发布,基于 SpringCloud 研发服务框架

    简介 JavaWeb_Cloud 服务平台是一款基于 SpringCloud 框架研发分布式微服务框架,主要使用技术栈包括: SpringCloud、Vue、ElementUI

    阅读」“来我公司技术总监吧” “要写代码吗?” “不写代码你来干嘛?”

    标题来源于一段真实对话,老赵,小李都是我朋友,我作为中间人介绍他们认识,我们约上海码农圣地--张江某咖啡馆。

    阅读」Mysql调优你不得不知细节

    多数时候数据库会成为整个系统瓶颈

    阅读」京东商城交易系统演进之路

    原文:https://www.toutiao.com/i6762874634867048963商城服务如图所

    阅读」从MySQL高可用架构看高可用架构设计

    高可用HA(High Availability)是分布式系统架构设计中必须考虑因素之一

    阅读」消息总线(MQ)知多少

    消息总线(Message Queue,MQ),是一种跨进程通信机制,用于上下游之间传递消息。MQ是一种常见上下游“逻辑解耦+物理解耦”消息通信服务,消息发送上游只需要依赖MQ,逻辑上和物理上