拥抱终一致性，以及基础设施的自动化

虽然遵循这些原则可以避免早期采用者和DIY者所遭受的痛苦，但将它们合并到体系结构中的复杂性扩大了对实践和设计模式的需求，尤其是随着实现扩展到数百个微服务时，迅速成为微服务体系结构的主要组成部分，值得讨论如何简化设计模式的实现-例如有限上下文，异步消息传递，成功实施的原则如何支持微服务体系结构采用的主要驱动力-包括缩短上市时间和近成为云原生，我们将在整个本文的基础上进行构建，因此，如果您需要复习，更喜欢音频版本或微服务新手。

设计模式可以地可视化，因此让我们从图开始吧

我们将把事件驱动的付款处理工作流的样机分解为许多嵌入式设计模式，我们将讨论每种模式解决的挑战，以及如何使用简化其实现，由于某些模式是实施其他模式的基础，因此我们将按一定顺序进行介绍，以使它们能够相互构建，设计模式：受限上下文->域驱动设计我们的个挑战是从逻辑上将业务划分为多个微子域，以便每个人都可以由一个授权的小型自治团队提供支持。每个子域的范围应受其团队管理其支持的微服务生命周期的能力的约束-从开始到后期制作。这种从临时项目到自主域所有权的转变激发了对微服务设计各个方面的责任感，并赋予了敏捷的决策能力-从而缩短了产品上市时间。

考虑一下前缀“微”，这暗示了在有限的业务子域中支持微服务的整个生命周期所需的团队规模

在我们的模型体系结构的上下文中，让我们从付款处理域开始，开始组织设计过程，该域包括欺诈检测，付款，结算等。由于这个范围对于一个小型团队来说可能太复杂了，因此，我们选择将其所有权范围缩小到欺诈检测子域。

欺诈检测由工作流的前三个微服务组成-包括数字身份

统计分析和基于AI的交易风险评分，由于他们的范围可能仍然太小而无法管理，因此让我们将欺诈检测进一步分为两个子域-终看起来更易于管理，在非常高的层次上，我们刚刚遵循的过程称为域驱动设计，该过程受推荐的模式支持，现代企业依赖实时数据的力量，企业可以高度可靠且可扩展的方式提供即时体验。

每个微服务都有其自己的专用数据库以进行隔离

概率欺诈检测检查点微服务，同时拥有紫色边界上下文的另一个团队实时支持“交易风险评分”尽管每个微服务都需要自己的数据模型来处理其独特的数据访问模式，使其不必评估，内置，管理和管理三个不同的数据库，他们可以在单个多租户群集中部署所有三个数据库，而无需考虑其发布周期。

设计模式：异步消息传递->服务间通信

既然我们已经为每个微服务确定了一个有限的上下文和数据模型，那么下一个挑战就是在不破坏对隔离的合规性的情况下实现它们之间的通信。这可以通过拥抱终的一致性来解决，后者假定服务间通信的接收端上的微服务在出站传输期间将不可用，但是，一旦恢复可用性，便可以使用该消息，服务间通信的推荐模式是使用发布-订阅消息代理作为其事件分发中心的异步消息传递，在这种模式下，生产者可以发布事件，而不必了解是否有任何消费者在收听，并且（以相同的方式）该事件的消费者可以在方便时对其做出反应或完全忽略它。这通常是事件驱动架构的基础。

由于我们已经选择作为多个微服务的主要数据库

因此我们可以通过来实现此模式，从而简化架构，不可变的按时间排序的日志数据结构，它允许生产者将异步消息发布到多个订阅的使用者，这确保了发布事件的微服务将与使用它们的微服务保持脱钩状态，因此不会对可用性和发布周期产生交叉依赖，可以配置为处理不同的交付保证，支持消费者群体以及本质上类似于其他细微差别-也是跨微服务架构的主要内容。

设计模式：基于编排的传奇->分布式事务

现在，我们已经启用了服务间通信，接下来的挑战是处理跨越多个有界上下文的事务，而又不会破坏对隔离的合规性，一旦数据跨多个数据库分布，两阶段提交协议就成为分布式事务的标准。但是，尽管这两种方法都可行，但在设计时并没有考虑到终的一致性，如果我们假设在分布式事务期间将不存在依赖项，那么我们还应该假设频繁的回滚将导致整个系统的零星不可用性—这既不是云本机，也不是缩短产品上市时间。

设计模式：事务发件箱和消息中继->一致性

既然我们已经设计了跨越多个有界上下文的事务，那么我们的下一个挑战是减轻微服务的数据库和消息代理之间的不一致风险，回想一下，在前两种设计模式中，每个微服务都在本地提交到其数据库，然后发布了一个事件，如果使用双写模式的某些变体来实现此目的，则通信可能会丢失并且分布式事务可能会变得孤立（尤其是在云环境中），可以将代码复杂性添加到每个微服务中，以处理各种失败和不一致的情况，但是请考虑将这种工作累加到数百个团队中，并考虑不正确实施的风险-所有这些都不会增加业务价值。

为了避免各种应用程序级别实现的风险和成本

建议的模式是事务发件箱和消息重播，简化并支持这两种模式的组合实现，辅助线程可以侦听更改的数据事件，按时间顺序持久地存储它们，并在可用时将其发布到消息代理，数据库上统一启用或升级此功能，设计模式：遥测->可观察性现在，我们已经减轻了主数据库和辅助数据平台之间不一致的风险，我们的下一个挑战是衡量整个体系结构及其支持的业务交易中微服务的运行状况，即可观察性。

观测是充满了数以百计的分布式系统中的一个必须具备的孤立和终一致的部件

可观察性建立在三大支柱上：指标，日志记录和可追溯性。我们将首先关注指标，这些指标通常存储在时间序列数据模型中，该数据模型可以处理大量按时间顺序排列的事件和时间点查询。地，可以实时跟踪指标，以便可以检测到SLA / SLO异常，并在发生异常时可以缓解这些异常，为了观察分布式系统的运行状况，我们首先需要它的数据。推荐的模式是遥测，它是从远程源自动收集和传输数据以进行监视。

设计模式：事件源->审核和重播

既然我们已经对度量标准数据实施了遥测，那么我们的下一个挑战是启用可观察性的其余支柱-日志记录和可追溯性，与指标不同，时间序列数据模型将无法使日志的固有属性受益，因为它们无法汇总或缩减采样，相反它们需要一个不可变且按时间排序的数据结构，该结构可用于按事件发生的顺序审核，恢复或重放事件链。

由于微服务需要隔离，因此它们不能依赖共享来维护捕获整体中所有事件的事务日志

因此推荐的模式是事件源，它在微服务数据库级别的不可变且按时间排序的日志中记录每个更改的数据事件，这种模式在大多数事件驱动的体系结构中很常见，通常使用消息代理和事件存储来实现事件源，许外部进程作为隔离的消费者组订阅其事件流，从而超出单个微服务的范围来简化事件源。这允许在业务流程，域甚至架构级别进行观察，例如工作流仲裁器或系统范围的分析平台。

微服务架构可以改变游戏规则，从而击败市场竞争者并减少组织云迁移的障碍

随着数字化转型的顺利进行，作为云原生微服务的重新平台的动力只会越来越大，但是就像生活中的一切一样，微服务也需要权衡。幸运的是，早期采用者和思想在实践设计模式上存在的陷阱已得到充分记录。尽管本文只是从容应对挑战，但我希望它能使读者识别曾经出现混乱的模式。

商业联合会数据分析专业委员会