新形势下的推送系统架构升级-阿里云开发者社区

开发者社区> 安全> 正文

新形势下的推送系统架构升级

简介:

一年一度的双十一大促帷幕即将拉开作为国内第三方推送服务的领导者极光JIGUANG会采取哪些措施来应对高并发推送服务同时极光基于 ICE 打造高可用云推送平台其背后有哪些技术细节值得探索

为此我们采访了负责极光开发者服务后台推送系统大规模高并发分布式云计算体系架构总体设计研发的极光首席架构师王丰他伴随着极光一路成长见证了极光推送用户数量从0到数十亿的飞跃经历了极光推送在架构上的重构、由 VM 全面转向容器化、微服务化等过程在推送上有自己的见解。

极光推送所经历的重构

软件系统在开发和演进过程中经常会经历较大规模的重构极光推送服务经历过三次较大规模的重构

第一次是从300万用户增加到500万用户的时候原先的 UDP 替换成 TCP提高消息传输的可靠性引入 ICE 框架减轻基础部分研发工作的压力。第二次是用户数量达到6000万左右的时候各服务模块间利用 MQ 进行解耦模块的升级依赖变得简单清晰。 第三次是用户数量达到3亿左右的的时候各服务模块间缓存优化采用大规模缓存集群CB大规模 Redis 集群内存规模 T 级别。另外硬件架构方面也发生了很大变化采用万兆交换机、万兆网卡、节点满配内存。
转向容器化、微服务化的推送技术

未来极光在技术架构上由 VM 全面转向容器化、微服务化是出于什么考虑这一步走的算不算晚呢

对此王丰回答说微服务是一种新的服务设计模式开发、测试、生产三个环境可以统一给开发工作带来了极大的灵活性。容器封装了所有必须的库原来的版本依赖问题不存在了由单纯的开发、运维两阶段合并成开发运维DevOps各方面的效率都将得到很大的提升。

极光研发团队很早就关注容器技术了那时版本还是0.x。没有着急使用容器技术主要是考虑到初始版本 bug 比较多社区反馈问题也很多所以就一直在等待容器技术相对成熟和稳定之后再使用。推送提供的是电信级的服务最重要的指标是稳定、及时极光的集群规模很大很多模块都是上百个节点基础模块出问题将是灾难性的。对于新技术极光以开放的心态接纳吸收以小心谨慎的方式验证使用。

在实现推送功能的同时安全性也是要极光重点考虑的因素。为了保证安全性极光推送服务没有在数据传输过程中采用双层协议方案。王丰说安全方面API 全面切换到 HTTPS。用户接入方面现在已经提供了对称加密版本。如果还有更高的要求还可以提供 SSL 连接需求。

基于 ICE 打造高可用云推送平台

极光研发团队基于 ICE 来打造高可用云推送平台在扩容缩容、系统配置集中统一、自动负载均衡等方面更加便利那是不是云推送平台有了 ICE 就一 劳永逸了

仅仅 ICE 是不够的。

ICE 是一个分布式的网络中间件提供了通信层的完全封装能自动处理网络异常负载均衡业务部署等基础性的工作避免在这些地方重复发明轮子省时省力让研发人员的工作变得更轻松。

但是还是需要做一些调整工作比如负载的调度策略、计划支持客户端语言选择以及 ICE 对象的设计。推送系统是多种技术结合的综合体系需要 缓存、需要数据库、需要 MQ 等大量的其它技术配合。

这里可以介绍一下 ICE 的体系架构下图这个 C/S 架构左边蓝色代码部分是通过 IDL 生成的相应平台的接口各平台下可以直接调用右边是对应的接口骨架类用来容纳具体的服务端业务逻辑。

ICE 本身提供的原生服务如 Ice Grid它可以管理 Glacier2极光内部服务节点很多都是在内网如果需要跨网访问的时候要跨外网不可能把成千上万节点都给它可以通过这样做一个流量的转发就是防火墙穿越。

Ice Patch2 是一个自动化的部署有点像交付它提供专用的服务把 Server 放在这样一个目录结构里面更新一下重新计算数值后发通知所有的节点会全部更新。在更新的过程中节点可能会停一下或重启。正在处理的请求处理完之后再重新启动。请求不会在启动和停止之间丢失因为 ICE 的客户端会把这个请求正常定位到其他正在运行的节点上客户端的调用是没有感知的。

像 DBAgent、STC、TagAlias 等集群都用到了 ICE在研发过程中能节省不少精力例如不需要从 Socket 做起通过 IDL 简化协议设计提高效率扩容缩容方便不用再专门处理容灾不同语言之间的差异由框架代劳系统配置集中统一自动负载均衡连接池管理等等。

双十一临近极光在架构上也会做好充分准备以确保推送服务后台系统平稳运作主要措施如下

扩容、优化网络访问、优化内部交换机、核心路由器网络路径和网络带宽。测试选择一部分云平台必要时动态扩充服务节点应对峰值并进行相应的访问控制。
在开发极光推送服务过程中的一些感悟

极光在短短五年时间里聚集了海量用户目前有超过40万款 APP 正在使用极光推送服务终端覆盖超过50亿月活跃用户达6亿。极光推送的开发工作一直处于高速推进中有时一个应用进来就有过亿的用户连注册模块都需要高并发这一点显著区别于绝大多数公司印象尤其深刻。

王丰说尽管业务量巨大极光的后台架构开发团队却始终保持小规模短小精悍。开发采用敏捷模式快速迭代验证灰度上线。

最后王丰也谈了一个比较轻松的关于架构师修炼方面的问题除了开发能力与设计能力以外“有效沟通”也是架构师很重要的一项技能。和项目经理、销售、开发、测试人员清楚、精准地表达自己的想法是不是需要有些技巧

王丰说沟通是天天在做的事情研发团队的需求来自产品经理和销售商务没有直接的沟通。和产品经理之间主要是反复确认有疑问的需求点比如 A/B 测试拿到需求之后开会讨论、邮件、面对面的沟通业务流程。

而对于开发测试人员来说详细讲解业务的功能点接口为什么这么设计、服务模块划分的考虑因素、是否需要采用新的技术、用户将来如何用不光知其然还要知其所以然。让每个开发测试人员将自己的角色转换成用户来体验确保准确的理解业务流程。

本文转自d1net转载

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

云安全开发者的大本营

其他文章