微服务架构包含哪些方面？

2005年Peter Rodgers 提出微 Web 服务（Micro-Web-Service）的概念，2014 年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，从 SOA 架构到服务化架构，再到微服务架构，是一个逐步演进的过程，我们知道微服务架构包含功能架构、技术架构和部署单元三个方面，今天我们就从这3个方面讲讲微服务架构：

1.功能架构

在分层的单体架构中，关注点在技术层面，包括应用的持久化存储、UI、业务规则等。

 单体架构是按照技术维度分层的，导致业务领域概念不清晰，业务领域概念会涉及展现层、业务规则和持久化存储等。分层架构的设计初衷不是容纳业务领域概念，因此，当应用的业务领域需求发生变更时，必须每一层都要进行修改。如果架构是按照技术分层的话，那么变更需求需要跨层进行协作，可见分层架构不具备演进性。

因此， 业务领域建模就成了微服务应用功能架构的核心， 每个微服务都围绕业务领域概念来定义，并将实现架构及其所依赖的其他组件（如数据库等）封装在该微服务中，从而实现了高度解耦。每个微服务都包含所有元素，并通过REST之类的协议与其他微服务通信。因为一个微服务不需要知道其他被调用的微服务的实现细节，从而避免了不当的耦合。每个微服务都通过无共享架构来实现低耦合，从而方便自身的变更。

2.实现架构

应用实现架构有整洁架构、六边形架构和分层架构三种，我们知道这三种架构的展现方式和解决问题的出发点不一样，但其架构思想与微服务架构高内聚、低耦合的设计原则高度一致。

整洁架构的用例层、六边形架构的应用程序层，分层架构的应用层都承担着应用逻辑管理的角色，通过服务组合和编排为前端提供粗粒度的服务。应用的需求会根据用户体验、操作习惯、市场环境以及管理流程的变化而变化，这往往会导致前端逻辑和流程的多变。但无论前端如何变化，核心领域逻辑基本保持稳定，从而在架构层面协调业务逻辑与应用逻辑。

这三种实现架构正是通过分层来控制需求变化对应用的影响的，从而确保从外向内受需求的影响逐渐减少。面向用户的展现层可以快速响应外部需求进行调整和发布，应用层通过服务组合和编排实现业务流程的快速适配上线，领域层基本不需要做太多的变动。这样设计的好处是，可以保证领域层的核心业务逻辑不会因为外部需求和流程的变化而发生调整。

对于基于微服务的应用，推荐使用整洁架构，整洁架构包含：

业务实体层（领域建模）∶它是微服务的核心所在，具体表现形式就是领域模型。

用例层（领域服务）∶用例层负责协调接口适配器层与业务实体层，与业务实体层进行交互，用例层是主要的交互方式。

接口适配器层（应用服务）：接口适配器层只负责为业务实体层和用例层中的领域对象协调任务、分配工作，使它们相互协作。

框架与驱动层（用户界面）：该层一方面负责向用户显示信息和解释用户命令，执行前端界面逻辑。另一方面负责与底层基础设施进行交互，向其他层提供通用的技术能力，该层主要包括两类适配代码∶主动适配代码和被动适配代码。

3.部署单元

部署单元的大小在很大程度上决定了应用的耦合性及灵活性。大的部署单元很难演进（如单体架构、SOA、ESB架构等），因为每次变更都需要进行协调，而小的部署单元为低耦合的架构提供了很多方便。每个微服务都是一个部署单元，可以实现独立部署，确保在更新一个微服务时不会影响其他微服务，从而实现其演进式的架构目的。

严格按照领域拆分是微服务的一个关键原则，通过领域拆分对微服务进行隔离，使得每个微服务在技术上都能实现无共享架构。同时各微服务在物理部署上也都是分离的，并且在每个微服务中都封装了完整的实现架构，从而可以轻松地进行替换和演进。开发人员可以单独处理每个微服务，因为微服务都是高度解耦的。

总的来说，按照业务领域来拆分每一个微服务应用，每一个微服务都包含全技术栈服务，从部署的角度来说，每个微服务完全独立开发、部署的，为应用实现低耦合提供了方便。