软件架构：核心挑战

第 2 章 辨析软件架构中的耦合

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

Wednesday, November 3, 13:00

Penultimate电子公司的首席架构师洛根打断了正在自助餐厅讨论分布式架构的一小群架构师。"奥斯汀，你又打石膏了？"

"不，只是个夹板，"奥斯汀回答道。"我周末打极限飞碟高尔夫时扭伤了手腕，现在差不多痊愈了。"

"什么......算了。我闯入的这场慷慨激昂的谈话是怎么回事？"

"为什么有人不总是选择微服务中的传奇模式来连接事务呢？"Austen 问。"这样，架构师就可以随心所欲地把服务做得很小。"

"Addison 问："但是，在传奇中不需要使用协调吗？"那我们需要异步通信的时候怎么办？而且，事务会变得多么复杂？如果我们把事情分解得太多，真的能保证数据的保真度吗？"

"你知道，"奥斯汀说，"如果我们使用企业服务总线，就能让它为我们管理大部分这些东西。"

"我以为已经没人用 ESB 了--我们不是应该用 Kafka 来做这样的事情吗？"

"它们根本不是一回事！"奥斯汀说。

洛根打断了越来越激烈的对话。"这是一种苹果与苹果之间的比较，但这些工具或方法都不是灵丹妙药。像微服务这样的分布式架构是很困难的，尤其是当架构师无法解开所有作用力的时候。我们需要的是一种方法或框架，帮助我们找出架构中的难题。

"艾迪森说，"无论我们做什么，都必须尽可能地解耦--我读过的所有书都说，建筑师应该尽可能地接受解耦。

"洛根说："如果你遵循这个建议，所有的东西都会被解耦，没有任何东西可以与其他任何东西通信--这样很难构建软件！像很多事情一样，耦合本质上并不是坏事；架构师只需要知道如何恰当地运用它。事实上，我记得一位哲学家说过这样一句名言...."

万物皆毒，无毒不丈夫。

帕拉塞尔苏斯

架构师将面临的最困难任务之一就是理清分布式架构中的各种力量和权衡。提供建议的人不断鼓吹 "松耦合 "系统的好处，但架构师如何才能设计出没有任何东西连接到其他任何东西的系统呢？架构师设计细粒度的微服务来实现解耦，但这样一来，协调、事务性和异步性就成了大问题。一般的建议都说 "解耦"，但却没有提供如何在构建有用系统的同时实现这一目标的指南。

建筑师们在粒度和通信决策方面苦苦挣扎，因为没有明确的通用决策指南，也没有适用于现实世界复杂系统的最佳实践。直到现在，建筑师还缺乏正确的视角和术语，无法进行仔细分析，从而根据具体情况确定最佳（或最差）的权衡方案。

为什么架构师一直在为分布式架构的决策而苦恼？毕竟，我们从上个世纪就开始构建分布式系统，并使用了许多相同的机制（消息队列、事件等）。为什么微服务的复杂性会如此之高？

答案在于微服务的基本理念，其灵感来源于有界上下文的思想。要构建以有界上下文为模型的服务，就需要对架构师设计分布式系统的方式进行微妙但重要的改变，因为现在事务性已成为一流的架构关注点。在微服务之前架构师设计的许多分布式系统中，事件处理程序通常连接到单个关系数据库，使其能够处理完整性和事务等细节。将数据库移入服务边界后，数据问题变成了架构问题。

正如我们之前所说，"软件架构 "是谷歌搜索不到答案的东西。现代架构师必须掌握的一项技能是权衡分析能力。虽然几十年来已经有了一些框架（如架构权衡分析方法，或ATAM），但它们缺乏对架构师日常面临的实际问题的关注。

本书的重点是，建筑师如何根据自己的实际情况，对各种方案进行权衡分析。正如建筑设计中的许多事情一样，建议很简单；难点在于细节，特别是难点如何纠缠在一起，使人难以看清和理解各个部分， ...