作者 | Rafal Gancarz
譯者 | 馬可薇
策劃 | Tina
領英採用協議緩衝區（Protocol Buffers），以實現其各類平台中更為高效的微服務間數據傳遞，並將其與開源框架 Rest.li 相集成。在全公司範圍的推廣完成後，領英將延遲降低了 60% 的同時，也提高了資源的利用率。
領英平台所採用的是微服務架構，而多年以來，JSON 一直都是領英在微服務暴露的五萬餘 API 節點中所使用的序列化格式。為幫助團隊在服務間構建一致性交互，領英創建並開源了一款名為 Rest.li 的 Java 框架。
該框架可用於創建使用 REST 通信風格的伺服器和客戶端，並抽象網絡、序列化、服務發現等數據交換的諸多方面。Rest.li 框架主要支持 Java 和 Python，但也可與 Scala、Kotlin、Java、Go 等語言協同運作。
Rest.li 伺服器和客戶端之間的數據流和控制流（來源：Rest.li 文檔）
Rest.li 的默認序列化格式為 JSON，這種格式支持多款語言且易於人類閱讀，後者雖然好處甚多，但卻給性能（尤其是延遲）方面帶來了許多問題。
領英工程師 Karthik Ramgopal 和 Aman Gupta 分享了在使用 JSON 進行服務間通信所要面臨的挑戰：
第一個挑戰在於，JSON 作為一款文本格式往往過於冗長，從而導致網絡帶寬的使用和延遲增加，效果並不理想。（……）我們所面臨的第二個挑戰則在於，JSON 的文本性質會導致序列化和反序列化的延遲和吞吐量均不甚理想。
第一個挑戰在於，JSON 作為一款文本格式往往過於冗長，從而導致網絡帶寬的使用和延遲增加，效果並不理想。（……）我們所面臨的第二個挑戰則在於，JSON 的文本性質會導致序列化和反序列化的延遲和吞吐量均不甚理想。
領英團隊一直在尋求 JSON 的替代方案，一款負載大小緊湊、系列化效率高，可減少延遲並提升吞吐量的方案。他們同時也希望這款方案不會限制所支持的語言棧數量，並能通過將這個新的序列化機制集成至 Rest.li 從而實現逐步遷移。最後，經過全面的思考，領英決定採用在各項考量中綜合得分最高的協議緩衝區（Protobuf）。
將協議緩衝區集成到 Rest.li 中的主要困難在於 PDL，一個基於框架的自定義模式定義系統的動態模式生成。這套解決方案中需生成一個用於動態生成 Protobuf 模式定義的符號表，但根據客戶端類型的不同，符號表的交付方式也會有所不同。後端客戶端按需獲取並緩存符號表，而網頁或移動端應用的符號表則在構建時生成，且其中包含版本號依賴關係。
在對框架進行修改之後，領英團隊通過 HTTP 頭逐步對客戶端進行重新配置，以 Protobuf 替代 JSON。採用協議緩衝區後，響應的吞吐量平均提高了 6.25%，請求的吞吐量平均提高了 1.77%。領英團隊同樣發現對大型負載而言，延遲降低了 60%。
JSON 和 Protobuf 的延遲比較（來源：領英將協議緩衝與 Rest.li 集成以提高微服務性能）
根據對協議緩衝區的採用所得來的經驗，領英團隊計劃後續將 Rest.li 遷移至 gRPC。gRPC 同樣使用協議緩衝區，並額外支持流式傳輸，其背後還有一個龐大社區的支持。
具體請見 InfoQ 博客：API 間的對決：REST vs. GraphQL vs. gRPC：該用哪一種？（https://www.infoq.com/podcasts/api-showdown-rest-graphql-grpc/）
英文原文：
LinkedIn Adopts Protocol Buffers for Microservices Integration and Reduces Latency by up to 60%（https://www.infoq.com/news/2023/07/linkedin-protocol-buffers-restli/）
C# 和 Type 之父親自帶隊開源 TypeChat，又一 AI 技術瓶頸被攻破？
終於找到 ChatGPT 「智商」下降的原因了！OpenAI 側面回應，GPT 可能真被你們玩壞了？
微信取消秋招；谷歌軟體工程師基本年薪超 500 萬；通報批評員工到點下班？比亞迪回應 | Q資訊
十年磨礪，持續闖入「無人區」，這家公司如何做好金融科技？