哈啰在分布式消息治理和微服务治理中的实践

公司之前使用RabbitMQ，下面在使用RabbitMQ时的痛点，其中很多事故由于RabbitMQ集群限流引起的。

• 积压过多是清理还是不清理？这是个问题，我再想想
• 积压过多触发集群流控？那是真的影响业务了
• 想消费前两天的数据？请您重发一遍吧
• 要统计哪些服务接入了？您要多等等了，我得去捞IP看看
• 有没有使用风险比如大消息？这个我猜猜

打造分布式消息治理平台

旨在屏蔽底层各个中间件（RocketMQ/Kafka）的复杂性，通过唯一标识动态路由消息。同时打造集资源管控、检索、监控、告警、巡检、容灾、可视化运维等一体化的消息治理平台，保障消息中间件平稳健康运行。 消息治理平台设计需要考虑的点

• 提供简单易用API
• 有哪些关键点能衡量客户端的使用没有安全隐患
• 有哪些关键指标能衡量集群健康不健康
• 有哪些常用的用户/运维操作将其可视化
• 有哪些措施应对这些不健康

尽可能简单易用

• 设计指南：把复杂的问题搞简单，那是能耐
• 极简统一API：提供统一的SDK封装了（Kafka/RocketMQ）两种消息中间件。
• 一次申请：主题消费组自动创建不适合生产环境，自动创建会导致失控，不利于整个生命周期管理和集群稳定。需要对申请流程进行控制，但是应尽可能简单。例如：一次申请各个环境均生效、生成关联告警规则等。

客户端治理

监控客户端使用是否规范，找到合适的措施治理。