5、微服务设计模式全解析

微服务设计模式全解析

1. 微服务设计模式概述

微服务架构虽然具有诸多优势，但也面临一些挑战。在单体应用中，只需处理一个应用的部署，而在微服务架构里，根据应用规模，可能有数百个服务承担相同的工作。为有效利用这种架构风格，我们需要探讨相关的设计模式。微服务设计模式根据其处理工作的性质分为不同类别。

2. 分解模式

当将单体应用转换为微服务架构，或使用微服务架构编写新应用时，最大的挑战是如何将应用划分为微服务。这需要遵循特定策略，将应用功能逻辑隔离为自主服务，并定义数据访问和通信策略。以下是几种常见的分解模式：

2.1 按业务能力分解

此策略依据应用的业务能力将单体应用拆分为自主微服务。业务能力是企业为创造价值而开展的活动。以信用卡应用为例，信用卡产品营销、开户、激活和生成账单等都是业务能力的体现。

随着时间推移，业务开展方式可能改变，但核心业务能力变化不大。按业务能力分解应用，能与当前业务运作方式保持一致，业务用户几乎感受不到变化。

要按业务能力分解应用，需要一个了解组织不同业务单元的团队，以及熟悉所有业务能力、能协助分解应用的主题专家。

不过，在确定微服务时要格外谨慎。例如，将创建客户视为业务能力并创建相应服务是不正确的，因为我们的业务是为客户提供信用卡，创建客户只是支持业务能力的服务。

这种分解方式有优点也有缺点：
|优点|缺点|
|----|----|
|若业务能力相对稳定，可创建稳定的微服务架构|应用架构与业务模型紧密耦合|
|架构中的组件会随业务变化而演进，但架构本身保持不变|业务流程中的异常会反映在目标架