|
|
從前，有個程序，
只有一個模塊，自己搞定所有事情，簡單又快樂地生活著。后來，干的事多了，需要劃分職責，
加了新模塊，不過他們需要彼此溝通協(xié)調(diào)工作……好在是進程內(nèi)的，如C#,Java之類的寫幾個Interface就搞定協(xié)作規(guī)范了。不過，再后來變成了兩個程序
這下麻煩更大了，因為你說話時，對方可能睡著了zzZZ。甚至，你可能需要同老外交流，更甚至，對方可能來自遙遠的半人馬座。很明顯，接口不是簡單的”interface”。
接口的本質(zhì)是一個協(xié)議——雙方交互的規(guī)范，是雙方為完成某件事情而事先做的一系列約定。約定分為三個層面：展現(xiàn)、業(yè)務和通信。業(yè)務層是核心，承上啟下，需要考慮如何直觀自然的表達業(yè)務。通信層是雙方的溝通方式。展現(xiàn)層則重在考慮溝通雙方的使用方式。如下圖：
業(yè)務層（這是核心）
一、協(xié)議的形式
- 命令式：通過一連串的指令進行交互，指令序列規(guī)定了具體執(zhí)行的步驟，即先1，再2，而3。 如：TCP的三次握手：SYN,ACK,SYN,ACK。
- 文檔式：通過文檔形式進行交互，文檔只說明要什么即目的，不規(guī)定任何執(zhí)行細節(jié)。如：REST形式的接口。
二、協(xié)議的內(nèi)容
- 命令式：請求命令有哪些，具體內(nèi)容如何。對應的響應命令有哪些，內(nèi)容又是怎樣的，正確結果如何表達，錯誤又如何表達。
- 文檔式：如何表達請求，如何表達響應，包括正常情況與錯誤情況。
通信層
一、通信方式
完成交互，還需通過一種通信方式為載體，傳遞具體協(xié)議的信息。通常通信環(huán)境有以下三種：
- 進程內(nèi) ：如一個進程內(nèi)的兩個模塊。通常將命令直接映射成一個個API，采用普通的API調(diào)用，協(xié)議設計直接簡化成API設計。
- 進程間 ：兩個進程間交互，如果有要求較高的性能，一般采用管道方式。如果需要多進程交互，可采用消息隊列方式，解耦發(fā)起方和處理方，并簡化互相間的連接管理。對于文檔風格的協(xié)議，在簡單的生產(chǎn)和消費的情況下，也可采用直接文件傳遞的方式，一方讀，另一方寫。
- 機器間：進程分布在多個機器上，可以考慮：
- 文件：在一對一的生產(chǎn)-消費模式下，最“愚蠢”文件方式有時反而是最簡單的高效。特別是異構系統(tǒng)間的一對一通信，可使用此方式，一次傳遞批量命令。
- 數(shù)據(jù)庫：多個異構系統(tǒng)間的通信，也能通過中央數(shù)據(jù)庫進行。但是，頻繁的修改和讀取同樣數(shù)據(jù)會帶來性能瓶頸和死鎖。
- 基于消息：通過一個消息系統(tǒng)傳送命令、結果和文檔。能從空間和時間上解耦發(fā)起者和處理者，兩者可以互相不知曉對方的存在，發(fā)送和處理消息可以異步進行。可以實現(xiàn)點對點或發(fā)布/訂閱方式。
- RPC：直接模仿本地調(diào)用，將一個方法調(diào)用轉換成一個數(shù)據(jù)塊，使用一種基于TCP/IP的傳輸協(xié)議進程點對點傳輸。
二、數(shù)據(jù)格式
確定通信方式后還需要考慮，傳輸時的具體數(shù)據(jù)格式。
- API方式：方法的簽名及參數(shù)
- 文件方式：文件格式（如XML，TXT，領域?qū)Ｓ械奈募袷剑ǔ＿€可定義一個描述格式的元文件，供對方根據(jù)它自動生成解析程序。如XML，需要考慮其具體Element，Attribute，通常用XSD定義。
- 數(shù)據(jù)庫：數(shù)據(jù)庫Schema。
- 消息：在MOM系統(tǒng)中使用的消息頭和消息體的具體內(nèi)容。
- RPC：自定義傳輸通道時需要考慮，傳輸數(shù)據(jù)包的格式。可采用：
展現(xiàn)層
無論業(yè)務與通信如何設計，使用者最終需通過一個API，完成交互。這個API即我們通常說的“接口”。存在兩種方式：
- 業(yè)務無關API：直接暴露下層協(xié)議細節(jié)，通過一個一般化的API完成工作。好處是對提供者而言所需工作小，可輕易跨平臺，當然消費者需要了解協(xié)議細節(jié)自行完成解析。一般用作文檔風格的協(xié)議的提供方式，如RESTful接口，可直接通過本地HTTP API使用。
- 業(yè)務專有API：即Wrapper。通過包裝器，封裝掉所有協(xié)議細節(jié)，在API上直接表達業(yè)務，簡化使用。缺點是需要提供每個目標客戶端平臺的API實現(xiàn)。
使用范圍也會影響接口的設計。如果是公司內(nèi)產(chǎn)品的交互，無論下層如何設計，通常會考慮提供包裝器，供相關團隊使用，因為客戶總是需要寫類似代碼的，不如由一個人（團隊）干了造福大家。如果是公司間產(chǎn)品的交互，在Java和.NET上，大Web服務還是不錯的選擇。一方面，雖然重，但因為有工具可以自動生成接口代碼，所以也輕了點。另一方面，大Web服務容易達成共識，因為WSDL是標準元數(shù)據(jù)格式，溝通方便。至于互聯(lián)網(wǎng)上，各式Open API都是類REST的，因為Web是天然面向文檔的，暴露的又都是資源，如此最自然，提供者所作的工作最少。至于消費者，天知道他們用什么語言平臺來訪問，只能請他們自己解析了：）
SOA中的接口
單看技術層次，SOA的核心是服務，服務有三個基本要素：契約、實現(xiàn)和綁定。契約是服務所提供功能的一個規(guī)范，重在表達業(yè)務概念；實現(xiàn)是服務的具體在語言和平臺的落地，包含提供者的實現(xiàn)和使用者的API；綁定則是服務之間的具體通信協(xié)議。分離了使用、業(yè)務表達和通信。
最后再看看經(jīng)典的ISO模型
it知識庫：研發(fā)的那些事3--接口之本，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
