08 | 微服务架构模型：几种常见模型的对比和分析
该思维导图由 AI 生成，仅供参考
整洁架构
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了微服务架构中的整洁架构、六边形架构和DDD分层架构，并对它们进行了对比和分析。整洁架构以洋葱模型为基础，强调依赖原则，将应用软件分为领域模型、领域服务、应用服务和外围内容。六边形架构通过端口与外部进行交互，实现了核心业务逻辑与外部资源的隔离。文章指出，这三种架构模型的设计思想体现了微服务架构的高内聚低耦合原则，以领域模型为中心。作者强调了领域模型和微服务的合理分层设计对中台和微服务设计的重要性，建议在中台设计中聚焦领域模型。此外，文章还探讨了微服务之间的层次依赖关系和服务集成方式，以及应用和资源的解耦与适配。总的来说，本文通过对不同架构模型的分析，为读者提供了对微服务架构设计的深入理解和实践指导。
《DDD 实战课》，新⼈⾸单¥59
全部留言(93)
- 最新
- 精选
ANYI微服务之间通过服务内部的应用层来连接多个微服务，微服务之间的相互调用；有两个疑问：1，微服务之间互相调用应该是什么样子？会不会就出现了网状微服务的调用关系结构了 2，是把这个夸多个微服务的应用层独立起来成为一个微服务（类似BFF微服务，没有领域）减少微服务之间调用关系？微服务之间就应该减少依赖调用？作者回复: 微服务之间要分两种情况，一种是项目级的少量微服务之间的调用。这样的调用可以放在微服务内的应用层，没必要再单独拿出一个微服务来进行服务组合和编排。 另外一种是复杂的企业级微服务调用和组合。拿出一个独立的BFF微服务的主要目的，一个是避免在一个微服务内组合太多的微服务的应用服务。二是，通过BFF微服务编排组合，可以减少由于前台的需求变化，传导到后端微服务中，可以降低后端微服务的发版频率，保持后端微服务的稳定。
2019-11-06540
IT_matters您好，关于分层架构和六边形架构区别，在您给别人的评论中看到区别这样一段话。 ------------------------------ 主要区别还是在外围的适配上，端口适配器会给每个不同的场景，设计一个端口提供调用服务，这种是主动适配。还有一种是资源方面服务，是被动适配的方式。所有的外围对象都是平等的，可以是自动化的测试工具，也可以是APP。 DDD是通过接口层来对外提供服务接口，基础资源通过仓储依赖倒置使用资源，并实现解耦。 ------------------------------ 我感觉这二者还是一样的啊，如果分层架构在接口层，实现各种适配器，比如job，soa,rest。就可以说它是六边形架构了吗？有具体代码的例子吗，一望便知。从评论区来看，很多读者都对二者的区别比较疑惑。作者回复: 其实这三种架构是一种演化的关系。2003年DDD诞生，它是一种上下层的关系。六边形架构是在2005年提出，将这种上下层的关系演变为内外关系，内部代表了应用的业务逻辑，外部代表应用的驱动逻辑。但六边形架构的内层的业务逻辑还没有明显的领域模型的概念。2008年洋葱架构出现，六边形架构实际上是洋葱架构的一个超集。它与六边形架构有着相同的思路，都是通过编写适配器代码将应用逻辑从对基础设施的依赖中解放出来，避免基础设施代码渗透到应用逻辑中。洋葱架构在业务逻辑中加入了一些在领域驱动设计的分层的概念，比如用户接口层、应用层、领域层和基础层，另外它还明确了外层依赖内层，内层对外层无感知的这种依赖关系。虽然这三者之间在表达形式上存在差异，但它们的核心职责都是要做到核心业务逻辑和技术实现细节的分离和解耦。
2020-03-25221
steven应用层与领域层的区别，一般情况下还是很容易的。但是有些复杂的，也是经常会遇到的场景：比如某个A领域和B领域在C应用层作拼装时，会有业务判断的情况（比如需要综合判断A领域与B领域的对象，才能继续作后续的业务操作），此种情况下，如何设计才能避免这类问题呢？ 尽量避免跨领域的业务聚合是一种方法，但是很多情况下很难避免这类现象。作者回复: 这种情况是经常遇到的，所以在开发的时候，在应用服务对聚合与聚合之间的服务编排时不要采用对象依赖，采用ID的方式。因为如果未来聚合被拆分到不同的微服务的时候，原来在一个微服务内的对象依赖就不存在了，你需要调的代码量就会比较多。
2020-03-22613
瓜瓜看完后，就是没区别。作者回复: 没有差异就不会有这么多叫法😄。它们几个其实是一点一点继承和发展过来的，在大的分层上基本上没什么太大的差异，思路基本是一致的，都是以领域模型为中心，加上用于编排的应用层逻辑。但是在分层的内部有一些小的差异。包括外部的适配方式也有差异。
2019-10-3012- Geek_d94e60如果有了BFF这一层做统一编排，微服务内部还需要编排吗？如果碰到如下两种方案 A调用B， B再调用C A调用B , A再调用C 刚开始识别不出复用性，两个方案感觉都可行，如何抉择，有什么原则指导吗？
作者回复: BFF做微服务之间的编排。微服务内的应用服务主要做领域服务的编排和聚合之间的协调。BFF是微服务之间的，应用服务是微服务内的。
2019-11-1310 
sundy始终不理解soa与中台有啥区别，感觉在技术上没什么创新作者回复: 中台体现的主要还是企业级的复用能力，它的价值不在技术上，可以说中台更偏业务。SOA或者微服务只是一种实现方式的不同。中台强调企业级内的整体解决方案。
2020-03-148
Jxin
回答问题： 1.为了支持外部应用，内部核心业务必须增加新逻辑。这种情况主要是要提高对价值的意识和风险的敏感。尽量不去加核心逻辑的代码，如果加了，必须是有足够价值的特性，且风险点可控或无。 2.为了支持外部应用，内部核心业务存在现有功能逻辑，但需调整兼容。这种情况就对该核心逻辑做进一步抽象，将通用部分复用，常变部分做抽象，实现更细力度的配置策略的定制能力。（当然也是要有足够价值）。 提问： 老的大项目并没有合理的架构分层。套到整洁架构上来看。 1.领域服务层会干领域模型的活。（贫血领域模型） 2.领域服务层会干应用层的活。（领域层大量rpc调用外部服务，并依托外部服务返回的dto做大量业务） 3.基础层会干领域服务的事。（dao层写业务，发mq，存solr，redis） 对于以上情况，做既有代码改善的小步重构，老师可有好套路或则思路？毕竟这种项目要大改规范，成本（时间）和风险（线上事故）都是接受不了的。（我重构了一遍，但是是业务架构上的。领域服务和基础层的职责越界并没有全量调整，仅是跟着需求，若涉及到就修修补补）作者回复: 这里你可以考虑单体架构的演进方式。可以先对系统做整体的领域建模分析，分解成多个不同的子域，建立领域模型。再根据优先级将部分领域模型对应的功能和数据从原来的单体应用中拆分出来，拆分为微服务。对原来的单体系统的前端提供API服务，原有系统的前端界面保持不变，整个架构演变用户无感知。当所有领域模型的微服务建设完成后，就可以抛弃原来的单体应用了。
2019-10-3047
kevin有个点一直不太理解，还望老师解惑。 文章提到抽象出一个仓储的接口，与基础层的数据库进行解耦，方便后续有替换数据库。这种情况在实际场景中很少出现，选用合适的存储中间件是一件重要的事情，一般在项目初期就确定了，中途替换的概率很小，为了这样的小概率事件，是不是有些过度设计？作者回复: 现在技术发展这么快，一切皆有可能的。这样做其实也是将领域模型和资源逻辑解耦的过程。
2020-01-0246
TH想起了一句话：软件开发中遇到的所有问题，都可以通过增加一层抽象来解决。 对于依赖倒置的实现不是很清楚，按我的理解就是面向接口编程，由调用方将基础设施层的具体实现传入到被调用的服务，老师可以详细解释一下吗？作者回复: 是这样的。直白一点就是业务的归业务，基础的归基础，两者通过一层来适配，具体就是通过接口的方式。
2019-10-3056
y3请问老师，在设计微服务接口编排的时候，有哪些需要注意的地方？最好可以在github上给一个demo。作者回复: 你是说应用服务的编排吗？ 你把这种编排理解成在同一个微服务内，一个方法对多个不同方法的调用就可以了，如果涉及到外部微服务的接口调用，你需要做DO与DTO的数据转换。
2019-11-1924
