ZEGO是全球领先的实时音视频云服务提供商。核心创始团队和核心技术团队在音视频技术方面积累了19年以上，大部分都是腾讯、华为、中兴、YY等国内最早从事音视频研发的人员。目前，公司团队已经服务了社交直播和在线教育行业TOP 50客户的70%以上，帮助全球200多个国家/地区的近4000家企业客户获得了语音和视频能力。那么，面对这么多客户的音视频需求，该架构如何守住千万级的高并发，实现灵活调度，为客户带来高质量的音视频体验呢？
1.ZEGO分层流媒体传输架构
首先来说说接下来构建的音视频数据传输网络的架构。在流媒体传输中，分为四个平面:接入层、分发层、中转层和基础设施层，这四个平面相互连接、相互影响，比如接入层如何解决用户的接入；分发层解决了流数据如何像树一样被分发和放大；传输层解决了流量在两跳之间逐跳传输时如何加速和容错；基础设施层是为了确保成千上万客户使用的资源相互隔离共享，必要时可以应对冲击和毛刺，从而实现良好的资源管理。
依靠这样的架构，在客户的请求量和容量急剧增加的情况下，零故障可以随时灵活扩展和收缩。在这种流媒体数据传输架构下，多中心调度服务非常重要。集中调度面临三个主要问题:
第一，时间延迟会很大。例如，从香港到美国和西方可能有140-160毫秒的时间延迟。
二是长途网络传输更不可靠，波动多，故障多。
三是断层影响较大。集中调度服务在设计上非常复杂，因为它管理着一个巨大的全球网络，然后每半个月发布一次。一旦失败，影响会很大。
基于以上分析，逐步升级为多中心接入调度服务。
2.多中心调度服务
多个中心之间，即建筑是单中心设计。单中心的问题是全世界都访问同一个中心，而且总是有很长的距离，导致信令延迟很高。同时也有用户平滑迁移的需求，即在建设前会做一些隔离，不同的客户可能会被安排在不同的部署集群中，后期发现有迁移客户的需求，也有IDC容灾和远程容灾的需求，所以构建了这个多中心设计。
例如，假设欧洲、东南亚、美洲和中国有一个调度中心，主要分为两个级别:
首先是业务逻辑，它是无状态的。
第二个是底层数据库。下层分布式数据库全局同步数据，这个分布式数据库不能简单理解为类似于Cassandra的结构。即使在早期研究了跨多个IDC的全球分布式同步数据库Cassandra，但发现它们的数据实际上与业务特征非常相关。
例如，美国的两个用户进入一个房间开始交流。如果房间里的所有用户都在美国，这些数据不需要全球同步。但是，如果一个中国用户突然加入房间，他需要能够看到美国那些用户推送的流，因为他们在同一个房间是彼此可见的，所以这个时候需要数据同步。
这种按需的数据同步，包括只需要在时间触发的瞬间进行同步的特点，导致构建无法通过非常通用的Cassandra数据库来解决。如稍后将详细描述的，该构造是基于订阅的推送模式。
3.具有多级容灾能力的调度中心
具体到某一级的调度中心，比如画一个美国的中心，一个欧洲的中心，也就是我们可以看到容灾机制是多级的。首先，在一个中心，我们可以看到有多个区域，可以认为是一个校园中的两个IDC，然后在一个区域中有不同的服务器。每个逻辑模块的服务器都是多台的，由SLB无差别访问，实现了相当于服务器级、IDC级、区域级的容灾。
也就是说，在极端情况下，如果美国的调度中心出现故障，其用户可以通过一次重试轻松连接到欧洲的调度中心。当然，接入欧洲调度中心后，延迟会增加，体验肯定不如美国，但至少是可用的，比不完全不可用要好得多。
在这样的架构下，建设最初依赖于DNS解析，但建设很快发现DNS传统实践中存在一些问题:
首先，客户端IP的地理判断往往不准确；
其次，有时候会失败，意味着进行不同的DNS容错比较麻烦。因此，ZEGO DNS已经推出。ZEGO DNS实际上是一种基于各种传统DNS技术打包的DNS服务，包括HTTP DNS，加上自己IP库的操作。
然后，在请求DNS时，SDK会根据自己的操作进行多级容灾，并修正自己的数据。随着DNS的长期运行，构建的IP库变得越来越精确。
还有一个统一访问的加速层。虽然基础设施分配的接入服务器已经在附近，但实际上基础设施会采用类似云商CDN加速的技术，进一步解决附近接入的问题。
4.类订阅/发布的同步机制
这是如上所述自己定制的全局分布式数据库。当欧美的数据库需要同步时，架构会在业务层抽象一个Key，告诉美国数据库在业务层订阅哪个Key。当美国的一个用户正在一个房间愉快地聊天，突然一个欧洲用户进入房间，他正在另一个中心进行调度，这会触发同步订阅和推送，这样他们就可以看到对方。
5.传输控制层
与流媒体数据传输相比，调度服务器之间的信令传输要求更高的时延和可靠性。因此，该架构专门抽象了一个层，称为传输控制层，可以理解为类似于SDN的可靠传输层。
也就是说，购买云商的虚拟机或者运营商的IDC资源，基于这些各种形式的网络抽象构建一个SDN，可以理解为服务器和网络的进一步虚拟化。
以下图左图为例，假设运营商A的源端想要与对端的目标端进行通信，路径可能是通过公网、云商网络、跨云商的智能路由，甚至是通过国外一些运营商的IDC进行投递。在这个过程中，会根据传输信令的优先级QoS进行调度，要么使用专线，要么使用外网。
上图右侧的矩形是分布在全球的IDC中的网络质量情况。蓝色表示质量比较好，红色表示质量比较差。基于这种调度/监控机制，一旦发现网络有问题，可以立即绕过它。
下图与之前的流媒体传输类似，但侧重点不同。这里的调度服务不仅是多中心的，而且是分层的。比如上面第一层是业务调度系统，第二层强调分布式数据库，第三层是SDN虚拟网络，第四层是基础层，强调如何管理计算能力和网络。
我觉得在施工的业务中更强调分层的思想，前期施工是一个团队负责整个结构。但随着业务的发展，结构在2017年前后进行了重构。重构后的层级模式可以更好地投入人力资源，各级建设可以有序、有重点地进行。
6.音频和视频引擎
除了音视频服务架构，它还开发了自己的音视频引擎，以实现高清流畅的视频效果和高保真的音频体验。
音频技术的挑战尤为巨大。也就是说，在看实时视频的时候，突然出现模糊和卡顿。大脑其实可以根据历史信息进行重建和还原，但如果音频不清晰，交流体验就会特别差。后来施工技术团队花了很多精力优化音频。目前，建设3A语音的预处理已经处于行业顶级水平。
也就是说，它在反弱网络方面做了大量的工作。目前可以实现流畅的音视频通信，丢包率高达70%。也就是说，引入了网络自适应流量控制技术。在较好的网络环境下，引擎自动传输高帧率、高比特率的视频，在较差的网络环境下，会自动降低帧率和比特率。
7.支持多种部署方法
公有云和PaaS层的服务前面已经介绍过了。有些客户可能会说我的数据是敏感的，即构建的音视频数据无法通过您的公共网络传输。我该怎么办？
还有一个私有化部署计划，可以简单理解为打包这么一个如上所述的庞大系统，然后开着一辆小型货车去你的IDC，插上电源。
如果私有化部署不满足，那么基础设施也支持混合云的部署，即为你部署一个音视频云网，同时连接基础设施的公网。如果你的用户在公司之外甚至全球范围内工作，他可以通过公有云访问，将其交付到私有云，同时与公司的同事进行交流。也就是说已经有了私有化部署计划，接入的客户也很多，主要是数据要求严格的行业，比如金融、政府、企业。
