松散耦合系统的高级集成模式和权衡

## 视频 <video src="https://dev-media.amazoncloud.cn/30-LibaiGenerate/31-LiBaiRebrandingVideo/API309-Advanced_integration_patterns___trade_offs_for_loosely_coupled_systems-LBrebrandingWCaptionCN.mp4" class="bytemdVideo" controls="controls"></video> ## 导读 现代应用程序很少孤立存在： 它们暴露应用程序接口、发布事件、调用第三方服务并将状态外部化。由于（通常）由解耦组件组成，此类应用程序必须应对分布式系统的基本挑战，包括无序交付、幂等性或部分故障。在本讲座中，您将了解到分布式系统的常见设计权衡、如何利用设计模式解决这些问题，以及如何在云自动化中嵌入这些模式。 ## 演讲精华 <font color = "grey">以下是小编为您整理的本次演讲的精华，共1400字，阅读时间大约是7分钟。如果您想进一步了解演讲内容或者观看演讲全文，请观看演讲完整视频或者下面的演讲原文。</font> 会议开始时，Dirk和Gregor向观众介绍了自己。Dirk是亚马逊云科技的主要解决方案架构师，而Gregor则是亚马逊云科技的服务工程团队的一员。 据Gregor表示，大约20年前，他曾写过一本关于集成模式和消息传递的书籍。有趣的是，他发现这些书中讨论的很多概念在今天仍具有很高的相关性。他认为，通过研究自然世界，我们可以学习到许多有关软件架构的知识。例如，他提到了格陵兰岛上的一座壮观的巨大石柱结构。就像软件中的巨型单体通常因其组件之间的紧密耦合和缺乏内聚性而出现问题一样，像冰川这样的实体单体在试图随着时间的推移进一步发展和侵蚀时也会遇到结构问题。在这两种情况下，解决方案都是从单体中小心地剥离某些痛苦的服务。对于软件架构而言，这意味着要识别出问题所在并将之提取成单独的服务。最终的结果是一个由集成系统构成的景观，其中一些基于邻近性紧密耦合，而其他一些则更松散地耦合，如同第三方系统。 Gregor解释道，过去，集成被视为在主要系统已经作为独立单体构建之后的一次性努力。然而，在今天的云原生世界中，集成从一开始就是应用程序架构的重要组成部分。在分布式系统中，更新组件和处理集成的节奏是一致的，因为它们可能甚至位于相同的代码库中。他强调，集成和分布式系统之间的区别并非严格的技术层面的，因为它们都涉及到将组件连接在一起。相反，差异在于它们周围的生命周期、控制水平和团队设置。在过去的集成中，团队通常与核心应用程序团队完全分开。但在现代分布式系统中，您可以自己构建组件，这样您拥有全部控制权，并允许团队紧密地一起工作。 德克作为一名建筑师，他热衷于欣赏那些简化复杂性问题并促使人们以清晰思路思考建筑结构的简单图表。尽管一个图表在视觉上可能看似简单，仅由两个盒子组成，但其中却涉及诸多建筑设计决策，例如同步与异步通信、点对点与发布订阅、面向消息与RPC、数据流与控制流、内存中与分布式系统等。建筑师的核心任务便是有意识地做出合适的权衡决策，因为没有任何一种解决方案是完美无缺的。我们的目标是根据特定环境选择能够最小化痛苦并最大化收益的方法。 关于集成概念，格雷戈尔再次强调，集成已不再是事情完成后才需要考虑的问题，而是云计算环境中应用架构的重要组成部分。集成与分布式系统之间的差异并非完全源于技术层面，而是与生命周期、控制和团队结构息息相关。在传统的集成环境中，我们无法控制已集成的系统以进行更改。然而在分布式系统中，我们可以掌控终端，从而降低变化传播带来的问题。他强调，过度的解耦实际上可能会增加复杂性的成本。因此，适当的耦合程度取决于我们对所涉及终端的控制程度。 格雷戈尔解释道，消息队列是一种消除服务间依赖的有效途径。通过这种方式，它们消除了系统间的运行时依赖，因为通信是通过队列间接地进行的。位置和时间的依赖性得以解除，因为系统不再直接互动。将数据封装成消息的形式，而不是依赖于复杂的调用栈或回调函数，也消除了交互方式本身的依赖性。然而，他也提醒我们，解耦并非没有代价。我们需要根据对终端的控制程度来寻找最佳的平衡点。 德克提供了一份关于共享乘车服务架构演变的虚构案例。起初，他们采用了同步API通信，这在整个系统中限制了资源的利用。他们的营销团队发起了一场活动，鼓励客户预订下周的行程，这导致了一个明显的负载高峰。为了解决这个问题，他们转向了异步的202 API，这使得请求能够立即得到确认，而不需要占用额外资源。然而，这种紧耦合的方式仍然存在着风险，可能会导致高负载下系统的稳定性受到影响。为了进一步提高系统的解耦能力，他们将服务进一步分离到了诸如SQS之类的消息队列中，这样系统之间的运行时依赖关系就被消除了。这样一来，消息中的元数据可以在需要时实现请求-响应的相关性。SQS还有助于防止下游出现故障。 格雷戈尔总结道，尽管过去集成一直被忽视，但是云原生系统的演化不可避免地涉及到一系列服务的整合。当你能够控制端点时，相邻服务之间的紧密连接是可以接受的。然而，当你无法完全控制时，比如使用第三方系统时，保持松散的连接通常对灵活性及可扩展性更为有益。 他指出，消息队列具有很好的解耦特性。控制和时机方面的解耦使得在队列的两侧可以独立地控制控制流的变动。这种流量控制能力允许服务按照它们自己的速度消费消息。然而，当到达速率超过了处理速率时，队列需要某种形式的速度控制来避免无界的增长。两种常见的模式包括基于消息的生存时间（Time-to-Live）以及限制新消息到达的反向压力。虽然消息的生存期可能看起来令人担忧，但格雷戈尔表示，最终每件事都有一个截止日期。反向压力并没有内置在队列中，因为队列并不知道消息源。因此，必须手动实施，例如在允许新订单之前检查容量。现实生活中的队列展示了这些队列理论模式在实际应用中的效果。 讨论继续关注消息订购和交付语义，尽管格雷戈里注意到这是一个常被要求的功能，但也存在固有的权衡。采用先进先出(FIFO)队列可以确保消息传递的严格顺序。然而，横向扩展和多个消费者可能会破坏这种保证。为了解决这个问题，消息组可以在发送同一组中的其他消息之前确认现有消息，从而提供每组内的有序交付。这提供了每个组的本地顺序，允许实现比在全球范围内对所有消息的全局顺序更大的横向扩展。对于发布-订阅架构，SNS主题具有简单的订购功能，没有并发消费者。将SNS主题和SQS队列链在一起可以保留端到端的顺序语义。格雷戈里还讨论了消息去重问题，这必须在时间间隔或接收尝试以实用为准进行限制。恰好一次语义在对抗规模和弹性方面存在重大权衡。 迪尔克解释说，错误处理是不可避免的，因此架构应该计划失败并利用诸如SQS死信队列之类的工具。暂时失败可能在状态更改后成功，但由于无效假设或错误，毒药消息将继续失败。将这些移动到死信队列可以避免无尽的重试，并在不影响生产流量的情况下促进调查。然而，大面积的重试逻辑可能会因为干扰在系统中传播而导致级联故障。应实施智能退避和抖动策略。 格雷戈里讨论了如何通过重新处理错误来解决消息存档的问题，因为在消费后，SQS队列消息会被删除。重播消息会产生新的ID，因此应用程序应该包括业务ID以正确地关联事件。消费者也应该设计成可重用的，以处理重播期间的潜在重复消息。 迪尔克提供了一些关于亚马逊云科技服务如何原生集成控制流概念的例子。EventBridge支持用于目标的API目的地，这对它们有限制以避免压倒它们。这需要内部队列来平滑交通。EventBridge管道主动拉取事件，而不是将它们推送，因此它使用批次大小和窗口来控制流量。当瞄准API时，它通过修改实例数量来平衡处理速率。 总的来说，德克强调在建筑决策中总是需要进行权衡，但云计算的可编程性使得能够将诸如流控制、重试和错误处理等元素直接编码到自动化代码中。尽管代码即基础设施已经关注供应、部署和连接性，但应充分利用抽象能力将更深入的建筑模式进行编码化。他还分享了一些改进编程模型的想法，例如使用亚马逊云科技的CDK来更好地在代码中表示架构。 总结一下，关键教训包括：在集成系统时，关注生命周期、控制和团队协作而非技术连接；根据端点需求找到合适的耦合程度；理解解耦的利弊；使用SQS队列分离位置、时间和交互；实施SQS队列流量控制；评估SNS和SQS之间顺序与灵活性之间的权衡；规划失败情况，使用SQS死信队列和重试机制；修复后利用SQS消息存档进行重放；将架构（而不仅仅是基础设施）编码化到自动化过程中；以及探讨如何通过改进编程模型（如亚马逊云科技的CDK）来表达架构。 **下面是一些演讲现场的精彩瞬间：** 格雷戈在探讨他的著作时，强调了设计模式在信息传递和集成方面的应用，这些模式在撰写书籍的20年后仍与当今时代息息相关。  为了应对紧密连接的单体系统所带来的挑战，大自然采用了分割痛苦的方法，从而创造出一种既集成又解耦的系统环境。  在数据迁移、集成和分布式系统之间，关键的区别在于变化的速度以及对各部分控制的程度。  最初的共享服务使用了可能导致高负载下稳定性受到威胁的同步API通信，因此它们逐渐演变成了采用异步事件驱动架构的形式。  EventBridge中的API目的地具有防止下游API淹没的速率限制功能。  在工作流程中，有一个步骤会检查队列是否具有可用容量，如果没有，它将报告“抱歉，现在无法下单咖啡”，这是从现实生活中咖啡馆的例子中学到的响应压力方法。  领导者们鼓励观众们参观意式咖啡摊位，以免费获取咖啡并了解服务架构的基本概念。  ## 总结 演讲者探讨了高级集成模式及松散耦合系统的利弊。他们认为，耦合并非非此即彼的选择，而是存在不同程度的灰色地带，因此架构师需根据具体情况找到合适的平衡点。通过反转控制流程，队列有助于降低系统间的耦合程度。然而，队列仍需利用诸如生存时间或反向压力等技术来防止溢出，这些技术对于流量控制至关重要。此外，控制流程的设计也至关重要——它可能不同于数据流，并且会影响错误处理。顺序语义相对于特定范围（例如消息组）具有相对性。实现精确的一次性交付相当困难；重复数据消除也具有局限性。故障在所难免，因此应考虑进行重试、回退和设置死信队列等措施。采用像亚马逊云科技CDK这样的自动化工具至关重要，因为它们将架构决策（如控制流程、错误处理等）编码化。演讲者建议我们在耦合度、精心管理流量控制、自动化架构决策以及应对故障等方面寻求平衡。 ## 演讲原文 ## 想了解更多精彩完整内容吗？立即访问re:Invent 官网中文网站！ [2023亚马逊云科技re:Invent全球大会 - 官方网站](https://webinar.amazoncloud.cn/reInvent2023/?s=8739&smid=19458 "2023亚马逊云科技re:Invent全球大会 - 官方网站") [点击此处](https://aws.amazon.com/cn/new/?trk=6dd7cc20-6afa-4abf-9359-2d6976ff9600&trk=cndc-detail "点击此处")，一键获取亚马逊云科技全球最新产品/服务资讯！ [点击此处](https://www.amazonaws.cn/new/?trk=2ab098aa-0793-48b1-85e6-a9d261bd8cd4&trk=cndc-detail "点击此处")，一键获取亚马逊云科技中国区最新产品/服务资讯！ ## 即刻注册亚马逊云科技账户，开启云端之旅！ [【免费】亚马逊云科技“100 余种核心云服务产品免费试用”](https://aws.amazon.com/cn/campaigns/freecenter/?trk=f079813d-3a13-4a50-b67b-e31d930f36a4&sc_channel=el&trk=cndc-detail "【免费】亚马逊云科技“100 余种核心云服务产品免费试用“") [【免费】亚马逊云科技中国区“40 余种核心云服务产品免费试用”](https://www.amazonaws.cn/campaign/CloudService/?trk=2cdb6245-f491-42bc-b931-c1693fe92be1&sc_channel=el&trk=cndc-detail "【免费】亚马逊云科技中国区“40 余种核心云服务产品免费试用“")