云计算的出现为企业的管理、业务开展、资源整合等带来了极大的便利性，也是数字化建设的核心基建之一。而高可用性和稳定性是衡量一家云服务厂商最核心的标准之一。

环信作为全球领先的互联网消息云服务商，提供全面SLA99.95%的全球公有云方案，以及SLA99.99%的全球专有云方案。如何做好全球网络服务支撑，构建超低延时的SD-GMN网络，保持全球用户100毫秒以内的最佳用户体验。本次将向您讲述服务背后的技术故事，包括环信全球实时消息网络的的整体规划、运维监测和服务、技术迭代以及持续优化。

 

目录

一、全球实时消息网络的主要挑战

二、环信全球实时消息网络整体规划

三、运维监测和服务

四、拥抱边缘计算和持续迭代优化

五、结语

一、全球实时消息网络的主要挑战

环信作为国内最早提供全球消息云服务的厂商，在提供全球实时消息网络方面面临诸多挑战，主要包括新兴市场国家基础设施差、延时高，以及DNS错误等问题。其中，消息的到达率和消息的延迟是最重要的核心指标之一。

面对国内用户的时候，基于国内的5G基础设施的领先性，消息延迟基本不算问题，国内整体网络延时整体可控。根据数据统计显示：“国内最慢的重庆市时延中值84ms，那收发消息单次往返就是84ms，再加上几十毫秒的服务器处理时间，整体时间控制在100ms左右，用户几乎感受不到延迟带来的交互问题。”

 

以上数据来自speedtest.cn

早在2014年当环信向海外客户提供服务之时，受制于国外网络基础设施良莠不齐，我们会发现海外的整体网络延迟差异巨大，无法跟国内一样通过部署3线、8线bgp的机房就能基本可用，或者使用自己攒的多线机房方案。环信全球实时消息定义我们收发的消息每次延时都是在1s内，一旦超过1s我们就会感觉到有明显的延迟。因此我们的目标就是单个客户端发送消息到达服务器端不能超过100ms。最终这个问题就演变成了我们在面对海外网络的情况下如何进行解决处理来达到这个标准。

 

 

以上数据来自

https://www.cable.co.uk/broadband/world-wide-speed-league/2022/worldwide_speed_league_data.xlsx

从上面数据虽然无法看出各个国家的手机网络延时，以及由于某些国家的网络出口原因导致结果并不完全准确，但是大体上我们可以看出来网络慢的都是一些新兴市场的国家和地区。这些地区主要是非洲、南美、中亚以及西亚等地区。

我们再来计算一下网络的传输速率，由于国际网络基本都是光纤来进行传递的。光纤延时计算：t=n*L/c，c为光速，其中光速约为c=30万公里/秒；光纤的材料是二氧化硅，其折射率n为1.44左右，计算延迟的时候可以近似认为1.5。我们用这个公式可以计算下北京到上海的延迟:最快就是11ms往返。但是实际情况可能就是这个数字要乘以2或乘以3的数值。因为这里会有各个路由节点的损耗，以及光纤从北京到上海可能并不是直线，而比如中美海底光缆这样的，由于有标注整体的长度，因此很容易计算整体延时。

