引言
云计算的出现为企业的管理、业务开展、资源整合等带来了极大的便利性，也是数字化建设的核心基建之一。而高可用性和稳定性是衡量一家云服务厂商最核心的标准之一。
环信作为全球领先的互联网消息云服务商，提供全面SLA 99.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 )
现在，我们已经找到了核心问题，同时定义好了目标，那就撸起袖子加油干吧！
从以上信息中我们可以看到，我们需要解决的是三个问题：
- 更近的数据中心
- 非发达国家的 Last mile 优化
- 路径选择
最后我们也将介绍一下声网环信集团的网络基础设施矩阵。
二、环信全球实时消息网络整体规划
第一：更近的数据中心
因为所有网络传输的延时最终都是跟光纤距离有关，所以我们需要将数据中心尽可能 的离用户更近。于是我们分别在北美、欧洲、东南亚选取了 3 个地点作为海外的核心 数据中心，分别覆盖各自本地的区域。非洲地区因为历史原因，非洲国家的出口网络 很多都是绕道英国、法国这些发达国家。
有一种声音认为代理也可以解决，可是代理并不能解决实际数据传输的距离问题，只 能是提升网络的稳定性。
因此我们在出海的选择上就选择了如下几个区域：
新加坡：覆盖东南亚、东亚、南亚、非地中海区域的西亚国家、南非、大洋洲
德国：覆盖欧洲、西亚、北非、东非、西非、中亚
美国 : 覆盖北美、南美
基本上环信数据中心到这些地区都控制在 10000里以内，这样往返加上 Last mile 的速度，基本上单程收或发消息的中值我们可以控制在100ms 内。
新加坡数据中心主要覆盖的地区：
德国数据中心覆盖的地区：
美国数据中心覆盖的地区:
环信全球实时消息网络 SD-GMN 实测数据展示：
第二: Last mile优化
这里分为两个问题点：
一个是本地跨运营商的，比如印度当地基本上每个邦都有自己的运营商，比较好的是他们基本都跟 AWS 这些大的运营商进行 IX(Internet Exchange Point，互联网交 换)。但问题点是一旦超过 IX 的容量就会产生拥塞。
环信的 IM SDK 不光使用 AWS GA 这些服务，同时也使用自己的 FPA(终端网络加速) 方案。而 FPA 使用的方式是在主要的邦都使用本地的运营商来进行接入，这样在网络 高峰时期会更可靠，毕竟 IX 通常的带宽上限都不太高。
另外一个问题点是手机网络的不稳定性。这个问题在一些新兴市场国家中尤为明显。而 FPA 可以有效的进行弱网对抗，有效的避免了终端网络不稳定性。同时 FPA 也提 供了水晶球的展示，这样方便观测来自各个地区，各个运营商的接入情况。
第三: 路径选择
路径选择分为两步：
1、找到离用户最快的接入地址
这个我们可以看到很多友商都会使用智能 DNS 这样的方式来进行处理。这样的准 确性并不太高。这里主要会产生如下问题。
- 用户自定义 DNS Server 跟他自己的运营商不匹配，虽然现在 bind 有扩展是支持传递用户 IP 的，但是还是有很多 DNS Server 是不支持的。
- 有些 DNS Server 地址对于智能 DNS 服务提供商会有误判。
- DNS 解析本身耗时。
环信首先会使用实际出口的 IP 来进行作为判断依据，因此我们全球部署了上百个 边缘的解析节点保证就近接入。这些解析不光是按照运营商，地域这些来进行分 配地址，同时也会根据 RTT，传输大小来进行智能的调配。
同时为了解决一些新兴市场国家弱网的情况，我们同时支持 tcp 和 udp 不同的方 式来进行获取。
2、支持多条路径
环信 IM SDK 支持多种路径选择，于是产生了路径选择的问题。前期在环信IM SDK 里其实默认包含了
3 种路径，包括直连、GA、FPA 这 3 种不同的方案，后期我们也将增加新的链路路径。
比如我们很多友商都是接入了 AWS GA，AWS 也显示了他们 102 个加速节点的地址。但是我们也看到了这里有一些不合理的地方。比如我们前面列的那些网络速度慢的 地区，AWS 基本没有做覆盖，作为创业公司在前期可以正常使用可能问题不明显, 但 对于真正要面向全球化的公司后期就有点力不从心了。
就算用 Azure 和 google cloud platform 也是一样，这几家主要覆盖欧美、日 韩和新加坡地区。而这些区域其实就算直连，它们的网络延时也都挺好。
下面这个是 AWS GA 网络加速节点：
除了 AWS GA，还有一些厂商在新兴市场国家拥有更多的节点：
环信相对于友商的核心优势是除了会用到这些公有云厂商的节点，我们也使用自建的 Agora FPA 网络，我们自建的终端加速网络覆盖了全球 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™ 的网络嗅探服务能够实时的感知网络的质量，结合 AI Ops ( 智能运维 ) 的分析能力，能够实现分钟级的用户迁移，保障用户的音视频体验。
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，更是一种理想追求。日拱一卒无有尽，环信一直在为了用户体验努力前进！
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
