云服务器的可用区是同一地域内相互独立、但网络互通的物理数据中心，它和容灾的关联在于：把业务部署在多个可用区，是抵御机房级故障的最基础手段。
可用区到底是个什么概念
你买云服务器时，控制台上总有两个下拉框：一个叫“地域”，一个叫“可用区”，很多新手直接选最近的城市，然后就不管了，但这两个词的区别,直接决定了你的业务扛不扛得住意外。
云服务器可用区是什么意思
用大白话解释：地域是城市，比如北京、上海、广州，可用区是城市里的不同机房，通常叫“可用区A”“可用区B”，同一个地域下的可用区，电力、网络、制冷都是独立供电的，物理位置也隔开一段距离，但它们之间通过高速光纤连接，内网延迟极低，一般低于2毫秒。
行业共识认为，可用区设计的初衷，就是让同一地域内的多个机房能协同工作，同时避免“一锅端”，比如北京地域有3个可用区，如果其中1个机房的空调故障导致高温宕机,另外2个还能正常服务。
地域和可用区有什么区别
地域更像“大区”，不同地域之间内网不互通，需要走公网或专线，可用区是地域内部的“小区”，内网可以互通，而且免费，举个例子：北京地域的可用区A和可用区B之间，用内网传输数据不花钱；但北京地域和上海地域之间，哪怕用内网，也要走跨地域流量,按量计费。
这里有个容易踩的坑：很多人以为买了多台云服务器，就自动有容灾能力，如果它们全在同一个可用区，一旦这个可用区发生网络分区或电力中断，所有机器同时宕机，真正的容灾，前提是跨可用区部署。
可用区和容灾有什么关系
容灾的本质是“冗余”，你想防服务器宕机，就搞多台服务器；你想防机房故障，就得把服务器分散到不同可用区，可用区就是云厂商给你划好的“防爆隔间”。
单可用区部署的风险有多大
假设你的业务只跑在一个可用区里，那么你面临的风险是：机房级别的故障，这类故障并不罕见比如施工挖断光纤、变压器起火、空调失效，据统计，国内主流云厂商每年都会发生几次机房级事件，虽然单次影响时间可能只有几分钟到几小时，但对于电商秒杀、支付回调、在线游戏这类业务,几十秒的中断就是真金白银的损失。
你可能觉得“我每天备份数据，不怕”，但备份只能救数据，救不了“正在进行的请求”，一个用户正在下单，你机房挂了，他的订单状态卡在半路，等他刷新，可能看到的是“系统异常”，这种体验，多来几次,用户就跑了。
跨可用区容灾是怎么运作的
常见的做法是：在同一个地域选两个可用区，各部署一组云服务器，前面挂一个负载均衡器，正常情况下，流量同时打到两个可用区，当某一个可用区故障，负载均衡会自动把流量全部切到健康的那一侧，整个过程对用户无感,IP都不用变。
数据库层面更讲究一点，比如云数据库MySQL，可以开启“多可用区部署”功能，主库放在可用区A，备库自动同步到可用区B，主库所在机房出问题，云平台自动把备库提升为主库，切换时间通常在30秒以内，你只需要在连接串里加一个参数,应用层几乎不用改。
可用区和容灾的匹配度分级
- 同可用区多台服务器：只能防单台机器故障,容灾等级最低。
- 跨可用区多台服务器：能防机房级故障,是主流云厂商推荐的入门级容灾。
- 跨地域多区部署：能防地域级灾难（比如地震、大面积断电），但成本高、架构复杂，适合金融、政务等关键系统。
行业专家指出，多数中小企业的容灾需求，做到“跨可用区”这一档就够了，盲目追求跨地域，可能让运维复杂度翻倍,收益却不成正比。
云服务器可用区怎么选
选择可用区不是随缘点一个，而是跟着你的业务需求走,这里有三条具体建议。
看业务延时要求
如果你的用户主要在某一个城市，那就选那个城市的地域，然后在可用区上尽量分散，比如用户都在杭州，地域选“华东1（杭州）”，可用区可以选A和B，这样内网延迟依然很低，同时获得容灾能力，不要为了“保险”去选另一个省份的地域,那会让你的首屏加载慢几百毫秒。
看云产品支持范围
不是所有可用区都拥有全部云产品，有些新出来的实例规格、GPU机型、本地盘，可能只在特定可用区供应，你去创建实例时，如果发现某个可用区“该规格已售罄”，那就换一个可用区试试。不同可用区的库存是独立的，这也是你分散部署的一个理由避免一个可用区资源紧张影响所有业务。
看跨可用区部署价格
需要明确一点：同一地域内跨可用区的内网流量免费，但跨可用区的实例价格本身没有差异，和地域有关，和可用区无关，真正的成本变化来自云产品功能，比如云数据库的多可用区版本，通常比单可用区版本贵一些，具体幅度因厂商而异，跨可用区容灾往往需要多买一台备机,这部分预算要提前算进去。
实操：控制台里的具体路径
以某主流云厂商为例，购买云服务器选配置时，可以在“地域及可用区”这一步看到类似“可用区A”“可用区B”的选项，如果你的业务已经跑在可用区A，再买一台新机器时，建议直接选相邻的可用区B，然后通过“安全组”和“内网IP”让它们互访,不需要额外配置。
对于负载均衡，通常在创建SLB实例时，会要求你选择“主可用区”和“备可用区”，这里一定要把后端服务器的可用区覆盖进去，比如你的服务器一台在A、一台在B，那负载均衡的主备池也要选A和B，否则流量只会打到一边,另一边闲置。
如何规划一套跨可用区的高可用架构
纸上谈兵没用，给你一套可以直接照做的步骤，假设你有两台云服务器，跑的都是同一个Web服务,数据库用的是云数据库MySQL。
第一步：创建跨可用区的资源
先在控制台创建第一台云服务器，地域选“华北2（北京）”，可用区选“可用区A”，再创建第二台，地域不变，可用区选“可用区B”，两台机器的操作系统、Web环境完全一样，如果你的代码需要写配置文件，记住数据库的内网地址要用云数据库提供的“高可用地址”,这个地址会自动识别主备切换。
第二步：配置负载均衡
购买一个负载均衡实例，地域同样选“华北2（北京）”，在“可用区类型”里勾选“多可用区”，然后分别选择主可用区A和备可用区B，监听协议用HTTP或HTTPS，端口80或443，把两台云服务器的内网IP加入后端服务器组，并开启健康检查，健康检查的路径可以设为/healthz，让你的应用返回一个固定文案，比如ok。
第三步：验证故障切换
这一步很多人忽略，完成上述配置后，你可以在可用区A的那台机器上手动执行sudo halt强制关机，模拟宕机，然后观察负载均衡的健康检查状态，正常情况下10到30秒内，它会自动把可用区A的服务器标记为“异常”，流量全部转发到可用区B，再用你的电脑访问公网IP,应该完全无感。
第四步：数据库的容灾配置
在云数据库控制台，MySQL实例的“可用性”选项里，选择“多可用区部署”，系统会让你指定备库所在的可用区，记得选和你的备用服务器一致的可用区B，这样数据库和Web服务在故障时能做到“同侧切换”，避免出现数据库在A、业务在B的跨区访问延迟。
关于容灾，你需要想明白的两件事
第一，可用区是容灾的地基，但不是全部，它解决了机房故障，但解决不了人为误操作、应用Bug、数据被删这些逻辑层面的问题，你仍然需要每天做快照，定期做整机演练，容灾是个完整方案,可用区只是其中最省力的一环。
第二，容灾是需要花钱的，跨可用区的机器至少多一台，负载均衡也要多可用区版本，数据库更贵，但你可以算一笔账：一次机房级故障，按你每小时流水、用户流失率、口碑损失来估算，大概率比那点云资源费用贵得多，据工信部数据，国内企业的平均IT服务可用性要求是99.99%，对应每年宕机时间不超过52.6分钟，想达到这个级别,没有跨可用区支撑几乎不可能。
Q&A：关于可用区容灾的常见疑问
是不是可用区越多越安全？
不是，可用区多数情况下是为了分散资源，如果你的业务负载量根本用不到那么多机器，强行在三个可用区各放一台，反而增加了跨区同步的复杂度和故障点，中小业务做两个可用区就够,关键是要保证每个可用区里都有足够余量承受另一个可用区的流量。
跨可用区和跨地域容灾，哪个优先？
先做跨可用区，再考虑跨地域，跨可用区解决的是频繁发生的机房设备故障，跨地域解决的是极端自然灾害，对绝大多数业务来说，前者性价比远高于后者，如果要做跨地域，建议用云厂商的“多活”方案或“异地备份”功能,不要自己裸搭数据库同步。
同一可用区内两台机器延迟一定比跨可用区低吗？
大部分时候是，同一可用区内的网络通常走二层或三层交换机，延迟在1毫秒到0.5毫秒之间；跨可用区经过城域网光纤，延迟在1毫秒到2毫秒，这个差距对普通网站几乎无感，对高频交易、实时音视频这类场景才有明显影响，所以如果你的业务对延迟极度敏感，优先保证核心链路在同一个可用区内,再通过其他手段做容灾。