共计 1130 个字符，预计需要花费 3 分钟才能阅读完成。
领英采纳 Protobuf，以实现其各类平台中更为高效的微服务间数据传递，并将其与开源框架 Rest.li 相集成。在全公司范畴的推广实现后，领英将提早升高了 60% 的同时，也进步了资源的利用率。
领英平台所采纳的是微服务架构，而多年以来，JSON 始终都是领英在微服务裸露的五万余 API 节点中所应用的序列化格局。为帮忙团队在服务间构建一致性交互，领英创立并开源了一款名为 Rest.li 的 Java 框架。
该框架可用于创立应用 REST 通信格调的服务器和客户端，并形象网络、序列化、服务发现等数据交换的诸多方面。Rest.li 框架次要反对 Java 和 Python，但也可与 Scala、Kotlin、JavaScript、Go 等语言协同运作。
Rest.li 的默认序列化格局为 JSON，这种格局反对多款语言且易于人类浏览，后者尽管益处甚多，但却给性能（尤其是提早）方面带来了许多问题。
领英工程师 Karthik Ramgopal 和 Aman Gupta 分享了在应用 JSON 进行服务间通信所要面临的挑战：
第一个挑战在于，JSON 作为一款文本格式往往过于简短，从而导致网络带宽的应用和提早减少，成果并不现实。（……）咱们所面临的第二个挑战则在于，JSON 的文本性质会导致序列化和反序列化的提早和吞吐量均不甚现实。
领英团队始终在寻求 JSON 的代替计划，一款负载大小紧凑、系列化效率高，可缩小提早并晋升吞吐量的计划。他们同时也心愿这款计划不会限度所反对的语言栈数量，并能通过将这个新的序列化机制集成至 Rest.li 从而实现逐渐迁徙。最初，通过全面的思考，领英决定采纳在各项考量中综合得分最高的 Protobuf。
将 Protobuf 集成到 Rest.li 中的次要艰难在于 PDL，一个基于框架的自定义模式定义零碎的动静模式生成。这套解决方案中需生成一个用于动静生成 Protobuf 模式定义的符号表，但依据客户端类型的不同，符号表的交付形式也会有所不同。后端客户端按需获取并缓存符号表，而网页或挪动端利用的符号表则在构建时生成，且其中蕴含版本号依赖关系。
在对框架进行批改之后，领英团队通过 HTTP 头逐渐对客户端进行重新配置，以 Protobuf 代替 JSON。采纳 Protobuf 后，响应的吞吐量均匀进步了 6.25%，申请的吞吐量均匀进步了 1.77%。领英团队同样发现对大型负载而言，提早升高了 60%。
依据对 Protobuf 的采纳所得来的教训，领英团队打算后续将 Rest.li 迁徙至 gRPC。gRPC 同样应用 Protobuf，并额定反对流式传输，其背地还有一个宏大社区的反对。
参考文档：https://www.infoq.com/news/2023/07/linkedin-protocol-buffers-…