互联网时代最常见的远程沟通和协同办公模式——云会议，每天为成千上万的参会方提供线上面对面沟通平台，它把人们从办公室中解放出来，无论参会者身处何方，使用任何终端入会，都能够轻松愉悦地聊天讨论。
随着云会议场景不断丰富，会议需求愈加复杂，远程沟通日趋频繁的当下，原有服务平台系统已难以支撑日益增加的业务需求，全时对云会议服务系统进行了升级优化。
突破原有平台瓶颈
满足持续增长的用户和业务需求
全时云会议平台包含网络会议跟电话会议两部分，每天有数十万用户基于此平台召开远程视频会议，不过随着不断增长的用户和业务需求，原有会议平台架构服务之间高度耦合、相互依赖、部分业务出现故障……都会导致整个平台服务不稳定，业务快速迭代能力变差，再加上有部分核心服务一直单点运行，在性能和稳定性上出现多处性能瓶颈，给全时的运营带来了不小挑战。
最明显体现在跨地区/跨国会议上，当入会方太庞大数据压力太大令线路突然中断，就会令场面十分尴尬。
为了支撑快速增长的用户和会议业务需求，实现远程多方入会的方便与稳定，提升会议质量，全时云平台开始了一次大规模的分布式以及服务化改造升级，从根本上解决了数据服务单点化、各个服务器之间数据不共享、模块之间耦合度偏大等问题。
云平台架构全新升级
化繁为简 分而治之
为了突破这个瓶颈，新版云会议平台对整个架构做了比较大的调整优化，对各个业务服务模块之间化繁为简分而治之，并通过负载均衡技术对部分核心业务去除单点，集群化运行，易于扩展，在性能稳定性以及业务快速迭代能力上做了较大优化。
全时云服务化分布式会议平台的整体技术架构
在服务之间的通讯方面，由于会议平台业务服务目前使用的开发语言较多，有基于C++开发的服务（例如音视频），基于JAVA或Go开发的API服务等。而我们主要采用RPC和MQ结合的方式，统一使用Thrift协议，并把集群服务之间的通信模式统一抽象为请求-响应、发布-订阅、管道-通信三种模式，开发底层公共通信模块库（tang-mq），在底层对集群间的通信进行统一管理，简化上层服务通信逻辑。
共享缓存使用Redis Cluster，开发该模式下支持pipeline等操作的tang-cache库，并对业务数据模型进行统一的抽象和逻辑简化整理，结合新的通讯模块，对各各服务进行了比较好的解耦，使用客户端负载均衡的方式实现部分核心服务如会议业务服务（会议管理以及传输管理）的集群化支持。
对单场会议、单个服务、单个业务以及整个服务实施不同的限流降级策略，会议信令根据优先级分成不同的等级，使用漏桶限流算法，对于触发不同等级限流阈值的情况实施不同的策略，进行降级熔断处理，精细化控制，以增加整体服务的稳定性，防止因单场会议或单个服务业务异常触发雪崩效应，导致其他会议甚至整个服务不稳定。
对于录制，混音等消耗计算资源比较大的服务，定时上报资源使用率，优化分配和切换算法，支持动态扩容缩容，增加服务的稳定性和可运维性。
我们是怎么解决的
会议节点分布式部署
就近接入
会议系统是一个RTC（Real-time Communications）实时音视频通信系统，网络延时、抖动等因素都会对我们的会议质量带来较大的影响，所以我们采用“就近接入”策略选择最优会议节点，减少网络延迟、抖动。
数据采集
客户端: 服务器会根据一些策略（就近接入）结合当时服务容量或者负载情况，下发一系列的服务器IP地址列表，客户端自身会根据一定的算法对这些服务ip地址进行测速，并将网络类型，比如（WIFI，2/3/4G）；访问目标服务时的测速数据（IO次数，每次IO字节和耗时，RTT估算值等）和服务质量数据将一并生成记录上传到后端大数据中心。
服务器: 服务器这边采集接入IP归属，比如电信，联通，移动，海外及其所属省市；用户开会的规模，同一个会中所有参会人的分布情况，语音接入VoIP，PSTN的占比等等数据上传到后端大数据中心。
大数据中心基于采集的数据，通过规则对用户打上各种标签，生成用户画像，智能选择最优链路上的会议节点，最终提供给用户最优的体验。
混合部署
有很多客户有自己的私有云，他们的需求是将会议系统部署到他们企业内部，这就是混合部署。随着混合部署需求的越来越多，问题主要集中在资源、部署跟维护上。目前全时云提供了一套轻部署方案, 部署一个会议节点即可加入全时云开会，但媒体流包括录制等重要文件都在企业内部，这样就保证了绝对的安全跟私密性。
分布式整体架构图
电话会议优先
优化电话系统整体可用性
近些年来，随着业务需求的发展，如何更有效的进行公司内部、公司跟客户/供应商之间的沟通，成为困扰很多公司的问题，随之兴起的远程沟通会议系统，也从最开始简单的多方电话模式，演进到异地多方接入、网络会议融合等模式。
电话会议目前面临的主要需求和问题
全时电话会议系统，上线至今服务过几百万电话用户，面对用户规模的持续增长，全时历经几次大的架构改进，目前已形成一套高可用可扩展的电话会议系统， 以下是全时云服务分布式会议平台电话会议系统目前的架构：
这个架构目前也正处在不断演进的过程中，除了最基础的核心功能单元之外，我们在电话会议的分布式管理、会议/线路监控切换、多地同一会议接入、会议/电话实时监控等方面也做了优化工作，保证电话会议服务的整体可用和稳定。
电话服务分布式管理：全时采用多运营商、多地区相结合的方式接入线路，在地域电话路由服务中增加线路监控、负载监控，之后统一加入多电话会议服务中心，并采用优化过的负载算法及健康检查服务，当地域服务和电话服务中心线路不稳定的情况出现时，电话服务中心就能动态切换会议呼入线路，让线路不稳定问题的影响削减到最小。多区接入同一会议：在国内及国外进行分布式多点部署，就能够让接入方就近匹配站点，实现多地就近呼入同一场会议。异地节点之间的动态互联则采用专线+多路线路优化的方式，能够使音频延迟及音频传输质量达到最高级别。会议/电话实时监控：实时监控各服务中心及硬件资源情况，以实现动态预警，使软件服务及会议硬件资源能动态负载，资源负载小的组，可以动态承载移接过来的会议，当总体资源预警时，服务资源能够及时有效得到扩充。对内接口及服务：根据服务功能级别，定义HTTP及RPC（TCP）级别接口，使用Nginx或LVS等实现负载均衡，同时提供对外MQ级别的事件通知机制，外部服务按需调取相关数据，对电话核心服务提供保护。
未来为适应应用多样化需求，全时云会议将集成接入各种应用端包括插件的呼入呼出，承载更多电话接入方，使云会议服务更加稳定，我们的服务可用性SLA高达4个9以上的级别。
资源监控与统计分析
传统对机器资源的监控、进程的监控方式已满足不了日益精细化的管理需求，我们需要对会议信令进行更细化的监控和统计分析，以便及时发现系统设计或者业务逻辑可能存在的问题，比如在业务服务、入口管理、数据链路层及消息中间件等多处地方进行分析，查看各种信令数据是否异常，包括监测单个会议是否正常、入口调用超时/TPS分析、客户端数据链路数据状态等。
实际使用时，除了常规的监控以外，我们选用了业界比较流行的ELK+FileBeat等组合工具，对于某些业务的分析，采用自建数据模型+自主实现的方式，让产生的数据统一输出到ELK；对MQ中流转的会议信令采用对正常业务影响较小的方式，从MQ中新增加一组消息分析业务，横向纵向对比分析业务服务数据，以便于在服务器或客户端版本的更新迭代中提前发现并解决问题。
