人與人溝通需要共同語言，系統間數據交換同理——必須約定雙方可解析的協議。面對 TCP/UDP/管道等傳輸方式與 XML/JSON/Protobuf/Thrift/Avro 等序列化格式，如何依應用場景做最優選型？本文從開放平台、內部服務、持久化存儲、跨語言、協議升級、兼容複用六大維度，提供決策框架與實戰建議。
核心決策維度
選型前須評估：開發便利性、介面發布易度、頻寬成本、序列化/反序列化效能、協議擴展性、跨語言支援、安全性、人工可讀性、存儲空間效率。
場景一：開放式平台（微博、SNS、開放 API）
- 特徵：調用方不可控、公網暴露、高併發、需防禦非法輸入。
- 策略：優先 JSON（傳輸量小、JS 原生支援），輔以 XML 兼容舊生態。極致效能場景可提供 Protobuf + 壓縮（gzip/snappy）雙通道，節省頻寬與解析 CPU。
場景二：內部服務（微服務 RPC、資料庫/緩存/訊息隊列交互）
- 特徵：可控環境、無防火牆阻隔、低延遲、高吞吐。
- 策略：效能優先。同語系首選二進制協議；跨語言場景採用 Protobuf/Thrift/Avro 並配合 IDL 定義契約。訊息隊列可考慮 Avro（Schema 演進友善）。
場景三：持久化存儲（配置檔、日誌、離線分析）
- 權衡：人工可讀性 vs 空間/效能。JSON/YAML 適合配置；Parquet/ORC/Avro 適合大數據分析；Protobuf 適合高頻寫入場景。
場景四：跨語言整合（前端 PHP + 後端 Java 等異構棧）
強制要求協議具備多語言 SDK 支援。JSON 普及度最高；Protobuf/Thrift/Avro 提供代碼生成工具，保證契約一致性，適合強類型語言陣營。
協議演進與兼容性原則
- 向前/向後兼容：新欄位預設值、忽略未知欄位、不可刪除舊欄位、不可修改欄位類型/標識號。
- Schema 版本管理：嵌入版本號或採用 Schema Registry（如 Confluent Schema Registry）集中治理。
兼容協議的策略性複用
新產品兼容成熟協議可大幅降低採用門檻。案例：新浪開源 MemcacheQ 直接複用 Memcached 協議，客戶端零修改遷移。
總結：序列化效能即協議效能
數據交換協議本質是序列化/反序列化實現的集合。若引入 RPC 框架，框架本身的線程模型、連接池、負載均衡同樣決定整體效能。選型無銀彈，唯有「場景匹配 + 壓測驗證 + 持續演進」。
