微服务

在整体架构中，执行复杂的业务交易（例如履行电子商务订单）非常简单。所有数据都驻留在单个关系数据库中，允许开发人员将跨库存、支付和运输的多个数据库写入包装在单个 ACID 事务中。如果任何时候发生错误，SQL ROLLBACK 会立即恢复系统一致性。 然而，现代云原生系统采用微服务架构，其中每个服务都拥有自己的数据并公开不同的 API 边界。在这种分布式范例中，单个端到端业务操作跨越多个独立的微服务和数据库引擎。 由于两阶段提交 (2PC) 协议在云网络中速度缓慢、阻塞且脆弱，因此分布式系统必须异步协调工作流程，同时保持最终一致性。 这使软件架构师做出了一个基本的设计决策：您应该使用编排还是编排来管理分布式微服务工作流程？ 在这份综合指南中，我们将分解这两种架构模式，探索现实世界的类比，分析架构权衡，详细介绍 Go 和 Java 中的生产代码实现，并建立一个框架来为您的基础设施选择正确的模式。 现实世界的类比：快闪族与交响乐团 要为这两种模式建立直观的心理模型，请考虑人类表演者群体如何协调他们的行动： 编舞类比：快闪舞者网络 想象一下一群专业街舞者表演快闪表演。没有教练站在舞台上指着个别舞者指挥他们的下一步动作。相反，每个舞者都会聆听中心音乐，并对旁边舞者的动作做出动态反应。 当舞者 A 完成翻转时，舞者 B 识别出该视觉提示并开始旋转。 当舞者B完成旋转后，舞者C向前迈出一步。 关键特征：去中心化、反应性和自主性。每个参与者都明白自己的责任，无需中央指导。 编排类比：交响乐团 现在想象一下一个由 70 名乐手组成的古典交响乐团。小提琴手、打击乐手和大提琴手不会通过观察舞台上彼此的手来获得暗示。相反，所有人都直视指挥。 指挥向小提琴发出何时演奏软弦的信号。 指挥指向鼓以发出打击乐的信号。 如果音乐家错过节奏，指挥会协调节奏调整或发出暂停信号。 关键特征：集中、明确、命令驱动。一名领导者指导所有参与者。 1.编排架构：去中心化和事件驱动 在编排中，分布式微服务在没有中央主协调器的情况下进行反应式通信。每当服务的内部状态发生变化时，服务都会将域事件发布到异步消息代理（例如 Apache Kafka、RabbitMQ 或 AWS EventBridge）。下游微服务订阅相关事件主题并独立决定下一步采取什么行动。 编排下的电子商务流程 考虑使用编排的电子商务结账流程： 订单服务：接收 HTTP POST 结帐请求，将挂单写入其数据库，并向 Kafka 事件总线发出 OrderCreated 域事件。 支付服务：订阅OrderCreated主题。收到事件后，它会向客户的信用卡收费并发出 PaymentProcessed 事件。 库存服务：订阅 PaymentProcessed 主题。它保留仓库物品并发出 InventoryReserved 事件。 运送服务：订阅InventoryReserved主题。它生成运输标签并发出 OrderShipped 事件。 通知服务：订阅OrderShipped并向客户发送跟踪电子邮件。 编排的优点 高度自治和松耦合：服务不知道下游处理程序的存在。订单服务只知道订单已创建；它并不关心谁使用该信息。 独立的可扩展性和速度：团队可以独立构建、部署和扩展微服务。添加新功能（例如，跟踪销售的分析服务）需要订阅现有事件，而无需修改上游代码。 无单点故障（SPOF）：因为没有中央工作流协调器，所以不相关服务的故障不会导致整个执行引擎瘫痪。 高性能和吞吐量：事件驱动的发布/订阅流异步处理大量事件，没有同步 HTTP/gRPC 阻塞延迟。 编排的缺点 隐式工作流逻辑：没有单个代码位置定义端到端业务流程。了解整个工作流程需要将多个代码库中的事件处理程序拼凑在一起。 循环依赖风险：如果微服务在没有仔细主题设计的情况下发布和订阅重叠主题，则无限事件循环可能会导致系统消息队列崩溃。 复杂的可观测性和分布式跟踪：跨 10 个事件主题跟踪单个订单交易需要强大的分布式跟踪基础设施（例如 OpenTelemetry、Jaeger、W3C Trace Context）。 困难的错误处理和补偿：如果付款成功后库存服务失败，则库存服务必须发出 InventoryFailed 事件。支付服务必须侦听此事件并手动触发退款补偿。 2.编排架构：集中式和命令驱动 在编排中，专用协调器服务（Saga Orchestrator）显式指导执行顺序。 Orchestrator 持有工作流状态机，向工作微服务发送命令请求（通过 gRPC、HTTP REST 或专用命令队列），等待响应并确定下一个执行步骤。