架构设计复杂度-高可用问题
Posted metashit
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了架构设计复杂度-高可用问题相关的知识，希望对你有一定的参考价值。
高可用指的是系统无中断的执行功能的能力
一个系统不可能一直无中断的执行下去，干扰因素有三个方面
- 硬件因素，机器宕机
- 软件故障，软件BUG
- 不可抗因素，地震、火灾、断电等
解决高可用问题的方案
本质上通过数据冗余备份和失效转移解决高可用问题，一台机器变成多台机器，单机变成集群架构
从高可用种类角度解决高可用问题：
- 任务分配器解决计算高可用问题，同一服务组件部署在多个服务器上
- 异地备份解决存储高可用问题，数据存储在多台服务器上
从引起高可用问题的因素角度解决高可用问题：
软件：通过软件工程质量保证，通过预发布验证、严格测试、灰度发布等手段解决上线服务的故障
硬件：应用层：负载均衡设备结合应用服务器集群通过心跳检测当应用服务器不可用时从服务器集群移除(应用层要进行无状态设计，应用逻辑和上下文分开)
服务层：这些服务层硬件被应用层通过分布式服务框架(如Dubbo)访问，分布式框架在应用层程序中实现软件负载均衡，通过服务注册中心提供服务层硬件有效性检测，
不可用则通知客户端程序修改服务列表，同时移除响应服务器
数据层：数据写入时进行数据同步复制实现数据冗余备份，数据服务器宕机时，应用程序访问切换数据服务器
不可抗：不可抗常常引起硬件的问题，常使用硬件因素的解决方案，对于玄学问题，可以模仿B站烧香
高可用的种类
- 计算高可用
- 存储高可用
计算高可用的复杂度来源：
任务分配器的增加(成本、性能、可维护性)、任务分配器与业务服务器的交互(需要管理连接)、任务分配器的算法
存储高可用的复杂度来源：
因为数据传输延迟导致的数据不一致性问题，CAP(一致性、可用性、分区容错性)三者需要权衡平衡取舍问题，其作者给出0.9+0.9+0.7的措施
高可用系统面临的理论局限性
CAP定理
如何判断当前系统是否处于高可用状态(高可用方案带来的新问题)
不要被字面意思迷惑，对于单台计算机来说，是否处于中断运行状态还是很好判断的，以下重点讨论的是，如何在集群中判断一个系统高可用，多个计算机到底哪个出了故障(其他正常的计算机应该处于一致状态)，此类问题常见名词：心跳检测
以下为决策方案:
- 中心独裁式
- 协商式(master-slave)
- 民主式
中心独裁决策一旦中心崩溃，决策瘫痪。
协商式决策有一个痛点，当协商双方信息交换通路出现问题，状态决策无法选举出master和slave，通常解决方案是在两台机器之间增加多条通路，但这样引入了新问题，即多条通路信息的取舍问题。
民主式类似区块链时用的决策算法，民主决策有一个固有的缺陷，即脑裂(选举出来多个结果)，脑裂通常用“投票节点数必须超过系统总节点数的一半”策略解决。
高可用和高可靠
高可用指的是正常提供服务的概率，数据指标常为故障恢复时间
高可靠指的是出问题的概率，数据指标常为故障出现次数
通过冗余·实现的高可用也会出现一个通用问题：集体故障
以上是关于架构设计复杂度-高可用问题的主要内容，如果未能解决你的问题，请参考以下文章