Application Architecture Guide 2.0 (Chapter 7: Quality Attributes) Part 5

可重用性

可重用性指的是组件通过很少的改动或不改动即可作为新功能使用在其他组件或方案中的能力。可重用性减小了重复开发组件与系统集成所耗费的时间。识别大量组件之间的通用属性是在系统中开发可重用组件的第一步。

关键问题

l 在系统不同的地方使用不同的代码或组件实现了相同的功能。

l 使用多个相似的方法而不是参数，完成相近的任务。

l 使用多个系统来实现相同的功能。

关键决策

l 如何在多个组件中减少逻辑重复。

l 如何在多个层或子系统中减少逻辑重复。

l 如何重用另一个系统的功能。

l 如何在多个系统中共享功能。

l 如何在一个系统的不同子系统间共享功能。

关键技术

l 检查应用系统的设计，识别并在独立组件中实现验证、日志、授权这些横切功能。

l 检查应用系统的设计，识别并在独立的组件中实现通用的功能，以便于日后重用。

l 考虑组件、层、子系统中需要通过服务接口暴露的功能，以便于其他层或系统使用。

l 考虑使用平台无关的数据类型和数据结构，保证不同平台能够理解和访问。

可伸缩性

可伸缩性是指，当用户数量和数据量增加时，软件系统维护高服务质量的能力。也就是说当系统负载增加的时候系统仍能保持自身可用性、可靠性以及性能。改进系统的可伸缩性有两种方式：纵向伸缩与水平伸缩。单个系统的纵向伸缩是指增加系统的资源如CPU、内存、硬盘容量等等。横向伸缩则意味着为服务或应用投入更多的设备。例如，当业务量较小时，软件系统运行在一台服务器上，当业务量增加时，可以通过增加服务器或增加单服务器上所运行软件系统的个数来提高性能，而无需对软件系统本身进行代码重构级的变更。

关键问题

l 应用系统无法处理负载增加的情况。

l 用户遇到响应延迟和完成任务时间过长。

l 系统故障。

l 系统无法将任务排队，以等待系统负载较低时运行。

关键决策

l 如何基于可伸缩性的考量设计系统的层。

l 应用系统如何扩容。

l 如何调优数据库。

l 如何调整UI。

l 传输与负载的高峰如何处理。

关键技术

l 避免使用降低服务性能的状态组件和子系统。

l 考虑在同一物理层在最大限度地保证负载分担和故障恢复功能的同时，减少所需服务器的数量。

l 考虑使用配置设置来改变应用系统工作方式。这些工作如系统切换到不同的服务，故障转移到另一个系统、访问备用或备份系统。

l 考虑当对现有系统的请求失败若干次后，使用替代系统的实现代码。

l 考虑当监测到当前系统达到一定负载或一定的等待请求数时使用备用系统的实现代码。

l 实现存储/转发或基于消息缓存的通信系统，当系统不可用时，发往系统的请求能够保存下来，在联机时重新处理这些请求。

l 考虑将数据分区存储在多个数据库服务器中，最大程度的提升系统的容积与数据子集位置的灵活性。