從前，有個(gè)程序，

　　只有一個(gè)模塊，自己搞定所有事情，簡(jiǎn)單又快樂地生活著。后來，干的事多了，需要?jiǎng)澐致氊?zé)，

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

　　這下麻煩更大了，因?yàn)槟阏f話時(shí)，對(duì)方可能睡著了zzZZ。甚至，你可能需要同老外交流，更甚至，對(duì)方可能來自遙遠(yuǎn)的半人馬座。很明顯，接口不是簡(jiǎn)單的”interface”。

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

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

　　一、協(xié)議的形式

1. 命令式：通過一連串的指令進(jìn)行交互，指令序列規(guī)定了具體執(zhí)行的步驟，即先1，再2，而3。 如：TCP的三次握手：SYN,ACK,SYN,ACK。
2. 文檔式：通過文檔形式進(jìn)行交互，文檔只說明要什么即目的，不規(guī)定任何執(zhí)行細(xì)節(jié)。如：REST形式的接口。

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

1. 命令式：請(qǐng)求命令有哪些，具體內(nèi)容如何。對(duì)應(yīng)的響應(yīng)命令有哪些，內(nèi)容又是怎樣的，正確結(jié)果如何表達(dá)，錯(cuò)誤又如何表達(dá)。
2. 文檔式：如何表達(dá)請(qǐng)求，如何表達(dá)響應(yīng)，包括正常情況與錯(cuò)誤情況。 

　　通信層

　　一、通信方式

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

1. 進(jìn)程內(nèi) ：如一個(gè)進(jìn)程內(nèi)的兩個(gè)模塊。通常將命令直接映射成一個(gè)個(gè)API，采用普通的API調(diào)用，協(xié)議設(shè)計(jì)直接簡(jiǎn)化成API設(shè)計(jì)。
2. 進(jìn)程間 ：兩個(gè)進(jìn)程間交互，如果有要求較高的性能，一般采用管道方式。如果需要多進(jìn)程交互，可采用消息隊(duì)列方式，解耦發(fā)起方和處理方，并簡(jiǎn)化互相間的連接管理。對(duì)于文檔風(fēng)格的協(xié)議，在簡(jiǎn)單的生產(chǎn)和消費(fèi)的情況下，也可采用直接文件傳遞的方式，一方讀，另一方寫。
3. 機(jī)器間：進(jìn)程分布在多個(gè)機(jī)器上，可以考慮：
   1. 文件：在一對(duì)一的生產(chǎn)-消費(fèi)模式下，最“愚蠢”文件方式有時(shí)反而是最簡(jiǎn)單的高效。特別是異構(gòu)系統(tǒng)間的一對(duì)一通信，可使用此方式，一次傳遞批量命令。
   2. 數(shù)據(jù)庫(kù)：多個(gè)異構(gòu)系統(tǒng)間的通信，也能通過中央數(shù)據(jù)庫(kù)進(jìn)行。但是，頻繁的修改和讀取同樣數(shù)據(jù)會(huì)帶來性能瓶頸和死鎖。
   3. 基于消息：通過一個(gè)消息系統(tǒng)傳送命令、結(jié)果和文檔。能從空間和時(shí)間上解耦發(fā)起者和處理者，兩者可以互相不知曉對(duì)方的存在，發(fā)送和處理消息可以異步進(jìn)行。可以實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)或發(fā)布/訂閱方式。
   4. RPC：直接模仿本地調(diào)用，將一個(gè)方法調(diào)用轉(zhuǎn)換成一個(gè)數(shù)據(jù)塊，使用一種基于TCP/IP的傳輸協(xié)議進(jìn)程點(diǎn)對(duì)點(diǎn)傳輸。

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

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

1. API方式：方法的簽名及參數(shù)
2. 文件方式：文件格式（如XML，TXT，領(lǐng)域?qū)Ｓ械奈募袷剑ǔ＿€可定義一個(gè)描述格式的元文件，供對(duì)方根據(jù)它自動(dòng)生成解析程序。如XML，需要考慮其具體Element，Attribute，通常用XSD定義。
3. 數(shù)據(jù)庫(kù)：數(shù)據(jù)庫(kù)Schema。
4. 消息：在MOM系統(tǒng)中使用的消息頭和消息體的具體內(nèi)容。
5. RPC：自定義傳輸通道時(shí)需要考慮，傳輸數(shù)據(jù)包的格式。可采用：
   1. 應(yīng)用層疊加：在已有TCP應(yīng)用協(xié)議上再增加一層專有業(yè)務(wù)數(shù)據(jù)格式。簡(jiǎn)單，無需考慮TCP傳輸層的編碼與解碼。如傳統(tǒng)WebService是 SOAP over HTTP的，在HTTP中傳輸SOAP格式的數(shù)據(jù)（如果需要也可）。
   2. 開發(fā)新應(yīng)用層：直接在TCP層上增加業(yè)務(wù)專有的應(yīng)用協(xié)議。需要考慮傳輸層的編碼與解碼，涉及數(shù)據(jù)分包、校驗(yàn)等。如Remoting。

　　展現(xiàn)層

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

1. 業(yè)務(wù)無關(guān)API：直接暴露下層協(xié)議細(xì)節(jié)，通過一個(gè)一般化的API完成工作。好處是對(duì)提供者而言所需工作小，可輕易跨平臺(tái)，當(dāng)然消費(fèi)者需要了解協(xié)議細(xì)節(jié)自行完成解析。一般用作文檔風(fēng)格的協(xié)議的提供方式，如RESTful接口，可直接通過本地HTTP API使用。
2. 業(yè)務(wù)專有API：即Wrapper。通過包裝器，封裝掉所有協(xié)議細(xì)節(jié)，在API上直接表達(dá)業(yè)務(wù)，簡(jiǎn)化使用。缺點(diǎn)是需要提供每個(gè)目標(biāo)客戶端平臺(tái)的API實(shí)現(xiàn)。

      使用范圍也會(huì)影響接口的設(shè)計(jì)。如果是公司內(nèi)產(chǎn)品的交互，無論下層如何設(shè)計(jì)，通常會(huì)考慮提供包裝器，供相關(guān)團(tuán)隊(duì)使用，因?yàn)榭蛻艨偸切枰獙戭愃拼a的，不如由一個(gè)人（團(tuán)隊(duì)）干了造福大家。如果是公司間產(chǎn)品的交互，在Java和.NET上，大Web服務(wù)還是不錯(cuò)的選擇。一方面，雖然重，但因?yàn)橛泄ぞ呖梢宰詣?dòng)生成接口代碼，所以也輕了點(diǎn)。另一方面，大Web服務(wù)容易達(dá)成共識(shí)，因?yàn)閃SDL是標(biāo)準(zhǔn)元數(shù)據(jù)格式，溝通方便。至于互聯(lián)網(wǎng)上，各式Open API都是類REST的，因?yàn)閃eb是天然面向文檔的，暴露的又都是資源，如此最自然，提供者所作的工作最少。至于消費(fèi)者，天知道他們用什么語言平臺(tái)來訪問，只能請(qǐng)他們自己解析了：）

　　SOA中的接口

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

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

it知識(shí)庫(kù)：研發(fā)的那些事3--接口之本，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。