|
|
從前，有個程序，
只有一個模塊，自己搞定所有事情，簡單又快樂地生活著。后來，干的事多了，需要劃分職責，
加了新模塊，不過他們需要彼此溝通協調工作……好在是進程內的，如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：自定義傳輸通道時需要考慮，傳輸數據包的格式。可采用：
展現層
無論業務與通信如何設計，使用者最終需通過一個API，完成交互。這個API即我們通常說的“接口”。存在兩種方式：
- 業務無關API：直接暴露下層協議細節，通過一個一般化的API完成工作。好處是對提供者而言所需工作小，可輕易跨平臺，當然消費者需要了解協議細節自行完成解析。一般用作文檔風格的協議的提供方式，如RESTful接口，可直接通過本地HTTP API使用。
- 業務專有API：即Wrapper。通過包裝器，封裝掉所有協議細節，在API上直接表達業務，簡化使用。缺點是需要提供每個目標客戶端平臺的API實現。
使用范圍也會影響接口的設計。如果是公司內產品的交互，無論下層如何設計，通常會考慮提供包裝器，供相關團隊使用，因為客戶總是需要寫類似代碼的，不如由一個人（團隊）干了造福大家。如果是公司間產品的交互，在Java和.NET上，大Web服務還是不錯的選擇。一方面，雖然重，但因為有工具可以自動生成接口代碼，所以也輕了點。另一方面，大Web服務容易達成共識，因為WSDL是標準元數據格式，溝通方便。至于互聯網上，各式Open API都是類REST的，因為Web是天然面向文檔的，暴露的又都是資源，如此最自然，提供者所作的工作最少。至于消費者，天知道他們用什么語言平臺來訪問，只能請他們自己解析了：）
SOA中的接口
單看技術層次，SOA的核心是服務，服務有三個基本要素：契約、實現和綁定。契約是服務所提供功能的一個規范，重在表達業務概念；實現是服務的具體在語言和平臺的落地，包含提供者的實現和使用者的API；綁定則是服務之間的具體通信協議。分離了使用、業務表達和通信。
最后再看看經典的ISO模型
it知識庫：研發的那些事3--接口之本，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
