21 大年夜软件架构特点周全解析_体系_技巧

众所周知，架构特点多以"ility"结尾（例如 scalability、deployability），也被称为 NFR（非功能需求）、质量属性。
架构的特点没有固定清单，但标准是有的，便是 ISO25010：

我们从业务需求（业务特色）、我们期望的系统运营办法（运营特色）中总结出这些特点，它们是隐式的、贯穿各领域，是架构师在字里行间能看出来的特点。
《软件架构根本》书中的这张表是隐蔽特点的一个例子。

《实践中的软件架构》一书中对架构特点阐明得很清楚。

刺激的来源 （Source of Stiumulus）可以是角色、触发事宜的东西等。
刺激 （Stimulus）是实际产生的事宜。
环境（Environment）代表事宜发生的系统条件。
工件 （Artifact）是系统中正在被刺激的部分。
相应 （Response）便是工件在我们该当度量（measure）的刺激下的行为办法。
背景理解完毕，让我们来看详细的特点。

根据 Smith 所说，“性能是指相应能力：相应特定事宜所需的韶光，或给定时间间隔内处理的事宜数”。
性能可以有以下指标：

首先我们要理解影响性能的成分。

我们须要掌握需求，为此我们可以利用行列步队、节流和背压机制。
通过改进算法，我们可以减少资源需求。
通过设置最大相应韶光（超时）和某种优先级，我们可以进一步掌握需求。

可以利用垂直缩放来得到更好的相应韶光。
提高性能的另一种方法是并发。
还须要把稳阿姆达尔定律。

加速效果的瓶颈是程序的串行部分。
例如，如果 95％的代码可以并行化，则并行打算的理论最大加速比将是 20 倍。

限定你的资源、对所有内容（线程、行列步队）履行固定的生产限定、方案资源利用并尽可能避免争用……这些提及来随意马虎，做起来难。
还可以充分利用缓存、水平缩放、添加多个处理单元等。

你该当理解你的框架和你的数据库，并优化它们。

根据《牛津词典》，可靠意味着质量或性能始终如一，且能够被信赖。
可靠性可以用均匀故障间隔韶光（MTBF）来表示，可靠性 =exp（-t/MTBF）。

可靠性很难用数字度量。
我们可以用一些软件指标衡量繁芜度和代码覆盖率，以理解可靠性的边缘情形。
适应度函数也可用于度量可靠性。
未办理问题的数量、成功的构建和支配的数量也是一些可用指标。
ISO-9001 是衡量可靠性的另一种方法。

遵照最佳工程实践将产生更好的产品。
利用更好的管理实践和流程，可以实现更高的可靠性。
突变测试技能会让系统考虑边缘情形。
混沌测试是提高可靠性的另一个主要工具。
总之我们要强化系统来提高可靠性。

表示可用系统韶光与总事情韶光的比率。
这是可靠性之上的另一层。
它是系统粉饰或修复特定阈值（例如韶光间隔）内故障的能力。
可用性可以表示为

MTBF= 均匀无端障韶光；MTTR= 均匀修复韶光

于是我们打算出下表：

提高可用性的技能

为了提升它，首先我们须要检测潜在的故障。

检测到非常情形后，我们可以进行干预。

4. 弹性

弹性指的是系统碰着问题时可以降级（而非中断做事），等待问题修复完成，表示的是系统在碰着严重故障时的持续运行能力。
为实现弹性，须要提前设置防御机制（断路器模式）。
弹性有时被称为容错性 。
弹性系统指的是可以适应压力并持续运行的系统。
很难用数字指标来度量弹性。

首先是确定潜在风险：系统有哪些关键功能？哪些硬件至关主要？然后我们须要履行保护策略，为此须要检讨哪些事宜可能导致这些主要部件发生故障。
找出风险成分后就须要确定容忍阈值。
详细的保护策略包括对要求数和线程数施加限定、缓存相同的要求、批量发送要求等。

它包括可靠性 、可用性 、弹性 、可持续性 （可用性 / 弹性的比值）、可规复性 （弹性函数）和稳健性 （可靠性函数）。
我们该当始终将它们视为一个整体。

拿一辆汽车来说，如果它是新车并且是有名的可靠品牌（例如梅赛德斯），我们可以说它是可靠的。
它有备用轮胎，以是有一些可用性。
四轮驱动意味着弹性，个中两轮出故障还有两轮能事情（但性能会低落）。
可持续性是可用性（备用轮胎）和弹性（四轮驱动）的综合。
健壮性在这里可以指道路通过能力。
如果汽车是电动的，那么充电速率便是一个可规复性指标。

它是系统在重负载下在可接管的阈值内的实行能力。
它分为手动和自动可伸缩性两种，后者也叫灵巧性 。
当负载突增时，系统会做出反应并水平缩放（添加 / 删除更多实例）。
我们可以查看 CPU 和内存来不雅观察这些突发事宜。
这些突发操作完成后，系统将杀去世不必要的实例，从而降落本钱。
垂直伸缩意味着我们向系统添加了更多物理资源（例如更多的内存、更好的 cpu）。

