19 | 分布式环境下如何快速定位问题？
何小锋
该思维导图由 AI 生成，仅供参考
你好，我是何小锋。上一讲我们学习了如何建立可靠的安全体系，关键点就是“鉴权”，我们可以通过统一的鉴权服务动态生成秘钥，提高 RPC 调用的安全性。
回顾完上一讲的重点，我们就切入今天的主题，一起看看 RPC 在分布式环境下如何快速定位问题。重要性看字面也是不言而喻了，只有准确地定位问题，我们才能更好地解决问题。
分布式环境下定位问题有哪些困难？
在此之前，我想先请你想想，在开发以及生产环境运行的过程中，如果遇见问题，我们是如何定位的？
在开发过程中遇见问题其实很好排查，我们可以用 IDE 在自己本地的开发环境中运行一遍代码，进行 debug，在这个过程中是很容易找到问题的。
那换到生产环境，代码在线上运行业务，我们是不能进行 debug 的，这时我们就可以通过打印日志来查看当前的异常日志，这也是最简单有效的一种方式了。事实上，大部分问题的定位我们也是这样做的。
那么如果是在分布式的生产环境中呢？比如下面这个场景：
我们搭建了一个分布式的应用系统，在这个应用系统中，我启动了 4 个子服务，分别是服务 A、服务 B、服务 C 与服务 D，而这 4 个服务的依赖关系是 A->B->C->D，而这些服务又都部署在不同的机器上。在 RPC 调用中，如果服务端的业务逻辑出现了异常，就会把异常抛回给调用端，那么如果现在这个调用链中有一个服务出现了异常，我们该如何定位问题呢？
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
在分布式环境下，快速定位问题是一项具有挑战性的任务。本文介绍了在RPC调用中如何应对分布式环境下的问题定位困难，并提出了两种实用的方法。 首先，文章指出了在分布式环境下定位问题的困难之处，包括复杂的依赖关系和跨团队沟通成本。针对这些困难，文章提出了解决方法。 其一，文章提出了借助合理封装的异常信息来快速定位问题。通过RPC框架打印的异常信息，包括异常类型、调用端与服务端的IP等关键信息，可以帮助快速定位问题所在，从而提高问题排查效率。 其二，文章强调了服务端业务逻辑的异常也需要进行封装，以便让服务调用方能够通过异常信息快速定位问题。 另外，文章介绍了利用分布式链路跟踪系统来快速定位问题的方法。通过将一次分布式请求还原为一个完整的调用链路，可以在整个调用链路中跟踪到每一个环节的调用情况，从而快速定位问题，降低排查问题的时间，降低沟通成本，以最高的效率解决实际问题。 总的来说，本文通过介绍分布式环境下问题定位的困难和解决方法，为读者提供了在RPC调用中快速定位问题的实用技巧。通过合理封装异常信息和利用分布式链路跟踪系统，读者可以更加高效地定位和解决分布式环境下的问题。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《RPC 实战与核心原理》，新⼈⾸单¥59
《RPC 实战与核心原理》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(13)
- 最新
- 精选
陈国林老师好，说下自己定位问题的一些经验和方法 1. 确认清楚问题的现象或本质 2. 如果时间允许可以复现下问题，对问题理解更直观 3. 查看日志，确认报错的异常信息（日志这步很关键，物理机时代通常做法是上机器grep，如果有多台机器这是比较麻烦的点，所以一般会有日志中心。容器时代的话屏蔽了Iaas层，日志都存在在日志中心，例如ELK，根据关键字就可以查了） 4. 查看代码确认业务逻辑 5. 根据日志和代码业务逻辑基本就可以确认报错的点了作者回复: 一看就很有经验
2020-04-0513
Jxin
1.tracid在碰到线程池异步时如何传递id？ 2.mq消息是否也该带上tracid？作者回复: 通过上下文或者agent
2020-04-0367
雨霖铃声声慢分布式链路系统中，最常用的调试问题方法还是文中提到的方法，主要依赖分布式调用监控系统，比如CAT，从里面可以看到是哪个链路出问题了。作者回复: 监控用时方恨少
2020-04-054
枫叶蓝opentracing ，就是需要接管业务流量才行作者回复: 👍
2020-04-3021
Darren老师应该介绍下skywalking、Zipkin等开源分布式链路跟踪的优缺点和使用问题等，毕竟能自研分布式链路跟踪的公司不多2020-04-03134
钱分布式环境下如何快速定位问题： 1：依赖公司运维基础设施的建设，比如：JD各种工具比较健全，查日志、方法监控、容器监控、网络监控等等，基础组件的问题各个运维团队支持也给力，系统问题比较好查，自身业务问题依赖自身对自己业务逻辑的理解程度，反例——如果查个日志，需要登录中控机，再登录目标机，还需输入验证码＋密码，然后找日志路径，然后使用命令查，这种方式原始低效 2：全链路追踪系统，目前还没看到做的比较好的，理想很丰满现实很骨感，如果做的好，对许多问题确实能够做到快速定位，尤其是性能问题，一下子就知道谁慢。如果各个方法都能统计，那就更棒了 3：我目前的经验，对于日志和各种监控工具依赖比较重，如果这些OK，又是业务问题，熟悉业务就能很快定位。最不好定位的是系统异常尤其是和网络通信相关且不好复现的，最常见的就是各种连接超时、socket超时、负载偶尔抖动，很令人头疼。网络认为是网络抖动了一下，就不了了之啦！具体原因则石沉大海 4：RPC封装相信的日志确实非常重要，一下子就清楚为什么了，反例——如果这些没有封装好，就只有一个连接超时，也不知道谁调谁？那个服务和方法？超时设置多少实际耗费多少，那这种问题就且查了 5：关键业务日志的打印也非常重要，多了耗性能费空间，少了排查问题不利，幸好Jd是有UCC的可以控制日志打印，不过具体打印的OK与否还要看个人经验＋代码评审2020-05-166- 小叶通过日志排错的话，产生的日志量是很大的，想问下在高并发下日志会不会有乱序的情况，rpc怎么解决这个问题2021-06-161
- hillwater全链路追踪比较麻烦的是各种中间价的支持，例如db，缓存，mq2022-10-13归属地：上海
远天老师好，实际使用skywalking链路追踪遇到一个问题，在一个trace里面 A服务多次调用B，每次调用在B服务打印的traceId都不同，这个是什么原因你们？2022-06-17- RPC1、看是否能复现，复现的目的是拿到TraceId 2、规范RPC通用返回值结果，加上TraceId，可以在ELK搜索关键线上报错信息拿到TraceId 3、拿到TraceId后去调用链平台查看详情，skywalking是真的好用，可以看到方法出入参、每个服务之间的调用耗时、SQL、Redis耗时都能看到。反而阿里内部这部分做的不是很好，不论是可视化UI还是使用感受都不好用 4、CAT监控搭配置好日志中的exception，可以从业务方法维度直接点击错误日志链接到分布式调用链后台2022-04-09
收起评论
