很多团队上云时最先关注性能和价格，等真出了事才想起容灾。要把高可用架构搭好，得先弄清阿里云可用区是什么，才能判断业务该放在哪里、怎么分布，故障发生后系统又怎么自动恢复。这篇文章从概念讲起，用一个电商业务的例子，说说可用区的划分思路和落地时要注意的地方。
什么是可用区
地域（Region）指阿里云在某个地理范围内的资源集合，比如华东、华北。一个地域里通常有多个可用区。每个可用区都有独立的供电、制冷和网络设施，同一地域内的可用区之间通过低延迟、高带宽的内网互联，数据交换效率有保障，单个机房出问题也不会拖垮所有业务。
可以把可用区想成同一座城市里几座相互独立的数据中心。距离够远，电力、空调、网络这些基础设施层面的故障不会互相传染；距离又够近，跨可用区的网络延迟通常在毫秒级，数据库主备、应用集群这类需要协同工作的组件，放在不同可用区依然能同步运行。
单可用区和多可用区的区别
不少中小项目一开始会选单可用区，原因很实际：配置简单，资源集中，跨区流量少，成本也低。但所有实例共用同一套基础设施，该可用区一旦断电、网络出故障或者规格售罄，业务就可能整体不可用。
多可用区部署是把应用实例、负载均衡、数据库和缓存分散到两个或更多可用区。平时负载均衡按权重把流量分给各个可用区；某个可用区异常时，健康检查会把它摘除，其余可用区继续接请求。原本可能让整个站点瘫痪的故障，就变成了只影响局部、还能自动恢复的事件。
案例：某电商平台的多可用区改造
某中型电商平台在大促期间遇到过一次可用区级故障。当时应用服务器、Redis 和 RDS 数据库都部署在同一个可用区，故障发生后，商品页和下单接口大约四十分钟无法访问，当晚成交额直接受影响。复盘之后，团队决定做多可用区改造，主要分三层来做。
1. 应用层：跨可用区部署和弹性伸缩
团队在华东地域的两个可用区分别建了 ECS 实例组，在伸缩组里设置最小实例数和分布策略，让实例尽量均匀落在两个可用区。负载均衡同样开启多可用区模式，统一接管外部流量。任一可用区的实例不可用时，伸缩组会在健康的可用区里补充实例，用户感受到的只是短暂的容量下降。
2. 数据层：数据库主备分处不同可用区
数据库是改造的重点。RDS 的主库和备库分别放在两个可用区，并开启高可用切换。主库所在可用区出故障时，备库会被提升为主库，应用通过数据库连接地址切换到新主库。跨可用区同步会带来一些写入延迟，所以团队针对写入密集的接口做了压测，确认延迟在可接受范围内，同时把一部分读请求分流到只读实例。
3. 缓存层：别让缓存变成新的单点
Redis 也做了多可用区部署。团队一开始发现，应用实例已经分散，但缓存主节点仍和应用集中在同一个可用区，这个可用区一出事，大量请求还是会穿透到数据库。于是缓存的主从节点也拆到不同可用区，并在应用侧加了降级策略：缓存不可用时，非核心数据直接返回兜底内容。
故障演练：验证设计是否真的有效
架构图画得再好，也要实际跑一遍才知道。改造完成后，团队挑了一个非高峰时段，计划性地模拟华东某个可用区不可用，观察系统的真实表现。结果是：负载均衡约三十秒内完成健康检查并摘除异常节点，数据库主备切换用了两分钟左右，期间有少量写入请求超时，由客户端重试补上。演练也暴露了两个问题：部分定时任务只绑定在单个实例上，监控告警又没有按可用区聚合，所以定位故障比较慢。团队修复这两处后，把演练放进了季度例行计划。
选可用区时要考虑的几件事
实际规划时，可用区的选择通常要在下面几个因素之间做取舍。
- 容灾等级：核心业务至少跨两个可用区部署。可用性要求更高的系统可以考虑更多可用区，但要把运维复杂度算进去。
- 延迟敏感度：同一可用区内的实例之间延迟最低。频繁交互的计算密集型服务，可以先在同一可用区组成子集群，再通过负载均衡对外提供服务。
- 成本：跨可用区的内网流量一般会产生额外费用。部署前先估算跨区调用量，判断容灾收益能否覆盖这部分支出。
- 资源供给：不同可用区的实例规格库存并不完全相同。大促前就要确认目标规格在各可用区的供应情况，否则扩容时可能卡住。
- 合规要求：部分行业对数据存放位置有明确规定，选可用区前要先确认这些要求，再定部署方案。
小结
可用区是云上高可用架构的基本单位。把业务拆到多个可用区，不只是多买几台机器，还要在应用、数据、缓存和运维流程上一起准备。对大多数业务来说，先把核心链路做成跨可用区部署，再通过演练逐步验证和补齐，是比较稳妥的路子。
