软件系统架构设计

基本公式 - 三板斧

性能优化

缓存
异步
并行

一致性

raft 多数节点投票
双写: 附加一致性校验 or 版本控制
分布式事务 / 最终一致性

安全

隔离
升级
权限
审计

高并发

队列
分流
熔断 / 降级

秒杀

限流
队列
锁: 避免超售

高可用

多副本
自动故障转移
自愈

高可用架构设计 - 基础设施

CAP 定理

分布式环境中有一个不可能的三角 CAP 定理: 一致性, 可用性, 分区容错性;

C(Consistency)一致性: 所有节点在同一时刻看到相同的数据;
A(Availability)可用性: 每个请求都能收到(非错误)响应, 但不保证数据是最新的;
P(Partition tolerance)分区容错性: 系统在网络分区(节点间消息丢失或延迟)时仍能继续运行;

在分布式系统中, 当发生网络分区(P 必须满足)时, 无法同时保证 C 和 A, 只能在 C 和 A 之间做取舍;

典型选择:

CP 系统: 放弃 A, 保证强一致性(如 Zookeeper, Etcd, HBase); 分区时可能拒绝服务;
AP 系统: 放弃 C, 保证最终一致性(如 Cassandra, CouchDB, Eureka); 分区时允许读到旧数据;

大部分互联网业务(如商品库存, 用户信息)倾向于 AP + 最终一致性, 配合消息队列, 对账修复来弱化不一致窗口;
金融, 分布式锁等场景必须用 CP(如 Raft), 允许在分区时短暂不可用;

多副本

双中心

同城主备
同城双活
异地备份
异地双活

两地三中心:

同城双中心
异地灾备中心

云环境

多 AZ
混合云
多 AZ + IDC 同城双活

延迟同步:

核心数据可以附加延迟备份, 避免类似 DDL 语句造成全量数据影响;

用户入口问题

DNS/CDN
- DNS 配置多个地址, 随机取一条访问
- 智能 DNS, 就近路由, 故障转移
- CDN 回源时, 按策略进入指定区域
网关重定向: 智能 DNS 解析到任意区域网关服务, 由网关服务根据条件将用户请求重定向到合适区域
前置: 客户端内置多个路径, 根据算法选择路径

多中心数据一致性

根据 CAP 和需求进行取舍;

数据冲突

同时只有 1 个数据中心可写, 将冲突问题改为同步问题
细化的全局锁, 获得锁的中心才能写数据, 同步完成才解锁
raft 协议, leader 节点可写;
数据拆分, 设计成不同中心写的数据完全不会冲突; 例如 uid 单双数进入不同中心;

数据同步

异步复制; 网络分区时, 暂时使用旧数据, 后续进行数据补偿和修复;
强同步, 只有对方机房同步成功, 本端才能成功;

灾备设计

传统的灾备只是单向同步数据, 日常没有流量; 导致在关键时刻没人有信心敢立即切流量过去;

通常启用灾备中心并切换流量后, 都会伴随较多的人工操作和各种大小问题;

所以正确的灾备中心设计, 不应该只做备, 而是日常就要有全业务的小比例流量, 才能保障在关键时刻能顶上;

灾备设计重点

入口流量怎么过来
数据一致性; 包括数据库, 中间件, 缓存等所有有状态数据节点的数据;

自愈

发生故障时的自我恢复能力, 应用程序有内部自愈和外部自愈两类;

内部自愈: 核心是防止自己死了;

例如当调用数据库不通时, 不再接收新业务请求, 等通了再接收新连接, 避免自己死掉
自我监控内存信息, 当无可用内存时, 主动释放资源

外部自愈: 死了后能被拉起来

脚本循环检测, 发现死了重新拉起来, 并且重写加入集群;
更多逻辑判断, 处理故障后再拉起来
在程序故障之前提前进行处理, 如通过监控发现程序可能出现内存泄漏, 主动重启或告警
参考 k8s 的 operator 模式, 由一个管理控制器来运维;
可回滚, 例如新版本刚发布的场景, 能自动回滚;

自动故障转移

一般来说特指将发往故障节点的流量, 转发到正确节点上去;

高可用架构设计 - 应用服务

核心是避免外部流量冲垮自己

服务降级

在高压力或某一块业务故障后, 进行服务降级; 屏蔽非核心业务, 以保障核心基础服务的可用;

限流

应对恶意流量
应对突增的超出业务处理能力的流量