在IT行业的发展过程中，先有传统行业，再有互联网，传统行业和 互联网是少林与武当的关系，其中的技术相辅相成，互联网技术不一定 比传统行业的技术高深很多，而是各有侧重点。传统行业更偏向于企业 级开发，项目具有业务复杂、流程完善、中心化管理、企业级抽象度高、业务重用率高等特点;而互联网技术则倾向于把复杂的业务拆分成 单一的职责模块，并对各个模块的非功能质量进行大幅度优化，包括高可用性、高性能、可伸缩、可扩展、安全性、稳定性、可维护性、健壮性等。
架构设计与非功能质量
如果我们定义架构设计不是艺术，而是方法论，那么在软件架构方 法论中一般将架构设计分为需求分析和整理、概要设计和详细设计等三个阶段。
- 在需求分析和整理阶段梳理所有用例和场景，并抽象出系统面 向的用户和角色，梳理对于每个用户和角色应该提供的功能需求、非功能质量需求和限制。这里的非功能质量需求包括:高可用性、高性能、 可伸缩、可扩展、安全性、稳定性、健壮性、可测试性等，然后对功能性需求和非功能质量需求进行整理，识别核心需求和特色需求，最后， 以核心需求和特色需求为根本来展开架构设计。
- 在概要设计阶段，根据需求分析和整理阶段产出的核心需求和特色需求，对整个系统进行模块划分，并定义良好的模块之间的关系和交互。
- 在详细设计阶段，通常会使用多视图的方法来描述系统的架构，多视图包括:数据视图、逻辑视图、开发视图、进程视图、物理视图、性能视图、安全视图等。
在互联网时代，软件架构设计使用服务化或者微服务架构对系统进行拆分，拆分后的系统职责单一，每个服务的业务逻辑简单，但是对非 功能质量尤其是性能和容量需求的要求非常高。互联网架构权衡分析方法(Architecture Tradeoff Analysis Method，ATAM)是评价软件构架的 一种综合且全面的方法，它不仅可以揭示架构满足特定质量目标的情况，而且可以使我们更清楚地认识到质量与目标之间的制约和权衡，因为在系统分析阶段，对于一个功能会捕捉多个质量属性，质量属性之间可能是有关联的，还有可能是互斥的，这需要对具体问题进行具体分析。
在生产实践中完成一个系统的构建，就必须满足用户提出的功能需求和非功能质量，例如:生产汽车的厂家在生产汽车的时候，不但需要 汽车能够在路上行驶，还需要评估汽车的性能和油耗等，这对应软件的高性能、可用性、可升级性和安全性等非功能需求。
ATAM是一个能够在项目开始实施之前评估架构是否能够满足这些 非功能质量的方法论。这个方法论通过在架构设计的不同阶段提出不同 的问题，来帮助架构设计人员发现架构设计上的问题，并在实践中总结 出设计的模式，进而可以将这些模式应用到将来更多的项目中。
全面的非功能质量需求
互联网企业会把业务进行水平拆分和垂直拆分，拆分后的服务职责单一、功能简单，可实现快速、敏捷地上线，但是对服务的非功能质量要求较高。这里我们学习具体的非功能质量和针对不同的技术组件需要关注的非功能质量指标。
非功能质量需求的概述
本节讲解核心非功能质量指标，主要体现在高性能、高可用、可伸 缩、可扩展、安全性等方面，并讲解其他非功能质量指标，例如:可测 试性、可监控性等，读者可以通过参考这些质量指标，来保证系统架构 设计满足用户和系统对非功能质量的需求。
核心非功能质量指标如表3-1所示。
这里，对于一个线上服务，
- 高性能通常指单节点服务的吞吐量和响应时间;
- 可用性以全年时间减去当年的宕机时间，并用得到的差值除以全年时间计算得出，通常是表明服务质量的最核心的指标;
- 可伸缩性指横向扩展的能力，也就是随着节点的增加，服务能力能够随着节点增加而线性增加，如果不能，则也可以使用百分比来衡量;
- 可扩展性通常指架构上的灵活性及可插拔性，将来可以不断地在系统上叠加新业务和新功能，
读者一定要区分可伸缩性和可扩展性;安全性指系统的安全保护措施，要防止攻击和数据泄露等。
其他非功能质量指标如表3-2所示。
- 可监控性是非常重要的，一个线上服务如果没有监控系统， 那么系统的可用性就没法保障，监控系统可以帮助开发人员和应急人员 快速发现问题;
- 可测试性指我们开发的服务一定要在不同的阶段有相应 的方法和途径来测试，包括QA测试、准生产测试和生产测试等;对于不具备测试条件的系统使用Mock等方式来解决;
- 鲁棒性表明系统的容错性、健壮性和可恢复性;
- 可维护性指系统要易于监控、运营和扩展;
- 可重用性指系统具有模块化、可移植、可通过迭代增加新功能的特性;
- 易用性指系统对用户友好，方便系统的各类用户使用。
非功能质量需求的具体指标
非功能质量需求的具体指标针对不同的系统主要分为4部分:应用服务器、数据库、缓存和消息队列，本节会总结并列出这4部分指标， 以帮助读者在实际生产实践中做非功能质量需求的设计方案。
应用服务器
应用服务器是服务的入口，请求流量从这里进入系统，数据库、缓存和消息队列的访问量取决于应用服务器的访问量。对应用服务器的访问量进行评估至关重要，应用服务器主要关心每秒请求的峰值及对请求 的响应时间等指标，通过这些指标可以评估我们需要的应用服务器资源 的数量。
部署结构的相关指标如表3-3所示。
容量和性能的相关指标如表3-4所示。
其他相关指标如表3-5所示。
数据库
根据应用层的访问量和访问峰值，计算出需要的数据库资源的吞吐量、每天的数据总量等，由此来评估所需数据库资源的数量和配置、部署结构等。
部署结构的相关指标表3-6所示。
容量和性能的相关指标如表3-7所示。
其他相关指标如表3-8所示。
缓存
根据应用层的访问量和访问峰值，通过评估热数据占比，计算缓存资源的大小并估算缓存资源的峰值，由此来计算所需缓存资源的数量、 部署结构、高可用方案等。
部署结构的相关指标如表3-9所示。
容量和性能的相关指标如表3-10所示。
其他相关指标如表3-11所示。
消息队列
根据应用层的平均访问量和访问峰值，计算出需要消息队列传递的数据量，进而计算出所需的消息队列资源的数量、部署结构、高可用方案等。
部署结构的相关指标如表3-12所示。
容量和性能的相关指标如表3-13所示。
其他相关指标如表3-14所示。
