gRPC 在內部服務間的定位是一個統一的呼叫層：身分驗證、觀測、可靠性策略在這層做一次、就套用到所有服務。選它的判準是組織要不要、也養不養得起這一層「框架層集中點」—— 序列化的位元組效率不是重點（protobuf 的序列化 REST 也拿得到）、真正換到的是這層集中能力、加上 HTTP/2 的連線層併發（multiplexing、雙向 streaming）。這一層值不值得、取決於組織有沒有平台層能集中吸收它的操作成本。本文用一個規模上限案例與一組反向成本、劃出 gRPC 落在哪個消費者形狀（誰在呼叫你的介面、部署在哪、用什麼語言）。

集中點的價值：一個規模上限案例

Dropbox 的 Courier 把自製 RPC（HTTP/1.1 加 protobuf）遷移到 gRPC、動機是 multiplexing（單連線多路併發）與雙向 streaming —— 序列化層沒有變動、protobuf 本來就在用（見 11.C31、Dropbox 一手工程紀錄）。遷移之後、他們在這條統一呼叫層上集中疊了四件可靠性能力：mTLS 服務身分、per-method 統計、強制 deadline 傳播、LIFO queue 熔斷。這四件都是「做一次、套全部服務」的 infra-wide 能力 —— 這正是框架層集中點的價值：可靠性策略不必每個服務各寫一遍。

這個案例是規模上限、要當上限讀而非通例。它成立的前提是百萬 RPS（每秒請求數）級的流量與一支能扛遷移的平台團隊。案例本身也留了兩個規模訊號：遷移比初始開發久得多、以及大規模重啟時 TLS 握手成本迫使把 RSA 2048 換成 ECDSA P-256、HTTP/1.1 與 gRPC 還得拆成不同 server 處理。這些踩雷是「有能力集中」的組織才會遇到、也才承擔得起的問題 —— 對沒有平台層集中能力的組織、它們是警訊不是路標。

反向成本：debug 可及性

集中點的價值要跟一項反向成本一起算：gRPC 的操作與 debug 可及性比 HTTP+JSON 差。這條成本在 streaming 與部署邊界 完整展開 —— on-call 不能徒手 curl、瀏覽器要 proxy、工具鏈要預先鋪好。兩相對照就成了選型位置的兩端：一端是 Dropbox 這種有平台團隊統一攤提可及性成本的組織、gRPC 的集中價值遠蓋過 debug 代價；另一端是沒有平台層、每個介面都要作者自己扛操作面的組織、集中點的價值兌現不出來、debug 代價在 on-call 現場一次次付出。

選型位置：落在哪個消費者形狀

把兩端收斂成判準：gRPC 的核心落點是「內部服務、多團隊、且有平台層能集中吸收操作成本」—— 這三者對齊、集中價值才兌現。跨語言是強放大器、不是門檻：schema-first 的跨語言契約確實是 gRPC 的長處、但全 Go 或全 Java 的內部多團隊照樣靠框架層集中拿到 mTLS、deadline 傳播、熔斷這些語言無關的能力、單語言不把 gRPC 排除掉。這一格對應 11.2 消費者形狀軸 的內部服務列。

往核心條件外走、判準就翻向別的風格：對外公開給匿名第三方、可及性與工具生態要求把答案推回 HTTP+JSON；前後端同倉全 TypeScript、契約同步的更省解是 tRPC；本地 process 間雙向低頻、JSON-RPC 的最小訊息層比 gRPC 的 HTTP/2 加 codegen 更貼；要 proto 契約與 codegen、但消費端有瀏覽器或過不了 HTTP/2 的中間層、走 Connect 這類中間協議(見 部署邊界)比純 gRPC 省事。選型的產出是把 gRPC 放對位置、不是全公司統一一種風格。

下一步路由