京东京麦TCP网关服务化架构实践
|
京麦TCP网关是基于Netty4.x+Protobuf3.x实现的高可用、高性能、高稳定的TCP长连接网关，对接京麦pc、android、ios、mac 4个客户端实现上下行通信。TCP网关的架构实现和上下行通信等具体原理及代码细节可参考张松然老师的博客（链接：http://linkedkeeper.com/detail/blog.action?bid=1042）。本文重点介绍京麦TCP网关服务化架构的演进与实践。 概述 京麦是京东商家一站式工作平台，是商家在京东开店必备的工具。TCP网关主要负责与客户端的上下行通信，保证客户端的稳定。TCP网关如今承载着京麦客户端日均上亿次的调用量，一套高可用、高性能、高稳定的架构对于保证客户端稳定，提升京东商家体验与办公效率至关重要。 总体架构 下图为TCP网关的总架构图，下面简单讲一下每个模块的作用。
1. 客户端通过域名+端口的方式访问TCP网关，TCP网关基于Netty实现，保证了高质量的通讯。客户端与服务端的通信数据均需加密，登录时数据采用RSA加密，创建Session管理机制构建会话层来提供应用层服务，后续请求采用aes加密，aes秘钥由客户端随机生成。客户端与TCP网关的通信协议是Protocol Buffer，保证了数据传输效率，通信协议分为协议层和数据层，协议层包含客户端版本、设备号、加密协议、oauth校验参数等信息。 2. TCP网关负责接入客户端的channel链接，处理客户端的请求，返回处理结果，同时负责将下行通知推送给客户端；TCP网关会对客户端每一个请求做oauth校验，通过时间戳、签名、token认证等机制保证安全，拦截恶意请求；TCP网关通过心跳机制和断线重连机制管理客户端的链接，及时关闭掉长时间无通信过期的链接；TCP网关支持泛化调用，泛化可以理解为通过配置和协议转化直接调用JSF接口（JSF是京东服务框架，可以类比为阿里的HSF），而不需要每次有新需求都要在网关增加Protocol Buffer对象，定义新接口，具体架构及原理下面篇幅单独介绍；TCP网关是京麦客户端平台所有请求的入口，构建一套完善的监控系统对于保证客户端稳定、实现提前预警和降级处理至关重要，后面会有单独篇幅介绍TCP网关的监控平台。 3. 京麦服务中心负责提供京麦工作台一些核心的业务接口，比如插件接口、店铺经营数据接口等，实现业务与网关的隔离。服务中心按接口的重要程度将接口实现隔离，核心的接口单独部署，同时可对非核心接口实时降级，保证故障期间客户端的高可用。 4. 其他业务线的服务中心可以理解为京东其他部门的原子服务中心，比如订单中心、商品中心等。京麦服务中心会依赖其他部门的接口服务。京麦是京东商家开放平台，随着业务的壮大，会有其他团队直接对接客户端里的部分频道页，但又不能提供多个网关给客户端增加客户端的复杂度，所以TCP网关支持了泛化调用，通过配置和协议转化直接调用其他部门接口，同时可实时对接口进行降级处理。 5. 京东商家关心的消息都可以通过京麦触达到商家，京麦消息中心负责对接上游消息源，通过配置实现协议统一，将消息进行存储、记录日志并分发给TCP网关。TCP网关实现在线通知和离线提醒。消息系统的架构后面篇幅单独介绍。 消息架构 下图为京麦消息系统架构图，Anycall是京东商家消息中间件系统，负责接收各业务中心的订单、商品、商家等消息，进行统一的消息过滤、转换、存储，及监控和统计等。Anycall处理消息后再将消息推送到订阅该消息的商家系统，目前京麦客户端的消息大部分来源于Anycall。自定义消息是运营可在后台配置消息定向推送。下面简单阐述下消息系统的实现。
1. 消息中心负责接收上游系统消息，根据消息源不同分发到不同的broker，消息中心有一个配置中心，作用是把上游消息和京麦消息关联起来，按照不同的协议处理消息； 2. 消息中心按照不同的协议生成消息体和离线推送消息，客户端解析消息并根据协议打开特定页面； 3. 消息存储在Hbase集群，消息追踪日志存放在Elasticsearch集群； 4. 消息中心可实现根据消息源、消息类型实现多维度的降级处理，通过mq重试保证消息不丢； 5. 消息中心将消息统一推送到TCP网关，TCP网关读取用户消息设置，判断是否推送在线通知和离线提醒； 6. 在线通知是通过MQ广播机制到所有服务器，所有服务器收到消息后，获取当前服务器所持有的所有Session会话，进行数据广播下行通知； 7. TCP网关基于 Netty 构建了HTTP2 协议的推送服务，将消息推送到苹果APNs服务器。由于苹果APNs服务器经常会主动断开链接，TCP网关实现了定时重连和一键重连的功能； 8. TCP网关对接了华为、小米、魅族，保证使用这些厂商手机的商家能够接受离线提醒消息； 9. TCP网关也支持根据消息类型实现多维度的降级，保证核心消息的触达； 10. 客户端负责消息的展示，当获取到在线通知时更新消息列表，更新消息未读数，当商家点击消息时根据协议请求服务端启动特定页面。 服务化框架 下图为京麦TCP网关服务化框架，支持各业务线提供服务接口与客户端直接对接，既可以基于Protocol Buffer开发接口，也可以只关注业务，由网关负责处理Protocol Buffer协议与客户端对接。下面简单阐述下原理。
1. 注册中心基于zookeeper开发，管理后台发布或变更接口，接口信息保存到zookeeper，TCP网关配置中心监听zookeeper各节点数据变化，同步更新本机jvm cache中接口配置信息； 2. cmd是与客户端约定的接口关键字，根据cmd可判断是平台接口还是服务化接口，平台接口直接通过java反射找到网关中的代理接口，调用后端服务中心接口； 3. 服务化接口需要首先从jvm cache中获取接口配置，如果找不到直接从zookeeper获取。然后看接口是否降级，降级则直接异常返回。然后进行限流，限流目前是基于semaphore信号量做的漏桶限流，降级开关和限流阈值都在接口配置信息里； 4. 责任链可以理解为一组handler，用来处理限流降级、参数拼装、生成泛化实例、泛化调用、结果处理等逻辑。一个cmd有唯一一组责任链，存储在配置信息里。可通过java反射找到每一个handler实例； 5. 管理后台的功能目前开放给了京麦咨询团队和京麦服务市场团队，与客户端定义好协议后直接在管理后台发布接口并联调，网关只做透传，极大提升了京麦平台的端能力，减少了接入成本。 总结 本篇文章粗浅的向大家介绍了京麦TCP网关服务化架构的实践，重点介绍了TCP网关总体架构、京麦消息架构、TCP网关服务化框架及京麦监控平台架构。由于作者水平有限，难免有些技术点阐述有误，请读者批评指正。京麦目前的TCP网关已相对稳定，足以支撑京东的商家使用京麦客户端，但不可否认目前还有很多待优化的地方，比如离线推送应该拆离TCP网关单独提供服务等，望广大读者多多给出优化建议。 本文校对：张俊卿 本文受原创保护，未经作者授权，禁止转载。 linkedkeeper.com (文／郝文欣) ©著作权归作者所有 |