以下这个网站是根据Wikipedia整理的现在已有和在建的海底光缆。这里我们可以比较清楚的看到，国际光缆主要是在亚洲和北美之间的太平洋，北美和欧洲之间的大西洋。(数据来源参考网址：
https://cablemap.info/_default.aspx)

 

现在，我们已经找到了核心问题，同时定义好了目标，那就撸起袖子加油干吧！

从以上信息中我们可以看到，我们需要解决的是三个问题：

-更近的数据中心

-非发达国家的Lastmile优化

-路径选择

最后我们也将介绍一下声网环信集团的网络基础设施矩阵。

二、环信全球实时消息网络整体规划

第一：更近的数据中心

因为所有网络传输的延时最终都是跟光纤距离有关，所以我们需要将数据中心尽可能的离用户更近。于是我们分别在北美、欧洲、东南亚选取了3个地点作为海外的核心数据中心，分别覆盖各自本地的区域。非洲地区因为历史原因，非洲国家的出口网络很多都是绕道英国、法国这些发达国家。

有一种声音认为代理也可以解决，可是代理并不能解决实际数据传输的距离问题，只能是提升网络的稳定性。

因此我们在出海的选择上就选择了如下几个区域：

新加坡：覆盖东南亚、东亚、南亚、非地中海区域的西亚国家、南非、大洋洲

德国：覆盖欧洲、西亚、北非、东非、西非、中亚

美国:覆盖北美、南美

基本上环信数据中心到这些地区都控制在10000里以内，这样往返加上Lastmile的速度，基本上单程收或发消息的中值我们可以控制在100ms内。

 

新加坡数据中心主要覆盖的地区：

 

德国数据中心覆盖的地区：

 

美国数据中心覆盖的地区:

 

环信全球实时消息网络SD-GMN实测数据展示：

 

 

 

第二:Lastmile优化

这里分为两个问题点：

一个是本地跨运营商的，比如印度当地基本上每个邦都有自己的运营商，比较好的是他们基本都跟AWS这些大的运营商进行IX(InternetExchangePoint，互联网交换)。但问题点是一旦超过IX的容量就会产生拥塞。

环信的IMSDK不光使用AWSGA这些服务，同时也使用自己的FPA(终端网络加速)方案。而FPA使用的方式是在主要的邦都使用本地的运营商来进行接入，这样在网络高峰时期会更可靠，毕竟IX通常的带宽上限都不太高。

另外一个问题点是手机网络的不稳定性。这个问题在一些新兴市场国家中尤为明显。而FPA可以有效的进行弱网对抗，有效的避免了终端网络不稳定性。同时FPA也提供了水晶球的展示，这样方便观测来自各个地区，各个运营商的接入情况。

 

第三:路径选择

路径选择分为两步：

1、找到离用户最快的接入地址这个我们可以看到很多友商都会使用智能DNS这样的方式来进行处理。这样的准确性并不太高。这里主要会产生如下问题。

-用户自定义DNSServer跟他自己的运营商不匹配，虽然现在bind有扩展是支持传递用户IP的，但是还是有很多DNSServer是不支持的。

-有些DNSServer地址对于智能DNS服务提供商会有误判。

-DNS解析本身耗时。

环信首先会使用实际出口的IP来进行作为判断依据，因此我们全球部署了上百个边缘的解析节点保证就近接入。这些解析不光是按照运营商，地域这些来进行分配地址，同时也会根据RTT，传输大小来进行智能的调配。

同时为了解决一些新兴市场国家弱网的情况，我们同时支持tcp和udp不同的方式来进行获取。

2、支持多条路径

环信IMSDK支持多种路径选择，于是产生了路径选择的问题。前期在环信IMSDK里其实默认包含了3种路径，包括直连、GA、FPA这3种不同的方案，后期我们也将增加新的链路路径。

 

比如我们很多友商都是接入了AWSGA，AWS也显示了他们102个加速节点的地址。但是我们也看到了这里有一些不合理的地方。比如我们前面列的那些网络速度慢的地区，AWS基本没有做覆盖，作为创业公司在前期可以正常使用可能问题不明显,但对于真正要面向全球化的公司后期就有点力不从心了。

就算用Azure和googlecloudplatform也是一样，这几家主要覆盖欧美、日韩和新加坡地区。而这些区域其实就算直连，它们的网络延时也都挺好。

下面这个是AWSGA网络加速节点：

 

除了AWSGA，还有一些厂商在新兴市场国家拥有更多的节点：

 

环信相对于友商的核心优势是除了会用到这些公有云厂商的节点，我们也使用自建的AgoraFPA网络，我们自建的终端加速网络覆盖了全球230多个国家和地区。当我们SDK支持多条路径选择的时候，我们就需要有相应的路径选择能力，这些能力使我们掌握了更多的调度主动权。

但这些都是需要我们有足够的数据来支撑和验证:

-我们使用了250+的FPA节点来采集延迟数据。

-用户主动上报来的延迟数据。

我们也建立了全球250+节点的监测网络，这样从全球200个国家到我们核心机房的延时和丢包率我们都可以做到实时监测，这些数据将作为我们链路调度的核心依据。

 

在2022年上半年的时候，太平洋海底爆发了地震，导致从南美到新加坡的海底光缆出现了异常。当时环信的监控系统迅速的发现了这个异常情况，我们就迅速的切换了南美到新加坡的路径，不从太平洋走，而是改道欧洲，再到亚洲。这样虽然整体的延时提高了，但是根据监控和客户反馈几乎没有发生丢包现象。

我们也同时迅速报告了相关的大运营商，他们也很快的修改了整个路由走向，大家都是一样牺牲了延时来保证了稳定性。

在2022年下半年，某海外运营商从欧洲到新加坡突然完全不可用，而当时很多使用了我们多链路的客户就基本没有影响，只是有可能在第一次连接的时候产生失败后会立刻重试后面的链路，保证了整体服务的可用性。我们也立刻告知了大运营商，但是这次运营商由于对端链路宣告的原因一直过了1个多小时才恢复。

 

综上所述，如何来调度显得至关重要，网络调度里最核心的部分就是延迟和丢包，而延迟主要是由路由走向来决定的。

环信通过建立了对应的监测节点来监测主干网络的情况。通常情况下，来的路由和去的路由走向是不一样的，所以通过使用fping来ping全球所有的网段，这种结果并不完全准确，最后我们通过模拟客户网络来ping过来会更准确，这样就完成双向的路由统计，同时我们也会使用用户上报的方式来查看各个网段情况。

第四：基础设施矩阵，机房全球分布、五地三中心资源覆盖

基础资源选点：集团SD-RTN™在全球部署了250+数据中心，覆盖全球200多个国家与地区，对于主要区域的最低要求是五地三中心的资源覆盖，每个区域采用核心节点+POP点的方式。这样一旦某区域其中一个或两个机房发生故障，依靠技术可以将故障城市的流量全部切换到运行正常的机房。

供应链管理:不依赖单家供应商的基础资源(包括:机房、硬件、网络等)，当一家供应商出现问题，可以快速切换到其他服务正常的供应商。

众所周知，基础设施会因为突发的网络拥塞、硬件故障、不可抗力等因素导致或大或小的一段时间的不可用。在这样的前提下，集团SD-RTN™大网的架构师团队从设计之初就充分考虑到了基础设施的不稳定因素。如果要用几个关键词来描述SD-RTN™，那就是全球覆盖、故障实时感知与智能调度、超低延时、弹性能力、异地多活、超高并发，而一旦基础设施出现故障，SD-RTN™的故障实时感知与智能调度能力以及异地多活的构建方式将发挥重要作用，保障服务的高可用。

1、故障实时感知与智能调度：从全球来看，公网网络的波动是较为频繁的，SD-RTN™的网络嗅探服务能够实时的感知网络的质量，结合AIOps(智能运维)的分析能力，能够实现分钟级的用户迁移，保障用户的音视频体验。

2、异地多活：SD-RTN™大网将全球资源划分为多个Region(区域)，在Region内依然能够做到最低N+3(即：在最大的3个资源集群不可用的情况下，剩余的资源依然能够承接当前Region的负载)资源冗余的要求，不仅如此，Region之间依然能够形成互补的态势，某个Region故障时，可以通过互补Region进行承接。

3、灵活的弹性扩缩容能力：SD-RTN™大网的每个Region至少具备200%的实时弹性扩缩容能力，具备应对突发事件的能力，配合智能调度能够充分合理的进行资源使用。

三、运维监测和服务

随着微服务化的浪潮，运维复杂度在迅速增加，传统运维已经捉襟见肘，为此，环信投入了巨大的资源和人力解决了传统运维的痛点，从运维监测的角度来看，我们主要从以下几个方面来梳理:

1.从最终的效果来作为评判标准，选取业务上最核心的指标

1.1用户连接5秒失败率。

1.2用户收发消息1秒失败率。

1.3在线用户数。

1.4在线消息数。

1.5以上数据再通过运营商，国家地区等多种维度来进行分类。

2.梳理收发消息的完整调用链

但是随着业务越来越复杂，基础组件也越来越多，微服务化又会导致现在单个api的整体调用链会非常冗长。而由于虚拟化、容器化，导致现在的网络问题点也是越来越多，运维在做研发评审的时候也要重点关注。

因此我们一般分为网络监控，基础监控和调用链的监控。

2.1网络监控

我们需要确定各个节点之间的延时和丢包率，以及带宽的使用率，这个是需要做到秒级。

-内部延时和丢包，这里要特别注意要区分好物理层网络的丢包延时以及虚拟容器层网络的丢包和延时。

-外部网络供应商的延时和丢包。这个在监控的时候要注意区分大小包以及不同的协议。对于有多个运营商组成起来的线路，最好是分段去监测，这样后期可以快速判断。

2.2基础监控

-服务器级别，操作系统级别。这里需要注意的是Linux有些监控指标我们需要多个角度去判断。

-基础组件级别监控，包括Redis、tendis、kafka、rabbitmq、nginx、haproxy、consul等等，得益于整个prometheus的生态非常好，都有对应的exporter来监控。但是其实问题不是在监控，而是在部署架构上就需要考虑好高可用和快速的扩缩容上。

-应用服务自身的qps，负载，jvm，以及内部逻辑核心指标的上报接口的采集和监控。

2.3调用链监控

-需要有一个统一的traceid来覆盖整个调用流程。

-调用流程需要包含connect、read、response的时间，以及请求次数。

-要进行抽样，但是要保证单一链条完整性。

3.第三方拨测

3.1从外部角度来模拟监控。

3.2覆盖多种场景和地域。

4.全时区服

务针对不同时区客户的需求，环信建立了全时区运维保障团队，7*24H值班，及时处理和反馈。并在印度、美国和国内建立了一支英文的技术专家团队，为海外客户提供英文的技术和方案支持。

四、拥抱边缘计算和持续迭代优化

1.真正的边缘计算

相对于传统的管理方便的数据中心，环信正在利用边缘计算来持续优化网络服务。我们看到了诸如Mastodon这些项目，就是从一个星形的网络架构变成一个网状的网络架构。这样对于最终用户的收发消息的延时就会有极大的提高。举个例子，原先一个阿根廷的用户发送消息到阿根廷的用户，网络上会汇总到美国集群，然后再分发下来。这样整个延时就得200ms以上了。但是如果是一个网状架构，那它可能就是使用阿根廷的边缘节点就直接传输了。

但这并不是说不需要中心端了，中心端会依旧保留，包括一些管理功能，离线功能等。在边缘计算的实践方面最近环信在和国内某头部运营商相关项目上做了一些非常重大的落地。

2.自动化运维

如今行业都有一个共识，即运维复杂度在迅速增加，然而传统运维已经捉襟见肘，为此，环信持续迭代整个监控和报警系统。从早期的Ganglia、nagios、zabbix搭配opentsdb、in?uxdb，到现在的Prometheus一统天下。

为了解决传统运维的痛点：7*24H不间断保障;高一致性和高质量的执行结果;统一高效的运维效率。环信引入了stackstorm自动化执行框架来保证常见的故障可以自动化高一致性的处理完成。

同时，我们投入了巨大的资源和人力在AIOps的落地上。AIOps(智能运维)能在1分钟之内(包含了数据聚合、上报、判断、执行、恢复等整体端到端时间)识别机房异常并且自动运维。我们在具体实现中主要是快速识别问题点，这个原先是非常依赖业务运维人员的经验，以前我们内部统计的时候就发现找到问题原因平均时间为10多分钟，而现在真正处理故障或者规避故障在几分钟内就能迅速完成。

五、结语

目前环信已经服务了30多万家国内用户和数百家海外头部客户，作为2013年国内最早的即时通讯云服务商，我们早在2014年就最先在硅谷设立了团队提供海外服务支持，环信国内和海外用户积累以及技术口碑的建立与我们的持续技术迭代优化息息相关。

“写代码，是一件愉快的事”，这不仅是环信官网上的一句slogan，也是环信在成功路上不可缺少的一种特质。对于环信的团队来说，技术的创新不仅仅是一份工作、一个KPI，更是一种理想追求。日拱一卒无有尽，环信一直在为了用户体验努力前进！

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。