本文分析了 Kitex 在作为 RPC 框架时遇到的并发问题，导致的 Client Panic 和 Server Panic 两种情况。案例揭示了并发读写可能导致的内存错误在框架编码过程中暴露，提出了解决方案，并强调了日常开发中加强代码质量的重要性。CloudWeGo 项目也被提及，提供了一系列用于构建云原生微服务的中间件。
委屈
Kitex 作为一款性能优秀的 RPC 框架，它在各业务中任劳任怨的同时，也不可避免地频繁出没在 panic 的 stack trace 里，因此承受了一些它这个年龄本不该承受的质疑和压力。
为洗 Kitex 的不白之冤，下面介绍两个典型案例。
Case 1: Client Panic
业务同学遇到 panic 监控报警，查日志中发现：
[KITEX: panic, to_service=XXX, to_method=XXX, error=runtime error: invalid memory address or nil pointer dereference
再看 panic 的 stack stace，最内层的两条是：
<kitex/pkg/protocol/bthrift.binaryProtocol.WriteBinaryNocopy(...) kitex_gen/XXXRequest.fastWriteField2(...)
最低0.47元/天 解锁文章
扫一扫
783
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
