一.理想的集成應該是什麼樣的？
1.避免破壞性修改
如果在一個微服務的響應中添加一個字段，服務的消費方不應該受到影響。
2.保證API的技術無關性
微服務之間的通信應該是與技術無關的。
3.使服務的消費方易於使用
如果消費方使用該服務比登天還難，那麼無論該微服務多漂亮都沒用任何意義。但同時，易於使用的服務可能內部封裝了很多細節，這會增加耦合。
4.隱藏內部實現細節
消費方與服務方的內部細節應該是分開的，如果與細節綁定，則意味着改變服務內部的一些變化，消費方也要跟着修改，這會增加修改的成本。
二.數據庫是否應該共享
共享數據庫是最快的集成方式，但這種方式應該避免。
如果是這樣，那麼外部的服務則能查看內部的實現細節，並與其綁定在一起，存儲在數據庫中的數據結構對所有人來說都是平等的，數據庫是一個很大的共享API，那麼爲了不影響其他服務，必須非常小心地避免修改與其他服務相關的表結構。這樣的情況下，需要做大量的迴歸測試來保證功能的正確性。
如果是這樣，消費方與服務方的特定技術綁定在了一起，如果消費方要從關係型數據庫換成非關係型數據庫，那麼這樣是不容易實現的。這不符合低耦合的原則。
如果是這樣，那麼原本由服務方提供的修改，現在可以由各個消費方直接操作數據庫來完成，而且每個消費方可能都會有一套自己的修改方法。這不符合高內聚的原則。
三.服務的協作：同步or異步？
對於同步方式而言，我們可以用請求/響應來概括整個過程，發起方發起一個遠程調用後，發起方會阻塞自己並等待整個操作的完成，同步對於響應的低延遲有着高要求，因而在現在，這也是不太實際的。我們通常選用方式。
異步的通信模型有兩種。
一種是請求/響應方式，這與同步的不同，它是在發起一個請求時，同時註冊一個回調，當服務端操作結束之後，會調用該回調。
一種是基於事件的方式，服務提供方不發起請求，而是發佈一個事件，然後期待調用方接收消息，並知道該怎麼做，服務提供方不需要知道該或者什麼會對此做出響應，這也意味着，你可以在不影響服務提供方的情況下對該事件添加新的訂閱。
四.服務的編排與協同
如果你註冊一家網站，它在註冊時做了下面3件事：
（1）在客戶的積分賬戶上創建一條記錄
（2）通過EMS系統發送一個歡迎禮包
（3）向客戶發送歡迎電子郵件
當考慮實現時，編排是一種架構風格，它由一箇中心大腦來指導並驅動整個流程。它可由客戶管理這個服務來承擔，在創建客戶時會跟積分賬戶服務、電子郵件服務及EMS服務通過請求/響應的方式進行通信。客戶管理服務可以對當前進行到了哪一步進行跟蹤，它會檢查積分賬戶是否創建成功、電子郵件是否發送出去、EMS包裹是否寄出。這種方式的缺點是：客戶管理服務承擔了太多職責，它會成爲網關結構的中心和很多邏輯的起點。這樣會導致少量的“上帝”服務，而與其打資產的那些服務通常會淪爲貧血的CRUD服務。
另一種實現的風格則是協同，它僅僅告知各個系統各自的職責，具體的實現留給他們自己。就上例而言，客戶管理服務創建一個事件，郵件服務、積分服務、EMS服務會訂閱這些事件並做相應的處理，如果其他的服務也關心客戶創建這件事情，它們只需要簡單的訂閱該事件即可。這種方式能顯著地消除耦合，但這需要額外做一些監控工作，以保證其正確進行。我們可以建一個跟業務流程相匹配的跟服務的監控服務，分別監控每個服務。
五.服務的版本管理
1.儘可能推遲修改
比如我們可以使用XPATH來讀取XML，它可以忽略XML的一些修改，Martin Fowler稱之爲容錯性讀取器（http://martinfowler.com/bliki/TolerantReader.html）。
接收消息的一方應儘可能靈活地消費服務，這就是魯棒性原則（https://tolls.ietf.org/html/rfc761），它認爲每個模塊都應該寬進嚴出。
2.及早發現破壞性修改
儘量對修改的影響進行全面的迴歸。
3.使用主義化的版本管理
每個服務的版本號支持：Major.Minor.Patch的格式，其中Major的改變意味着其中包含着向後不兼容的修改；Minor的改變意味着有新功能的加入但應該是向後兼容；Patch的改變代表對已有功能的缺陷修復。
4.不同版本的接口共存
當不得不這麼做時，我們的生產環境可以同時存在接口的新老版本。
假如一個接口存在着V1、V2、V3三種版本，我們可以在所有對V1的請求轉換給V2，然後V2轉換給V3，這樣是一種平滑的過度，首先擴張服務的能力，對新老兩種都支持，然後等老的消費者都採用了新的方式，再通過收縮API去掉舊的功能。
我們也可以在URI中存放版本信息，但同時我們需要一套方法來對不同的請求進行路由。
5.不同版本的服務共存
短期內同時使用兩個版本的服務是合理的，尤其是當你做藍綠部署或者金絲雀發佈時，在這些情況下，不同版本的服務可能只會存在幾分鐘或者幾個小時，而且一般只會有兩個版本。升級消費者到新版本的時間趙長，就越應該考慮在同一個微服務中暴露兩套API的做法。
六.服務的UI管理
PC端的程序我們需要關注瀏覽器和分辨率；移動端的程序我們需要關注帶寬和手機的電量，甚至是地區發展的水平（也許使用短信登錄更符合當地的實際）；在平板上，我們很難使用右鍵操作。我們通過把服務的功能進行不同的組合，可以爲Web、移動端、可穿戴設備提供不同的體驗。那麼，如何很好的組織起來呢？這就是UI管理面臨的問題。
如果組織一個移動端的頁面，需要調用20個服務，那麼對於移動設備來說會有些吃力，我們可以使用API Getway來緩解這一問題，這種模式下多個底層的調用會被聚合成一個調用。
另外一種方式是讓服務暴露出一部分UI，然後只需要簡單地把這些片段組合在一起就可以創建出整體UI。也許音樂商店的訂單管理團隊可以對所有與訂單管理相關的頁面負責。但在最後，我們仍然需要將這些UI集成在一起，我們可以使用類似服務器模板的技術來實現。這種方式的優勢是可以完成快速修改，但很難保證用戶體驗的一致性，因爲各個服務的維護，它們給出的UI風格可能迥異，同時如果你給PC、Web、平板、移動端都提供HTML方式的UI，那麼你需要進行一系列的組件嵌入處理，而原生的應用有可能提供更大好的體驗。
七.與外系統集成
可以在外系統上再包裝出一些服務，對調用者隱藏細節，或者捕獲所有的請求，並決定是否路由到遺留代碼還是導向新的代碼中，這種方式可以幫助我們從老系統進行替換，從而避免影響過大的重寫。
參考
《微服務設計》（Sam Newman 著 / 崔力強 張駿 譯）
轉自：https://www.cnblogs.com/gudi/p/6624828.html