1. 容灾调度说明
线上服务(后台服务)署地 "天津， 上海， 深圳， 香港" 四地部署
每个地方4个VIP(业务提供服务的外网IP地址, 就叫 接入IP吧) 分别为 :
移动、电信、联通、CAP(提供给小运营商接入)
这里我们要关注的几个问题:
1. APP 接入的IP是最优的吗？ （跨运营商? 跨地域? 容量饱和?）。
2. APP 接入的IP是对的吗？（不是被 劫持返回的非法IP）。
3. 接入的IP是合适的吗? (免流通道)。
2. 解决方案:
首先 app 客户端与 服务端是 TCP 长链接（用于发送在线 push）
客户端通过 tcp 三次握手后，会发送一个特殊的 handshake 数据包，为啥?
（1）验证TCP链接可用性。移动网络下会出现链接建立成功，但实际不可用的情况!
（2）验证服务器真伪。对于DNS劫持的网络，一般无法识别握手包协议(私有协议)
（3）服务器重定向。接收服务器返回新的IP来连接，后台常用来实现就近接入、容灾调度、高负载自动断链等功能
对于服务端 handshake 的作用?
( 1 )通过不同的 APP 的 appid (一个数字表示一个具体的应用), 确认接入的域名是否正确，用于调度客户端到正确的域名对应的 VIP;
详细解释: 比如 sns 业务 对应的域名为 xx.sns.com
音乐业务对应的域名为: xx.music.com
sns 和 音乐 用的是同一套 sdk, 后面因为一些bug 问题， 导致 音乐链接到了 sns 的接入机， 或者 sns 业务链接到了 音乐的接入机, 那么通过后台，可以告诉客户端正确的接入 VIP， 让客户端接入正确的接入机器(可以有效的避免业务体验问题，接入错误了业务肯定就不通了！)
( 2 ) 通过判断客户端 IP地址信息（查询 IP 库）返回给客户端最优的，对的，合适的接入 IP。
详细解释： 客户端接入后，通过 accept() 得到客户端的 IP， 查询 IP 库可以得知 客户端（国家，省份，运营商，APN信息）如果发现，接入 IP 是电信 而客户端是移动， 那么可以返回移动的 接入IP地址给客户端，避免 跨运营商的情况，同时也客户端对接入区域进行有效的统计。
（3）告诉客户端自己的出口IP地址，国家，省份，运营商，APN信息。
详细解释： 客户端上报数据进行相关统计
（4）方便快速的容灾调度
详细解释: 如最初上面所说，比如我现在要裁撤某个地方的 VIP (以天津为例子)， 那么发现客户端是通过天津地区的 VIP接入的 我可以 返回 上海 的 VIP给客户端，使得接入到天津的用户链接到上海来（这只是其中一种接入期间的调度）。
具体的实施:
这里主要是定义了一个 xml 文件， xml 文件里面 说明了
各个国家 省份对应的接入VIP，
后台通过查询客户端的 IP 返回的 IP 库信息，匹配返回对应的接入 VIP， 发现客户端的接入 IP 与 xml 里面的一致的时候那么就不用重定向了！
// 当然这里还是有很多问题是没有得到很好的解决的
1. 接入 VIP 机器故障的时候怎么处理
2. 怎么保证某个区域接入的量的合理性
3. 怎么保证 xml 配置的接入 vip 是合理的 （西藏接入 天津快？ 上海快？深圳快？ ）
//
1. 客户端通过 DNS 域名解析拿到一个合法的 VIP 后 发现接入不上怎么处理
解决： 客户端在发布的时候 内置了对应的 域名， 和 几个 VIP 地址， 发现 域名解析链接不上的时候去通过预埋的 VIP链接。（这里又得考虑好，不要又调度到了 链接不上的 VIP 那边去了， 服务端告诉客户端要调度到最优的 VIP的时候，一般是确认 与服务链接通信是 OK的才会断开，当前的链接,切换到新的链接）
2. 这里主要是容灾，现在一般保证一个区域接入容量能够接入两个区域的量，具体的做法就是 正常情况下上海的长链接量是 1000W 那么机器部署支持的接入量为 2000W+ , 保证一个区域出现故障可以安全的迁移到另外一个区域，迁移过程中不会导致雪崩。
3. 这里涉及到客户端 对 VIP 测速 以及服务端对客户端测速统计信息的分析与决策返回最优 IP （更新 xml 文件对应的VIP？ 我们这边也有一套单独的决策系统，决策系统告诉我们最优的 IP）。
随机给客户端返回一些 域名对应的VIP信息（同运营商的） 比如 新疆电信用户链接到天津后(我们最初认为链接天津是最优的)通过一些客户端命令的请求 GetTestIP 用于测速, 我们给 新疆电信用户 分别返回 (天津电信，上海电信，深圳电信 的接入 IP) 在空闲时间 用户端 app 分部给 天津 上海 深圳 电信发送测试包(ECHO包)，得到相关的 RTT 数据，上报给服务端， 服务端通过分析，最终可以确认 新疆电信用户是接入那个区域最优！
接着上面的说天津调度说
（现在要裁撤天津的VIP了，接入的时候我们可以通过握手将客户端接入调度到上海）
那么已经链接上来的怎么处理了，嗯， 我们还有 心跳机制，客户端给后台发送心跳的时候我们可以告诉客户端要重新链接，这样实现链接后的客户端的重定向；
天津裁撤了后面的客户端链接（更新 DNS 数据 保证天津用户不在链接到裁撤的 VIP上去,
走其他下发的 VIP？）
走其他下发的 VIP ？
这里主要是心跳机制 现在的心跳主要是用来下发配置给客户端， 这个时候 我们会下发一组不同区域的 VIP下去
比如 客户端心跳过来的时候 服务端会给 客户端下发，其他另外三个区域的 VIP
上海用户连接到上海后（电信IP）， 心跳的时候 会发送 上海的(移动，电信，联通， CAP， 香港的 VIP)
同时还会下方 深圳或者天津的 (移动，电信，联通， CAP， 香港的 VIP), 当 某个 VIP不可以使用的时候，可以有能力去连接其他 VIP .
心跳的一些常用的场景：
1：第一次链接
2：断开重连
3：正常心跳
4：正常心跳省电模式
5：后台切换到前台
6：前台切换到后台
481
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
