开发者学习笔记【阿里云云原生助理工程师认证(ACA)课程:消息队列和应用工具产品体系-企业应用评判指标】
课程地址:https://edu.aliyun.com/course/3112075/lesson/190234
消息队列和应用工具产品体系-企业应用评判指标
内容介绍:
一.企业应用的评价标准
二.传统软件架构下的高可用设计
三.通过微服务实现高可用架构
一.企业应用的评价标准
在之前的课程中,我们经常会用到高可用、高并发等形容词对软件架构进行描述,那这些对系统应用特征描述定义的具体意义是什么?对于一个企业应用来说最核心的技术指标又是什么呢?
一般来讲,企业级应用最重要的指标有四个,高可用、高并发、高性能,俗称三高,再加上易扩展性。
1. 高可用性能是企业应用中最重要的指标,主要在内部组件损坏或外部资源不可用时有充分的应对措施。即系统稳定,不易出现故障,或出现故障影响小,恢复快。
2. 高并发是指系统可承受的同时访问量大,能应对瞬时激增的访问量,即系统可以支持很多用户同时访问,或者当在某一时刻访问用户量突然增加时,系统能够承受。这在互联网应用场景下显得尤为重要。
3.高性能是指应用消耗资源少,同等访问量下花费成本低,简单的来说就是同样的业务规模下,用户需要的服务器和网络资源小,应用的响应速度快,需要投入的it成本比较低,综合性价比高。
举例来说,用户如果自建IDC,前期需要投入大量的安装、采购、调试成本,而后期需要雇用运维人员进行维护。同时一些底层组件需要自己研发,又需要投入底层研发人员,相比较租用云服务厂商的计算资源,自建IDC的性价比较低,不符合高性能的质量。
4.易扩展性,易扩展性指可以快速迭代发布的新业务,对旧业务影响小,也就是说,无论是系统拓展新功能,还是在用户规模达到一定程度后的架构扩展,都可以迅速、便捷、安全、低成本的完成。例如单体应用架构和微服务架构的对比。单体架构模块耦合度高,牵一发动全身,功能修改之前需要缓慢的流程和文档准备工作,因此很难进行快速扩展,而微服务架构模块规模小,可单独进行迭代开发,新功能上线可批量或灰度发布,可靠性有保障,从扩展性看,比单体架构有了很大的提升。
二.传统软件架构下的高可用设计
为提高系统的可用性,首先要从软件架构进行考虑,传统的单体架构中,系统的高可用需求一般采用主备架构进行处理。主备架构的设计,简单来说就是单体应用的实例,平时运行在一台性能强劲的服务器上,作为主服务器,为防止系统出现故障,会再准备一台或多台类似配置的服务器并安装应用作为备份。
在应用程序正常运行时,主服务器上的实例负责对外提供服务,而备份服务器上的应用并不提供服务。在主服务器实例出现故障时,前端网络设前端网络设备将流量切换到备份服务器,由备份服务器提供服务。平时系统正常运行时,备份实例并不提供服务,因此这种模式就被称为冷备份模式。从技术角度来看,冷备份架构的优点是部署方式比较简单,不需要对程序架构有太多要求,只需要在应用升级时,同时升级主服务器和备份服务器即可。但冷备份的缺点也是非常明显的,首先,备份服务器平时虽然部署了应用,但是并没有对外提供服务,造成了资源的浪费,其次,备份服务器平时并没有提供服务,一旦主服务器出现故障需要切换到备份服务器的时候,通常会为避免备份服务器平时疏于准备或准备不足的情况,在启动之前先进行冒烟测试,以确保备份服务器的状态可用。同时为防止贸然将全部流量导入冷备份服务器,导致服务器预热不及时,一下子被压垮。通常会一点一点的增加访问流量,以保证服务器有充足的预热时间。这就导致了冷备份模式下备份服务器上线接替主服务器的时间不及时,通常需要十几分钟到几十分钟甚至几个小时,这种模式系统整体的可用性就会显得比较低,用户的整体使用体验也十分不友好。
三.通过微服务实现高可用架构
在分布式微服务架构下,系统的高可用设计抛弃了传统的主备高可用架构,而是遵循五大原则进行设计,即假定失效原则、多可用区原则、自动扩展能力、自我修复能力、松耦合架构。
1. 假定失效原则,在大型系统长期运行的过程中,硬件设备和外部环境的小概率事件也是开发者不得不面对的问题。一般来讲,磁盘的年损坏率在4%左右,而服务器的日到期率大概在万级,虽然云服务厂商可以通过底层数据多副本、服务器弹性调度等方式尽量避免故障的产生,但在大规模部署的情况下,即使是小概率事件,在架构设计时也不应该忽略,应该时刻考虑到应用的实例会随时失效的情况。
2. 多可用区原则,在系统设计中,尽量避免出现单点组件或者单地域部署的情况,基于假定失效原则,如果系统中存在单点组件,而一旦单点组件出现故障,则会导致整个系统不可用,同时,组件虽然采用集群部署,但是部署在同一地域,这样虽然可以避免服务器的硬件故障,但对系统的外部风险还是缺乏足够的应付手段,例如前面提到的机房或某个地域出现天灾或者电器故障、网络故障等,这些情况一旦出现,会导致整个地域的应用全部无法对外提供服务,因此在高可用服务的部署上,尽量采用多节点备份、多地域部署的方式才是最佳的选择。
3. 自动扩展设计,自动扩展指当服务器的实力并发量过大时,通过弹性扩容的方式创建新的服务实力,分摊现有实例的压力。需要说明的是,在分布式微服务架构中,并不会单独设置完全不提供服务的备份服务器,而是平时就会让所有服务器都分摊一定的计算量,这样就避免了冷备份模式下临时抱佛的问题。
4. 自我修复能力,自我修复能力和自我扩展设计类似,当通服务检查发现某个服务出现异常时,首先将错误的实例摘除,由其他实例分摊流量,再通过自动伸缩组件扩展出一个新的实例替代错误实例,实现错误的自动修复。
5. 松耦合设计,松耦合设计优势在之前的微服务开发中多次提及,补充一点,即应用的耦合度越低,当服务出现故障时影响越小,弹性控容也更加容易。