英文互动网站建设,梅县区住房和城乡规划建设局官方网站,家装设计图纸,沈阳电力建设总公司网站目录
1、前言
2、软件架构模式的演进
3、微服务设计和拆分的困境
4、为什么 DDD适合微服务
5、DDD与微服务的关系
6、总结 1、前言
我们知道#xff0c;微服务设计过程中往往会面临边界如何划定的问题#xff0c;不同的人会根据自己对微服务的理
解而拆分出不同的微服…目录
1、前言
2、软件架构模式的演进
3、微服务设计和拆分的困境
4、为什么 DDD适合微服务
5、DDD与微服务的关系
6、总结 1、前言
我们知道微服务设计过程中往往会面临边界如何划定的问题不同的人会根据自己对微服务的理
解而拆分出不同的微服务于是大家各执一词谁也说服不了谁都觉得自己很有道理。
那在实际落地过程中见过不少项目在面临这种微服务设计困惑时是靠拍脑袋硬完成的上线后
运维的压力就可想而知了。那是否有合适的理论或设计方法来指导微服务设计呢有的就是
领域驱动设计DDD。
2、软件架构模式的演进
我们知道这些年来随着设备和新技术的发展软件的架构模式发生了很大的变化。
软件架构模式大体来说经历了从单机、集中式到分布式微服务架构三个阶段的演进。随着分布式技
术的快速兴起我们已经进入到了微服务架构时代。 我们先来分析一下软件架构模式演进的三个阶段。
第一阶段是单机架构
采用面向过程的设计方法系统包括客户端 UI 层和数据库两层采用 C/S 架构模式整个系统围
绕数据库驱动设计和开发并且总是从设计数据库和字段开始。
第二阶段是集中式架构
采用面向对象的设计方法系统包括业务接入层、业务逻辑层和数据库层采用经典的三层架构
也有部分应用采用传统的 SOA 架构。这种架构容易使系统变得臃肿可扩展性和弹性伸缩性差。
第三阶段是分布式微服务架构
随着微服务架构理念的提出集中式架构正向分布式微服务架构演进。微服务架构可以很好地实现
应用之间的解耦解决单体应用扩展性和弹性伸缩能力不足的问题。
我们知道在单机和集中式架构时代系统分析、设计和开发往往是独立、分阶段割裂进行的。
比如在系统建设过程中我们经常会看到这样的情形A 负责提出需求B 负责需求分析C 负
责系统设计D负责代码实现这样的流程很长经手的人也很多很容易导致信息丢失。最后
就很容易导致需求、设计与代码实现的不一致往往到了软件上线后我们才发现很多功能并不是
自己想要的或者做出来的功能跟自己提出的需求偏差太大。
而且在单机和集中式架构这两种模式下软件无法快速响应需求和业务的迅速变化最终错失发展
良机。此时分布式微服务的出现就有点恰逢其时的意思了。
3、微服务设计和拆分的困境
那进入微服务架构时代以后微服务确实也解决了原来采用集中式架构的单体应用的很多问题比
如扩展性、弹性伸缩能力、小规模团队的敏捷开发等等。
但在看到这些好处的同时微服务实践过程中也产生了不少的争论和疑惑微服务的粒度应该多大
呀微服务到底应该如何拆分和设计呢微服务的边界应该在哪里
可以说很久以来都没有一套系统的理论和方法可以指导微服务的拆分包括微服务架构模式的提
出者 Martin Fowler 在提出微服务架构的时候也没有告诉我们究竟应该如何拆分微服务。
于是在这段较长的时间里就有不少人对微服务的理解产生了一些曲解。有人认为“微服务很
简单不过就是把原来一个单体包拆分为多个部署包或者将原来的单体应用架构替换为一套支持
微服务架构的技术框架就算是微服务了。” 还有人说“微服务嘛就是要微要小拆得越小效
果越好。”
但我想这两年你在技术圈中一定听说过一些项目因为前期微服务拆分过度导致项目复杂度过
高无法上线和运维。
综合来看我认为微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地
方。换句话说确定了业务边界和应用边界这个困境也就迎刃而解了。
那如何确定是否有相关理论或知识体系支持呢在回答这些问题之前我们先来了解一下领域驱
动设计与微服务的前世今生。
2004 年埃里克·埃文斯Eric Evans发表了《领域驱动设计》Domain-Driven Design–Tackling
Complexity in the Heart of Software这本书从此领域驱动设计DomainDriven Design简称
DDD诞生。DDD核心思想是通过领域驱动设计方法定义领域模型从而确定业务和应用边界
保证业务模型与代码模型的一致性。
但 DDD提出后在软件开发领域一直都是“雷声大雨点小”直到 Martin Fowler 提出微服务架构
DDD才真正迎来了自己的时代。
有些熟悉 DDD设计方法的软件工程师在进行微服务设计时发现可以利用 DDD设计方法来建立领
域模型划分领域边界再根据这些领域边界从业务视角来划分微服务边界。而按照 DDD方法设
计出的微服务的业务和应用边界都非常合理可以很好地实现微服务内部和外部的“高内聚、低耦
合”。于是越来越多的人开始把 DDD作为微服务设计的指导思想。
现在很多大型互联网企业已经将 DDD设计方法作为微服务的主流设计方法了。DDD也从过去“雷
声大雨点小”开始真正火爆起来。
4、为什么 DDD适合微服务
DDD 是一种处理高度复杂领域的设计思想它试图分离技术实现的复杂性并围绕业务概念构建
领域模型来控制业务的复杂性以解决软件难以理解难以演进的问题。DDD不是架构而是一
种架构设计方法论它通过边界划分将复杂业务领域简单化帮我们设计出清晰的领域和应用边
界可以很容易地实现架构演进。
DDD包括战略设计和战术设计两部分。
战略设计主要从业务视角出发建立业务领域模型划分领域边界建立通用语言的限界上下文
限界上下文可以作为微服务设计的参考边界。
战术设计则从技术视角出发侧重于领域模型的技术实现完成软件开发和落地包括聚合根、
实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。
我们来看看 DDD是如何进行战略设计的。
DDD战略设计会建立领域模型领域模型可以用于指导微服务的设计和拆分。事件风暴是建立领
域模型的主要方法它是一个从发散到收敛的过程。它通常采用用例分析、场景分析和用户旅程分
析尽可能全面不遗漏地分解业务领域并梳理领域对象之间的关系这是一个发散的过程。事件
风暴过程会产生很多的实体、命令、事件等领域对象我们将这些领域对象从不同的维度进行聚
类形成如聚合、限界上下文等边界建立领域模型这就是一个收敛的过程。 我们可以用三步来划定领域模型和微服务的边界。
第一步在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等根据这些要素梳理
出领域实体等领域对象。
第二步根据领域实体之间的业务关联性将业务紧密相关的实体进行组合形成聚合同时确定聚
合中的聚合根、值对象和实体。在这个图里聚合之间的边界是第一层边界它们在同一个微服务
实例中运行这个边界是逻辑边界所以用虚线表示。
第三步根据业务及语义边界等因素将一个或者多个聚合划定在一个限界上下文内形成领域模
型。在这个图里限界上下文之间的边界是第二层边界这一层边界可能就是未来微服务的边界
不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行物理上相互隔离所以是物理边
界边界之间用实线来表示。
有了这两层边界微服务的设计就不是什么难事了。
在战略设计中我们建立了领域模型划定了业务领域的边界建立了通用语言和限界上下文确定
了领域模型中各个领域对象的关系。到这儿业务端领域模型的设计工作基本就完成了这个过程
同时也基本确定了应用端的微服务边界。
在从业务模型向微服务落地的过程中也就是从战略设计向战术设计的实施过程中我们会将领域
模型中的领域对象与代码模型中的代码对象建立映射关系将业务架构和系统架构进行绑定。当我
们去响应业务变化调整业务架构和领域模型时系统架构也会同时发生调整并同步建立新的映射
关系。
5、DDD与微服务的关系
有了上面的讲解现在我们再次总结下 DDD与微服务的关系。
DDD是一种架构设计方法微服务是一种架构风格两者从本质上都是为了追求高响应力而从
业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发其核心要义是强调根据业务
发展合理划分领域边界持续调整现有架构优化现有代码以保持架构和代码的生命力也就
是我们常说的演进式架构。
DDD主要关注从业务领域视角划分领域边界构建通用语言进行高效沟通通过业务抽象建
立领域模型维持业务和代码的逻辑一致性。
微服务主要关注运行时的进程间通信、容错和故障隔离实现去中心化数据管理和去中心化服务
治理关注微服务的独立开发、测试、构建和部署。
6、总结
今天我们主要学习微服务设计和拆分的难题。通过DDD战略设计可以建立领域模型划定领域边
界解决微服务设计过程中边界难以划定的难题。如果你的业务焦点在领域和领域逻辑那么你
就可以选择DDD作为微服务的设计方法
更关键的一点是DDD不仅可以用于微服务设计还可以很好地应用于企业中台的设计。
如果你的企业正在做中台转型DDD将会是一把利器它可以帮你建立一个非常好的企业级中台
业务模型。有关这点你还会在后面的文章中见到详解。
除此之外DDD战术设计对设计和开发人员的要求相对较高实现起来相对复杂。不同企业的研
发管理能力和个人开发水平可能会存在差异。尤其对于传统企业而言在战术设计落地的过程中
可能会存在一定挑战和困难我建议你和你的公司如果有这方面的想法就一定要谨慎评估自己的
能力选择最合适的方法落地DDD。
总体来说DDD可以给你带来以下收获 DDD是一套完整而系统的设计方法它能带给你从战略设计到战术设计的标准设计过程使得你的设计思路能够更加清晰设计过程更加规范。 DDD善于处理与领域相关的拥有高复杂度业务的产品开发通过它可以建立一个核心而稳定的领域模型有利于领域知识的传递与传承。 DDD强调团队与领域专家的合作能够帮助你的团队建立一个沟通良好的氛围构建一致的架构体系。 DDD的设计思想、原则与模式有助于提高你的架构设计能力。 无论是在新项目中设计微服务还是将系统从单体架构演进到微服务都可以遵循DDD的架构原则。 DDD不仅适用于微服务也适用于传统的单体应用。
