业务架构 序列5 -- 以终为始（非功能性需求分析）

我们知道软件有功能性需求和非功能需求之分。在很早以前，惠普公司的罗伯特·格雷迪（Robert Grady）及卡斯威尔（Caswell）就提出了FURPS需求模型(关于什么是FURPS模型，自己百度之）。

有兴趣朋友也可以进一步关注公众号“架构之道与术”， 获取原文。 或扫描如下二维码：

软件的非功能性需求其实有很多，不同类型的软件，其侧重点也会有差别。同时，随着分布式系统的发展，这方面的理论也在扩充。

本文想通过一些最通俗的表述，来说明我们常用的、关注最多的非功能性需求都有哪些。

并发性
c端的系统，大家首先关注的，就是系统能抗多大的量。说通俗点，可以多少人同时访问。常用的衡量指标就是TPS/QPS, 平均响应时间/最大响应时间，并发数。（关于高并发相关的技术设计，将会在另外一个序列：技术架构中详细讲述）

可用性
从服务角度来说，1个服务不可用，有2层意思：
（1）机器挂了，不能对外提供服务，直接抛错
（2）机器没挂，但是超时。这涉及到“性能”2字。

一致性
比如数据库的参照完整性、事务、缓存与DB数据同步、多备份数据一致性问题。。

大家熟知的CAP里面，C就是这里的一致性，A就是这里的可用性，还有1个P（指的网络出现分区。网络分区其实是不可避免的1个客观存在）。

稳定性/可靠性
稳定性，可靠性，这2个词的界限很模糊，此处也不想去深究这2个词到底有什么本质差别。只是想用直白的语言，说明一下这个词指代什么？

我理解的“稳定性”，指系统没有任何undefined的行为。啥叫undefined？

所有的if-else语句里面，没有不处理的分支；
所有的API调用，每种异常返回值都有处理；
有没有考虑内存、磁盘的上限；
系统不会时不时冒个bug出来；
出了case，有很好的日志监控，能快速修复。
系统的qps，不会有抖动（除非业务有变化，比如大促），是1条平滑的曲线；
发布新版本，回滚方案？
新系统上线，灰度平滑切换？
Monkey Test？ 压力测试？
。。。
可以看出，“稳定性”或者“可靠性”，这个范围非常广，这个也就是我们常说的，“很能反映一个工程师的素养的地方”。

可维护性
跟可维护性密切相关的，是另外一个1个词：“可理解性”，或者说“代码可读性”。

系统架构设计简单，接口简洁，表数据合理？
旧的人离职，新人接手，是否要用很长时间才能搞清楚代码逻辑？

系统功能耦合，改1个地方，牵动全身？

系统某些模块，年久失修，没人能搞清内部逻辑？
。。。

可扩展性
来个新需求，堆1堆新功能，没办法在现有系统上灵活扩展？

很多地方写死的，没有办法灵活配置？

容易变化的逻辑，散落在各个系统里面，很多地方跟着一起改？

可重用性
开发新的需求，旧的功能模块，拿过来可以直接用？
还是要改很多地方，改了半天，发现还不如做个新的？

补充：
对于C端应用来讲，会很关注高并发/高可用，然后有的业务（比如支付），对一致性要求非常高；

对于B端业务，会更关注系统的可维护性、可扩展性、可重用性，有了这些特性，你的系统才能不拖业务后腿，可以快速的支撑各种各样的复杂业务需求的开发。

总结
本文讲这个，主要是想说明做架构的一种“以终为始”的思维方式。先明确落脚点，或者说最终要达到目的（也就是上面这些非功能性需求），再去想要达到这些目的，可以用什么样的技术手段。

相关链接：
《业务架构 – 序列4 – 圈定边界（利益相关者分析）》