精读《从零开始做架构》( 四 )


FMEA 是一种在各行各业都有广泛应用的可用性分析方法,通过对系统范围内潜在的故障模式加以分析,并按照严重程度进行分类,以确定失效对于系统的最终影响 。
回到软件架构设计领域,FMEA 并不能指导我们如何做架构设计,而是当我们设计出一个架构后,再使用 FMEA 对这个架构进行分析,看看架构是否还存在某些可用性的隐患 。
在架构设计领域,FMEA的具体分析方法如下:

  1. 给出初始的架构图
  2. 假设架构中某个部件发生故障
  3. 分析此故障对系统功能的影响
  4. 根据分析结果,判断架构是否需要优化 。
存储高可用存储高可用的本质是通过将数据复制到多和存储设备,通过数据的冗余方式来实现高可用 。常见高可用存储架构:主备(备库只是一个备份),主从(主机负责读写,备库可以用来读),主主(都可以负责读写,保障数据能够被双向复制),数据分散集群(急群众的每台服务器会负责存储一部分数据,同时也会备份一份数据),数据按照地理级别分区主备架构一些复杂点:主备状态判断(常见直连方式,中介方式,客户端判断),数据一致性 。
在数据一致性中,常见技术有分布式事务例如 两阶段提交,三阶段提交;一致性算法例如Paxos,Raft,ZAB 。
计算高可用计算高可用的主要设计目标是当出现部分硬件损坏时,计算任务能够继续正常运行 。因此计算高可用的本质是通过冗余来规避部分故障的风险,单台服务器是无论如何都达不到这个目标的 。所以计算高可用的设计思想很简单:通过增加更多服务器来达到计算高可用 。计算高可用架构的设计复杂度主要体现在任务管理方面,即当任务在某台服务器上执行失败后,如何将任务重新分配到新的服务器进行执行 。计算高可用架构:主备,计算集群 。
业务高可用从“异地多活”和“接口级别故障”两个业务场景中,考虑如何保障业务高可用 。
异地多活是指,正常情况下用户无论访问哪一个地点的业务系统,都能够得到正确的业务服务;若某个地方业务异常的时候,用户访问其他不同地理位置正常的业务系统,也能够得到正确的业务服务 。
异地多活架构设计是为了应对在一些极端场景下,服务器出现故障如机房断电、地震等等 。但是,要实现异地多活的代价比较高,一方面系统的复杂度会变变高;另一方面,系统实现的成本也会变高 。
设计技巧:异地多活设计技巧:保证核心业务的异地多活、保证核心数据最终一致性、采用多种手段同步数据、只保证绝大部分用户的异地多活 。
异地多活方案主要针对系统级别的故障,而接口级别故障,顾名思义就是针对接口级别的故障 。其典型表现就是,系统没有宕机、网络没有中断,但是业务出现问题 。内部可能是程序bug问题,外部可能是黑客攻击、大量请求访问等等 。解决办法一般分为三种:降级、熔断、限流、排队 。
可扩展架构模式软件系统与硬件和建筑系统最大的差异在于软件是可扩展的,一个硬件生产出来后就不会再进行改变 。而我们需要不断地让软件系统具备更多的功能和特性,满足新的需求或者顺应技术发展的趋势 。
如何避免扩展时改动范围太大,是软件架构可扩展性设计的主要思考点 。可扩展架构的基本思想就是:“拆” 。就是将原本大一统的系统拆分成多个规模小的部分,扩展时只修改其中一部分即可,无须整个系统到处都改 。
可以减少改动范围,降低改动风险 。3种拆分思路,面向流程拆分、面向服务拆分、面向功能拆分 。
1.面向流程拆分:将整个业务流程拆分为几个阶段,每个阶段作为一部分 。面向流程拆分:展示层--》业务层--》数据层--》存储层
精读《从零开始做架构》

文章插图
 
2.面向服务拆分:将系统提供的服务拆分,每个服务作为一部分 。面向服务拆分:注册服务、登录服务、信息管理服务、安全设置服务 。
精读《从零开始做架构》

文章插图
 
3.面向功能拆分:将系统提供的功能拆分,每个功能作为一部分 。面向功能拆分:手机号注册、邮箱注册、手机号登录、邮箱登录、课程信息管理、成绩信息管理、修改密码、找回密码 。
精读《从零开始做架构》

文章插图
 
面向流程拆分:分层架构分层架构是很常见的架构模式,它也叫 N 层架构,通常情况下,N 至少是 2 层 。例如,C/S 架构、B/S 架构 。常见的是 3 层架构(例如,MVC、MVP 架构)、4 层架构,5 层架构的比较少见,一般是比较复杂的系统才会达到或者超过 5 层,比如操作系统内核架构 。


推荐阅读