企业架构之微服务应用架构
微服务设计的本质
应用架构设计指的是一套用于系统性规划和回答以下关键问题的方法：
- 规划哪些应用承载业务能力？
- 这些应用之间是什么关系？
- 它们如何交互？
- 它们访问或变更了哪些数据？
- 它们如何与用户进行交互等？
应用架构的核心是围绕“应用”或“微服务”这一基本单元展开的系统性设计，现代企业应用都采用“微服务”架构。微服务不仅仅是一种技术形态，更是一种设计理念。在这种设计理念下，企业的业务能力被拆分为一个个小规模、自治的服务单元。每个服务可以拥有独立的逻辑、数据和技术栈，再通过这些“微小个体”之间的灵活组合，使得复杂业务能力可以被高效地构建和演进。
微服务与传统的单体架构不同，后者是一种集中控制的系统形态。不论是现实世界的物理系统，还是数字世界的虚拟系统，在底层逻辑上有着很大的相似性。分布式系统与集中式系统的对比，其实就是看：当面对外部不确定性时，哪一类系统具备更强的生存能力？
任何复杂系统在其发展过程中都会受到各种扰动，比如需求变更。只有那些在遭受“损失”后能快速修复并重建的系统，才更容易在变化中生存下来。相比之下，单体架构由于模块间高度耦合，即使一个微小的需求变更，也可能引发整个系统的重新构建。而在微服务架构下，各服务之间具备良好的可替换性，可以低成本地替换不符合需求的服务。虽然服务个体更替频繁，但系统整体因此具备了更强的稳定性和演化能力。
这才是微服务架构被广泛采纳的根本原因：它天然支持企业在试错、创新和快速迭代中的灵活变更需求。这种设计思想，与自然界生态系统的运行机制基本是一致的。在生态系统中，动植物作为个体，各自自治、自由演化，在“物竞天择、适者生存”的机制驱动下，虽然个体之间存在竞争与淘汰，但整个生态系统却能保持多样性和持续繁荣。以微服务为基础构建的IT系统生态，正是一个同样具备“进化”能力的数字世界中的生态系统。
微服务的本质是一种通过分布式方式解决复杂问题的设计哲学。而在这种分布式方式下，能够自下而上激发个体的活力，从而提升整个系统的创新和演进速度，这都属于在“生存能力”之下的延伸能力。
微服务设计的主要问题
第一个问题是微服务的颗粒度太小。
微服务中的“微”字本身很容易给人带来误导，导致现实中“只管分、不管合”。很多场景中服务拆分粒度过细，甚至给人一种“为了拆而拆”的印象。因为从技术角度看，总能找到新的维度继续拆解。然而，这种做法忽略了一个关键点：IT系统本质上是一个有机整体，服务之间需要高效的协同与整合。微服务多了之后，通讯成本也会快速上升。只不过可能不涉及到真金白银，大家体验没那么强。
第二个问题是服务接口质量偏低。
许多微服务的接口设计仍停留在“页面驱动”的层面，缺乏对业务能力的有效抽象与封装。这在当前智能体（Agent）逐步进入企业应用的背景下尤为突出：业务人员或智能体可调用的高质量、语义清晰的服务接口非常有限，严重影响了业务的灵活组合与快速响应能力。
微服务设计的解决思路
一是面向“能力域”去规划。
要想保证服务接口的质量，最有效的方式是采用领域模型驱动的方法。在实践中这个说起来容易做起来难，问题在于虽然领域模型本身可能并不难绘制，但如果模型的思考范围过于狭窄，即使有了模型，也很难设计出高质量、可复用的接口。同时，领域模型本身缺乏一套明确的标准来判断其优劣。所以，到了微服务这个粒度再去设计，很容易“只见树木，不见森林”。
为了解决这个问题，引入了一些自上而下的规划视角。首先从企业整体出发，识别并规划出核心的“能力域”，然后，围绕每一个能力域，思考应对外暴露哪些大粒度的服务能力。在构建能力领域级的模型时，由于站位更高、视野更广，反而能够过滤掉一些管理细节的干扰，聚焦于真正的业务本质。这种高层次的抽象，也有助于各方在关键问题上更容易达成共识。
二是强调微服务的整合。
在微服务设计过程中，不仅要明确服务拆分的规则，也制定一些服务整合与协同的机制。微服务划分的关注点，主要有功能属性、非功能属性和管理属性三大类。
- 功能属性
- 业务流程：按照应用功能高内聚的原则，相同或相似的业务流程，应该独立作为一个应用考虑。
- 数据对象：对同类数据对象进行管理或操作的应用模块可合并为一个应用。这种不要在不同微服务- - 中独立建模，比如，主数据不应该分散到多个微服务中进行建模。
- 服务对象：同一类业务功能范围内，若多个应用的服务对象相同，在功能边界模糊的情况下，可聚合为一个应用。
- 非功能属性
- 变更频率冲突：某个应用模块如果存在高频变更的需求，可考虑独立作为一个应用。
- 弹性要求：应用是否容易通过调整容量来应对流量变化。
- 性能要求：与弹性要求类似，要求将不同性能要求（请求处理快慢程度）的应用模块分开。
- 可用性要求：与弹性要求类似，将不同可用性要求的应用模块分开。
- 安全要求：将不同安全要求的应用模块分开。
- 合规要求：如果某个应用模块受法律、法规或行业规定的影响，可考虑独立作为一个应用。
- 灾备等级要求：将不同灾备等级的应用模块分开。
- 管理属性
管理属性具体就是指业务领域或组织架构。根据康威定律，管理架构会反应在应用架构中。按照管理架构进行应用划分，可以减少部门沟通成本，提升需求质量，加快应用研发效率。
微服务拆分可以有许多种理由。拆分本身并不是目的，真正的目标是让各个微服务能够更好地协同配合，共同实现业务价值。微服务的拆分和整合有点类似于“微积分”的思想。面对一个复杂的问题，最常用的方法是“拆大为小”，这可以看作是一个“微分”的过程。要注意的是，只是拆分还不够。这些拆分出来的“小部分”之间，还需要能够很好地协同起来，才能以高效、低成本的方式完成整体目标，这个过程，就是“积分”的过程。
微服务整合设计思路
微服务的拆分只是起点，更重要的是后续的整合设计。
- 交互链路维度
上下游应用之间的交互关系，应尽可能形成清晰的单向链路，而不是复杂的网状结构。如果发现交互关系混乱，往往就是微服务拆分不合理导致的。 - 数据完整性维度
在服务整合过程中，应参考业务架构建模阶段的实体关系模型，重点关注以下两种典型情况。
一是一个原本完整的业务实体，因某种业务或技术原因被拆分成多个子实体，并归属于不同的微服务，这种做法容易导致业务语义的割裂。
二是多个关联密切的实体，被拆分到不同应用中。在 DDD 中提到了一个聚合的概念，指的是一个由多个实体和值对象组成的集群，它定义了一个一致性边界，对外作为一个整体被访问和修改。
遇到这两种情况，不建议拆分。因为拆分之后，可能在交易过程中需要完整实体或多个实体的实时协同，这时就会带来数据一致性与可用性之间的冲突，显著增加系统复杂度和运维成本。