從前，有個程序，

只有一個模塊，自己搞定所有事情，簡單又快樂地生活著。

后來，干的事多了，需要劃分職責，

加了新模塊，不過他們需要彼此溝通協調工作……好在是進程內的，如C#,Java之類的寫幾個Interface就搞定協作規范了。

不過，再后來變成了兩個程序

這下麻煩更大了，因為你說話時，對方可能睡著了zzZZ。甚至，你可能需要同老外交流，更甚至，對方可能來自遙遠的半人馬座。

很明顯，接口不是簡單的”interface”。

????? 接口的本質是一個協議——雙方交互的規范，是雙方為完成某件事情而事先做的一系列約定。約定分為三個層面：展現、業務和通信。業務層是核心，承上啟下，需要考慮如何直觀自然的表達業務。通信層是雙方的溝通方式。展現層則重在考慮溝通雙方的使用方式。如下圖：

業務層（這是核心）

一、協議的形式

命令式：通過一連串的指令進行交互，指令序列規定了具體執行的步驟，即先1，再2，而3。 如：TCP的三次握手：SYN,ACK,SYN,ACK。

文檔式：通過文檔形式進行交互，文檔只說明要什么即目的，不規定任何執行細節。如：REST形式的接口。

二、協議的內容

命令式：請求命令有哪些，具體內容如何。對應的響應命令有哪些，內容又是怎樣的，正確結果如何表達，錯誤又如何表達。

文檔式：如何表達請求，如何表達響應，包括正常情況與錯誤情況。

??

通信層

一、通信方式

???? 完成交互，還需通過一種通信方式為載體，傳遞具體協議的信息。通常通信環境有以下三種：

進程內 ：如一個進程內的兩個模塊。通常將命令直接映射成一個個API，采用普通的API調用，協議設計直接簡化成API設計。

進程間 ：兩個進程間交互，如果有要求較高的性能，一般采用管道方式。如果需要多進程交互，可采用消息隊列方式，解耦發起方和處理方，并簡化互相間的連接管理。對于文檔風格的協議，在簡單的生產和消費的情況下，也可采用直接文件傳遞的方式，一方讀，另一方寫。

機器間：進程分布在多個機器上，可以考慮：

文件：在一對一的生產-消費模式下，最“愚蠢”文件方式有時反而是最簡單的高效。特別是異構系統間的一對一通信，可使用此方式，一次傳遞批量命令。

數據庫：多個異構系統間的通信，也能通過中央數據庫進行。但是，頻繁的修改和讀取同樣數據會帶來性能瓶頸和死鎖。

基于消息：通過一個消息系統傳送命令、結果和文檔。能從空間和時間上解耦發起者和處理者，兩者可以互相不知曉對方的存在，發送和處理消息可以異步進行。可以實現點對點或發布/訂閱方式。

RPC：直接模仿本地調用，將一個方法調用轉換成一個數據塊，使用一種基于TCP/IP的傳輸協議進程點對點傳輸。

二、數據格式

???? 確定通信方式后還需要考慮，傳輸時的具體數據格式。

API方式：方法的簽名及參數

文件方式：文件格式（如XML，TXT，領域專有的文件格式），通常還可定義一個描述格式的元文件，供對方根據它自動生成解析程序。如XML，需要考慮其具體Element，Attribute，通常用XSD定義。

數據庫：數據庫Schema。

消息：在MOM系統中使用的消息頭和消息體的具體內容。

RPC：自定義傳輸通道時需要考慮，傳輸數據包的格式。可采用：

應用層疊加：在已有TCP應用協議上再增加一層專有業務數據格式。簡單，無需考慮TCP傳輸層的編碼與解碼。如傳統WebService是 SOAP over HTTP的，在HTTP中傳輸SOAP格式的數據（如果需要也可）。

開發新應用層：直接在TCP層上增加業務專有的應用協議。需要考慮傳輸層的編碼與解碼，涉及數據分包、校驗等。如Remoting。

??

展現層

???? 無論業務與通信如何設計，使用者最終需通過一個API，完成交互。這個API即我們通常說的“接口”。存在兩種方式：

業務無關API：直接暴露下層協議細節，通過一個一般化的API完成工作。好處是對提供者而言所需工作小，可輕易跨平臺，當然消費者需要了解協議細節自行完成解析。一般用作文檔風格的協議的提供方式，如RESTful接口，可直接通過本地HTTP API使用。

業務專有API：即Wrapper。通過包裝器，封裝掉所有協議細節，在API上直接表達業務，簡化使用。缺點是需要提供每個目標客戶端平臺的API實現。

??

????? 使用范圍也會影響接口的設計。如果是公司內產品的交互，無論下層如何設計，通常會考慮提供包裝器，供相關團隊使用，因為客戶總是需要寫類似代碼的，不如由一個人（團隊）干了造福大家。如果是公司間產品的交互，在Java和.net上，大Web服務還是不錯的選擇。一方面，雖然重，但因為有工具可以自動生成接口代碼，所以也輕了點。另一方面，大Web服務容易達成共識，因為WSDL是標準元數據格式，溝通方便。至于互聯網上，各式Open API都是類REST的，因為Web是天然面向文檔的，暴露的又都是資源，如此最自然，提供者所作的工作最少。至于消費者，天知道他們用什么語言平臺來訪問，只能請他們自己解析了：）

SOA中的接口

???? 單看技術層次，SOA的核心是服務，服務有三個基本要素：契約、實現和綁定。契約是服務所提供功能的一個規范，重在表達業務概念；實現是服務的具體在語言和平臺的落地，包含提供者的實現和使用者的API；綁定則是服務之間的具體通信協議。分離了使用、業務表達和通信。

??

最后再看看經典的ISO模型

如來神掌……

??

??

?

?

轉載于:https://www.cnblogs.com/Chaos/archive/2011/03/05/1971498.html

總結

以上是生活随笔為你收集整理的研发的那些事3--接口之本的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。