一个公司决定用软件解决一个特定的问题,公司会收集该系统的需求清单。需求可以说是软件开发的基础,但除了需求以外,架构师有很多因素需要去考虑。

下图在第 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

主要分为下图的各大类,在此不再展开。

任何架构特征列表必然是不完整的,任何软件都可能根据独特的因素发明重要的架构特征。

权衡架构

由于各种原因,应用程序只能支持列出的几个架构特性:

  • 每一个被支持的特性都需要设计上的努力,或许还需要结构上的支持;
  • 更大的问题在于,每个架构特性往往会对其他特性产生影响。例如,如果架构师想要提高安全性,几乎肯定会对性能产生负面影响;

因此,架构师很少会遇到这样的情况:他们能够设计一个系统,并将每一个架构特性最大化。更多的情况是,决定要在几个相互竞争的问题之间进行权衡。

过多的架构特性导致设计变得笨重。

**架构师应该努力使架构设计尽可能地迭代。**如果能更容易地对架构进行修改,就可以减少在第一次尝试中就设计出完全正确的东西的压力。敏捷软件开发最重要的经验之一就是迭代的价值,这在软件开发的各个层面都适用,包括架构。

(这本书一直在强调,在软件架构和开发中,快速迭代和敏捷的重要性。)

永远不要追求最佳的架构。