应用微服务架构模式语言

微服务架构模式语言包含了许多组模式。模式语言的值超出了它的各个模式的总和，因为它定义了模式之间的这些关系：
Predecessor - Predecessor模式是一种激励自身模式需求的模式。例如，微服务架构模式是除了单体架构模式之外的模式语言中其余模式的predecessor。
Successor - 解决由此模式引入的问题的模式。例如，如果您应用微服务架构模式，则必须应用许多successor模式，包括服务发现模式和断路器模式。
Alternative - 提供这种模式的替代解决方案的模式。例如，单体架构模式和微服务架构模式是构建应用程序的可选方法。你选择一个或另一个。这些关系在使用模式语言时提供有价值的指导。应用一种模式会产生您必须通过应用successor模式来解决的问题。模式的选择不断递归，直到你达到没有successor的模式。如果两个或多个模式是替代方案，则通常只能选择一个。在许多方面，这与遍历图类似。
我们来看看如何应用微服务架构模式语言来构建你的应用程序。在这篇文章中，我们将看看你必须做出的3个关键决定。在后来的帖子中，我们将看看其他重要的，虽然不是那么重要的模式。

决策#1:单体架构或微服务架构？
您必须做出的第一个决定是使用单体架构模式还是使用微服务架构模式。如果您选择微服务架构模式，您必须选择许多其他模式来处理您所做决定带来的后果。



您可以看到，您还必须应用许多其他模式。让我们看看你必须做的几个选择。

决策#2:如何将应用程序分解成服务？
如果您决定使用微服务架构，您必须定义您的服务。有两个主要选择，

按业务能力进行分解 -定义与业务能力相对应的服务
通过子域分解 -定义与DDD子域相对应的服务

这种模式产生的结果：服务围绕业务概念而不是技术概念进行组织。

决策#3：如何维护数据一致性并执行查询？
微服务的一个关键特征是每个服务单独数据库模式。这是可选方案，共享数据库模式本质上是一种反模式，最好避免。每个服务单独数据库模式的数据库极大地改变了如何维护数据一致性并执行查询。您将需要使用Saga模式。您将经常需要使用命令查询责任分隔（CQRS）模式来实现查询。
To becontinued….