这里涉及到 devops，最好利用 aws fargate 之类的云做事。
下图中可以看到放大和缩小策略。

7. 安全性

它实际上是许多特点的凑集： 机密性是指系统保护用户数据安全的能力； 完全性是保护外部资源免遭修改的能力； 身份验证许可用户访问系统； 授权则见告用户可以访问系统的哪些部分。
授权常日利用 RBAC、ACL 或 ABAC 来实现。
不可否认性担保了的发送者不能否认自己发送了，并且吸收者也不能否认自己吸收了。

首先我们须要检测。

针对攻击行为，我们须要制订灵巧的应对策略。
大多数情形下我们可以撤消访问权限，在某些极度情形下我们可以关闭系统，当然最好还是避免后一种情形涌现。
最好利用成熟的安全办理方案，自行实现每每不是好办法。

它表示系统与外部系统通信的能力。
合约接口是互操作性中最主要的观点，其涵盖了通信的所有方面，包括缺点处理。

最好的策略是利用企业集成模式。
如果用到多个通信协议，这种策略便是最佳方法。

也称为可变性 ，其描述了系统变革的难易程度。
一样平常来说它是一个隐含的特色。
作为架构师，你要知道系统变革的概率是未知的，但一旦涌现变革，系统该当能够优雅地应对。
变革是软件天下中唯一确定的事物。
话虽如此，我们不能将全体系统都设计为可变组件。
如果每个组件都是即插即用组件，设计就做不完了。
因此我们须要找到那些变革概率很高的部分。

有两个维度。
作为一名架构师，你须要确定哪些部分具有较高的变革概率；作为软件工程师，你必须确保这些部分随意马虎改动。
遵照 SOLID 原则是一个很好的开始。
可以利用适应度函数度量传入和传出耦合。
我们须要打算变革本钱。
比如要构建一个 UI 表单，它须要的位置比我们最初想像的要多，则我们可以复制粘贴代码并进行必要的调度，也可以构建一个新组件并插进来。
然后我们得到了变革的本钱：

N x 编写代码的本钱（复制粘贴）<= 编写组件 +（N x 将其插进来的本钱）

还须要考虑韶光，不雅观察较长的韶光才能得到可靠的不雅观察结果。

10. 可支配性

所有系统都应封装在某种工件中，可以是 war、jar、ear、apk、dll、gem 等。
它们被支配在能够运行它们的环境中。
由于 docker 的进化，现在我们可以在一台机器上拥有多个环境。
可支配性是一种将代码转换为客户可用产品的机制。

最有效的是履行持续集成 / 持续支配（CI/CD）。
负责的话，每次代码推送都将触发一个生产支配。
为此，应通过适应度函数和自动化测试来保护你的代码。
它是抗薄弱性的关键部分。
我们希望能按需支配，一键完成事情。
我们也会支配硬件。
利用根本架构即代码之类的技能可以提高效率。

在所有系统中它都是一个主要特色。
我们必须确保构建的系统尊重了客户的需求。
繁芜的系统很难测试。
以微做事架构为例，我们有很多独立开拓的活动部件。
这个特色常常会让步给其他特色。
为了使系统可测试，我们须要能掌握每个组件的输入和输出。

请只管即便掌握系统的繁芜性。
我们该当构建较小的组件，不要重新发明轮子；还该当编写可测试的代码，在适当的位置运用 TDD。

这条特色是很难实现的。
统统都是权衡取舍，而大多数情形下这一条都会被捐躯掉。
但如果我们须要在有限的韶光内快速构建某些东西，那么就该当优先考虑大略性。
在构建 MVP（最小可行产品）时，我们关心的只有大略性。
但请把稳，实现目标之后，我们不应丧失落所有东西。
不要与 PoC（观点验证）或某种 R&D 稠浊。
可重用性在这里也很主要。

可以构建粗粒度的组件；利用 RAD 框架，例如 ApacheIsis、Vaadin 或 JHipster；捐躯大略性之前请确保自己能承受对应的代价；遵照 KISS 原则。
记住韶光是关键：先跑起来，再考虑都雅和性能。

指的是系统从一个操作系统移植到另一个的能力，它会影响编程措辞的选择。
例如，我们知道为了运行 Java 代码须要一个 JVM，因此问题便是“JVM 是否可移植？”答案是肯定的。
另一个例子是 golang：它打包为二进制文件，不须要外部依赖项，因此是可移植的。
一些微软专属技能就弗成，它们只能运行在微软操作系统中。

一个显而易见的选项便是容器化、docker。
一个 docker 引擎能够运行多个隐蔽了实现细节的 docker 容器。

谈到易用性时常日会提到可配置性 ，即用户自定义系统的能力，比如通过 UI 主题变动外不雅观和配置系统行为（例如掌握用户访问权限等）。
还有本地化，也称为 i18n（internationalization）。
它指的是系统支持多种标准的能力，一样平常是通过用户体验（UX）实现的。
这里的标准指的是措辞、货币、公制单位、字符编码等。
本地化资源常日是静态的。

