從前，有個程序，

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

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

加了新模塊，不過他們需要彼此溝通協(xié)調(diào)工作……好在是進程內(nèi)的，如C#,Java之類的寫幾個Interface就搞定協(xié)作規(guī)范了。

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

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

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

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

業(yè)務(wù)層（這是核心）

一、協(xié)議的形式

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

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

二、協(xié)議的內(nèi)容

命令式：請求命令有哪些，具體內(nèi)容如何。對應(yīng)的響應(yīng)命令有哪些，內(nèi)容又是怎樣的，正確結(jié)果如何表達，錯誤又如何表達。

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

??

通信層

一、通信方式

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

進程內(nèi) ：如一個進程內(nèi)的兩個模塊。通常將命令直接映射成一個個API，采用普通的API調(diào)用，協(xié)議設(shè)計直接簡化成API設(shè)計。

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

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

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

數(shù)據(jù)庫：多個異構(gòu)系統(tǒng)間的通信，也能通過中央數(shù)據(jù)庫進行。但是，頻繁的修改和讀取同樣數(shù)據(jù)會帶來性能瓶頸和死鎖。

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

RPC：直接模仿本地調(diào)用，將一個方法調(diào)用轉(zhuǎn)換成一個數(shù)據(jù)塊，使用一種基于TCP/IP的傳輸協(xié)議進程點對點傳輸。

二、數(shù)據(jù)格式

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

API方式：方法的簽名及參數(shù)

文件方式：文件格式（如XML，TXT，領(lǐng)域?qū)Ｓ械奈募袷?#xff09;，通常還可定義一個描述格式的元文件，供對方根據(jù)它自動生成解析程序。如XML，需要考慮其具體Element，Attribute，通常用XSD定義。

數(shù)據(jù)庫：數(shù)據(jù)庫Schema。

消息：在MOM系統(tǒng)中使用的消息頭和消息體的具體內(nèi)容。

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

應(yīng)用層疊加：在已有TCP應(yīng)用協(xié)議上再增加一層專有業(yè)務(wù)數(shù)據(jù)格式。簡單，無需考慮TCP傳輸層的編碼與解碼。如傳統(tǒng)WebService是 SOAP over HTTP的，在HTTP中傳輸SOAP格式的數(shù)據(jù)（如果需要也可）。

開發(fā)新應(yīng)用層：直接在TCP層上增加業(yè)務(wù)專有的應(yīng)用協(xié)議。需要考慮傳輸層的編碼與解碼，涉及數(shù)據(jù)分包、校驗等。如Remoting。

??

展現(xiàn)層

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

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

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

??

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

SOA中的接口

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

??

最后再看看經(jīng)典的ISO模型

如來神掌……

??

??

?

?

轉(zhuǎn)載于:https://www.cnblogs.com/Chaos/archive/2011/03/05/1971498.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。