【架构】21个软件架构特点解析

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

1性能

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

• 延迟 。表示获得响应之前经过的时间，这里指的是一段时间。我们有最小延迟（开始时间）和 截止日期 （结束时间）。衡量延迟的其他因素包括 优先级（我们在其中查看响应的顺序）和 抖动 （随时间观察到的延迟波动）。

• 吞吐量。是指在固定时间间隔内获得的响应数。但为了提高精度，我们应该度量多个时间间隔。

• 可用容量。以上度量的结合体。在不超出延迟要求的情况下可实现的最大吞吐量。

• 可调度的利用率。利用率是资源繁忙时间的百分比，而可调度的利用率是满足一定时间要求的最大利用率。

• 数据丢失。如果使用缓存来提高性能，那么缓存未命中将成为性能指标。

 提高性能的技术

首先我们要了解影响性能的因素。

• 需求 。我们需要多少资源/p>

• 硬件 。我们需要什么类型的资源如 CPU、内存、I/O 设备、 络等。系统是否运行在正常条件下是在重负载下/p>

• 软件 。我们使用的框架是否是高性能的没有使用缓存否涉及某种反射（java）否做了最大的优化工作/p>

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

可以使用垂直缩放来获得更好的响应时间。提高性能的另一种方法是并发。还需要注意阿姆达尔定律。

MTBF= 平均无故障时间；MTTR= 平均修复时间

于是我们计算出下表：

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

7安全性

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

 增强安全性的技术

首先我们需要检测。

11可测试性

在所有系统中它都是一个重要特征。我们必须确保构建的系统尊重了客户的需求。复杂的系统很难测试。以微服务架构为例，我们有很多独立开发的活动部件。这个特征经常会让步给其他特征。为了使系统可测试，我们需要能控制每个组件的输入和输出。

 改善可测试性的技术

请尽量控制系统的复杂性。我们应该构建较小的组件，不要重新发明轮子；还应该编写可测试的代码，在适当的位置应用 TDD。

12简单性

 改善简单性的技术

可以构建粗粒度的组件；使用 RAD 框架，例如 ApacheIsis、Vaadin 或 JHipster；牺牲简单性之前请确保自己能承受对应的代价；遵循 KISS 原则。记住时间是关键：先跑起来，再考虑美观和性能。

13可移植性

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

 改善可移植性的技术

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

14易用性

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

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

另外还有 可支持性 ，比如说帮助页面或者 24×7 技术支持。我们应该努力让系统直观易用，这会影响可学习性，也就是用户习惯系统所需的时间。用户培训和帮助页面之类的策略很好用。

15可扩展性

它是描述系统对即插即用组件需求程度的特征。对于使用内核架构的系统来说，这是很重要的特征。Eclipse Platform 和 OSGI 标准就是经典的例子。

16抗脆弱性

它是系统应对压力、冲击、波动、噪声、错误、故障或攻击的能力。

 改善合规性的技术

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

19成本

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

 降低成本的技术

帮助客户控制成本是我们的责任。我们需要区分单纯的成本和投资，并让客户相信投资是划算的。

以 Scrum 流程为例，我个人认为它没什么用。在一个固定的周期（通常为两周）中，我们有这么多的仪式（计划、站会、演示、回顾），然后根据（猜出来的）估计值做计算，结果 Sprint 完成度 100％只是偶然而非必然。我们需要敏捷和适应，而不是盲目地遵循流程。我们应该减少会议和仪式，这样成本就会下降。我们应该专注于完成工作的本质要素。

测试是必要的投资，快速前进的唯一方法就是正确前进。我们必须说服客户，从长远来看，成本是会下降的。测试会减少错误的数量，从而减少成本。

代码质量是另一项投资。好的代码将带来更好的测试，提高稳健性、可维护性、可调整性等。与难以维护的系统相比，我们的更改花费的时间会更少，成本会下降。

20可存档性

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

 实现可归档性的技术

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

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

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

【IDEA插件】  EasyCode(代码生成器)

【推荐】Docker 图形化管理工具：Portainer

戳这儿

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92542 人正在系统学习中