高可用
关于系统高可用,最好就是直接看刚刚放的链接,以我现在的水平总结不会超过上面的文章,不过我想通过自己的方式表达出来。
分布式系统的特点
- 网络不可靠(拥挤,延迟,光缆被挖断,运营商网络故障等);
- faults and patial failure
In a distributed system, there may well be some parts of the system that are broken in some unpredictable way, even though other parts of the system are working fine. This is known as a partial failure.
If we want to make distributed systems work, we must accept the possibility of partial failure and build fault-tolerance mechanisms into the software.
- 时钟同步问题
- 拜占庭问题
- 顺序问题
也正是因为这些问题,所以我们的系统要fault-tolerance.
冗余
因为各种客观原因(操作系统,电源,磁盘,误操作等..),单机会宕机,导致系统不可用。
对于无状态服务,我们需要多台机器 + 负载均衡 来处理,所以负载均衡就是重要的组件,要保证负载均衡的高可用,同时也要冗余(常用的方式主从)。而当一组负载均衡达到上限后,就需要分区,使用多组负载均衡。 负载均衡的分类
负载均衡算法
对于有状态的服务,应用层通过2pc(两阶段提交),TCC等方式保证数据正确提交,而数据存储节点,通过复制(同步或异步)的方式冗余存储,但不同的方式有各自的优缺点。
M/S、MM实现起来不难,但是会有很多问题,2PC的问题就是性能不行,而Paxos的问题就是太复杂,实现难度太大。
对应的就是分布式系统存在的问题,也就是通常所说的CAP理论,分布式系统需要再高可用和强一致性上作出一定的取舍。
对于最终一致性来说,在宕机的情况下,会出现数据没有完全同步完成,会出现数据差异性。
对于强一致性来说,要么使用性能比较慢的XA系的两阶段提交的方案,要么使用性能比较好,但是实现比较复杂的Paxos协议。
容错
容错就是在刚刚我们提到的分布式系统的基础上,构建出具有足够容错的系统。也是我们常说的弹性设计。
系统隔离(服务拆分/API拆分):一个系统出错,不会影响其他系统,包括资源隔离,最直观的就docker'的资源隔离。
系统间可靠通讯(保证数据一致性):TCC,一致性事务消息,事务补偿机制,消息重试,幂等。
熔断降级(防止雪崩),保护系统在异常情况下,也能继续使用。
限流(阻断异常流量),从入口处保证系统可用,阻断异常流量等。
cloud pattern
所谓的pattern就是根据实践总结出来通用经验,以上的问题的通用解决方案, https://docs.microsoft.com/en-us/azure/architecture/patterns/