微服务架构模式语言由多个模式组构成。模式语言的价值超过了其各个模式的总和，因为它定义了模式之间的这些关系：
- Predecessor – Predecessor模式是激发对这种模式的需求的模式。例如，微服务架构模式是模式语言中除单体架构模式之外的其他模式的前身。
- Successor – 解决此模式引入的问题的模式。例如，如果您应用微服务架构模式，则必须应用许多后继模式，包括服务发现模式和断路器模式。
- Alternative – 为该模式提供了替代解决方案的模式。例如，单体架构模式和微服务架构模式是构建应用程序的替代方法。你选一个。这些关系在使用模式语言时提供了宝贵的指导。应用模式会产生问题，然后您必须通过应用后继模式来解决这些问题。模式的选择不断递归，直到您达到没有后继的模式。如果有两种或多种模式可供选择，那么您通常必须只选择一种。在许多方面，这类似于遍历图。
决策#1：单体架构还是微服务架构？
您必须做出的第一个决定是使用单体架构模式还是微服务架构模式。如果您选择微服务架构模式，您必须选择许多其他模式来处理您的决定的后果。
决策#2：如何将应用程序分解为服务？
如果您决定使用微服务架构，则必须定义您的服务。有两个主要方向：
- 按业务能力分解——定义业务能力对应的服务；
- 按子域分解——定义DDD子域对应的服务；
这种模式产生等效的结果：围绕业务概念而非技术概念组织的一组服务。
决策#3：如何保持数据一致性并执行查询？
微服务的一个关键特性是每个服务的数据库模式。作为替代方案，共享数据库模式本质上是一种反模式，最好避免。每个服务的数据库模式极大地改变了您维护数据一致性和执行查询的方式。您将需要使用 Saga 模式。您经常需要使用命令查询职责分离 (CQRS) 模式来实现查询。
留下评论