迁移到事件驱动架构的好处

type

Post

status

Published

date

Nov 18, 2022

slug

eventdriven

summary

之前在搜系统设计的时候，无意看到了 AWS Blog 上的这篇文章，我想着把文章翻译一下，又是学习又是学英语的一种方式吧，本文是翻译 AWS BLOG 上的一篇关于事件驱动的文章

Challenges with request-response architecture「请求响应架构面临的挑战」

When starting to a build a new application, many developers default to a request-response architecture. A request-response architecture may tightly integrate components and those components communicate via synchronous calls. While a request-response approach is often easier to get started with, it can become challenging as your application grows in complexity.

当开始构建一个新的应用，许多的开发者默认使用请求响应架构。请求响应架构可能使得组件耦合紧密，这些组件使用同步调用来通信。通常请求响应架构能更简单地开始，但随着应用变得复杂这个架构可能变得很具有挑战性。

In this post, I review an example request-response ecommerce application and demonstrate the challenges of tightly coupled integrations. Then I show you how building the same application with an event-driven architecture can give you increased scalability, fault tolerance, and developer velocity.

在这篇文章中，我将回顾一个基于请求响应架构的电子交易应用的案例，并演示紧密耦合接入所带来的挑战。之后，我将向你展示如何通过事件驱动架构构建相同的应用，帮助你提高扩展性、分区容错性和开发速度。

Close coordination between microservices 「微服务之间协调」

In a typical ecommerce application that uses a synchronous API, the client makes a request to place an order and the order service sends the request downstream to an invoice service. If successful, the order service responds with a success message or confirmation number.

在一个使用同步API的经典的商业应用中，客户端通过发送请求去创建一个订单，之后订单服务通过发送请求给下游去调用发票服务。如果成功订单服务将响应一个成功的信息或者是确认数字。

In this initial stage, this is a straightforward connection between the two services. The challenge comes when you add more services that integrate with the order service.

在这个初始化阶段，两个服务是直接连接的。如果你将集成更多的服务到订单服务中，你将面临更多的挑战。

If you add a fulfillment service and a forecasting service, the order service has more responsibilities and more complexity. The order service must know how to call each service’s API, from the API call structure to the API’s retry semantics. If there are any backwards incompatible changes to the APIs, the order service team must update them. The system forwards heavy traffic spikes to the order service’s dependency, which may not have the same scaling capabilities. Also, dependent services may transmit errors back up the stack to the client.

如果你增加一个履约服务和预约服务，订单服务将承担更多的职责和变的更复杂。订单服务必须知道每一个服务的 API 的调用结构和重试逻辑。系统将转发大量的请求到订单服务所依赖的其他服务，但这些服务可能不会拥有同样的伸缩性。此外依赖的服务可能将错误传输到客户端。

Error handling and retries 「错误处理与重试」

Now, you add new downstream services for fulfillment and shipping orders to the ecommerce application.

现在，你为这个电子商务应用增加新的下游服务为履约服务和订单发货

In the happy path, everything works as expected: The order service triggers invoicing, payment systems, and updates forecasting. Once payment clears, this triggers the fulfillment and packing of the order, and then informs the shipping service to request tracking information.

如果幸运的话，一切都按照预期工作：订单服务触发发票、支付系统，并更新预测系统。付款完成后，将触发订单履约和包装，之后通知运输服务去请求追踪信息。

However, if the fulfillment center cannot find the product because they are out of stock, then fulfillment might have to alert the invoice service, then reverse the payment or issue a refund. If fulfillment fails, then the system that triggers shipping might fail as well. Forecasting must also be updated to reflect the change. This remediation workflow is all just to address one of the many potential “unhappy paths” that can occur in this API-driven ecommerce application.

然而，如果履约中心因为超出库存找不到这个商品，履约服务可能必须要通知发票服务，之后去扭转付款或者是发起退款。如果履约失败，那么出发运输的系统可能也一样会失败。预测服务也必须更新以反应这些变化。这个修复工作流仅仅是为了解决 API 驱动的电子商务应用中可能发生的许多潜在的“不幸的事情”之一。

Close coordination between development teams 「开发团队间的密切协调」

n a synchronously integrated application, teams must coordinate any new services that are added to the application. This can slow down each development team’s ability to release new features. Imagine your team works on the payment service but you weren’t told that another team added a new rewards service. What now happens when the fulfillment service errors?