软件架构基础 4: 你的架构需要考虑的架构特性
文章目录
一个公司决定用软件解决一个特定的问题，公司会收集该系统的需求清单。需求可以说是软件开发的基础，但除了需求以外，架构师有很多因素需要去考虑。
下图在第 1 章出现过：
架构师可能会参与收集需求，但架构师一个关键的职责是要发现、定义其它和具体需求没有直接关系的东西，这些东西称之为架构特性（architectural characteristics）。
一个架构特性满足三个标准：
- 指定了一个非领域（业务）设计的考虑因素：例如，一个重要的架构特性是应用程序的性能水平，而这一点往往不会出现在需求文档中；
- 影响结构上的设计：这个架构特性是否需要特殊的结构才能成功？例如，考虑要支持支付功能的系统，可以选择第三方支付（只需要符合安全即可嵌入），还是应用自己处理支付（这需要设计特定的支付模块），这将导致不同的架构设计；
- 对应用的成功至关重要：应用程序可以支持大量的架构特性，但每个架构特性的支持都会增加设计的复杂性，因此，架构师的一项工作是选择最少的架构特性；
架构特性主要分为显性的和隐性的。
隐性的很少出现在需求中，但它们却是项目成功的必要条件。例如，可用性、可靠性和安全性几乎是所有应用的基础，然而它们很少在设计文档中被提及。
架构师必须在分析阶段利用他们的知识来发现这些架构特性。
架构特性列表
架构特性存在于软件系统的广泛范围内，从代码特性如模块化，到复杂的问题如可扩展性和弹性。由于软件生态系统变化如此之快，新的概念、术语、措施和验证不断出现，并不存在真正的标准。但是架构师通常将架构特性分为下面几大类：
运行架构特性
运行架构特性涵盖了性能、可扩展性、弹性、可用性和可靠性等能力。
| 类型 | 定义 |
|---|---|
| 可用性(Availability) | 系统可用时间，如果是24/7，则需要使系统在发生任何故障时能够迅速启动和运行 |
| 持续性(Continuity) | 灾难恢复能力 |
| 性能(Performance) | 包括压力测试、峰值分析、分析功能的使用频率、所需容量和响应时间。性能报告有时需要自行演练，需要几个月才能完成。 |
| 可恢复性(Recoverability) | 业务持续性要求(例如，在发生灾难的情况下，系统需要多快才能重新上线？)。这将影响备份策略和对冗余硬件的要求 |
| 可靠性/安全性(Reliability/safety) | 评估系统是否需要具备某些安全功能，如果发生故障，是否会给公司带来大笔资金损失？ |
| 稳健性(Robustness) | 在网络连接中断、断电或硬件故障时，系统是否能够处理运行中的错误和边界条件 |
| 可扩展性(Scalability) | 随着用户或请求数量的增加，系统执行和运行的能力 |
结构架构特性
架构师也必须关注代码结构。在许多情况下，架构师对代码质量问题负有单独或共同的责任，如良好的模块化、组件之间的可控耦合、可读的代码以及一系列其他内部质量评估。
| 类型 | 定义 |
|---|---|
| 可配置性(Configurability) | 能够轻松地变更软件配置 |
| 可扩展性(Extensibility) | 添加新的功能是多么的重要 |
| 可安装性(Installability) | 易于在所有必要的平台上安装 |
| 可利用性/重复使用(Leverageability/reuse) | 能够重复利用通用组件 |
| 本地化(Localization) | 在文字输入、显示上支持多种语言；在报表、计量单位、货币上支持各种字符 |
| 可维护性(Maintainability) | 如何轻松地进行应用变更和系统维护 |
| 可移植性(Portability) | 系统是否需要运行在超过一个平台上 |
| 支持性(Supportability) | 应用程序需要什么级别的技术支持？需要什么级别的日志和其他设施来调试系统中的错误？ |
| 可升级性(Upgradeability) | 能够在服务器和客户端上轻松、快速地升级 |
交叉架构特性
许多特征不在分类范围内或无法分类，却形成了重要的设计限制和考虑因素。
| 类型 | 定义 |
|---|---|
| 可访问性(Accessibility) | 让您的所有用户，包括色盲或听障等残疾用户都能访问(例如 Iphone 就有类似的支持) |
| 归档性(Archivability) | 数据是否需要在一段时间后归档或删除？例如，客户账户在三个月后要删除或标记为过时，并归档到二级数据库，以便将来访问。 |
| 认证(Authentication) | 安全要求，确保用户就是那个人。 |
| 权限(Authorization) | 安全性要求，以确保用户只能访问应用程序中的某些功能 |
| 法律要求(Legal) | 系统在什么法律约束下运行(数据保护、萨班斯法案、GDPR 等)？公司需要哪些保留权限？关于应用程序的构建或部署方式有什么规定？ |
| 隐私(Privacy) | 能够对公司内部员工隐藏交易(加密的交易即使是 DBA 和网络架构师也无法看到) |
| 安全性(Security) | 数据库中的数据是否需要加密？内部系统之间的网络通信是否需要加密？远程用户访问时需要进行哪种类型的认证？ |
| 可用性/可实现性(Usability/achievability) | 你的用户使用应用程序需要的培训程度，是否易用？。需要像对待其他架构问题一样认真对待可用性要求。 |
其它架构特性
ISO 也发布过软件质量的列表，参见：https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
主要分为下图的各大类，在此不再展开。
任何架构特征列表必然是不完整的，任何软件都可能根据独特的因素发明重要的架构特征。
权衡架构
由于各种原因，应用程序只能支持列出的几个架构特性：
- 每一个被支持的特性都需要设计上的努力，或许还需要结构上的支持；
- 更大的问题在于，每个架构特性往往会对其他特性产生影响。例如，如果架构师想要提高安全性，几乎肯定会对性能产生负面影响；
因此，架构师很少会遇到这样的情况：他们能够设计一个系统，并将每一个架构特性最大化。更多的情况是，决定要在几个相互竞争的问题之间进行权衡。
过多的架构特性导致设计变得笨重。
**架构师应该努力使架构设计尽可能地迭代。**如果能更容易地对架构进行修改，就可以减少在第一次尝试中就设计出完全正确的东西的压力。敏捷软件开发最重要的经验之一就是迭代的价值，这在软件开发的各个层面都适用，包括架构。
（这本书一直在强调，在软件架构和开发中，快速迭代和敏捷的重要性。）
永远不要追求最佳的架构。
微信公众号
