中年Serverless 实战:通过 Component 实现多地域部署容灾( 二 )


针对问题 2 , 在云函数上运行服务很少会因为流量太高导致服务不可用 , 或者服务中存在 bug 导致整个项目不可用 , 因为云厂商会解决很大一部分的可用性 , 例如流量并发问题等 。 另外 , 就算是程序中存在 bug , 在 Serverless 架构下 , 函数的前一次后一次运行实际上关联性不大 , 所以完全可以通过告警来确定 , 人为排查消灭隐患 。 事实上 , 在 Serverless 架构下出现大规模服务性灾难 , 多数情况都是云厂商的问题(此处已经排除掉用户代码层面的 bug) , 而这种问题一旦出现 , 就不是我们能够掌控的了 , 是否可以修复、什么时候修复 。
中年Serverless 实战:通过 Component 实现多地域部署容灾
本文插图
如果是 API 网关层面出现问题 , 可以通过上一层来解决 , 例如云解析的切换;如果是函数层面出现问题 , 可以考虑切换到 API 网关到同区域的备用函数;如果是函数服务的整个区域性故障(概率非常低) , 可以考虑切换解析到备用区 。
如果不是单地域提供服务 , 那么就需要考虑多地域部署、多地域就近接入以及多地域容灾方案 。
【中年Serverless 实战:通过 Component 实现多地域部署容灾】
中年Serverless 实战:通过 Component 实现多地域部署容灾
本文插图
从上图可以看到 , 我们将一个域名 , 划分地域进行解析 , 例如华北、华东两个地区 , 就可分别解析到北京 1 区、北京 2 区两个不同的机房中两台不同的服务器上 。 当其中一个服务不可用时 , 其他区域不受影响 , 可以使用云函数对解析进行修改 , 将其解析到每个地区的备用服务上 。
中年Serverless 实战:通过 Component 实现多地域部署容灾
本文插图
整体结构图:
中年Serverless 实战:通过 Component 实现多地域部署容灾
本文插图
传统的服务需要每个地区部署多套服务 , 无疑大大增加了成本 , 但是在 Serverless 架构下 , 即使部署了多套云函数还是按量付费 , 大大节约了成本 。
若采用 Serverless 架构作为后端服务 , 以华北地区为例 , 华北地区用户在访问后端服务的时候 , 通过 DNS 重定向到北京区的 API 网关 , 然后再由 API 网关触发北京区云函数 , 此时我们需要两个云函数对服务进行监控 , 一个函数对云函数进行监控 , 当云函数服务失效之后 , 可以将 API 网关绑定到备用的函数上 , 另一个监控是对 API 网关进行监控 , 当某个地域的 API 网关失效之后 , 可以对解析进行修改 , 重定向到备用地域的 API 网关上 , 尽可能快速的保证服务的可用性 。
如果想要让服务更稳定 , 可以增加数据库 / 对象存储的主备与监控 , 以及数据库 / 对象存储封装函数的主备与监控 , 这样就可以在四个层次做监控告警以及服务保障:在我们的服务中 , 通常数据库或者存储模块不会同时在多个区域部署 , 也可能只有一套主备服务 , 此时 , 可以通过对数据库和对象存储做一层封装 , 即在外层增加一个对应的函数 , 通过内网对数据库以及对象存储进行数据转发等 , 通过外部云函数调用 invoke(专线调用)大幅度降低由于网络原因造成的延时 , 当云数据库 / 对象存储出现问题 , 在接入层(数据库 / 对象存储封装函数)一侧 , 进行切换 , 将云数据库 / 对象存储切换到备用服务上 , 并进行告警;当接入层发生故障 , 无法继续服务时 , 在逻辑函数初(北京区 / 上海区 / 广州区) , 切换封装函数 , 即通过内部专线(函数间调用)调用备用接入层函数;同理 , 当逻辑函数 / 业务函数出现故障 , 监控脚本对 API 网关侧的后端服务进行切换 , 切换到备用逻辑函数 / 业务函数上;如果当 API 网关出现故障 , 无法继续提供服务 , 则只能在解析层面做切换 。 在整个这样的一个流程中 , 每一阶段或者说每一层面都有自身的负载机制 , 主备策略 , 可以根据不同组件出现故障的实际情况 , 进行多层级的自动切换 , 进而保证业务可用时长的一个最大化 。