2013年7月30日 星期二

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


圖片來源:cloudave


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

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

首先是API


如何設計好的API與命名一直以來都是個充滿挑戰的工作,也是令人頭痛,所以無怪乎網路上都有成千上萬的文章在討論如何設計好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,也較難上手

    第二種方式雖然有興趣,但是還沒有時間深入研究,有興趣的可以參考這些文章:
    另外也可以參考這個投影片: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

    沒有留言 :