什么是架构属性
本文探讨如下几个问题：
- 什么是架构属性
- 约束和架构属性的关系
- 有哪些架构属性
- 各个架构属性涉及知识点
什么是架构属性
首先，问个很简单的问题！请看下面的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备份等
可访问性
类似让视觉障碍之类的残疾人也能使用你的软件，这个好像目前考虑得不是太多，暂不讨论。主要还是用户体验方面，只是面向的群体不同，优化的点也就不同。
监测（可运维）
上面说可用性，4个9时基本就要保障机器全年都要可用，为了达到这个目标，就要对系统进行监控，以期在早期发现问题，在影响系统可用性前，就将其解决。这就是监测。主要包括完善的监控视图，异常数据的提醒，日志的记录等
监测涉及知识点：日志记录，日志统计，请求跟踪，机器负载监控，请求监控等，偏运维。
管理
如果你做过线上系统，应该会遇到过需要不停机调整系统某些参数的情况。例如：调整日志的输出级别，删除某些数据，刷新缓存。
管理指：「运行时修改系统配置、刷新缓存等能力」。这里需要注意的是，要避免对线上系统的影响，比如：全量刷新了缓存，导致系统雪崩了。
管理涉及知识点：需要权衡哪些配置需要在线进行调整。
灵活性
系统上线后，可能主要是运营人员对系统进行操作，一般运营人员不懂技术，如何提供方便的功能，能够让运营人员方便的使用系统。例如：用户下错单了，运营人员需要取消订单；敏感词审核了；屏蔽某些用户了；调整工作流流程了等等等等
灵活性指：「非技术人员修改软件内部使用的业务规则的能力」。
灵活性涉及知识点：确定哪些功能需要后台管理功能，及相关功能的设计。比如是否需要完善的权限体系，及运营人员如何管理权限体系。
可扩展性
系统开发是个持续的过程，对内项目一般会分期，一期二期三期；互联网项目会不断的根据用户反馈进行迭代。如何方便的进行迭代就是架构的可扩展性。
扩展性指：「扩展软件使其可以做现在还不能做的事的能力。即添加新功能的难易程度。」
扩展性涉及知识点：主要是设计方面的考量。面向对象设计、组件设计，高内聚，低耦合等。一些架构风格，例如插件风格，过滤器风格等对扩展性比较友好。其实大部分架构都支持可扩展性，只是支持的程度不同而已
可维护性
开发为什么要使用框架？为什么要走变更流程？为什么有各种开发流程？为什么发布代码还要提交运维申请？是为了管理项目，提高开发进度，能够跟进项目计划，确定是否出现偏差，及时进行调整。这些都是可维护性的范畴。
可维护性指：「系统是否能快速的开发、测试、发布？」
可维护性这个属性偏流程管理，包括编码规范，开发流程，测试流程，发布流程等
国际化
支持多国语言的能力。比如：很多网站分为中文站，国际站。这就需要考量，是使用相同的数据进行翻译，还是部署不同的系统等。
本地化
以符合最终用户文化习俗的方式展示数字、货币、日期等
其它影响因素
- 法律法规：某些行业会受到法律或监管机构的管理，需要符合法律法规。例如金融行业
- 成本：成本不够，可能就会先降低甚至忽略某些架构属性的要求
- 人员水平：人员水平也可能会降低或提高某些架构属性
举个例子
这些架构属性，就是在做系统架构时需要考虑的点。依然以在线教育系统为例：
- 这个系统需要支持多少学员同时在线学习？能容忍多长时间的系统响应？这是「性能」
- 系统需要连续多长时间不出问题？3个9?4个9？还是5个9？这是「可用性」
- 如果系统出现了问题，该如何处理？如何响应？这是「系统容错」
- 如果学员增多了，能否能方便的多部署系统来支持？反之，如果学员减少了，能否减少系统部署来节约成本？这是「伸缩性」
- 如果要新增直播的功能，能否方便的添加？且基本不影响现有功能？这是「扩展性」
- 系统能否防御恶意攻击？是否能保证用户的信息安全？这是「安全性」
- 如何能以最小的花费来完成系统？这是「成本」考量
- 目前的团队技术水平如何？这是「人员」考量
- 系统出现问题或异常情况，是否能快速的通知相关人员？这需要完善的监控系统，这是「可运维性」
- 系统如何能快速的开发、测试、发布？这是「可维护性」
- 有哪些法律法规需要遵守？是否需要申请直播功能
- 有国外用户吗？需要国际化吗？
总结
本文梳理了什么是架构属性；有哪些架构属性及相关知识点！后续对各个属性进行详细讨论。
每个约束之间并不是正交的，可能满足的某个约束，却违背了另外一个或多个约束，这就需要架构师来进行取舍。就像CAP原则一样，一个分布式系统不可能同时满足可用性、一致性和分区容错性。一个架构也不可能同时满足所有的约束。
