中年Serverless 实战：通过 Component 实现多地域部署容灾 |地域|部署|

作者 | 刘宇
策划 | 田晓旭
单点故障是实际生产中无法避免的，单副本的存储方案也早已无法满足业务的可靠性要求。现在，我们通常都会做双机存储架构，会涉及到主备、主从、主主模式。

本文插图
在 Serverless 架构下，高可用方案或者容灾方案是否还需要主备、主从以及主主等模式？如果还需要，那么又是什么样子？
1 Serverless 与多地域部署
针对服务可用性，几乎每个云厂商都会有非常高的承诺，但是我们也不能掉以轻心，认为不会出现故障导致不可用，容灾方案是必须要有的。
在传统主机时代有主备、主从以及主主模式，这个模式更多针对的是单台机器或者某个集群。但是在 Serverless 架构下，没有机器和集群的概念（至少在用户层面没有），是不是就表示在 Serverless 架构下无法做容灾？
理论上，云厂商会保证整个服务的可用性，如果云厂商管理的某个机器出现故障，机器会被及时剔除，确保新的函数在安全、稳定、健康的环境下启动，正常提供服务。但在实际情况中，由于某些原因，云厂商也可能会在某个地域出现大规模故障，这时如何确保服务依旧可用，而不是苦苦等待云厂商的恢复？
针对单地域解析的网站，我们可以实现多地域的主备方案。在云函数中，多地域的主备方案更加经济实惠，因为函数是按量付费的，完全可以将函数复制到其他的地域，只要不进行触发，就不会产生额外的费用。相对于传统主机时代的主备模式，这种主备方案显得更加人性化。
一般情况下，单地域部署的服务中比较容易出问题的是 API 网关服务、云函数服务、数据库服务。其中，数据库服务可以考虑跨地域主从、跨区域同步，一旦出现问题，就在函数中做一个负载，确保整体数据不会出现问题，在腾讯云的云数据库描述下可以看到：
本地 IDC 机房 MySQL 数据库与云数据库 MySQL 之间可以通过数据迁移服务实时同步数据，本地 IDC 机房如遇到断电、网络故障等引起数据库服务中断，可迅速切换数据库服务至作为灾难备份的云数据库 MySQL 实例，实现数据库容灾；同时，云数据库 MySQL 可支持同城多可用区灾备 / 跨城灾备，保障高可用。所以说，数据库相关服务的容灾可以通过备用数据库来提高可用性。
那么云函数和 API 网关怎么解决？
以多地域部署容灾为例，我们可以考虑这样的架构：

本文插图
同样是作为单地域解析服务，相对来说，多地域部署更加安全稳定，一旦某个地域的服务出现问题（例如 API 网关，云函数），都可以通过监控程序及时发现，并且迅速切换解析到其它地域。多地域部署的监控函数与时间触发器进行结合，定期进行网站可用性的排查，一旦出现问题，就可以在云解析层面进行解析切换，实现单地域服务的多地域部署容灾方案：

本文插图
这个方案的逻辑是先请求服务是否可用，如果不可用，则获取容灾列表，剔除不可用的服务，并通过云解析进行可用区的解析。在实际生产中，一旦确定某个服务不可用，还要进行精确告警，在获得到不可用解析记录对应的服务之后，通过邮件或者企业微信、短信等方法进行告警。
至此，一个简单版的“高可用”服务就算做好了，有的读者可能有所疑问：
对服务进行修复，是否比切换解析更加靠谱呢？
针对问题 1 ，其实切换解析是需要时间的，虽然一小部分的机房可能不会按照设定的 TTL 进行生效，但是大部分的机房都是可以按照设定及时生效，所以需要注意的是，在添加解析的时候要尽可能地确保 TTL 时间短一些，目前腾讯云的云解析付费版最低 TTL 可以设置为 1s ，免费版是 600s 。