架构属性（转载）

作者：IvanEye

原文链接：https://www.cnblogs.com/ivaneye/p/9842011.html

架构属性

架构属性一般包括如下方面：性能，伸缩性，可用性，安全性，容错性，灾难恢复，可访问性，可运维，管理，灵活性，可扩展性，可维护性，国际化，本地化。还有法律法规，成本，人员等对上面架构属性的影响。

性能

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

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

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

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

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

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

伸缩性

简单来说，伸缩性就是：「你的系统能否能通过简单的增加部署，来应对更多的访问量」！

例如：原来你的系统只有一台服务器，现在一台服务器撑不住了，你能否不修改任何代码，只增加一台一样的服务器就可以支撑更多的人来访问？ 相对的，反过来，如果你的用户量减少了，两台服务器浪费了，你能否直接关闭一台服务集，来节约成本？

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

可用性

可用性指的是：「系统能够连续多长时间正常运行？」

• 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），容错（见容错处理）等。

安全性

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

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

容错性

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

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

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

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

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

灾难恢复

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

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

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

可访问性

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

监测（可运维）

对系统进行监控，以及在早期发现问题，在影响系统可用性前，就将其解决。这就是监测。主要包括完善的监控视图，异常数据的提醒，日志的记录等

监测涉及知识点：日志记录，日志统计，请求跟踪，机器负载监控，请求监控等，偏运维。

管理

如果你做过线上系统，应该会遇到过需要不停机调整系统某些参数的情况。例如：调整日志的输出级别，删除某些数据，刷新缓存。

管理指：「运行时修改系统配置、刷新缓存等能力」。这里需要注意的是，要避免对线上系统的影响，比如：全量刷新了缓存，导致系统雪崩了。

管理涉及知识点：需要权衡哪些配置需要在线进行调整。

灵活性

系统上线后，可能主要是运营人员对系统进行操作，一般运营人员不懂技术，如何提供方便的功能，能够让运营人员方便的使用系统。例如：用户下错单了，运营人员需要取消订单；敏感词审核了；屏蔽某些用户了；调整工作流流程了等等等等

灵活性指：「非技术人员修改软件内部使用的业务规则的能力」。

灵活性涉及知识点：确定哪些功能需要后台管理功能，及相关功能的设计。比如是否需要完善的权限体系，及运营人员如何管理权限体系。

可扩展性

系统开发是个持续的过程，对内项目一般会分期，一期二期三期；互联网项目会不断的根据用户反馈进行迭代。如何方便的进行迭代就是架构的可扩展性。

扩展性指：「扩展软件使其可以做现在还不能做的事的能力。即添加新功能的难易程度。」

扩展性涉及知识点：主要是设计方面的考量。面向对象设计、组件设计，高内聚，低耦合等。一些架构风格，例如插件风格，过滤器风格等对扩展性比较友好。其实大部分架构都支持可扩展性，只是支持的程度不同而已。

可维护性

开发为什么要使用框架？为什么要走变更流程？为什么有各种开发流程？为什么发布代码还要提交运维申请？是为了管理项目，提高开发进度，能够跟进项目计划，确定是否出现偏差，及时进行调整。这些都是可维护性的范畴。

可维护性指：「系统是否能快速的开发、测试、发布？」

可维护性这个属性偏流程管理，包括编码规范，开发流程，测试流程，发布流程等。

国际化

支持多国语言的能力。比如：很多网站分为中文站，国际站。这就需要考量，是使用相同的数据进行翻译，还是部署不同的系统等。

本地化

以符合最终用户文化习俗的方式展示数字、货币、日期等。

其它影响因素

• 法律法规：某些行业会受到法律或监管机构的管理，需要符合法律法规。例如金融行业
• 成本：成本不够，可能就会先降低甚至忽略某些架构属性的要求
• 人员水平：人员水平也可能会降低或提高某些架构属性

举个例子

这些架构属性，就是在做系统架构时需要考虑的点。依然以在线教育系统为例：

• 这个系统需要支持多少学员同时在线学习？能容忍多长时间的系统响应？这是「性能」
• 系统需要连续多长时间不出问题？3个9?4个9？还是5个9？这是「可用性」
• 如果系统出现了问题，该如何处理？如何响应？这是「系统容错」
• 如果学员增多了，能否能方便的多部署系统来支持？反之，如果学员减少了，能否减少系统部署来节约成本？这是「伸缩性」
• 如果要新增直播的功能，能否方便的添加？且基本不影响现有功能？这是「扩展性」
• 系统能否防御恶意攻击？是否能保证用户的信息安全？这是「安全性」
• 如何能以最小的花费来完成系统？这是「成本」考量
• 目前的团队技术水平如何？这是「人员」考量
• 系统出现问题或异常情况，是否能快速的通知相关人员？这需要完善的监控系统，这是「可运维性」
• 系统如何能快速的开发、测试、发布？这是「可维护性」
• 有哪些法律法规需要遵守？是否需要申请直播功能
• 有国外用户吗？需要国际化吗？

总结

每个约束之间并不是正交的，可能满足的某个约束，却违背了另外一个或多个约束，这就需要架构师来进行取舍。就像CAP原则一样，一个分布式系统不可能同时满足可用性、一致性和分区容错性。一个架构也不可能同时满足所有的约束。

原文：https://www.cnblogs.com/sunshine-blog/p/9849670.html