高可用架构的设计

设计思路

分层：数据侧 网络侧 应用侧 组件侧 分项目：业务线1 业务线2 业务线3具体落实

风险：横向和纵向高可用 ，尤其尾大不掉的架构风险

科学设计：最终一致性模式 可查询模式 补偿模式 最大努力通知模式

参考：https://zoyi14.smartapps.cn/pages/note/index?slug=4328f332db9c&origin=share&_swebfr=1&_swebFromHost=baiduboxapp

可用性是什么？

可用性是一种安全属性，是信息安全三要素中的 A：

保密性（Confidentiality）
完整性（Intergrity）
可用性（Availablility）
高可用是系统的重要目标，其重要程度取决于系统的定位。
例如：
军用系统中保密性最重要（宁可毁掉也不能将机密落入敌手）
商业系统中完整性最重要（宁愿服务终止，账本泄露也不容许篡改）
然而保密性和完整性不能很好地量化，也就不适合用来评价一个系统的架构强弱。
可用性却是一个很适合量化的指标：系统能正常运行的时间占总时间的百分比。99%的可用性就表示系统保证在99%的时间内正常服务。
通常99.99%四个九称为高可用，载人航天中，这一标准是99.9999%。

————————————————
版权声明：本文为CSDN博主「傲游步虚」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/yifeng_peng/article/details/88359810

一 具体运维操作关键词：

1 搭建
高可用集群（中间件 数据库等）
2 监控
健康检查 心跳检查 随时告警
3 告警响应 热备演练
收到告警 宕机一台 ，手动或自动 重启
4 容灾演练 异地冷备

二 架构设计

1 网络和基础系统架构侧 设计
负载均衡设备或集群
haproxy ？
nginx？
lvs？
硬件F5？
k8s高可用？

2 中间件（含数据库）侧 设计
中间件（数据库）高可用集群 通用原理
原文：
https://zoyi14.smartapps.cn/pages/note/index?slug=d1bf27f5f685&origin=share&hostname=baiduboxapp&_swebfr=1

关键词：
集群化部署 + 数据多副本冗余
为什么至少三台？
假设集群里有3台机器，那么其中一台宕机了，你后续再写入另外一台的时候，判断一下集群里还有剩余两台机器，足以保证数据双副本的高可用性和容错性，所以可以继续正常的写入数据到MQ集群里去。
集群里必须有超过2台机器可以接收你的数据副本复制。
具体的RabbitMQ、Kafka、RocketMQ等各种不同的消息中间件，对这种高可用架构的实现，都有一定的相似想通性，但是也都有各自不同的技术实现，以及相对应的区别。

3 应用业务系统侧 设计 （深入策略和细节）

负载策略？
熔断降级 业务类型和策略选型？
限流策略 要点？
重试策略？
超时时间？

应对连锁故障？
总结：应用业务侧微服务这些 熔断降级限流 是为了 运维侧 弹性扩容和弹性伸缩提供一个处理时间。