談一下我對如何設計微服務介面的理解和思考
一、 概述
微服務是一個獨立執行、自帶資料儲存管理，對外提供介面的自治系統。微服務設計很關鍵的一點是微服務介面的設計。不同微服務經常是分配給不同的團隊開發的，介面是各團隊程式設計的契約。
下面只討論微服務間介面的設計，至於微服務內部子模組間介面的設計比較靈活，內部介面修改也不會有太大的影響，不在這裡討論。
從我的理解來看，微服務介面設計要考慮以下幾個方面：1、介面協議選型。2、定義介面內容。4、明確介面效能。5、做好介面管理。
二、 介面協議選型
考慮介面使用什麼通訊協議來傳遞資料，是使用TCP、UDP，還是HTTP? 亦或是採用檔案下載，資料庫共享，Redis快取共享的方式？同一個微服務的不同介面都可能採用不同的方式：
- 現在微服務流行採用的http協議restful介面(語言無關)。
- RMI遠端介面呼叫(Java語言支援)。
- 大資料傳遞採用檔案離線下載的方式(FTP)。
- 狀態資料(如果進度條)放在Redis中共享快取。
- 資料庫共享。一般來說微服務的資料庫是隔離的，不同微服務不允許直接訪問彼此的資料庫。如涉及大資料有效能問題時可特殊考慮。
如果涉及機密資料的傳輸， 特別是在interenet上釋出的介面為防止資料被人抓包分析，需要有加解密處理。
做了介面協議選型後就可以考慮採用哪些第方件，常用的cxf、spring boot是restful服務釋出元件；RMI是Java原生支援的；C++可以採用SOAP。FTP存在安全性問題，可以採用SFTP。
三、 定義介面內容
介面內容包含介面名稱(url)、輸入引數、返回值、錯誤碼。一個典型的restful介面內容定義如下：
補充說明：返回的錯誤碼，1表示成功，0表示失敗。引數型別按http協議的定義一般有query引數、body引數、Header引數這幾種。
四、 明確介面效能
介面效能定義了介面單次響應時間、單次查詢返回記錄條數，每秒支援呼叫次數等。
資料量比較大的查詢介面一把都會設計成分頁查詢，需要定義好單次查詢返回的最大記錄條數。
微服務介面的支撐能力是有限的，必須定義好單位時間內允許的最大請求次數(超過請求次數就不響應或者返回錯誤碼)，否則海量的請求一下湧過來，服務就掛了。對於釋出在interenet上的服務，一般還會根據會員級別設定一天的請求次數上限等。
五、 做好介面管理
介面管理涵蓋介面版本管理、介面許可權管理、介面管控。
同一個介面在不同時期可能有不同的訴求，當有新需求來時我們就需要做版本升級。一般來說新增介面，舊的介面不會立即下線（因為還有很多其它的微服務在使用），這時候就通過加一個版本號來解決。在URL中帶上不同的版本號，需要使用新特性的可以呼叫新版本的介面；不使用新特性的可以仍然沿用舊版本介面。
對外發布的介面需要做許可權控制，未授權的微服務不允許訪問。可以採用在介面的header引數中加上加密的token作為許可權認證。
當整個系統很龐大以後，各微服務釋出的介面需要做視覺化管理，包含服務的註冊、釋出、呼叫、下線都需要在統一的運維平臺上操作。
前面提到的介面版本管理對介面不同版本的相容處理是不可能不限支援下去的。釋出舊版本介面的下線公告到期後，如果在監控平臺上發現舊版本介面已無人呼叫就可以下線了，如果還有人呼叫則通知他限期整改。