聲明，此連續文章爲閱讀《微服務設計》[英]紐曼（Sam Newman）的讀書筆記，旨在記錄重點內容和閱讀心得，有共讀的朋友可以交流書中疑惑。
4.1 尋找理想的集成技術的指導原則
避免服務方修改一個字段就引起消費方的修改
保證API的技術無關性
消費方應該能夠很簡單的使用服務方提供的服務，提供客戶端庫的做法會增加耦合。
隱藏內部實現細節
4.2 MusicCorp創建用戶接口
4.3 共享數據庫
數據庫集成（即消費者直接訪問數據庫）的缺點：表結構直接暴露給所有消費者，維護性差，改了表可能多個消費者都要改、有一天想換成非關係數據庫，這樣消費者都要改、多個消費者中都包括操作統一表結構的邏輯代碼，代碼可重複性低，可維護性差。
4.4 同步與異步
服務之間通信同步與異步的選擇。
1.請求/響應
2.基於事件，客戶端不是發起請求，而是發佈一個事件。（沒說清楚）
4.5 編排（orchestration）與協同（choreography）
在開始對越來越複雜的邏輯建模時，我們需要處理跨服務業務流程的問題，而使用微服務時這個問題會更加凸顯。
MusicCorp創建客戶流程
當考慮具體實現時有兩種系統設計風格：
1.編排
客戶服務作爲中心控制點來指導和驅動整個業務流程。
缺點：客戶服務承擔太多職責，這種方法會導致中心控制點成爲“上帝”服務，而與之打交道的其他服務都淪爲CRUD的貧血服務。
2.協同
針對請求/響應 方式，可以考慮兩種技術RPC和REST.
4.6 遠程過程調用
RPC的缺點：客戶端與服務端技術耦合、許多RPC框架隱藏遠程調用的複雜性，讓你可以像調用本地方法一樣調用，但是也帶來一些問題，網絡不可靠的一些因素沒有得到處理、脆弱性，接口API發生變化，會引起客戶端的代碼也要變化。
4.7 REST
https://martinfowler.com/articles/richardsonMaturityModel.html
《REST實戰》
4.8 基於事件的異步協作方式
1.技術選擇
主要有兩個部分需要考慮：微服務發佈事件機制和消費者接收事件機制。
RabbitMQ
ATOM
2.異步架構的複雜性
《企業集成模式》
4.9 服務即狀態機
狀態機設計
4.10 響應式擴展
Reactive extensions
4.11微服務世界中的DRY和代碼重用的危險
微服務內部DRY，但是跨服務時引入大量的公共庫會導致耦合，因此有些情況下可以適當增加微服務中代碼的重複。
4.12 按引用訪問
舉例，發貨之後要給客戶發郵件，一種做法是把客戶信息發給郵件系統，但是郵件系統在發送之前，這些信息可能發生變化，所以更合理的方式是將客戶資源的URI發給郵件系統，郵件系統在發送時再次查詢客戶服務中的用戶信息。
4.13 微服務版本管理
1.避免破壞性修改
客戶端代碼的高度容錯性，比如：客戶端讀取xml時，可以使用XPath，若xml中字段順序發生變更不會影響客戶端解析。（所謂的“魯棒性”原則、寬進嚴出）
2.及早發現破壞性修改
使用消費者驅動的契約來及早的定位這些破壞性修改對消費方的影響。
3.使用語義化的版本管理
4.不同接口共存
5.運行多個版本的同一個服務
4.14 用戶界面
爲前端服務的後端（BFF）
4.15 與第三方軟件集成
使用外觀服務來隱藏底層的第三方服務，增強對第三方軟件的控制