软件架构师 第一部分 基础篇 第六章 架构特性的范围

在软件架构领域中，一个普遍的假设就是在传统上将架构特性的范围置于系统级别。 例如，当架构师谈论可伸缩性时，他们通常会围绕整个系统的可伸缩性进行讨论。这是十年前的假设，当时几乎所有系统都是单机的。随着现代工程技术及其它支持的架构样式（例如微服务）的出现，架构特性的范围已大大缩小。随着软件开发生态系统持续不断发展而逐渐过时的一个典型例子。

在《演进式架构》一书的撰写过程中，作者需要一种技术来衡量特定架构风格的架构演变。现有措施均未提供正确的详细程度。在“架构度量”中，我们讨论了各种代码级度量，这些度量允许架构师分析架构的各个方面。但是，所有这些度量标准仅揭示了有关代码的底层细节，无法评估受影响许多架构特性（尤其是 *** 作性）的代码库之外的依赖组件（例如数据库）。例如，无论架构师在设计高性能或d性代码库上花费了多少精力，如果系统使用的数据库与那些特征都不匹配，则该应用程序将不会成功。

在评估许多运行架构特性时，架构师必须考虑代码库之外的会影响这些特性的相关组件。因此，架构师需要另一种方法来测量这些依赖特性。《演进式架构》的作者定义了这个术语“ 架构量子”。要了解架构量子定义，我们必须在这里引出一个关键指标，即共生性。

耦合与共生性

许多代码级耦合度量（例如输入和输出耦合（在“架构度量”中进行了介绍））都以太细粒度的级别揭示了细节，这里不再赘述。1996年，Meilir Page-Jones出版了一本书，标题为“每个程序员都应该了解面向对象设计（Dorset House）”（Dorset House），包括几种新的耦合方法，他将其称为共生性，定义如下：

共生性

如果一个组件的变更需要修改另一个组件以保持系统的整体正确性，则两个组件是相邻的

他定义了两种类型的共生性：静态（可通过静态代码分析发现）和动态（运行时行为）。为了定义架构量子，我们需要一种度量组件如何“连接”在一起的方法，这与共生性概念相对应。例如，如果微服务架构中的两个服务共享某个类的相同类定义，例如address，我们说它们在静态上是相互关联的-更改共享类需要同时更改这两个服务。

对于动态共生性，我们定义了两种类型：同步和异步。两个分布式服务之间的同步调用使调用者等待被调用者的响应。另一方面，异步调用允许事件驱动的架构中的即弃式语义，从而允许两种不同的服务在运行架构中有所不同

架构量子和粒度

组件级耦合并不是将软件绑定在一起的唯一方法。许多经营理念在语义上将系统的各个部分绑定在一起，从而产生功能上的聚合力。为了成功地设计，分析和开发软件，开发人员必须考虑所有可能破坏的耦合点。

许多具有科学知识的开发人员都从物理学中了解量子的概念，即相互作用中涉及的任何物理实体的最小量。“量子”一词源自拉丁语，意思是“多大”或“多少”。我们采用了这个概念来定义架构量子：

架构量子

具有高度功能聚合和同步共生性的可独立部署的工件

此定义包含几个部分，在这里进行了剖析：

可独立部署

一个架构范围包括所有必需的组件，以独立于架构的其他部分起作用。例如，如果应用程序使用数据库，则它是不可或缺的一部分，因为没有它，系统将无法运行。这一要求意味着，实际上，根据定义，使用单个数据库部署的所有旧系统都构成一个整体。但是，在微服务架构样式中，每个服务都包含自己的数据库（微服务中有界上下文驱动原理的一部分，将在第17章中详细介绍），从而在该架构中创建多个量子。

高度功能聚合

组件设计中的内聚性是指所包含的代码在目的上的统一程度。例如，具有与客户实体相关的属性和方法的Customer组件表现出很高的聚合；而具有很多杂项方法的随机集合的Utility组件则不会。

高度功能聚合意味着架构量子可以做一些有目的的事情。在具有单个数据库的传统单机应用程序中，这种区别无关紧要。然而，在微服务架构中，开发者通常设计每个服务匹配单个工作流流程（一个界上下文，如在“领域驱动设计的有界上下文”），因此表现出高度功能性的聚合。

同步共生性

