关于dubbo:Dubbo-ZooKeeper丨如何解决线上故障排查链路长的难题

52次阅读

共计 1471 个字符,预计需要花费 4 分钟才能阅读完成。

背景

ZooKeeper 作为通用的元数据存储组件,用处宽泛,是 Dubbo 最早反对的注册核心之一,通过长时间的磨合,目前 Dubbo 和 ZooKeeper 的组合具备很好的稳定性和扩展性。

ZooKeeper 作为 Dubbo 注册核心时,因为开源 ZooKeeper 没有提供服务注册的逻辑模型,因而对 Dubbo 服务的治理老本比拟高,存在问题排查链路长等一系列治理问题。针对这些问题,MSE ZooKeeper 最新提供 Dubbo 服务治理能力,同时联合 TopN 监控大盘,推送轨迹等自治能力,帮忙用户进步问题排查速度,集群运维效率。

服务治理

通过实例详情页中的数据管理中的服务治理来查看 ZooKeeper 中注册的服务,以及服务的提供者,订阅者信息。服务详情页展现对应的服务名以及服务类型,目前只反对 Dubbo,将来还会反对更多的服务注册类型,单击服务名进入服务详情页面。

服务详情页面展现了,服务的元信息,蕴含服务的版本,分组,利用名等信息,反对多个分组,版本展现。服务提供者信息通过更加正当的表格结构化展现,并且能够实时看到实例的高低线,权重,超时工夫等信息,可能更加清晰的把握利用的配置信息。

如果您想对 Dubbo 服务进行精细化的治理,能够将您的 Dubbo 服务接入 MSE 微服务治理。在接入服务治理的状况下,您能够通过点击接口详情按钮来跳转到微服务治理对应的页面,查看您的 Dubbo 服务的具体数据信息,蕴含服务的 QPS、延时、成功率、并发等信息。

如果您的 Dubbo 利用遇到了一些线上问题,须要在保留现场的场景下进行问题定位。您能够在跳转后的微服务治理对应的界面中找到节点详情菜单。抉择呈现问题的实例,通过右侧的服务下线按钮进行下线操作。这样就能够将出问题实例的流量摘除掉,在既保留现场又不影响业务的状况下进行问题定位。

联合 MSE 服务治理能力,可能轻松实现服务的无损伤高低线,灰度公布,使得公布过程中更加平滑,危险升高。同时联合推送轨迹性能不便查问服务提供者的高低线记录,可能帮助排查注册不上,反复注册,服务下线然而注册核心中数据未删除,频繁变更等场景。

同时通过查问订阅者的推送轨迹咱们直观看到每次服务高低线被推送的客户端状况。

同时 MSE ZooKeeper 加强了稳定性,对于异样的注册场景,Server 提供防护能力,避免因为业务侧异样导致服务宕机。

例如,某用户因为代码缺点导致 Dubbo Service Refrence 透露,ZooKeeper 中存在大量泄露的 Reference 创立的长期节点,并且因为 ZooKeeper 同步机制中的限度(可参考 ZooKeeper 避坑指南,jute.maxbuffer 的设置文章),导致服务宕机,MSE ZooKeeper 针对这种极其状况做了 Server 侧的自我爱护,在 Reference 透露的状况下会限度业务注册的无用的数据,保障 Server 的稳定性。

问题排查

对于极其状况下问题的排查,MSE ZooKeeper 提供丰盛的 TopN 大盘,联合上述的推送轨迹能力,可能帮忙用户疾速找到问题源头。例如在 Dubbo Service Refrence 这种场景下,咱们首先能够依据 TopN 大盘中的 Session Tps TopN 确定透露的 refrence 是由哪一个客户端产生的。

之后咱们通过此客户端的 SessionId,在推送轨迹中查问对应的变更记录,并通过变更记录找到问题的起因。

从推送轨迹中咱们能够看到异样 session 创立的所有的 path,从 path 中蕴含的信息能够疾速溯源到源客户端,从而找到问题起因。

作者:子葵

原文链接

本文为阿里云原创内容,未经容许不得转载。

正文完
 0