业务连续性

责任共担

实现云上的业务连续不中断是阿里云和阿里云客户的共同责任。

阿里云负责边缘节点服务 ENS 本身的稳定性，确保其可用性不低于服务等级协议中的承诺值。

阿里云的客户需要负责业务系统的架构设计合理性，确保能在必要时实现故障转移，保障业务连续不中断。

建议您根据本文介绍的相关方案，来建设您的边缘计算应用的业务连续性能力。

最佳实践

多实例容灾

为了确保高可用，应用必须能处理高负载、避免单节点故障造成业务中断。这些可以通过边缘负载均衡 ELB来实现。为此，您可以先在多个 ENS 实例上部署应用，然后结合ELB来实现流量负载均衡。这样即使某个 ENS 实例出现故障，ELB 仍然可以将流量分配到其他 ENS 实例上，保障业务持续可用。

跨地域主备容灾

应用的主备切换

为了避免地域级别的故障造成业务中断，在某个边缘节点上部署应用之外，还应该在其他边缘节点或公共云地域部署备份应用。

您可以借助全局流量管理服务，在出现地域级别故障时，自动将域名解析指向到其他地域的应用上，实现故障时的流量切换，保障业务持续可用。

在设计备服务时，您可以考虑将应用部署到其他边缘节点服务地域上，甚至也可以部署到其他就近的公共云地域上。不过需要注意的是，启用备服务时，终端用户访问服务的延迟可能会增大。

数据的备份和恢复

故障时流量转移可以很好地避免地域级别故障造成业务中断，但此时故障地域的数据服务也可能同样不可用。

为了让业务在备地域的应用启用期间也能正常运转，您需要根据自身的业务设计合适的方案，在非故障期间将数据从主地域同步到备地域中。

比如，您可以：

• 在应用程序中双写，向当前地域的存储服务上写入数据，同时也向备地域写入数据。这么做的好处是备地域的数据和主地域几乎是一致的，但代价是写入的延迟会增大。

• 向主地域的存储服务中写入数据后，异步地将主服务数据同步到备地域的存储服务中。这么做的好处是写入延迟不会增大，但启用备地域服务时，数据可能和主地域有一些差异。

此外，您还需要设计好应用程序的恢复机制。在主地域故障消除后，应该将备地域服务在故障期间记录的新增数据同步到主地域，确保主地域恢复时，用户看到的业务数据不会丢失。

部署架构示意图

为了尽可能地提升可用性以确保业务连续不中断，上述实践是可以组合使用的。下图是一个同时采用了负载均衡、应用主备切换、数据备份和恢复能力的系统部署架构示意图。

您可以结合自身业务的需要，来有选择地参考。

• 该系统的主服务是部署在瑞士的 ENS 节点，主服务采用了多实例加负载均衡的架构，以规避 ENS 实例单点故障引起的业务中断。

• 备服务部署在就近的德国 ENS 节点（备服务也可以选择就近的公有云地域中），备服务同样采用了多实例加负载均衡的架构。同时，主地域正常期间会将数据同步到备地域，以确保启用备地域服务时，数据尽可能的和主地域保持一致。

• 该系统的域名解析引入了全局流量管理服务：

  • 全局流量管理服务会跟进设置的频率，周期性地对主服务进行健康检查。

  • 主服务工作正常时，域名解析会指向主服务。

  • 主服务异常时，全局流量管理服务执行的健康检查失败指定的次数后，会自动将域名解析指向备服务，从而实现自动的主备切换。

• 主服务故障期间，流量切换到了备服务，数据会记录在备服务的存储服务中。因此在故障恢复后，还需要将备地域的数据同步回主地域。