架构设计四大目标
1、高可用
可用性概念
可用性指的是业务系统无故障的对外提供服务的概率,可用性的计算涉及到如下几个概念:
- 系统无故障运行时间
- 系统维修时间
可用性=系统无故障运行时间/(系统无故障运行时间+系统故障维护时间),可用性指标一般按照年为维度来统计。
高可用性设计的目标,是通过系统设计去提高业务系统的可用性,以达到业务对于无故障运行的要求。SLA(服务等级协议 Service-Level Agreement)中,根据可用性大小,把可用性分为了如下等级:
可用性 | 停机时间/年 | 描述 |
---|---|---|
90% | 36.5天 | 达不到使用门槛 |
99% | 2.65天 | 基本可用 |
99.9% | 8.76小时 | 较高可用 |
99.99% | 52.6分钟 | 自动恢复能力的高可用 |
99.999% | 5.25分钟 | 极高可用性,重要服务常常需要达到此要求 |
如何提高可用性
我们从可用性的计算公式来看,提高可用性,可以从两个方面着手,一是减少系统故障不能对外提供服务的时间,二是减少系统维修的时间。
减少系统故障不能对外提供服务的时间,可以使用如下的办法
- 梳理业务系统的技术组件是否完善,即技术架构是否能够保证高可用,比如,如果业务系统是对外的,那么一般后端服务是需要API网关的来保护后端服务。除过组件的完整性之外,各个组件本身也需要达到足够的可用性,比如系统使用的数据库是否高可用,缓存是否高可用等。
- 梳理业务系统核心业务过程在大流量或者遭受攻击的时候能否正常对外提供服务,比如公司统一的用户登录服务,商品服务。
- 梳理业务系统部署架构是否高可用,比如业务系统本身是否是多地域多机房部署,是否能够应对极端情况,比如机房停电,断网等。
2、高扩展
什么是扩展性
业务系统的扩展性,指的是业务系统在应对业务变更的时候,自身调整的难易程度,好的扩展性可以帮助业务系统有很好的应对变化的能力,使IT系统能够更好的适应业务的变化。
AFK原则
在《可扩展的艺术》一书中,提出了系统扩展可以从三个维度来做,理论上,按照这三个扩展模式,可以把一个单一系统无限扩展。
- X 轴 :指的是水平复制,单体系统的前端进行横向扩展,多台前端实现负载均衡。
- Z 轴 :是数据层的扩展,业务量激增,承载业务的集群不足以承载过大的业务数据量,就进 行数据层面的扩充。
- Y 轴 :是微服务的拆分模式,就是基于不同的业务或功能拆分。
软件系统常见的一些扩展点
- 服务去状态化:服务的无状态可以使服务横向扩展(即按照X轴扩展)变的很容易。最常见例子的是把session放到远端的redis中而不是本地。
- 大服务拆分:把一个巨大的单体服务按照业务领域打散为独立微服务,微服务相比单体应用的好处可以自行百度。
- 业务过程解耦:把原本同步依赖的业务拆分开,最典型的是用户注册之后同步调用赠送积分,赠送赠品。这样做有两个缺点,一是如果赠送积分或者赠品失败会导致用户注册失败,二是如果赠送积分和赠品的接口有改变那么用户注册这里还得被动的去修改。这时候可以把送积分和送赠品使用mq来解耦开来,这样就可以大大降低注册服务的维护成本。
3、高安全
保障安全的目的是为了业务更好的连续运行,同时保证业务的安全性,比如数据不丢失、不泄露。安全涉及到的面很广,大型业务关注的业务一般分为如下五个方面
- 主机安全 应用所在设施本身的安全性
- 网络安全 应用所在设施的网络环境的安全性
- 数据安全 应用使用的数据存储设施(数据库,对象存储,文件存储,缓存),以及数据存储方式(加密、脱敏),数据访问方式的安全性
- 应用安全 应用的安全设计(组件的完整,比如对外的应用前端对后端的访问只能是通过网关访问),部署(内网部署,接口不乱暴露),相关操作安全(权限管控,身份认证)
- 业务安全 业务过程设计的安全性
4、低成本
IT系统的成本一般包括基础设施的投入以及人员投入。成本优化也是个非常大的话题,最近几年互联网都在搞降本增效,也是从方方面面来优化。关于成本优化,我后边还会专门再写文章,就不在这里深入了。
业务特点
要明白业务的特点,比如活跃用户的数量,是电商场景还是政企场景?是对外的系统还是企业内部的系统。不同的场景在可用性、安全性、扩展性、成本方面的追求不同。比如ToC的应用,更强调用户体验,而ToB的应用更强调要解决企业问题。很多时候内部应用的接口可以不需要通过api网关只在应用内部做相对简单的控制即可,如果用户量不大,一般也不需要拆分服务,这样也可以降低维护成本。
领域驱动设计(DDD)
DDD(领域驱动设计)最大的作用是实现复杂业务的拆分,这属于业务系统战略设计阶段所做的事情,关于DDD,可以看参考文章中我写的DDD的文章或者掘金上一些其他DDD的文章。