同步共生性意味着在应用程序上下文内或形成此架构范围的分布式服务之间进行同步调用。例如，如果微服务架构中的一项服务同步调用另一项服务，则每种服务在运行架构特性上都不会表现出极大的差异。如果调用者比被调用者具有更大的可伸缩性，则会发生超时和其他可靠性问题。因此，同步调用会在整个调用过程中产生动态共生性-如果一个调用正在等待另一个调用，则它们的运行架构特性在调用持续时间内必须相同。

在第6章中，我们定义了传统耦合度量和共生性之间的关系，其中不包括我们新的沟通共生性度量。我们在图7-1中更新此图。

 

图7-1。在统一图中添加量子共生性

再举一个例子，考虑具有Payment服务和Auction服务的微服务架构。拍卖结束时，Auction服务会向该服务发送付款信息Payment。但是，假设付款服务只能每500毫秒处理一次付款-当大量拍卖一次结束时会发生什么？设计不良的架构将使第一个呼叫继续进行，并使其他呼叫超时。或者，架构师可以设计Payment和之间的异步通信链接Auction，从而允许消息队列临时缓冲差异。在这种情况下，异步共生性将创建更灵活的架构。我们将在第14章中详细讨论该主题。

领域驱动设计的有限上下文

埃里克·埃文斯（Eric Evans）的著作《领域驱动设计》（Addison-Wesley Professional）对现代架构思想产生了深远的影响。领域驱动设计（DDD）是一种建模技术，可以对复杂的问题域进行有组织的分解。DDD定义了有界上下文，其中与领域相关的所有内容在内部都是可见的，但对其他有界上下文是不透明的。在DDD之前，开发人员寻求在组织内的常见实体之间进行整体重用。然而，创建通用的共享工件会导致许多问题，例如耦合，更困难的协调和增加的复杂性。该界上下文的概念承认，每个实体最适合本地化的范围内。因此，代替Customer在整个组织中创建统一的类，每个问题域都可以在集成点创建自己的和协调的差异。

架构量子概念为架构特性提供了新的范围。在现代系统中，架构师在量子级别而不是系统级别定义架构特性。通过将范围缩小到重要的 *** 作问题，架构师可以及早发现架构难题，从而导致混合架构。为了说明由架构量子度量提供的作用域，请考虑另一种架构kataGoing Going Gone。

案例研究：Going, Going, Gone

在第5章中，我们介绍了架构kata的概念。考虑一下这与一家在线拍卖公司有关。这是架构kata的描述：

描述

一家拍卖公司希望将其拍卖网络扩大到全国范围。客户选择参加拍卖，等到拍卖开始，然后像拍卖师在房间里一样竞标。

用户数

每次拍卖最多可扩展至数百名参与者，可能最多可扩展至数千名参与者，并尽可能多地同时拍卖。

要求

-拍卖必须尽可能实时。

-投标人用xyk注册；如果中标者，系统会自动从卡中扣款。

-必须通过信誉指数来跟踪参与者。

-竞标者可以观看拍卖的实时视频流以及发生的所有竞标。

-在线投标和实时投标都必须按照其放置顺序进行接收。

其他背景

-拍卖公司正在通过与较小的竞争对手合并来积极扩张。

-预算不受限制。这是一个战略方向。

-公司刚退出诉讼，就指控欺诈的诉讼达成和解。

就像在“案例研究：硅三明治”中一样，架构师必须考虑以下每一项要求才能确定架构特性：

1.“全国范围的拍卖”，“每次拍卖最多可扩展至数百名参与者，潜在地最多可扩展至数千名参与者，并尽可能多地同时拍卖”，“拍卖必须尽可能实时。”

这些要求中的每一个都暗示着可扩展性以支持庞大的用户和d性来支持拍卖的突发性。当需求明确要求可伸缩性时，d性表示基于问题域的隐式特征。在考虑拍卖时，是否所有用户都在招标过程中有礼貌地散布自己，还是在接近尾声时变得更加疯狂？领域知识对于架构师了解隐式架构特性至关重要。考虑到拍卖的实时性，架构师当然会认为性能是关键的架构特性。

2.“投标人用xyk注册；如果投标人中标，系统会自动从卡中扣除。”““公司刚退出诉讼，它就指控欺诈的诉讼达成和解。”

这两个要求都明确指出安全性是一种架构特性。如第5章所述，安全性实际上是每个应用程序中的隐式架构特性。因此，架构师依赖于架构特性定义的第二部分，它们影响了设计的某些结构方面。建筑师应该设计一些特殊的东西来适应安全性，还是一般的设计和编码卫生就足够了？建筑师开发了通过设计安全处理xyk的技术，而不必构建特殊的结构。例如，只要开发人员确保不要以纯文本形式存储xyk号，在传输过程中进行加密等，那么架构师就不必针对安全性进行特殊考虑。

