江苏龙网

  1. 首页 > 人文 > >

产业气象站|实战：通过 Component 实现多地域部署容灾，Serverless( 二 )


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


推荐阅读


上一篇：焦点科技|唐豆云店分享：传统经销商如何转型社区电商？

下一篇：雷科技|12发售日期，终于来了！苹果发布新一季财报，确认iPhone