架构演变：微服务架构的四种常见模型-工具盒子

Hello，Hi，你好，我是猿java。

互联网的快速发展，微服务架构已经成为了后端人员一个必备技能，今天我们就来分享微服务中四种常见架构模型，帮助我们更好的去了解微服务的发展。

洋葱架构 {#洋葱架构}

洋葱架构：Onion Architecture，它是由 Jeffrey Palermo（杰弗里·巴勒莫）在 2008年提出的，下图摘自作者原论文：

洋葱架构因为整个架构外形看似像洋葱，因此而得名，它在很大程度上依赖于依赖倒置原则，所有代码都可以依赖于更中心的层，但代码不能依赖于远离核心的层。换句话说，所有耦合都朝向中心。这种体系结构毫不掩饰地偏向于面向对象的编程，它将对象置于所有其他对象之上。

各层说明 {#各层说明}

Domain Model：领域模型层，它是最中心的，代表了为组织建模真相的状态和行为组合，封装了企业级的业务规则；
Model Services：领域服务，涉及多个实体的复杂业务逻辑，例如抽象存储库（仍然将实现细节留给外层，例如数据库连接）；
Application Services：应用程序服务，它定义了应用程序的业务流程；
User interface/Infrastructure/Tests：最外层是用户界面、与外部基础设施的连接和自动化测试。与端口和适配器一样，此模式将与所有外部依赖项（例如数据库、API 和用户界面）的连接留在边缘，以便轻松切换；

提出原因 {#提出原因}

洋葱架构被提出的原因是作者觉得传统自上而下的分层架构模式存在严重的弊端弊端：耦合，每一层都耦合到它下面的层，每一层通常耦合到各种基础设施问题。下图为传统分层架构图：

从传统架构图可以看出每层的强依赖关系，UI 和业务逻辑与数据访问的耦合，如果业务逻辑不存在，UI 将无法运行。如果没有数据访问，业务逻辑就无法运行。而洋葱架构强调整个系统的关注点分离，使得应用程更易于维护。

适用范围 {#适用范围}

洋葱架构不适合小型网站，它适用于长期存在的业务应用程序以及具有复杂行为的应用程序。

整洁架构 {#整洁架构}

整洁架构：Clean Architecture，它是由 Robert C. Martin (Uncle Bob) 于 2012 年提出。整洁架构是基于洋葱架构的概念之上提出的，但各层的细节有所不同。它的核心不叫"领域模型"，而是称为"实体"，但仍然代表企业范围的业务规则。下图摘自作者原文：

从整洁架构的架构图可以看出：整洁架构最主要的原则是依赖原则，它定义了各个层级的依赖关系，同心圆代表软件的不同领域，越往里能力越是核心。外圆代码依赖只能指向内圆，内圆无需关注外圆变化（包括函数、类。变量，或任何其他命名的软件实体）。

各层说明 {#各层说明-1}

Entities：实体。它封装了企业范围的业务规则，实体可以是具有方法的对象，也可以是一组数据结构和函数。只要实体可以被企业中的许多不同应用程序使用，就没有关系。
Use Cases：用例。该层中的软件包含特定于应用程序的业务规则。它封装并实现了系统的所有用例。这些用例协调进出实体的数据流，并指导这些实体使用其企业范围的业务规则来实现用例的目标。
Interface Adapters：接口适配器。该层中的软件是一组适配器，可将数据从对用例和实体最方便的格式转换为对某些外部机构（如数据库或 Web）最方便的格式。例如，这一层将完全包含 GUI 的 MVC 架构。 Presenters、Views 和 Controllers 都属于这里。这些模型可能只是从控制器传递到用例，然后从用例返回到呈现器和视图的数据结构。
Frameworks and Drivers：框架和驱动程序。最外层主要提供适配的能力，适配能力分为主动适配和被动适配，一般由Database、Web Framework等框架和工具组成，这一层一般不会写太多代码，除了往内和下一个圈子通信的胶水代码。

在图表的右下方展示了如何跨越圆圈边界的示例。它显示了 Controller 控制器和 Presenters演示器与下一层中的用例进行通信。注意控制流。它从控制器开始，通过用例移动，然后结束在演示器中执行。还要注意源代码依赖性。它们中的每一个都向内指向用例。

六边形架构 {#六边形架构}

结构 {#结构}

六边形架构：Hexagonal Architecture，又名"端口适配器架构"，它是由 Alistair Cockburn 于 2005 年在论文中引入的。

需要说明的是：六边形架构中的六边形不是六边形，因为数字 6 很重要，而是让绘图的人有空间根据需要插入端口和适配器，而不受一维分层绘图的限制。"六边形架构"一词就源于这种视觉效果。更直白的说，该图案实际上与六边形无关，它只是通常的绘制方式而已。下图摘自作者原论文：

六边形架构将系统分为内六边形和外六边形两层，这两层的职能划分如下：

内六边形实现应用的核心业务逻辑；
外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以 API 主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。

六边形架构的核心理念是：应用是通过端口与外部进行交互的，一个端口可能对应多个外部系统。也就是说，在下图的六边形架构中，最内层的核心业务逻辑与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。

实现逻辑 {#实现逻辑}

当任何驱动程序想要在端口上使用应用程序时，它会发送一个请求，该请求由针对驱动程序特定技术的适配器转换为可用的过程调用或消息，然后将其传递到应用程序端口。该应用程序对驱动程序的技术一无所知。当应用程序有东西要发送时，它会通过端口将其发送到适配器，适配器会创建接收技术（人工或自动）所需的适当信号。应用程序在其所有方面都与适配器进行了语义上的声音交互，而实际上并不知道适配器另一端事物的性质。

DDD分层架构 {#DDD分层架构}

DDD 分层架构应该是目前流行度最高的一种架构方式，但是，其架构也经历了多次的变更。DDD 最早使用的是传统的四层架构；后来四层架构发生了优化，实现了各层对基础层的解耦；再后来领域层和应用层之间增加了上下文环境（Context）层，五层架构（DCI）就此形成了。架构演变图如下：

DDD 分层架构有一个重要的原则：每层只能与位于其下方的层发生耦合。

各层说明 {#各层说明-2}

User interface：用户接口层，用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是：用户、程序、自动化测试和批处理脚本等等。
Application：应用层，它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作；
Domain：领域层，领域层的作用是实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。
Infrastructure：基础层，基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。

模型对比 {#模型对比}

通过上面对四种架构详细介绍可以发现：几种架构里面都有核心领域层（不同架构命名可能不一样），但都是实现核心业务逻辑，它的作用就是将核心业务逻辑与外部应用、基础资源进行隔离。不同架构，核心业务逻辑也是有差异的，有的业务逻辑属于领域模型的能力，有的则属于面向用户的用例和流程编排能力。
应用层实现面向用户操作相关的用例和流程，对外提供粗粒度的 API 服务。它就像一个齿轮一样进行前台应用和领域层的适配，接收前台需求，随时做出响应和调整，尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。