本文摘要:中通快递天天有数千万的运单在各个环节运转,每个环节都有对应的多套业务系统来支撑,业务系统之间上下游关系较为密切,从上游的客户订单到下游转运、结算、分析等每个环节都离不开消息中间件,它主要解决了系统之间的耦合、业务的削峰填谷、异步通信、数据同步和冗余存储等等功效需求,是现有系统架构中不行或缺的重要一环。

od体育app

中通快递天天有数千万的运单在各个环节运转,每个环节都有对应的多套业务系统来支撑,业务系统之间上下游关系较为密切,从上游的客户订单到下游转运、结算、分析等每个环节都离不开消息中间件,它主要解决了系统之间的耦合、业务的削峰填谷、异步通信、数据同步和冗余存储等等功效需求,是现有系统架构中不行或缺的重要一环。在2015年中通开始大量接纳消息中间解决一些特定的问题,随着业务的增长,各环节有了更精致化的产物,我们消息中间件的数据体量越来越大,集群规模越来越多,中间件也越来越多样化,统一治理这些消息中间件变得尤为重要,因此我们研发了中通消息中间件平台 ZMS,主要基于 RocketMQ+Kafka 两套业界比力主流消息中间件,提供了自动化部署、主题/消费者的申请审核、统一的SDK、治理控制台、监控诉警到无感知扩容迁移等一系列运维的功效,现在ZMS治理了17个集群,包罗 7个 Kafka 集群和 10个 RocketMQ 集群,主题近2000个,消费组3000+,消息存储空间凌驾140TB,日均消息流转更是到达千亿级别。ZMS 从最初的版本演进到现在基本凭据每个阶段的痛点差别,解决差别的问题。

其生长阶段或许分为如下三个维度展开。经公司内部评估,ZMS 已经发展为一套相对成熟的消息中间件云平台化解决方案,可以正式对外开放,与社会上的同行配合打磨,故决议于2020年5月26号正式开源,将代码推送到 github 堆栈。

★ 堆栈地址:https://github.com/ZTO-Express/zms01自动化运维与部署自动化运维部署,主要是利便运维人员可以快速通过ZMS平台向导式初始化一个集群,其架构设计如下图所示。zms-portal:zms 治理后台,可同时治理多个情况的资源,包罗:添加主机、服务,消息集群状态监控、设置消息集群告警规则,消息集群资源治理等。

备注:所谓的情况我们可以简朴看成是开发情况、测试情况、高保真情况、生产情况。在每台机械上首先需要安装 zms-agent (署理服务)、supervisor 等基础组件,为了利便运维,ZMS 提供了一键初始化主机的剧本,自动在目的主机上安装基础服务组件,其操作流程如下:运维人员只需要去指定的机械上复制上述下令即可。这样实现的目的是 zms-portal 无需治理宿主机械的用户名、密码等敏感信息,做到宁静可控。

zms 能自动感知安装了 zms-agent 的机械并将其纳入 zms-portal 的治理运维体系。在 ZMS 中我们统一将 Kafka、RocketMQ、ZK、监控指标收罗、监控诉警等统一看成是一个服务,在差别的情况中可以选择性的安装,其操作如下图所示:02统一的客户端 SDK基于中通业务的特点项目中主要接纳了 Kafka 与 RocketMQ 两种差别的消息中间件,如果业务方在自己项目中既要使用 Kafka 的消息中间件,又要使用 RocketMQ 的消息中间件,对于消息中间件的使用来说要求很是高,因为需要相识这些相似又差别的 API,划分相识其设置参数与其代表的寄义,因此为业务方提供统一的 API 显得尤为重要与迫切。

zms-sdk 的主要设计理念:﹡ 屏蔽底层消息中间件类型,提供统一尺度的API。﹡ 提供尺度的埋点,利便打造完备的监控体系。﹡ 云平台化,开发人员只需关注 TOPIC、消费组自己,无需关注 TOPIC 存储在哪个集群上,即 TOPIC、消费组b被界说成资源,用户只需按需向平台申请 topic、消费组即可。

zms-sdk 的整体架构设计如图所示:主要的交互与设计要点如下:﹡ 运维人员通过 zms-portal 在线安装集群,集群的元数据将会存在 zookeeper 中。﹡ 开发人员通过在 zms-portal 申请 topic、消费组。