但是，第二个短语应使架构师停顿并要求进一步澄清。显然，安全性（欺诈）的某些方面过去是一个问题，因此，无论他们设计何种安全性级别，架构师都应要求进一步的投入。

3.“必须通过信誉指数来跟踪参与者。”

该要求提出了一些奇特的名称，例如“

anti-trollability”，但该要求的跟踪部分可能提出了一些架构特性，例如可审计性和可登录性。决定因素又回到了定义的特征-这是否超出了问题领域的范围？架构师必须记住，产生架构特性的分析仅代表设计和实现应用程序的全部工作的一小部分-许多设计工作在此阶段之后进行！在架构定义的这一部分中，架构师会寻找具有结构影响的需求，而该影响尚未被域涵盖。

架构师在确定领域与架构特性之间的关系时，有用的石蕊测试方法是：需要实施领域知识还是抽象的架构特性？在《 Going，Going，Gone kata》中，一位建筑师在遇到“信誉指数”一词时会寻求业务分析师或其他主题专家来解释他们的想法。换句话说，短语“信誉指数”不是像更常见的架构特性那样的标准定义。作为反例，当架构师讨论d性（处理用户突发事件的能力）时，他们可以纯粹抽象地谈论架构特性-他们考虑使用哪种应用程序无关紧要：银行业务，目录站点，流视频，等等。架构师必须确定需求是否尚未包含在领域中，是否需要特定的结构，从而增加了对结构特征的考虑。

4.“拍卖公司正在通过与较小的竞争对手合并来积极扩张。”

尽管此要求可能不会对应用程序设计产生直接影响，但它可能成为在多个选项之间进行权衡的决定因素。例如，架构师必须经常选择诸如集成架构的通信协议之类的细节：如果与新合并的公司的集成不是问题，那么架构师就可以选择针对该问题的高度特定的东西。另一方面，架构师可能会选择一些不完美的东西来适应一些其他的权衡，例如互 *** 作性。 微妙的隐式架构特性（例如这种普遍存在的架构）说明了为什么做好这项工作会带来挑战。

5.“预算不受限制。这是一个战略方向。”

一些架构选项对解决方案施加预算限制，以代表常见的现实世界的权衡。但是，在Going，Going，Gone kata中却没有。这使架构师可以选择更精细和/或特殊用途的架构，这将给下一个需求带来好处。

6.“竞标者可以观看拍卖的实时视频流，并实时查看所有竞标，”“在线竞标和实时竞标都必须按照其放置顺序来接收。”

此要求提出了一个有趣的架构挑战，肯定会影响应用程序的结构，并暴露了将架构特性视为系统范围评估的徒劳。考虑可用性-在整个架构中是否需要统一的？换句话说，一个竞标者的可用性是否比数百个竞标者之一的可用性重要？显然，建筑师希望为这两种方法都采取好的措施，但其中一项显然更为关键：如果拍卖师无法访问该网站，则任何人都无法进行在线竞标。可靠性通常与可用性一起出现。它解决了运行方面的问题，例如正常运行时间，数据完整性以及应用程序可靠性的其他度量。 例如，在拍卖现场，架构师必须确保消息排序可靠，正确，消除了竞争状况和其他问题。

Going，Going，Gone kata中的最后一项要求突出了在架构上比系统级别更细化的范围的需求。使用架构量子度量，架构师可以在量子级别上确定架构特性。例如，在《 Going，Going，Gone》中，架构师会注意到该架构的不同部分需要不同的特征：流式竞标，在线竞标和拍卖人是三个明显的选择。架构师使用架构量子度量作为思考部署，耦合，数据应驻留的位置以及架构内通信方式的一种方式。在此方法中，架构师可以分析每个架构量的不同架构特性，从而在此过程中更早地进行混合架构设计。

因此，对于Going，Going，Gone，我们确定了以下量子和相应的架构特性：

投标人反馈

包含出价的出价流和视频流

-可用性

-可扩展性

-性能

拍卖

现场拍卖师

-可用性

-可靠性

-可扩展性

-d性

-性能

-安全

投标人

网上竞标和竞标

-可靠性

-可用性

-可扩展性

-d性