什么是架构属性

本文探讨如下几个问题:

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

什么是架构属性

首先,问个很简单的问题!请看下面的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原则一样,一个分布式系统不可能同时满足可用性、一致性和分区容错性。一个架构也不可能同时满足所有的约束。

参考资料

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值