本文探讨如下几个问题:
- 什么是架构属性
- 约束和架构属性的关系
- 有哪些架构属性
- 各个架构属性涉及知识点
什么是架构属性
首先,问个很简单的问题!请看下面的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原则一样,一个分布式系统不可能同时满足可用性、一致性和分区容错性。一个架构也不可能同时满足所有的约束。