你好，我是 shengjk1，多年大廠經驗，努力構建 通俗易懂的、好玩的編程語言教程。 歡迎關注！你會有如下收益：

1. 了解大廠經驗
2. 擁有和大廠相匹配的技術等

希望看什么，評論或者私信告訴我！

零、 背景

最近趁有時間，搞一下 MCP，前面我們已經再為更進一步的 MCP 打下了基礎
一文搞定 Python 裝飾器 以及 Web架構全解析：8種類型優缺點及場景

這邊文章，我們繼續，搞一下 MCP 的 Json-rpc，目前 MCP 主要靠 json-rpc 進行 client 和 server 的通信

一、RPC vs HTTP

1.1 什么是RPC

RPC（Remote Procedure Call，遠程過程調用）是一種通過網絡在不同計算機程序之間實現服務調用的協議或技術框架。其核心目標是讓開發者能夠像調用本地方法一樣調用遠程服務，而無需關注底層網絡傳輸的細節（如通信協議、序列化、網絡連接等）。

核心特征：

• 透明性：開發者無需感知遠程調用的存在，調用邏輯與本地方法一致。
• 標準化：通過接口定義語言（IDL）或動態代理技術，統一不同系統間的數據表示、傳輸和方法調用規范。
• 跨語言支持：允許用不同編程語言編寫的服務進行交互（如 Java 服務調用 Python 方法）。

1.2 為什么需要 RPC？

RPC 的誕生源于分布式系統的需求，主要解決以下問題：

• 分布式協作

  現代應用常拆分為多個獨立服務（如電商系統的訂單、庫存服務），RPC 提供高效的服務間通信機制，使各模塊能協同工作。

• 性能優化

  相比傳統的 HTTP 短連接，RPC 通過長連接復用、二進制序列化（如 Protobuf）和協議優化（如 HTTP/2 多路復用），顯著降低網絡延遲和資源消耗。

• 服務治理

  RPC 框架內置服務發現、負載均衡、熔斷降級等能力，簡化分布式系統的運維復雜度。

• 跨語言集成

  在異構技術棧環境下（如 Java 后端與 Python 數據分析服務），RPC 提供統一的通信標準，避免各語言自行實現協議適配。

1.3 RPC 解決了什么問題？

• 網絡通信的復雜性

  RPC 封裝了底層網絡傳輸（如 TCP/UDP）、數據序列化與反序列化，開發者只需關注業務邏輯，無需手動處理網絡編程細節。

• 數據表示的異構性

  通過標準化的序列化協議（如 JSON、Protobuf），解決不同系統間數據格式差異問題，確保數據跨語言、跨平臺兼容。

• 服務發現與調用規范

  提供注冊中心（如 ZooKeeper）和動態代理機制，自動定位服務節點并生成調用代碼，避免硬編碼服務地址。

• 高并發與容錯

  支持線程池管理、請求隊列和重試策略，提升系統在高負載下的穩定性和容錯能力。

1.4 RPC vs HTTP

HTTP 和 RPC 雖然都用于網絡通信，但 RPC 的誕生并非取代 HTTP，而是為了在特定場景下彌補 HTTP 的不足，尤其是在分布式系統和高性能服務調用的需求中。以下是兩者核心差異及 RPC 存在的必要性：

一、協議設計與性能效率

• 協議效率優化

  RPC 通常采用二進制協議（如 Protobuf、Thrift）進行數據序列化，相比 HTTP 的文本格式（如 JSON/XML），二進制協議的體積更小、序列化速度更快。例如，傳輸相同數據時，Protobuf 的帶寬占用比 JSON 減少 60% 以上，解析速度提升 5-10 倍。

示例：傳輸 {“userId”: 12345, “name”: “Alice”}，JSON 需要 32 字節，Protobuf 僅需 8 字節。

• 連接管理機制

  RPC 默認使用長連接和連接池，復用 TCP 連接減少握手開銷，而 HTTP/1.1 的短連接需要頻繁建立/斷開連接（即使啟用 Keep-Alive 仍需傳輸冗余頭部）。例如，gRPC 基于 HTTP/2 實現多路復用，一個 TCP 連接可并行處理多個請求。

二、開發體驗與服務治理

• 調用方式透明化

  RPC 通過動態代理和接口定義語言（IDL）實現類似本地方法調用的體驗，例如：
  User user = userService.getUser(123); // 無需關注網絡傳輸細節

  而 HTTP 需手動封裝 URL、Header、Body，代碼復雜度更高。

• 內置服務治理能力

  RPC 框架（如 Dubbo、gRPC）集成服務發現、負載均衡、熔斷降級等功能。例如，服務節點動態擴容時，RPC 通過注冊中心（如 Zookeeper）自動通知調用方，而 HTTP 需手動修改 Nginx 配置。

三、適用場景的差異

• RPC 的主戰場

  微服務架構：內部服務高頻調用（如訂單服務調用庫存服務），要求低延遲、高吞吐（每秒數萬次調用）。

  高性能計算：金融交易、實時數據處理等場景，節省 1ms 延遲可能帶來百萬級收益。

• HTTP 的優勢場景

對外暴露 API：瀏覽器、第三方系統等異構環境兼容性強（如微信支付接口）。

快速原型開發：無需復雜服務治理時，HTTP 的 RESTful API 開發更簡單。

四、綜合對比與選擇建議

維度	RPC（如 gRpc/Dubbo）	HTTP（RESTful）
協議類型	二進制協議（Protobuf/Thrift）	文本協議（JSON/XML）
性能	高（低延遲、小帶寬）	低（高冗余、大帶寬）
服務治理	內置（負載均衡、熔斷）	依賴網關（如 Nginx）
跨語言支持	需協議適配（如 Protobuf）	天然支持
適用場景	微服務內部調用、高性能計算	前后端交互、開放 API

五、為什么需要 RPC？

• 解決 HTTP 的性能瓶頸

  在高并發場景下，HTTP 的文本協議冗余、短連接開銷、線程阻塞模型會成為性能瓶頸，而 RPC 通過二進制協議、長連接復用、異步 I/O 顯著提升效率。

• 降低分布式系統復雜度

  RPC 隱藏網絡通信細節，提供“透明化”調用，開發者只需關注業務邏輯，無需手動處理序列化、重試、超時等問題。

• 適應技術棧統一的內部協作

  在公司內部使用統一技術棧時，RPC 的強類型接口和代碼生成能力可減少聯調錯誤，提升開發效率。

六、總結
HTTP 是通用協議，適合開放性和異構環境；
RPC 是高性能專用方案，適合技術棧統一、高并發的內部服務。兩者并非替代關系，而是互補共存。
例如，對外用 HTTP 提供 RESTful API，對內用 RPC 實現微服務調用，兼顧靈活性與效率。

二 、JSON-RPC

2.1 什么是JSON-RPC

JSON-RPC 是一種基于 JSON 格式的輕量級遠程過程調用（RPC）協議，允許客戶端通過結構化請求調用遠程服務器上的方法，并獲取響應結果。其核心設計目標