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
《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 與第三方軟體整合
使用外觀服務來隱藏底層的第三方服務，增強對第三方軟體的控制
第4章 springboot整合Servlet
1.通過註解掃瞄完成servlet元件的註冊 springboot整合servlet方式一 servletcomponentscan 在springboot啟動時掃瞄webservlet,並將該類例項化 public static void main string args 2.通過方法完成serv...
第5章 整合測試
一 整合測試定義 二 整合測試策略 三 整合測試過程 四 小結 練習1.為什麼有了單元測試，還需要整合測試？2.什麼是整合測試？3.當被測單元本身不是乙個獨立的程式，無法完整的執行，為了驗證被測單元的功能和輸入 輸出是否能正確處理，我們要為被測單元開發 和 4.是乙個或者一系列功能，它在被測的單元糊...
帶著問題學PMP 第4章 專案整合管理
1.專案整合管理是指什麼？答 專案整合管是專案管理的核心，是為了實現專案各要素之間的相互協調，並在相互矛盾的 相互競爭的目標中尋找最佳平衡點。2.什麼是 整合 答 整合是指協調與統一。整合兼具統 一 合併 溝通和整合的性質。總 分 總 3.專案整合包含哪幾個過程？分別屬於哪個過程組？答 專案整合包含...