严选消息中心管理平台建设实践

消息中心作为电商业务场景必不可少的核心组件,自严选上线以来,就开始了建设和演进迭代之路。截止目前,消息中心已接入200+服务,1500+消息,覆盖基础技术、供应链、分销客售、主站、交易订单、数据算法等严选所有业务场景。本文对于消息中心的技术架构演进不做详细叙述,重点介绍面向业务使用方的消息中心管理平台建设实践经验。,消息中心作为电商业务场景必不可少的核心组件,自严选上线以来,就开始了建设和演进迭代之路。截止目前,消息中心已接入200+服务,1500+消息,覆盖基础技术、供应链、分销客售、主站、交易订单、数据算法等严选所有业务场景。,本文对于消息中心的技术架构演进不做详细叙述,重点介绍面向业务使用方的消息中心管理平台建设实践经验。,通过广泛沟通收集需求,在消息中心研发运维过程中,经常会碰到如下痛点问题:,定位和处理上面这些问题,通常会花费较长时间,极大影响研发效率,更严重的还会影响线上业务。因此,亟需一个面向业务开发的消息中心管理平台,提高研发效能:,面向业务使用方:为了提升各位业务开发同学对各自负责系统的消息收发治理和问题排查定位的效率,建设严选消息中心管理平台,通过整合串联不同系统间的消息链路,统一并标准化定义消息链路的关键节点,基于元数据进行统计分析从而配置报警监控,最终达到整个严选技术体系降本增效的目的。同时,通过自动化工单闭环消息发布、下线、消息订阅、取消订阅完整生命周期管理,入驻严选DevOps管理平台天枢,将消息中心融入整个DevOps研发体系。,核心思路就是通过提升消息中心的可观测性,通过消息中心管理平台给用户提供可视化配置管理能力。一个好的可观测系统,最后要做到的形态就是实现Metrics、Tracing、Logging的融合:,在严选消息中心场景,在尽量复用现有组件能力的原则下,获取这三者数据的具体执行路径如下:,消息中心以HTTP Proxy的模式对外提供服务,业务方不感知底层消息中间件,提供HTTP异步方式的发布订阅功能。由如下三部分构成了消息中心:,完整的消息链路如下图所示:,图片,节点定义如下:,不同的用户视角关注的消息链路是不同的,用户只需聚焦于自己的对应的消息链路即可:,图片,数据源主要是基于如下三部分日志,可串联整个消息链路:,复用日志平台现有功能,在日志平台配置业务日志采集任务,此处不详述。,按需在数仓平台配置T+1的离线分析任务,在严选实时计算平台配置运行自定义flink任务,聚合时间窗口可根据实际情况配置,主要指标如下:,​支持如下两个维度的消息链路查询:,提供拓扑和日志两种视图模式,供用户进行切换展示。​,图片,图片,拓扑视图下可点击查看消息内容、消费失败原因、发送耗时、消费耗时、端到端延迟。默认展示消息的所有消费者,用户可点击筛选只展示自己感兴趣的消费者消费链路。,图片,图片,可筛选查看topic 【指定时间范围内 + 指定时间间隔】的聚合指标数据,相关统计图具体如下:,图片,图片,图片,图片,图片,系统管理员不关注具体某个topic,而是关注消息中心集群的整体运行情况,相关统计图表具体如下:,图片,图片,图片,图片,支持从消息主题、发布方、订阅方三个维度分页查询消息元数据信息,主要包括消息主题、发布方CMDB服务编码、订阅方CMDB服务编码、订阅url等相关配置,具体如下:,图片,可点击消息详情,查看消息元数据、消息格式、消息示例信息,具体如下:,图片,可点击消息拓扑查看图形化的发布订阅关系,具体如下:,图片,可查看消息失败重试策略,工单申请调整重试策略,具体如下:,图片,可查看报警配置,消息订阅方所属服务技术负责人可调整告警配置,主要分为两种类型的告警:,图片,报警的指标数据是通过flink实时任务聚合采集存入Ntsdb,告警通知对接严选告警平台,告警接收人员即为线上服务所对应的线上监控人员角色。,当消息中心上下游系统出现异常时,只要确保消息已成功投递到消息中心,消息中心可提供自助补推功能,来辅助业务快速恢复。支持根据消息id或者消息状态筛选查询指定时间范围内的消息,来决定是给消息的所有订阅者推送还是给某个订阅者推送。,图片,消息推送对操作人进行严格的数据权限隔离:,消息补推属于高危操作,所有操作都会进行记录进行事后审计跟踪,并可查看每条推送记录的具体详情:,图片,通过自动化工单闭环消息发布、下线、消息订阅、取消订阅完整生命周期管理,入驻严选DevOps管理平台天枢,有机的将消息中心融入整个DevOps研发体系。,图片,同时将消息工单作为一个变更事件,基于天枢平台自动将测试环境的工单同步到线上。同时作为需求发布上线的风险变更管控卡点项,有效规避漏申请消息发布/订阅的情况而导致的业务异常。,图片,消息中心管理平台自上线以来,受到了不少业务方的好评,也广泛收集建议进行了一些功能迭代优化,初步达成了预期目标:,消息中心管理平台下一步的重点方向是数字化建设,借鉴当前比较流行的FinOps执行路径:成本展示 -> 成本分析 -> 成本优化:,当然,作为一个消息中心管理平台,对于底层消息中间件的运维、部署、监控也是必不可少的。当前在严选的落地实践是,广泛调研并引入开源组件EFAK、rocketmq-dashboard,二次开发接入严选监控告警体系,再结合严选OF监控,低成本、高效的解决了消息中间件集群及机器维度的运维监控管理问题。至于后续是否需要将这部分功能统一集成到消息中心管理平台,需要结合实际业务诉求和成本收益再进行决策。

文章版权声明

 1 原创文章作者:cmcc,如若转载,请注明出处: https://www.52hwl.com/18955.html

 2 温馨提示:软件侵权请联系469472785#qq.com(三天内删除相关链接)资源失效请留言反馈

 3 下载提示:如遇蓝奏云无法访问,请修改lanzous(把s修改成x)

 免责声明:本站为个人博客,所有软件信息均来自网络 修改版软件,加群广告提示为修改者自留,非本站信息,注意鉴别

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023年3月5日 上午12:00
下一篇 2023年3月7日 下午10:34