软件架构基础 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
主要分为下图的各大类,在此不再展开。
任何架构特征列表必然是不完整的,任何软件都可能根据独特的因素发明重要的架构特征。
权衡架构
由于各种原因,应用程序只能支持列出的几个架构特性:
- 每一个被支持的特性都需要设计上的努力,或许还需要结构上的支持;
- 更大的问题在于,每个架构特性往往会对其他特性产生影响。例如,如果架构师想要提高安全性,几乎肯定会对性能产生负面影响;
因此,架构师很少会遇到这样的情况:他们能够设计一个系统,并将每一个架构特性最大化。更多的情况是,决定要在几个相互竞争的问题之间进行权衡。
过多的架构特性导致设计变得笨重。
**架构师应该努力使架构设计尽可能地迭代。**如果能更容易地对架构进行修改,就可以减少在第一次尝试中就设计出完全正确的东西的压力。敏捷软件开发最重要的经验之一就是迭代的价值,这在软件开发的各个层面都适用,包括架构。
(这本书一直在强调,在软件架构和开发中,快速迭代和敏捷的重要性。)
永远不要追求最佳的架构。
微信公众号
