2. 高可用架构设计原则：CAP理论在跨境场景下的取舍、BASE原则、冗余设计、故障隔离
做跨境做市系统，说白了就是在钢丝上跳舞。你既要保证交易不中断，又要应对全球网络的不确定性。我做了这么多年跨境系统，踩过的坑比吃过的盐还多。今天咱们就聊聊高可用架构的那些核心原则。
2.1 CAP理论：跨境场景下的残酷取舍
CAP理论大家都熟——一致性、可用性、分区容错性，三者只能取其二。但在跨境场景下，这个选择题其实没得选。
分区容错性（P）是必选项。 为什么？因为跨境网络天然不可靠。光缆被挖断、海底地震、国际出口拥堵……这些事我全遇到过。你想想看，如果网络分区了，系统直接罢工，那还做什么市？
所以实际的选择题是：C（一致性）和 A（可用性），你保哪个？
我的经验：在跨境做市场景下，保可用性（AP）是主流选择。原因很简单——做市商的核心是持续报价，哪怕价格稍微旧一点，也比报不出来强。
我记得有一次，新加坡到香港的光缆断了整整4个小时。我们当时选择了强一致性方案，结果香港那边的做市引擎直接停摆，损失惨重。从那以后，我再也不敢在跨境链路上搞强一致性了。
2.1.1 一致性级别的实际选择
既然选了AP，那一致性怎么办？总不能乱报价格吧？这里有几个实用策略：
- 最终一致性：允许短暂的不一致，但保证最终能对齐。比如报价延迟几毫秒同步，问题不大。
- 读写分离：写操作走主节点，读操作可以走从节点。哪怕从节点数据稍微旧一点，也能接受。
- 版本向量：每个数据带版本号，冲突时以最新版本为准。我在项目中用过DynamoDB的版本机制，效果不错。
避坑指南：我曾经在跨洲链路（比如纽约到东京）上尝试过同步复制，结果延迟飙到300ms以上，做市引擎直接超时。后来改成异步复制+补偿机制，才把问题解决。
2.2 BASE原则：弱一致性也能玩得转
BASE原则是CAP理论在工程上的落地。说白了就是：别追求完美，先保证能用。
BASE三个核心：
- Basically Available（基本可用）：系统大部分时间可用，允许降级。比如行情延迟时，报价频率降低，但不停报。
- Soft State（软状态）：允许中间状态存在。比如订单状态从"已提交"到"已成交"之间，可以有短暂的"处理中"状态。
- Eventually Consistent（最终一致）：数据最终会一致，但别指望立刻一致。
我习惯把BASE原则理解为"先干活，后对账"。做市系统里，很多操作都是先执行，再异步校验。比如你报了一个价，客户端先看到，后台再慢慢算风控。只要最终能对上账，问题就不大。
实际案例：我们曾经在跨境做市系统中，把订单确认从同步改成异步。客户端收到"已受理"就继续报价，后台异步处理成交确认。虽然偶尔有订单冲突，但整体可用性从99.9%提升到了99.99%。
2.3 冗余设计：别把所有鸡蛋放一个篮子里
冗余设计听起来简单，但做起来门道很多。我见过太多"伪冗余"——看起来有备份，实际上单点故障一打就全挂。
2.3.1 冗余的层次
| 层次 | 冗余方式 | 我的经验 |
|---|---|---|
| 计算节点 | 多活部署 | 至少3个节点，跨机房 |
| 数据存储 | 主从/多副本 | 副本数≥3，跨AZ |
| 网络链路 | 多线路BGP | 至少2家运营商 |
| 机房 | 异地多活 | 距离>1000公里 |
你想想看，如果只做同机房冗余，一个火灾全完蛋。我有个朋友的公司，所有节点都在同一个数据中心，结果一次电力故障，整个做市系统停了6小时。嗯，后来他们被客户骂惨了。
2.3.2 冗余的代价
冗余不是免费的。每增加一个副本，成本就翻一倍。而且数据同步也会带来延迟。我的建议是：按业务重要性分级冗余。
- 核心链路（报价、成交）：3副本起步，跨机房部署
- 非核心链路（历史查询、报表）：2副本，同机房即可
- 日志类数据：1副本，甚至可以用对象存储
注意：冗余不是越多越好。我曾经见过一个团队，每个数据搞了5个副本，结果同步延迟高得离谱，反而影响了可用性。冗余要适度，够用就行。
2.4 故障隔离：别让一个Bug拖垮整个系统
故障隔离的核心思想是：把故障限制在最小范围内。一个模块挂了，别把整个系统拖下水。
2.4.1 隔离的常用手段
- 线程池隔离：不同业务用不同的线程池。比如报价线程池和成交线程池分开，报价线程池满了，不影响成交。
- 资源隔离：CPU、内存、网络带宽按业务分配。我习惯用cgroup做资源限制。
- 熔断降级：下游服务挂了，上游自动熔断，避免雪崩。Hystrix或者Resilience4j都行。
- 舱壁模式：每个服务实例独立运行，一个实例挂了不影响其他实例。
我记得有一次，一个第三方行情源突然挂了，结果因为没做熔断，整个做市引擎都在等行情响应，最后所有报价都超时了。后来我们加了个熔断器，行情源挂了就自动切到备用源，问题就解决了。
2.4.2 隔离的粒度
隔离粒度太粗，等于没隔离；太细，管理成本又高。我的经验是：按业务域隔离。
- 报价域：独立进程/容器，独立线程池
- 成交域：独立进程/容器，独立数据库连接池
- 风控域：独立进程/容器，独立缓存
- 清算域：独立进程/容器，异步处理
避坑指南：我曾经把隔离粒度搞得太细，每个交易对都单独一个线程池，结果管理了上百个线程池，运维成本极高。后来改成按业务域分组，每个域一个线程池，既隔离了故障，又降低了复杂度。
2.5 知识体系总览
下面这张图是我自己画的，把本章的核心逻辑串起来了。你一看就明白：
这张图把四个原则的关系讲清楚了。CAP理论是顶层决策，BASE原则是落地方法，冗余设计和故障隔离是具体手段。四者缺一不可。
2.6 总结
高可用架构设计，说白了就是一场权衡游戏。你不可能既要强一致性，又要高可用性，还要低成本。我的建议是：先保可用性，再谈一致性；先做冗余，再做优化；先隔离故障，再追求性能。
嗯，这些原则说起来简单，做起来全是细节。但只要你把握住核心——让系统在故障时还能继续服务——方向就不会错。