【p1】谈一谈灾备

（转载请注明作者和出处‘https://fourthringroad.com/’，请勿用于任何商业用途）

对于非关键服务我们通常不太考虑这个问题，之前在Amazon工作的时候，有时候将服务的高可用建立在底层设施/托管服务的高可用上。但是离开了这些环境，这就是一个我们自己需要关注的点了。京东云发展之前，业务部门更多的使用的是自己搭建的中间件，这边就需要不少的灾备工作，来应对大大小小的促销节点。

即使在云上，对于关键服务，我们也要关注灾备的问题。

首先谈谈高可用。

高可用HA

截了个wikipedia的描述。高可用是现代IT系统极为关注的点，作为微服务链路中的一个重要环节，哪怕你的SLA实现了四个9，一年也难以避免会有一个小时的宕机。你无法想象S3发生几个小时的宕机的后果是什么（事实上也发生过）。

如果灾难一定会发生，那么我们要做的就是准备好后续的措施，这个就是灾备要做的事情。

灾备Disaster Recovery

灾备DR其实就是如何从灾难中恢复，早期可能主要关注数据层面，现在对我们来说如何快速让业务层面恢复正常也同样重要。我最近听的一个讲座这样拆分灾备：

灾备= 容灾 + 备份

容灾侧重于设置主备中心，保证服务的不间断；而备份从数据层面保证安全。

从我的理解上讲这两个概念有重复的地方，主备中心必然牵扯到数据的备份。单独说备份可能更多的是强调这是最基础，也是最后一道防线。倒也是合理

容灾

如前所述容灾通常采用主备部署方式，最理想的方式是两地三中心：

本地数据/服务中心 + 本地灾备中心 + 异地灾备中心

在云上，本地的两中心通常同Region，跨AZ（不同机房）；异地的中心则跨Region部署。

这种部署方式从最大程度保证了安全。当主服务出现了问题，可以灵活切换到备用服务。理想状态是备份中心和主中心可以互相感知健康状态并自动切换，当然也可以人工干预。

这种主备方式有一个问题是资源的使用率，备用机房只是进行数据的同步，并不承接业务，存在资源的浪费。所以有些业务会在备用服务使用更少的资源或者服务降级或者处在睡眠状态，只要保证服务能够在可接受范围内启动即可。这就引出了热备和冷备，其实这只是根据业务能承受中断恢复时间进行的一个选择。还有一些业务会在备用服务上提供只读服务进行数据挖掘分析，或者将其改造成跟沙盒来进行测试，这些都是为了提高资源的使用率。

上述部署方式，涉及到底层数据的同步问题，通常同步过程可拆解为：全量复制（快照）和增量复制，不同的服务这两个阶段的复制具体实现方案不同。快照的机制包括COW，ROW等，增量复制的机制对数据库来说就是事务日志。

除了主备部署，另一个常见的方案：双活/多活（也可分本地和异地）。其实就是备用服务也承接业务流量，变成了主-主或者主-主-主架构。它的技术难点是需要进行数据的双向同步；并且要保证数据的一致性，有一些数据库是支持的。

备份

解决的问题不是服务高可用不中断，而是以某个Recovery Point恢复点为准，对服务，数据进行备份，用于应对故障发生后的恢复。

常见的衡量指标是RPO（Recovery Point Objective）和RTO（Recovery Time Objective），前者衡量能接受的数据丢失量，后者衡量能接受的恢复时间。

类似的，备份方式也分为全量备份（快照）和增量备份，差异备份等

各个数据库服务基本上都有快照或者镜像功能，elasticsearch有提供snapshot的接口

我这个博客使用的lightsail服务本身也有备份功能，同时可以自动调整备份周期：从客户（容忍程度）和成本进行综合考虑。

小结

除了很多服务自身有灾备的功能，现在专用支持灾备的云上独立服务也很多，比如阿里的HDR-为企业级应用提供低至秒级RPO和分钟级RTO的容灾服务。类似还有DRaaS。

这里面有很多复杂的底层原理，不赘述。

下一篇文章详细的讲讲ES的灾备方案。