云通信行业背景下云片高可用架构演进之道

1、云通信部署架构面临的挑战：宕机、黑天鹅事件

数据统计显示：2016年Google Cloud的宕机时间总计为47分钟，微软Azure服务宕机时间为270分钟，亚马逊AWS宕机时间为108分钟。

做为构建在IaaS之上的PaaS服务，云片为了防止云服务厂商的故障形成影响，设计了多可用区的同城双活架构，最大限度保证部署架构层面的高可用。

2、云通信系统架构面临三大挑战

在系统架构上，云通信系统主要面临三大挑战：

一、不一样类型短信间的相互影响

不一样类型的短信特色不同，好比验证码短信实时性要求很是高，能多快就多快、营销短信虽然实时性要求没那么高，但数量巨大，峰值QPS可能会过万。

二、运营商状况复杂，稳定性问题突出

 

△运营商状况复杂，带来诸多问题

运营商的状况比较复杂，这其中会遇到各类各样的问题。首先是突发事件，好比在杭州G20期间有些通道就没法正常运转。其次有些代理商服务稳定性不高，RT会须要2-3s。另外也有些代理商会限制短信类型，好比只能发带验证码的短信。最后还有速率限制，有些通道最高2000/s，有些200/s通道间容量不一致。

三、产品频繁迭代的过程当中如何保障系统稳定性

△产品快速迭代功能不一

云片的产品一直在进行快速迭代，像报表、统计等功能，基本每周要发两个版本，在快速迭代过程当中如何保证产品核心流程的稳定也是系统架构设计中的挑战。

基于以上挑战，云片设计了“异步解耦”的分布式系统架构。

△云片系统架构

上图是演化后的云片系统架构，异步解耦是核心，异步带来的好处是每一个模块能够独立演进。首先，写记录的模块，由于它不是影响短信可否到用户手机上的核心流程，因此云片把它异步化了。另外是产品相关的模块，也经过异步日志的形式，尽可能保证主流程比较稳定，而且是尽可能少依赖的状态。

△云片系统管理模块

上图是云片系统管控模块，它很好的解决了前面所提到的问题。好比有些通道只能发包含某个关键字的短信，云片系统加了一个模块之后，经过不一样的队列，不一样的通道，对不一样的地域发送不一样的短信。另外有些通道可能卡住了，可经过监控模块监测到而后进行实时的切换。还有资源的隔离，前面提到有些通道的数据容量不同，不一样的速率对不一样的资源，经过这种模式也达到了一个隔离。包括不一样的业务类型进来之后，也会进入不一样的通道。

△云片系统架构

云片系统架构消息中间件采用的是RocketMQ，它的全部角色节点都是无状态的，能够很是方便地实现横向扩容，另外也可以与云片系统多可用区部署的方案结合。

四、高可用系统架构设计经验分享

云片系统架构演进中有几点经验能够分享给你们。

首先关于消息队列的使用，须要有堆积的监控告警，好比出现问题时消息很容易堆积，监控报警就要作好。

其次Procedure预路由，在Procedure端，不知道发的是哪一个topic，好比云片启动时，忽然进来了比较高的请求，会在获取topic路由这里有个锁，整个过程就很慢，因而云片就作了预路由，实现提早去获取topic的路由。

最后云片也作了topic均衡，由于默认自动建立的topic只会在一台broker，否则在broker重启的时候就会变得不可用。

3、智能监控：保障系统稳定性的关键因素

△云片智能监控系统

上图是云片智能监控系统架构。完善的监控系统是稳定性的关键，云片有一个监控中心，它跟普通的用户请求是同样的，这些短信会到云片的监控机上面，而后云片开发了一个Android的App，在上面获取到短信，把这个信息汇报给监控对象。若是一段时间没收到汇报，基本能够判断某条短信的通道存在问题。此外，管控模块提供通道切换的功能，发现某个通道有问题就能够切掉，经过这种方式云片实现了智能化的通道监管和切换。

 

因为Android系统不够稳定，若是短信只发到一台机器上出现问题，就以为它有bug，而且切掉的话，极可能这是一个误报。此外云片还考虑到，假如整个杭州地区出现问题，并且监控机器也所有在杭州，是否也会出现问题，若是出现问题是否都要切掉，这样会致使整个服务都不可用。基于这两方面的因素，云片监控机器是多区域分布的，经过这种方式一方面能够达到系统的智能性，另外一方面能够尽量地保障高可用性。

 

总的来讲，云片系统架构的演进：基于系统面临的诸多挑战进行系统架构的部署，并有智能监控系统确保流程的稳定性。在系统架构设计过程当中，云片网资深架构师陈涛分享了一条重要的经验，把“简单的事情”作到极致，不断进行产品迭代。

 

以上内容来自2017年4月16日，云片网资深架构师陈涛在QCon的主题分享：《云通信行业背景下的稳定性架构演进》。

 

演讲者｜陈涛Qcon2017技术专场分享