软件架构质量评估方案
1 质量属性
在系统设计和开发过程中，我们比较容易关注系统的功能维度，例如有没有实现预期功能，输入参数和输出参数是否匹配等等，这是比较容易衡量的。 但是我们不能就此止步，因为满足功能是系统的基本要求，还需要关注系统的非功能维度，例如系统性能是否优秀，代码可扩展性如何，出现异常是否可以自动降级等等，这些指标决定了系统能否提供高质量的服务。
我之前在文章《结构化思维如何指导技术系统优化》提到了三个质量属性：高性能、高可用、高扩展。本文我们可以充实为六个质量属性：性能、可用性、可修改性、可靠性、安全性、易用性。
1.1 性能
1.1.1 如何定义
性能有两个定义维度：第一个维度是单位时间内可以做多少事情，第二个维度是做完单位数量的事情需要多少时间，常用以下参数进行量化： QPS：每秒处理请求数
TPS：每秒处理事务数
并发数：同一时刻处理请求数/事务数
响应时间：系统对请求做出响应的时间
并发数 = QPS x RT
1.1.2 如何提升
提升性能可以从两个维度思考，第一个维度是时间维度，从事前、事中、事后三个时间节点进行优化。事前是指在访问最开始就拒绝无效流量。事中可以使用提高并发度（并发编程），增加资源（服
务器、分布式缓存、读写分离，分库分表），减少交互（批量请求）等方案。事后是指数据分析需求可以放到离线数据中心进行，不要放在主应用和主数据库进行。
第二个维度是层次维度，每一层都可以进行优化。系统架构一般分为数据层、缓存层、服务层、网关层、客户端、代理层，每一层都可以进行优化，每一层都可以按照事前、事中、事后进行优化，而不是一提到优化就是加缓存，应该更加全面地思考。
1.2 可用性
1.2.1 如何定义
可用性是指系统正常运行时间占总运行时间比例，业界常用X个9指标进行量化，例如可用性达到5个9，那么全年系统不可用时间只有5分钟：
1.2.2 如何提升
(1) 非线性
我们从另一个概念理解可用性：非线性，这个概念在生活中无处不在。
假设要赶早上8点钟的火车，如果6:30出发可以在7:00到达车站，所以得到一个结论：只要30分钟就可以到达车站。
如果早上睡晚一点7:15出发，那么按照预期7:45可以到达车站。但是最可能的结果是错过这趟火车。因为正好遇上早高峰导致至少需要1个小时才能到达车站。
我们再分析一个互联网秒杀场景。假设秒杀系统当每秒30个请求时，响应时间是10毫秒。如果按照线性思维可以做出如下设计：
每秒30个访问量响应时间10毫秒
每秒300个访问量响应时间100毫秒
每秒3000个访问量响应时间1000毫秒
如果按照这个思路做系统设计将会发生重大错误。因为当每秒3000个访问量发生时，响应时间可能不是1000毫秒，而是可能直接导致系统崩溃。系统平台开发评估
这就是非线性，事物不是简单线性叠加关系，当达到某个临
界值时会造成一种截然不同的结果。
(2) 提升策略
冗余 + 自动故障转移
最基本的冗余策略就是主从模式。原理是准备两台机器，部署了同一份代码，在功能层面是相同的，都可以对外提供相同的服务。
一台机器启动提供服务，这就是主服务器。另一台机器启动在一旁待命，不提供服务，随时监听主服务器的状态，这就是从服务器。当发现主服务器出现故障时，从服务器立刻替换主服务器，继续为用户提供服务。
自动故障转移策略是指当主系统发生异常时，应该可以自动探测到异常，并自动切换为备用系统。不应该只依靠人工去切换成，否则故障处理时间会显著增加。
降级策略
当系统遇到无法承受的压力时，选择暂时关闭一些非关键的功能，或者延时提供一些功能，把此刻所有的资源都提供给现在最关键的服务。
在秒杀场景中下订单就是最核心最关键的功能。当系统压力将要到达临界值时，可以暂时先关闭一些非核心功能如查询功能。
还有一种降级策略，当系统依赖的下游服务出现错误，甚至已经完全不可用了，那么此时就不能再调用这个下游服务了，否则可能导致雪崩。所以直接返回兜底方案，把下游服务直接降级。
延时策略
用户下订单成功后就需要进行支付。假设秒杀系统下订单每秒访问量是3000，有没有必要将每秒3000次访问量压力传递给支付服务器？
答案是没有必要。因为用户秒杀成功后可以稍晚付款，例如可以跳转到一个支付页面，提示用户只要在10分钟内支付完成即可。
这样流量就被分摊至几分钟，有效保护了系统。技术架构还可以使用消息队列做缓冲，让下游系统根据处理能力拉取消息。
隔离策略
物理隔离：应用分别部署在不同物理机、不同机房，资源之间不会互相影响。
线程隔离：不同类型的请求进行分类，交给不同的线程池处理，当一类请求出现高耗时和异常，不影响另一类请求访问。
1.3 可修改性
1.3.1 如何定义
可修改性是指是否能够以较高的性价比对系统进行变更的能力，可以分为以下四种类型：
可扩展性：系统扩展新构件时对其它构件的影响程度
可维护性：系统修改旧构件时对其它构件的影响程度
结构重组：重新组织构件关系的难易程度
可移植性：在不同硬件平台、编程语言、操作系统间移植的
难易程度
1.3.2 如何提升
可修改性最终还是在解决牵一发而动全身的复杂性问题，复杂业务之所以复杂，一个重要原因是涉及角或者类型较多，如果平铺直叙地进行设计会出现if-else代码块，可读性和可修改性都很低。
从功能上完全可以实现业务需求，但是程序员不仅要满足功能，还需要思考代码的可维护性。如果新增一种订单类型，或者新增一个订单属性处理逻辑，那么我们就要在上述逻辑中新增代码，如果处理不慎就会影响原有逻辑。
为了避免牵一发而动全身这种情况，设计模式中的开闭原则要求我们面向新增开放，面向修改关闭，我认为这是设计模式中最重要的一条原则。
需求变化通过扩展，而不是通过修改已有代码实现，这样就保证代码稳定性。扩展也不是随意扩展，因为事先定义了算法，扩展也是根据算法扩展，用抽象构建框架，用实现扩展细节。标准意义的二十三种设计模式说到底最终都是在遵循开闭原则。
1.4 可靠性
1.4.1 如何定义
可靠性包括容错性和健壮性，系统面对错误输入仍能保证正确输出的能力，可以分为两种类型：系统可靠性和业务可靠性。
系统可靠性是指面对出现基本错误的输入，系统能够识别和
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议