閒聊分散式系統開發之痛 - API 與 Protocol

圖片來源：cloudave

最近在開發系統遇到了許多的困難與挑戰，也產生了滿肚子的苦水，一直常試著要把它寫下來，無奈詞窮，不知道該從什麼角度切入，不過既然是技術分享的文章，好像應該減少這些廢話與抱怨，直接切入主題比較實在？╮(╯▽╰)╭

[最後結論是...要回去多K J2EE Design Pattern...用正確的工具解決正確的問題...]

首先是API

如何設計好的API與命名一直以來都是個充滿挑戰的工作，也是令人頭痛，所以無怪乎網路上都有成千上萬的文章在討論如何設計好API，如：

• How to Design a Good, Regular API - Principle of least astonishment
• Design Beautiful REST + JSON APIs 
• 如何設計一個優秀的API
• 追求神乎其技的程式設計之道（十一）- 抽象化與命名

對於寫程式來說，只要是溝通的介面都叫做API，所以從同一種語言內部的function call、程式語言呼叫作業系統的system call or IPC (Inter process communication)、一直到系統與系統之間的RPC (Remote Producer Call)都是屬於API的範疇，但是設計的難度與要考慮的東西可是有天壤之別，而且對於一般的Application 光設計好的API就令人夠頭疼了，更不用說遇到跨系統垮語言整合的分散式系統，要考慮的層面就更多。

如何交換？如何溝通 - Protocol

根據WIki 上對於Prototocol的定義：

Protocol 通常是提供給兩種不同的技術/語言之間做整合/溝通/交換資料，而API狹義的來說通常是指同一種語言的溝通介面，當然還是可以透過某些特定的轉換Lib來轉換或借接。

為了讓不同的技術/語言要能彼此交換資訊，他們就必須先定義好一種語言中立的檔案交換格式，例如SOAP 使用XML，然後為了使用方便(物件導向語言通常用Object 在操作)，所以每種語言就會有相對應的工具來幫忙 (marshalled and unmarshalled)

那訊息如何交換? 通常透過以下幾種方式：

• RPC (Remote Producer Call)
• RMI
• Web Service
• proprietary socket command 
• Message Exchange
• JMS
• ESB
• Message Queue
• DataBase
• File Transfer 

而通常在遇到跨系統跨語言的系統整合時，會採取下面幾種模式：

• 採用Plan Text 且標準化Protocol 與結構化的語言，如XML JSON

• 優點：結構清楚，任何語言都可以實作與讀取
• 缺點：肥，相對慢

• 採用Binary 的格式，自定資料結構與序列化Serialization的方法，如Thrift、protobuf、Avro..等。
• 優點：體積小，速度快
• 缺點：針對不同的語言都必須要提供對應的SDK，也較難上手

第二種方式雖然有興趣，但是還沒有時間深入研究，有興趣的可以參考這些文章：

• Protocol Buffers, Avro, Thrift & MessagePack 
• Schema evolution in avro protocol buffers thrift  

另外也可以參考這個投影片：Thrift vs Protocol Buffers vs Avro - Biased Comparison。


下一篇文章主要是想針對使用Plan Text - JSON 在開發所遇到的問題來討論。

[Update] 有興趣的也可以參考以下延伸閱讀

[1] A fault tolerant, protocol-agnostic RPC system http://twitter.github.io/finagle
[2] Don’t Use JSON And XML As Internal Transfer Formats
[3] Modern distributed messaging and rpc