第五章：分解單塊系統(tǒng)
事務邊界
事務可以保證一些事件要么都發(fā)生据德，要么都不發(fā)生肩民。在插入數(shù)據(jù)庫時，這一點非常有用蚪战。
服務一定會慢慢變大牵现，直至大到需要拆分。關鍵是要在拆分這件事變得太過昂貴之前邀桑，意識到你需要做這個拆分瞎疼。
第六章：部署
本章主要討論持續(xù)集成 & 持續(xù)交付。
6.1 持續(xù)集成 & 微服務
CI（Continuous Integration壁畸，持續(xù)集成）保證新提交的代碼與已有代碼進行集成贼急，從而讓所有人保持同步茅茂。如果沒有 CI，向微服務架構進行轉型會非常痛苦竿裂。關于 CI玉吁，要理解以下三個問題：
- 是否頻繁的進行代碼 merge：如果你的代碼和別人的代碼沒被頻繁的 merge，那將來的集成就會很困難
- 是否有單元測試來驗證修改：由于微服務強調(diào)靈活修改腻异，快速集成进副，所以需要保證修改代碼的質(zhì)量
- 當構建失敗后，團隊是否把修復 CI 當作第一優(yōu)先級的事
每個微服務都應該有自己獨立的代碼庫悔常，并分別與對應的 CI 綁定影斑。當對代碼庫進行修改時，可以只運行相關的構建及測試机打。
6.2 構建 Pipeline
把一個構建過程分成多個階段是很有價值的矫户。構建流水線可以可視化整個構建流程。
CD（Continuous Delivery残邀，持續(xù)交付）
第七章：測試
如何高效且有效地測試分布式系統(tǒng)的功能是一個挑戰(zhàn)皆辽。它能幫助我們在盡早交付軟件與保證軟件高質(zhì)量之間保持平衡。
測試類型包括：
- 單元測試：測單個方法
- 接口測試：測單個服務接口
- 性能測試
- 界面測試：測單個功能
其中芥挣，單元測試驱闷、接口測試、性能測試屬于自動化測試空免。放棄大規(guī)模的手工測試空另，盡可能多地使用自動化測試是近年來業(yè)界的一種趨勢。而微服務架構尤其需要自動化測試蹋砚。
7.1 單元測試
單元測試通常只測試一個函數(shù)和方法扼菠，它不會啟動服務，通常情況下一個服務需要大量的單元測試坝咐。
通過 TDD（Test-Driven Design循榆，測試驅動開發(fā)）寫的測試就屬于這一類。單元測試對于代碼重構非常重要墨坚，它允許你肆意的重構而不必擔心引入 bug冯痢。
7.2 接口測試（服務測試）
只測試為用戶界面提供服務的一些類。接口測試只覆蓋單個服務接口框杜，為了達到隔離性，需要給外部合作者打樁（or mock）袖肥。接口測試比單元測試覆蓋的范圍更大咪辱。
對于每一個下游合作者，我們都需要一個打樁服務椎组，然后在運行接口測試的時候啟動它們油狂，還需要配置被測服務，在測試過程中連接這些打樁服務。接著专筷，為了模仿真實服務弱贼，需要配置打樁服務為被測服務的請求發(fā)回響應。
7.3 界面測試
在微服務系統(tǒng)中磷蛹，界面展示的一個功能往往涉及多個服務吮旅。
7.4 藍／綠部署 vs 金絲雀部署
7.4.1 藍／綠部署
使用藍／綠部署時，我們會部署兩份軟件味咳，但只有一個接受真正的請求庇勃，這也就是我們說的不停機部署。
發(fā)布的時候:
- 將所有的請求全部交給A處理
- 在B上發(fā)布新應用
- B上內(nèi)部測試
- 測試通過后槽驶，所有請求轉向B
- 在A上發(fā)布新應用
- A上內(nèi)部測試
- 測試通過后责嚷，A和B同時提供服務
實施藍／綠部署的整個過程可以完全自動化，它有幾個前提條件：
- 需要能夠切換生產(chǎn)流量到不同的主機掂铐。切換時罕拂，可通過改變 DNS ／更改負載均衡策略
- 提過足夠多的主機，以支持并行運行兩個版本
帶來的好處：
- 在切換流量前全陨，可以測試
- 遇到問題時及時回滾
- 在用戶無感知的情況下零宕機部署
7.4.2 金絲雀部署
金絲雀發(fā)布和藍／綠部署容易混淆爆班，因為它們會使用一些相似的技術。兩者的不同之處在于：金絲雀新舊版本共存的時間更長烤镐，而且經(jīng)常會調(diào)整流量蛋济，它需要更復雜的請求配置。
金絲雀發(fā)布強調(diào)將部分生產(chǎn)流量引到新部署的系統(tǒng)炮叶，來驗證系統(tǒng)是否按預期執(zhí)行碗旅。按預期執(zhí)行包括：功能性 & 性能性 & 其它各種場景（如：新系統(tǒng)的推薦算法的點擊率是否比舊系統(tǒng)高）等。
如果沒有達到預期镜悉，可以迅速回滾到舊版本祟辟，如果達到預期，可以全部引流侣肄。
向新服務引流分兩種：直接引流生產(chǎn)請求 or 復制一份請求旧困，復制請求比較復雜，尤其是在請求不是冪等的情況下稼锅。
7.5 性能測試
將系統(tǒng)拆分成較小的微服務后吼具，跨網(wǎng)絡邊界調(diào)用次數(shù)明顯增加了，之前可能只涉及一次數(shù)據(jù)庫調(diào)用矩距，現(xiàn)在可能涉及三四次跨網(wǎng)絡調(diào)用拗盒，還有匹配數(shù)量的數(shù)據(jù)庫調(diào)用，所有這些調(diào)用都可能減緩系統(tǒng)操作的速度锥债。因此陡蝇，追蹤延遲的根源顯得尤為重要痊臭。
7.6 總結
比較來說，單元測試粒度更細登夫，測試所用時間更短广匙，出現(xiàn)bug后也更好定位。為不同的目的選擇不同的測試來覆蓋恼策。
一般來說鸦致，單元測試要比接口測試大一個數(shù)量級，接口測試比界面測試大一個數(shù)量級戏蔑。一種常見的測試反模式：很少甚至沒有單元測試蹋凝。這意味著當提交有錯誤時，需要很長時間才能發(fā)現(xiàn)這個問題总棵。
包含在測試中的服務數(shù)量越多鳍寂，測試就會越脆弱，不確定性也就越強情龄。如果測試失敗以后迄汛，只是想重新運行一遍測試，然后希望可能通過骤视，那么這種測試是脆弱的鞍爱。
涉及多個服務的測試很脆弱，涉及多線程的測試通常也會有問題专酗。測試失敗有時是因為資源競爭睹逃、超時等。當發(fā)現(xiàn)脆弱的測試時祷肯，要及時解決沉填，否則隨著時間的推移，人們會對出錯習以為常佑笋。
同時測試case要精細的管理翼闹，不能盲目的覆蓋、堆砌蒋纬，要想辦法讓測試變快猎荠。
測試結果的反饋周期過長，會影響開發(fā)人員的效率蜀备，同時會間接影響服務部署关摇。所以要及時反饋 bug，及時修復 bug碾阁，盡可能頻繁發(fā)布小范圍改變拒垃。
把測試的重心放到少量核心場景中。