可访问性是另一个易用性特色。
天下上有些人是残疾的（失落明、听力受损、色盲），我们如何确保这些人可以受益于我们的系统呢？对付色盲来说，选择颜色会花很多韶光。
Siri/Alexa 是盲人的好帮手。
考虑可访问性时，请想到我们的祖父母是不是能方便地利用我们的系统。

其余还有可支持性 ，比如说帮助页面或者 24x7 技能支持。
我们该当努力让系统直不雅观易用，这会影响可学习性，也便是用户习气系统所需的韶光。
用户培训和帮助页面之类的策略很好用。

它是描述系统对即插即用组件需求程度的特色。
对付利用内核架构的系统来说，这是很主要的特色。
Eclipse Platform 和 OSGI 标准便是经典的例子。

它是系统应对压力、冲击、颠簸、噪声、缺点、故障或攻击的能力。

改进抗薄弱性的技能

首先我们要敲打敲打系统。
可以利用 CI/CD，它们本来便是做这种事的。
每次代码变动都必须投入生产。
当然，我们也要有防御机制，适应度函数便是个好方法； Simian Army 也是个不错的工具。

它是指系统无缝升级自身的能力。
对付非 Web 产品（例如 App Store 和 Google Play），这很随意马虎实现，由于它们的升级能力是嵌入到 OS 中的；涉及到 Web 运用时，事情就麻烦多了。

首先我们须要为做事供应版本掌握。
下一步是利用蓝绿支配或金丝雀支配等策略进行零停机的韶光支配。

不管我们须要的是哪种第三方工具和框架，都该当得到它们的合法授权。
我们须要重视开源软件的合规性成分，由于它们可能会附带一些我们不想要的额外约束。
没有人乐意暴露自己的源代码，因此我们该当阔别 GPL 容许证。
在欧盟，《GDPR》已成为逼迫规定，因此我们须要确保系统符合其规定。
还要考虑一些 ISO 标准，公司可能须要遵照某些流程才能符合它们的哀求。

空想情形下，每家公司都该当有一个法律部门，但现实并非如此。
适应度函数（例如许可证检讨）可以保护我们免受列入黑名单的容许证的影响。
在设计系统时，我们必须找到一种保护用户数据隐私的方法。

19. 本钱

可能是最主要的架构特点。
统统都有本钱，虚拟的、还是现实的都一样。
任何本钱都可以换算成金钱。
如果我们须要购买某些工具（IDE）、云做事（例如 AWS）、第三方框架（例如 new-relic）的容许证，则总会产生财务本钱。
开拓团队也要发人为，学习新技能或培训团队成员须要费钱。
不尊重敏捷宣言是有代价的；缺点的代码要付出代价；短缺单元测试会有代价；短缺 CI/CD 会有代价；没有根本架构即代码也会有代价……这个列表是没有尽头的。

帮助客户掌握本钱是我们的任务。
我们须要区分纯挚的本钱和投资，并让客户相信投资是划算的。

以 Scrum 流程为例，我个人认为它没什么用。
在一个固定的周期（常日为两周）中，我们有这么多的仪式（操持、站会、演示、回顾），然后根据（猜出来的）估计值做打算，结果 Sprint 完成度 100％只是有时而非一定。
我们须要敏捷温柔应，而不是盲目地遵照流程。
我们该当减少会媾和仪式，这样本钱就会低落。
我们该当专注于完成事情的实质要素。

测试是必要的投资，快速提高的唯一方法便是精确提高。
我们必须说服客户，从长远来看，本钱是会低落的。
测试会减少缺点的数量，从而减少本钱。

代码质量是另一项投资。
好的代码将带来更好的测试，提高稳健性、可掩护性、可调度性等。
与难以掩护的系统比较，我们的变动花费的韶光会更少，本钱会低落。

指系统保留历史数据记录的能力。
在数据是一等公民的系统中（例如财务系统），这个特色非常主要。
数据绝不会删除，而只会归档，这紧张是考虑到法律哀求。
可归档性是对可审计性的支持。

首先是在数据上利用韶光戳（例如 updatedOn、createdOn）。
然后要有一个 cron 作业，将所有低于特定阈值的数据移入历史表中。
另一种技能是将数据标记为软删除，但这会影响查询性能。

这是支持重构历史的系统特色。
我们必须记录所有关键操作（尤其是在安全场景中），以便重现问题并从缺点中学习履历。
我们也可以将这些记录用作法律依据。

记录每个关键操作并集中存放这些记录。
可以利用 ELK ，或 sleuth-zipkin 工具。

英文原文：

https://sergiuoltean.com/2020/06/26/architecture-characteristics/

关注我并转发此篇文章，私信我“领取资料”，即可免费得到InfoQ代价4999元迷你书！