少依赖原则:能不依赖,尽可能不依赖,越少依赖越好
当两个事物之间有了关系,就会相互影响,就互为对方的一个风险,一个出问题可能会影响另外一个,所以能不依赖的尽量不依赖。
弱依赖原则:一定要依赖的,尽可能弱依赖,越弱越好
事物a强依赖事物b,一旦b出现问题时,那么a也会出问题,任何强依赖都要尽可能的转化为弱依赖,可以直接降低出问题的概率。
如完成交易后会积分发放,交易核心系统需要依赖积分服务,好的方式是使用异步化的方式,就算积分服务出现问题,也不会影响交易核心链路。
解决方案:解耦,异步调用设置合理超时时间
分散原则:鸡蛋不要放在一个篮子里,分散风险
0-0-100❌ ,避免全局只有一份,否则一有问题影响范围就是100%
如所有数据都放在同一库同一张表中,万一这个库挂了,将影响所有数据。
均衡原则:均匀分散风险,避免不均衡
1-1-98❌,最好的N份中每份都是均衡的,避免某个份额过大,否则过大的一有问题就影响范围过大。
负载均衡设置合理,不要把某台机器权重设置的过大,导致流量访问不均衡。
隔离原则:控制风险不扩散,不放大
每份之间是相互隔离的,避免一份有问题影响到其他的也有问题,传播扩散影响范围。
隔离级别越高,风险传播扩散的难度就越大,容灾能力就越强。
隔离级别由低到高排序:同一台物理机 -> 同一机房不同物理机 -> 同一城市不同机房 -> 不同城市机房
如数据库表都部署在同一台物理机上,万一某张表有一条大SQL把网卡打满了,那所有的库表都会受到影响。
如push系统某个业务发送量突增不能影响到其他业务方的正常使用。
泳道就是解决隔离,它意味着按照功能提供独立的网络、应用和数据库服务器,确保一条泳道上的故障不会对其他泳道上的用户操作产生不利的影响。
无单点原则:要有冗余或其他版本,做到有路可退
快速止血的方式是切换、回滚、扩容,其中回滚和扩容属于特殊的切换,需要一定的时间。
切换得有地方可切才可以,所以不能有单点,要有冗余或其他版本,单点会限制整体的可靠性。
假设单点的可靠性是99.99%,要提升到99.999%很难,但是如果是依赖两个节点,那整体可靠性就是99.999999%,会有质的提升。
自我保护原则:少流血,牺牲一部分,保护另外的一部分
极端情况下可能无法快速止血,可以考虑少流血,牺牲一部分保护另外一部分,可通过限流、降级等操作。
可用性治理主要从3个方面着手提升
- 加强系统韧性。
- 完善止损手段,提升止损有效性,加速止损效率。
- 加速原因定位和解除效率。