一、云通讯部署架构面临的挑战：宕机、黑天鹅事件
数据统计显示：2016年Google Cloud的宕机时间总计为47分钟，微软Azure服务宕机时间为270分钟，亚马逊AWS宕机时间为108分钟。
作为构建在IaaS之上的PaaS服务，云片为了防止云服务厂商的故障造成影响，设计了多可用区的同城双活架构，最大限度保证部署架构层面的高可用。
二、云通讯系统架构面临三大挑战
在系统架构上，云通讯系统主要面临三大挑战：
1、不同类型短信间的相互影响
不同类型的短信特点不一样，比如验证码短信实时性要求非常高，能多快就多快、营销短信虽然实时性要求没那么高，但数量巨大，峰值QPS可能会过万。
2、运营商情况复杂，稳定性问题突出
运营商的情况比较复杂，这其中会遇到各种各样的问题。首先是突发事件，比如在杭州G20期间有些通道就无法正常运转。其次有些代理商服务稳定性不高，RT会需要2-3s。另外也有些代理商会限制短信类型，比如只能发带验证码的短信。最后还有速率限制，有些通道最高2000/s，有些200/s通道间容量不一致。
3、产品频繁迭代的过程中如何保障系统稳定性
云片的产品一直在进行快速迭代，像报表、统计等功能，基本每周要发两个版本，在快速迭代过程中如何保证产品核心流程的稳定也是系统架构设计中的挑战。
基于以上挑战，云片设计了“异步解耦”的分布式系统架构。
上图是演化后的云片系统架构，异步解耦是核心，异步带来的好处是每个模块可以独立演进。首先，写记录的模块，因为它不是影响短信能否到用户手机上的核心流程，所以云片把它异步化了。另外是产品相关的模块，也通过异步日志的形式，尽量保证主流程比较稳定，并且是尽量少依赖的状态。
上图是云片系统管控模块，它很好的解决了前面所提到的问题。比如有些通道只能发包含某个关键字的短信，云片系统加了一个模块以后，通过不同的队列，不同的通道，对不同的地域发送不同的短信。另外有些通道可能卡住了，可通过监控模块监测到然后进行实时的切换。还有资源的隔离，前面提到有些通道的数据容量不一样，不同的速率对不同的资源，通过这种模式也达到了一个隔离。包括不同的业务类型进来以后，也会进入不同的通道。
云片系统架构消息中间件采用的是RocketMQ，它的所有角色节点都是无状态的，可以非常方便地实现横向扩容，另外也能够与云片系统多可用区部署的方案结合。
4、高可用系统架构设计经验分享
云片系统架构演进中有几点经验可以分享给大家。
首先关于消息队列的使用，需要有堆积的监控告警，比如出现问题时消息很容易堆积，监控报警就要做好。
其次Procedure预路由，在Procedure端，不知道发的是哪个topic，比如云片启动时，突然进来了比较高的请求，会在获取topic路由这里有个锁，整个过程就很慢，于是云片就做了预路由，实现提前去获取topic的路由。
最后云片也做了topic均衡，因为默认自动创建的topic只会在一台broker，不然在broker重启的时候就会变得不可用。
三、智能监控：保障系统稳定性的关键因素
上图是云片智能监控系统架构。完善的监控系统是稳定性的关键，云片有一个监控中心，它跟普通的用户请求是一样的，这些短信会到云片的监控机上面，然后云片开发了一个Android的App，在上面获取到短信，把这个信息汇报给监控对象。如果一段时间没收到汇报，基本可以判断某条短信的通道存在问题。此外，管控模块提供通道切换的功能，发现某个通道有问题就可以切掉，通过这种方式云片实现了智能化的通道监管和切换。
由于Android系统不够稳定，如果短信只发到一台机器上出现问题，就觉得它有bug，并且切掉的话，很可能这是一个误报。此外云片还考虑到，假如整个杭州地区出现问题，而且监控机器也全部在杭州，是否也会出现问题，如果出现问题是否都要切掉，这样会导致整个服务都不可用。基于这两方面的因素，云片监控机器是多区域分布的，通过这种方式一方面可以达到系统的智能性，另一方面可以尽可能地保障高可用性。
总的来说，云片系统架构的演进：基于系统面临的诸多挑战进行系统架构的部署，并有智能监控系统确保流程的稳定性。在系统架构设计过程中，云片网资深架构师陈涛分享了一条重要的经验，把“简单的事情”做到极致，不断进行产品迭代。
以上内容来自2017年4月16日，云片网资深架构师陈涛在QCon的主题分享：《云通讯行业背景下的稳定性架构演进》。
