移动互联架构升级：通讯、推送与内容分发三位一体网关实践

　　上周选题会，主编把「移动互联架构升级：通讯、推送与内容分发三位一体网关实践」扔上大屏，我差点笑出声——这题目我熟啊，去年十二月我们组刚啃完这个硬骨头，现在看它跟看自己去年拍的丑照似的，又亲切又尴尬。当时甲方死活要上这个「三位一体」网关，说是要「降本增效」，结果呢？优胜劣汰呗，那些老旧的、各自为战的模块，被我们硬塞进同一个网关里，能活下来的才是真本事。

　　说起来，这事儿能成，还真得感谢甲方那帮人「既要又要」的劲儿。他们原话是：「通讯要实时，推送要精准，内容分发要快，但服务器不能多买，运维不能加人。」我原以为这是扯淡，结果发现他们还真有底气——他们那套旧系统，通讯走的是单独的Socket服务，推送用消息队列，内容分发靠CDN，三个团队各自管各自的，数据都不互通。去年双十一，推送系统崩了，结果通讯那边还在正常发消息，用户收到一堆空消息，客服电话被打爆，运维半夜爬起来重启服务，结果发现是推送和通讯的IP池冲突了——这哪是降本增效，这是自己给自己挖坑。

　　所以去年十二月，我们组接了这个活儿，目标就一个：把三个系统揉进一个网关里，让它们能互相「看见」对方的数据。比如用户A刚收到一条通讯消息，推送系统就能根据这条消息的内容，判断要不要给他推个广告；内容分发系统也能根据用户的实时行为，调整缓存策略。听起来简单，做起来要命——通讯协议是TCP长连接，推送是HTTP短连接，内容分发是UDP，三种协议混在一起，网关得能同时处理，还得保证低延迟。我原以为得写三套协议解析器，结果老张（我们组的技术大牛）说：「别，咱们用Netty的ChannelPipeline，把三个协议的Handler串起来，共享同一个EventLoopGroup。」我当时还担心性能，结果测试下来，延迟比原来还低了15%——这老家伙，藏得够深。

　　不过最坑的不是技术，是排期。甲方要求三个月上线，我们组当时同时在做三个项目，排期表贴得显示器边都翘了角。我记得有天下午，群里一直在弹消息，说是推送模块的测试用例卡住了，原来是因为通讯模块的日志级别没调对，把推送的数据给淹了。小李（测试组的）在群里喊：「谁动了日志配置？这得重新跑一遍测试！」我抬头看了眼排期表，离上线只剩两周，键盘上F5那个键都快磨白了——改一次配置，就得重新部署，部署一次就得等十分钟，这效率，急得人想砸键盘。

　　外卖到了半天没人拿那事儿，也发生在那天。小王（前端组的）点的麻辣烫，放桌上凉透了，他还在盯着监控看推送成功率。后来还是老张看不下去，说：「先吃饭，吃饱了才有力气改bug。」结果那顿饭，大家吃得飞快，吃完又接着干——甲方催得紧，我们自己也知道，这项目要是黄了，年底奖金就悬了。

　　但最绝的是，我们刚把三位一体网关上线，甲方就要求加功能——他们说：「现在推送能根据通讯内容推广告了，那能不能根据用户的位置推？比如用户刚收到一条『附近有优惠』的消息，推送就给他推个附近商家的优惠券？」我当场就懵了——这哪是加功能，这是要重构啊！通讯模块只管消息收发，哪知道用户位置？内容分发模块倒是知道，但它和推送模块又不互通。老张却说：「行，咱们在网关里加个位置服务的中介层，把用户位置存到Redis里，推送和内容分发都从Redis读。」我当时还想，这会不会增加延迟？结果测试下来，延迟只涨了3ms——这老家伙，又藏了一手。

　　现在回头看，这个「三位一体」网关能成，真不是靠什么高大上的技术，就是靠「优胜劣汰」——那些老旧的、各自为战的模块，被我们硬塞进同一个网关里，能活下来的，都是能互相配合、能共享数据的。比如原来的推送系统，只管发消息，不管用户收没收；现在的推送系统，能根据通讯模块的确认消息，判断用户是否在线，不在线就不发，省了带宽，也省了服务器资源。原来的内容分发系统，只管缓存热门内容，不管用户实时需求；现在的内容分发系统，能根据用户的实时行为，动态调整缓存策略，命中率提高了20%。

　　不过我也得承认，这项目不是完美的。比如我们为了兼容旧系统，保留了一些冗余代码，现在想删都删不掉——甲方说：「别动，万一出问题，还得回滚。」还有，网关的监控系统，是我们临时搭的，现在看，数据不够细，出了问题得花半天时间定位。但这些都不重要，重要的是，我们证明了「三位一体」网关这条路能走通——优胜劣汰，能活下来的，就是好的。

文章配图，仅供参考

（编辑：我爱制作网_池州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!