本文探讨如下几个问题：

• 什么是架构属性
• 约束和架构属性的关系
• 有哪些架构属性
• 各个架构属性涉及知识点

什么是架构属性

首先，问个很简单的问题！请看下面的Java代码：

class Person {
    private String name;
    private int age;

    public void skill() {
        ......
    }
}

请问上面的代码中:

• name和age被称为Person这个类的什么？
• skill又称为Person这个类的什么呢？

name和age一般被称为字段、成员变量或属性；skill一般被称为方法，表示Person所具有的功能！

我们稍微修改下代码：

class Architecture {
    private String safe;
    private String performance;

    public void func() {
        ......
    }
}

safe(安全性)和performance(性能)就是Architecture(架构)的属性！func就是架构所具有的功能！

架构属性一般又称为质量属性！

这些架构属性和架构功能是从哪来的呢？

在什么是软件架构中提到过约束包含：功能性约束（这个系统要完成的功能）、非功能性约束（可用性、扩展性、容错性等）、其它约束（人员技能、法律法规、公司规定等）

实际上，架构属性和架构功能是从约束而来:

• 对「功能性约束」的决策结果就是架构功能
• 对「非功能性约束」的决策结果就是架构属性
• 而对「其它约束」的决策可能会同时影响到架构功能和架构属性

给架构属性和架构功能下个定义：

• 架构属性是对「非功能约束」决策后，架构所具有的特征，且受到一些其它约束的影响
• 架构功能是对「功能约束」决策后，架构所具有的功能，且受到一些其它约束的影响

以在线教育系统为例，来说明一下：

• 这个系统需要具有在线直播的功能，完成这个功能约束后，系统即有了在线直播这个架构功能
• 这个系统需要4个9的可用性，如果这个系统达到了这个非功能性约束，系统即有了高可用的架构属性
• 法律法规规定，现在直播需要有《信息网络传播视听节目许可证》或《广播电视节目制作经营许可证》，如果你没有，那么你的系统就没法进行直播也就没有了直播这个功能；而如果人员技能不达标或者某些突发情况，那可能导致系统就不具备高可用这个属性，号称「能同时支持8位明星同时出轨的微博」，不是又挂了吗？

架构属性

架构属性一般包括如下方面：性能，伸缩性，可用性，安全性，容错性，灾难恢复，可访问性，可运维，管理，灵活性，可扩展性，可维护性，国际化，本地化。还有法律法规，成本，人员等对上面架构属性的影响。下面分别讨论（由于涉及的内容很多，这里只是一个概要，详细内容后续慢慢讨论）。

性能

我们经常挂在嘴边的优化，绝大部分情况下指的是「性能优化」。「性能优化」的目的就是提高系统响应速度。而优化的原因就是系统响应速度不够快。

一般认为，一个网页打开速度超过3s，用户就开始没有耐心了；如果超过5s，用户就要打算放弃访问了；而如果超过10s以上用户还没关闭，这个网站不是12306就是查分网站。

上面指的「响应速度」主要分为系统性能和用户感知性能。这两者的区别是：

• 系统性能指系统自身的响应，即调用一个接口，此接口多久能返回。
• 而用户感知性能，是用户操作后到操作反馈的时间。

举个简单的例子，假设一个页面完整加载完要3s，如果用户一点击就白页，3秒后再显示出来，那么用户感知性能就是3秒；而如果一点击1秒之内就加载了第一屏或者立即就有一个加载反馈，那么用户感知性能就在1s以内。虽然系统性能实际是一样的，但是用户的感知性能却不同。

性能方面的知识点主要涉及各种优化：前端优化，网络优化，代码优化，数据库优化，JVM优化等等等等，提高TPS，QPS等系统性能和用户感知性能（用户体验）

伸缩性

如果你玩游戏的话，你肯定知道「开服」和「合服」吧？其实这就是伸缩性！

简单来说，伸缩性就是：「你的系统能否能通过简单的增加部署，来应对更多的访问量」！
例如：原来你的系统只有一台服务器，现在一台服务器撑不住了，你能否不修改任何代码，只增加一台一样的服务器就可以支撑更多的人来访问？

相对的，反过来，如果你的用户量减少了，两台服务器浪费了，你能否直接关闭一台服务集，来节约成本？

伸缩性涉及的知识点主要涉及分布式相关内容：应用集群，负载均衡，负载均衡算法，分布式事务，分库分表，拆分应用，服务化，SOA，微服务等

可用性

可用性可能是最基本的架构属性了。你经常听到的3个9,4个9,5个9就是指可用性的。
可用性指的是：「系统能够连续多长时间正常运行？」

• 3个9就表示系统全年可用时间占全年时间的99.9%，即不可用时间是365*24*60*60*0.1%=31536秒，大概8个多小时，好像时间还挺长的
• 4个9就表示系统全年可用时间占全年时间的99.99%，即不可用时间是365*24*60*60*0.01%=3154秒，大概50多分钟。基本上最多只能出一次故障
• 5个9就表示系统全年可用时间占全年时间的99.999%，即不可用时间是365*24*60*60*0.001%=315秒，大概5多分钟。基本上等于系统全年都要保证可用。一般情况下，系统故障了5分钟还不一定能定位到问题，更不要说解决问题了。

可用性和伸缩性涉及知识点有些重合，因为保障可用性的方法就是「冗余」，实际就是集群和分布式：集群，多数据中心，主备切换，心跳，注册中心，负载均衡，负载均衡算法（轮询、随机、hash），容错（见容错处理）等

安全性

最近Facebook出现了系统漏洞，5000多万的用户数据被泄露了。之前的携程也是，不少的知名系统都出现过安全问题。

安全性就是：「保障用户在使用系统的过程中，信息不会被泄露，导致个人财产受到损失，个人安全受到威胁等」

安全性相关知识点包括：各种攻击防范（CSRF，SQL注入，脚本注入，DDos等），https，鉴权，授权，单点登录，加解密等

容错性

做系统时，我们都听说过，要把用户当傻瓜，要把操作做得尽量简单。而实际上，我们也要把用户当做破坏分子，他们不小的概率不会按照正常情况来操作你的系统。

比如：电话号码里面写了字符啦，添加了各种表情啦，狂点提交按钮啦，狂刷新啦等等等等。你的系统需要应对这些。

容错性就是：「系统对非正常情况（输入、输出、操作，异常数据等）的宽容程度」。

你不能动不动就给个500错误，需要对可能的情况做容错处理。比如：前后端的数据检查，友好的错误提示。

容错性涉及知识点：如何进行异常处理？非正常输入输出处理。网络波动，请求超时，服务挂掉，硬件问题，用户体验等

灾难恢复

灾难恢复和容错性比较类似，只是程度上的区别。用户输入错误这样的问题，可能只是导致这个用户的流程无法走下去。而「灾难」会影响一部分甚至所有用户都无法使用系统，从而导致可用性问题。

比如：服务器宕机、机房断电、硬盘损坏、甚至地震了。你如何保证你的系统在上述情况下还能正常对外提供服务？

灾难恢复涉及的知识点：线路的快速切换，负载均衡算法，硬件损坏的恢复，跨DC备份等

可访问性

类似让视觉障碍之类的残疾人也能使用你的软件，这个好像目前考虑得不是太多，暂不讨论。主要还是用户体验方面，只是面向的群体不同