整合是微服務相關技術中最重要的一個。做得好的話，你的微服務可以保持自治性，可以獨立修改和釋出他們，如果做的不好的話，會帶來災難。 4.1尋找理想的整合技術 微服務間的通訊選擇性很多，REST、SOAP、RPC、Protocol buffers等。 4.11避免破壞性修改 有些時候對一個微服務的修改會造成該服務消費者的修改，例如：微服務A增加了一個欄位，如果處理不好的話，會導致A服務的消費者B服務也必須增加該欄位才能保證服務B能夠正常呼叫A服務。 4.12保證API的技術無關性 保證微服務間的技術無關性非常重要，這意味著不應該選擇那種對微服務的具體實現技術有限制的整合方式。 4.13使你的服務易於消費方使用 消費方應該很容易的呼叫我們的服務。理想情況下，消費方可以使用任何技術來實現； 另一方面，提供一個客戶端庫也可以簡化消費方的使用，但是消費方使用客戶端庫也會造成微服務間的耦合。 4.14隱藏內部實現細節 我們不希望消費方和服務的內部實現細節繫結在一起，因為這會增加耦合。 與細節繫結意味著，如果改動服務內部的一些實現，消費方就需要跟著做出修改，這會增加成本，因此我們要避免。 這也會導致我們為了避免消費方的修改而儘量少的對服務本身進行修改，從而導致服務內部技術債的增加。 因此，所有傾向於暴露內部實現細節的技術都不應該被採用。 4.2為使用者建立介面 以MusicCrop為例，建立客戶這個業務，包括新客戶的建立、付賬設定、傳送歡迎郵件等介面； 接下來會以這個業務為例說明整合的各種方式。 4.3共享資料庫 業界最常見的整合形式就是共享資料。使用這種方式時，如果其他服務想要從一個服務獲取資訊，可以直接訪問資料庫。如果想要修改，也可以直接在資料庫中修改。這種方式看起來非常簡單，而且可能是最快的整合方式，這也正是它流行的原因。 共享資料庫的方式有以下缺點： 多個服務同時訪問相同共享資料庫，會造成外部服務能夠檢視到內部實現細節，並與其繫結在一起。儲存在資料庫中的資料對所有人來說都是公平的，所有服務都可以完全訪問該資料庫。如果我們更改資料庫表結構，那麼消費方就無法進行工作。共享資料庫是一個大的共享API，但同時也非常不穩定。 消費方與特定的技術進行了繫結，這說的是所有服務都與共享資料庫進行了繫結。如果一個某個服務使用非關係型資料庫更好，那麼會為以後這種形式的修改帶來很大的困難。這也造成了服務間的耦合。 微服務的設計核心：高內聚和鬆耦合。因此通過共享資料庫的方式很難滿足設計要求。 4.4同步和非同步 服務間的協作包括兩種方式“同步和非同步。 如果使用同步通訊，發起一個遠端服務呼叫後，呼叫方會阻塞自己並等到整個操作的完成。 如果使用非同步通訊，呼叫方不用等待操作完成就可以返回，甚至不需要關心這個操作是否完成。 同步可以知道事情是否成功執行。 非同步通訊對於執行時間比較長的任務來說比較有用，否則就需要在客戶端和服務端之間開啟一個長連線，這是非常不實際的。 當需要低延遲的時候可以使用非同步通訊。 處理異常通訊的技術相對來說比較複雜。 同步通訊 即請求/響應：發起一個請求，然後等待響應。 非同步通訊 即基於事件：發起一個請求，註冊一個回撥，當服務端操作結束後，會呼叫該回調。 對於使用基於事件的協作方式來說，客戶端不是發起請求，而是釋出一個事件，然後期待其他的協作者接收到該訊息，並知道該怎麼做。 基於事件的系統天生就是非同步的； 業務邏輯並非整合中某個核心服務中，而是平均分佈在不同的協作者中。 基於事件的協作方式耦合性很低。 4.5編排和協作 待續。。。。。。。。。。。。。。