﹡ 运维人员在 zms-portal 中对用户的申请举行审批,并凭据用户的需求分配到适合的集群中,topic 所在集群等元信息会写入到 zookeeper中。﹡ 开发人员通过 zms-sdk 向所申请的 topic 发送消息,zms-sdk 内部会从 zk 获取 topic 对应的元信息并建立对应的客户端,最终完成消息的发送。整个设计的焦点是引入 zookeeper 作为元数据的存储堆栈,并充实使用其事件监听机制,能完成许多“高峻上”的功效,例如主题在线迁移功效。

试想一下在双十一等大促场景,如果一个集群负载很高从而到达瓶颈,一方面是可以对集群举行扩容,另外一种可行的方法是将该集群中的 topic 迁移到其他空闲集群,正是依托于 zookeeper 的事件机制,应用客户端无需重启就可以自动感知 topic 的设置发生了变化,从而重新构建到新集群的客户端工具,完成消息发送的不停机在线迁移。03监控数据收罗服务对消息中间件举行监控并举行可视化展示是运维最基本的需求,RocketMQ、Kafka 消息中间件自己提供了监控数据的收罗并存储在各自的服务器内存中,可是是非持久化的,在内存中只存储当前时间段的挪用信息,并随着时间的推进,旧的数据将被删除。固然 RocketMQ、Kafka 都提供了相应的API利便客户端收罗存储在服务端内存中的监控数据。ZMSCollector 的职责就是定时向 RocketMQ、Kafka 集群收罗相关的挪用信息并持久化到 influxdb 中,为后续的可视化展示提供须要的基础,ZMSCollector 已经被服务化,可以通过 zms-portal 在线安装。

od体育app

ZMSCollector 的整体架构设计如下图所示:ZMSCollector 的整体设计比力简朴,一方面通过定时调理的方式挪用底层消息中间件提供的 API,将监控指标存储到 influxDb,另外一方面收罗 zms-sdk 收罗的监控数据,zms-sdk收罗的监控数据会发送的一个牢固的 topic ,ZMSCollector 订阅指定的 topic,对消息举行加工后存储在 influxDb 中。04多机房解决方案现在中通在异地容灾方面还刚刚起步,现在只需要实现同城机房冷备,即一个机房的入口网络发生故障,将流量切换到另外一个备份机房即可。ZMS 消息中间件运维平台天然支持多机房的部署架构,因为在 ZMS 的视野中,一个差别的机房就相当于一个情况,可以直接在 zms-portal 中完成一个新机房的安装部署服务。

但由于发生故障后,两个机房内部的网络有可能会断开,故两个机房中的元数据应该离开存储,即 zms-sdk 所依赖的 zookeeper 集群差别,故需要完成 zookeeper 元数据的同步,该事情由 ZMSBackupCluster 服务来负担,其架构设计如下图所示:其基本的设计思路是 ZMSBackupCluster 订阅待同步机房的 zookeeper,一旦元数据有发生变化,会根据设置集群元数据映射关系将其同步到目的机房的 zookeeper中,这样部署在备份机房中的应用可以无感知的接受主机房中所有的消息发送与消息消费任务。05zms-portal 部门界面展示zms-portal 提供了集群自动化安装部署、主题消费组审批、种种监控报表可视化报表,接下来展示部门界面,详细请移步 zms 开源堆栈。06ZMS 开源信息中通科技正式开源内部的消息Pass云平台化产物ZMS,堆栈地址:https://github.com/ZTO-Express/zms ,包罗了 ZMS 的使用说明、架构设计文档、技术交流群。

开源只是完成万里长征第一步,后续希望更多的开源喜好者加入到该项目中,配合打造一体化的智能消息运维平台。接待大家前往我们的堆栈,关注我们、加入我们。


本文关键词:中通,消息,服务,运维,平台,实践,已,od官网app下载,开源,【

本文来源:od官网app-www.yijunhs.com

中通消息服务运维平台实践(已开源)【od体育app】

建筑设计

作 者:admin

时 间:2021-12-19

在线咨询
联系电话

075-89399731