Grpc on Tarragon

11.C28 protobuf 官方規範：field number 紀律

Fri, 03 Jul 2026 00:00:00 +0000

這個案例的核心責任是提供 proto 演進紀律的規範錨點。

觀察

官方語言規範明文：field number 一旦訊息投入使用即不可變更、因為它就是 wire format 的欄位識別；刪欄位後必須 reserve 該編號、重用編號會使 wire 解碼歧義、後果列舉包括 parse / merge error、PII 洩漏、資料損毀。文件把 schema 變更分三類：wire-unsafe、wire-safe（加欄位、加 enum 值、刪欄位皆安全）、conditionally wire-compatible。

判讀

契約相容性在 protobuf 是編碼格式的數學性質、不是 code review 慣例 —「加法演進 + 編號永不回收」是 protobuf 相對 JSON schema 的核心工程差異、也是所有 breaking-change 工具（C29）存在的前提。

對應大綱

styles/grpc/「proto 演進紀律」（anchor）、11.6 向後相容的變更紀律交叉。

下一步路由

回模組十一案例庫。

引用源

Language Guide (proto 3)（Protocol Buffers 官方文件）

11.C29 Buf breaking detection：四級規則對應消費者依賴

Fri, 03 Jul 2026 00:00:00 +0000

這個案例的核心責任是說明相容性檢查如何工具化進 CI、以及檢查粒度的選擇邏輯。

觀察

buf breaking 對比歷史版本 schema、在 merge 前擋下如「Field 1 type int32 改 string」這類變更；規則分四級（FILE、PACKAGE、WIRE_JSON、WIRE、嚴格包含寬鬆）。文件明言「Catching this before merge is the point」、並指出破壞發生在多層 — 改名破壞 generated code、改 type 破壞 wire format — 人工 review 抓不全。

判讀

這是 C28 紀律從「人的自律」升級成 CI gate 的論證。四級規則的核心主張：「選符合消費者實際依賴的等級」— 只走 wire 的消費者用 WIRE、有外部 Go import 的要 PACKAGE。教學重點是「相容性檢查粒度是產品決策、不是工具預設」。

對應大綱

11.6 向後相容的變更紀律（工具層 anchor、已引用）、styles/grpc/「proto 演進紀律」、11.10 API 規範治理（linting 進 CI）交叉。

下一步路由

回模組十一案例庫。

引用源

Breaking change detection（Buf 官方文件）

11.C30 Buf Connect 發布文：對 grpc-go 的系統性批評

Fri, 03 Jul 2026 00:00:00 +0000

這個案例的核心責任是提供 gRPC 部署邊界的完整批評清單。Buf 是利益相關方、引用時標明；但 trailers 與瀏覽器不相容是可獨立驗證的協議事實。

觀察

發布文指 grpc-go 有 13 萬行手寫程式碼、近百個設定選項、不用 Go 標準庫而自帶 HTTP/2 實作、導致無法與其他 HTTP 流量共存；gRPC 協議要求端到端 HTTP/2 加 trailers、瀏覽器支援需要翻譯 proxy；不遵守 semver、debug 時連 curl | jq 都不可行。Connect 的對案：建在 net/http 上、同時支援 gRPC / gRPC-Web / Connect 三協議。

判讀

gRPC 的部署邊界（瀏覽器、proxy、trailers）是風格選型時常被忽略的維度 — 協議能力表不會列「你的 LB 過不過 trailers」。與 C32 的獨立批評互證後、批評點的可信度不依賴 Buf 的立場。

對應大綱

styles/grpc/「streaming 語意與部署邊界」（anchor）、11.2 風格選型（操作可及性軸、已引用）。

下一步路由

回模組十一案例庫。

引用源

Connect: a better gRPC（Buf blog）

11.C31 Dropbox Courier：百萬 RPS 規模的 gRPC 遷移

Fri, 03 Jul 2026 00:00:00 +0000

這個案例的核心責任是提供內部 RPC 選型的規模上限案例。

觀察

Dropbox 從 HTTP/1.1 加 protobuf 的自製 RPC 遷移到 gRPC、動機是保留既有 protobuf、取得 multiplexing 與雙向 streaming；在 gRPC 上疊了 mTLS 服務身分、per-method 統計、強制 deadline 傳播、LIFO queue 熔斷。踩雷紀錄：大規模重啟時 TLS 握手成本迫使 RSA 2048 換 ECDSA P-256、且 HTTP/1.1 與 gRPC 要拆成不同 server 處理。

判讀

gRPC 在 Dropbox 的價值是「框架層集中加 infra-wide 可靠性」的載體、不是序列化效能本身 — 選型判準應該看組織要不要這一層集中點。「migration 比初始開發久得多」與 TLS 握手踩雷適合當規模判讀訊號。

對應大綱

styles/grpc/「內部 RPC 的選型位置」（anchor）、11.2 風格選型（操作可及性軸、已引用）。

下一步路由

回模組十一案例庫。

引用源

Courier: Dropbox migration to gRPC（Dropbox tech blog）

11.C32 gRPC: The Bad Parts：cURL 測試不過的 API（反例）

Fri, 03 Jul 2026 00:00:00 +0000

這個案例的核心責任是提供非 vendor 立場的 gRPC 獨立批評、跟 C30 互證。

觀察

批評點：非標準術語（unary RPC）墊高學習曲線、通不過「傳一個 cURL 範例給朋友」測試、瀏覽器無法處理 HTTP trailers 需 gRPC-Web 加 proxy、HTTP/3 採用遲緩、protobuf 要求完整解析整個訊息使大檔處理容易出錯、依賴管理長期無標準。文章同時承認 Buf CLI / ConnectRPC / Postman 支援已改善部分問題。

判讀

「批評 + 承認生態已修補」的平衡結構適合直接當教材敘事骨架。cURL 測試是「debug 可及性」這個選型維度的好判準 — 協議效率表不會告訴你 on-call 時能不能徒手戳一個 endpoint。

對應大綱

styles/grpc/「內部 RPC 的選型位置」（gRPC 邊界與代價段）、11.2 風格選型（操作可及性軸、已引用）。反例 / 邊緣。

下一步路由

回模組十一案例庫。

引用源

gRPC: The Bad Parts（Kevin McDonald）