背景

随着应用开始进入投放阶段，用户数量在不断的增加，虽80%用户来源于东南亚与港台，但仍有20%用户会是来自全球多个地区，当然也包括中国大陆，由于目前架构并不是异地多活，服务器、数据中心集群都分布在新加坡，地区之间端到端的网络延迟导致了常有用户会反馈网络慢、卡等问题。

网络问题分析

1. 用户所处地区距离服务器较边缘，比如跨大洲
2. 用户自身网络情况差，比如移动网络信号差、wifi速度慢等
3. 用户是大陆用户且未开启网络代理
4. 用户使用其他类似应用网络情况正常，只有使用我们的应用慢

问题排查方案

1.确定用户网络情况

我们使用了某三方的流SDK，控制台有用户运营大盘，能清晰知道用户客户端信息和网络运营商情况，可以借助其定位一下,如下图所示，能快速定位用户所属地区和网络运营商情况

2.全球网络拨测 利用阿里云的全球网络拨测工具，可以对自己的源站进行全球的网络情况探测

如图所示，我们主要先对大陆进行探测，可以很明显的看到，我们源站(新加坡)对大陆某些地区的运营商网络延迟非常之高，有的甚至达到了5秒，这是不能让人接受的，毕竟我们有些主播用户就是在大陆的，如此网络情况他们有些人是完全没法进行开播的。

再来看看境外网络的拨测情况

整体表现还是不错的，这也是为什么把源站放在新加坡地区的原因，其作为东南亚的重要贸易港口和枢纽，连接着全球的商业中心，并拥有优秀的运输和通讯基础设施，这些先进的基础设施使新加坡成为了网站和在线服务的重要托管点，也是亚洲的数字中转站。

3.问题确定

• 大陆某些地区用户网络延迟高，有些甚至无法正常使用
• 境外整体表现良好，鲜少有用户反馈网络情况差，但为了提升用户体验，实际端到端情况仍需要进行加速处理
• 目前为止应用内未进行任何网络情况的加速，需要制定网络加速方案1.0版本

全球网络优化方案1.0

敲定方案前的思考

• 了解实际用户网络分布情况
• 基于投入产出比考虑前提下进行优化
• 优化为了什么？不做能行吗？做了有实际效果吗？

未加速前网络情况

没做任务操作前全球用户的运营商都是直连源站的，源站只有一个，所以就会出现十万八千里的地方也会跨越直连的情况

CDN内容加速

对于一些静态资源，使用CDN加速无可厚非，对图片、视频、前端h5页面静态资源的加速，是必须要做，也是最容易落地和投入产出比较大的一种方式。

单纯的CDN加速对API接口有作用吗？

• 如果API接口被大量用户从不同的地方调用，并且响应时间对用户体验很重要，那么使用CDN可以加速响应时间。
• 对于不经常变化的数据，例如静态数据或者被缓存的数据，CDN是非常有用的。但是，对于实时或经常变化的数据，使用CDN可能会带来数据的不一致性，这可能是不允许的。
• 对于一些敏感或需要加密的API，可能需要额外的考虑。虽然现代的CDN提供者提供了许多安全性选项，但在配置CDN时仍然需要特别注意。
• CDN频繁的回源通常会产生额外的费用，所以，需要考虑是否增加的性能和减少的响应时间值得这些费用。

总结：有用也没用，可用也可不用，反正我不用

阿里云全站加速 DCDN 对API接口有作用吗？

• 边缘节点和二级节点间利用私有协议做传输控制，保证了高可用性和稳定快速的传输效率。
• 使用智能选路系统，可以在网络内快速找到终端用户到源站的最优路径，进一步提升可用性及传输速率

那对我们的长连接gRpc有作用吗？

• 全站加速DCDN适配HTTP、HTTP/2、HTTPS、TCP、UDP、Websocket等协议接入,gRpc底层通信协议是HTTP/2，所以是支持的。

总结：这个真有用

域名未在国内备案怎么办？

公司主体不在国内，所以无法进行国内备案，另外组织上也不会让其在国内进行备案~

解决办法(多域名加速分发)

• 重新搞一个国内主体用新域名进行备案
• 黑产买已完成备案的直接使用(慎重选择平台)

多域名加速分发怎么做？

搞了多域名后，我们可以对多域名对应不同加速地区进行加速配置了

加速分发策略1:根据客户端网络情况进行分发

1. 客户端进入App请求接口获取当前全量可用域名列表
2. 客户端每隔30s 对所有域名 连续Ping 3次 延迟低的则将访问域名替换成加速域名
3. 所有Ping发生失败兜底走源站域名继续，全过程用户无感知

加速分发策略2:根据用户IP、地区所属分配最优路线

1. 客户端进入App前先请求服务端接口获取最优路线
2. 服务端预先配置IP/地区对应的最优线路
3. 每次获取到用户IP/地区根据配置快速返回最优路线
4. 客户端根据返回的最优路线直接连接，如果失败自己继续走策略1

优化结果

总结

1. 使用CDN、DCDN加速可以解决全球大部分地区网络问题
2. 基于服务端+客户端一起的加速分发方案可以让大部分用户以最低的使用延迟使用我们的服务
3. 不需要也没必要盲目一上来就搞异地多活解决全球网络问题
4. 2.0版本会结合全局流量管理、不同厂商CDN成本控制做更精准的流量分发