一.长连接服务灰度变更问题
- IM系统都有一个长连接服务（这个长连接服务是netty与客户端建立长连接的），在灰度变更的时候对于这个长连接服务，旧版本是v1，新版本是v2，先把v2灰度上线了，双版本共存，把一部分流量（用户）引到v2上，验证没问题以后全量引流，把所有流量都引流到v2，完成版本变更。
- 我想问的问题是：
- 把一部分流量从v1引流到v2，那是不是要v1版本的这部分用户主动断开和客户端的长连接，然后和v2的服务端建立长连接？
- 如果如（1）所说，这部分用户和v1断开连接，和v2建立连接，这个过程如果用户发消息是不是就失败了？
- istio可以实现这部分用户再次建立链接的时候，路由到v2建立长连接吗？
二.IM系统怎么做推拉结合？
- IM系统中用户信息变更/状态变更，目前我们采用的推模式为主，即：用户状态发生变化--》查找订阅该用户的人（可能是把这个人加为好友，可能是和这个人在一个群里等）--》把该用户状态发生变化的信息广播给所有订阅了该用户的人
- 我想问的问题是：
- 因为不知道订阅了哪些人订阅了该用户，所以会把该用户的状态变更信息广播给所有长连接服务，由所有长连接服务器去判断本次要通知的用户是不是这个长连接服务纳管的，这样子效率很低，大佬们有没有什么更好的办法呢？
- 我们系统里订阅的标准很多：比如只要a点开过b的资料,a和b聊天过,a和b打过电话,a和b在一个群里等等，这样会导致一个用户会订阅起码1000+用户，按照10w用户算，早上批量上线的时候10w*1000=1亿，大概会广播1亿条状态变更消息，这个量实在太恐怖了，大家有什么好的办法吗？既能保证实时又能保证性能
