1. 什麼是微服務？
是一些協同工作的小而自治的服務。
2. 爲什麼會有微服務架構？
傳統的單體應用架構在開發大型項目時的缺點是突出且嚴重的：
- 一個龐大的代碼庫，以至於時間久了想要知道該在什麼地方修改都很困難
- 相似的功能代碼隨處可見，修復bug難上加難
- 嚴重的耦合性問題，代碼牽一髮而動全身，代碼結構的修改（重構）成本極高
- 一個小的修改就得對整個應用重新部署上線，上線成本高使得上線週期長，難以同步快速變化的需求
- 心智負擔
3. 微服務的特點
- 優點
- 根據業務特點拆分多個服務進行部署，服務之間的資源操作權限(DB-Table)相互隔離，通過網絡通信，保持單個服務的自治性
- 單個服務，更小的代碼量，能夠快速開發/上線新功能以及定位bug
- 單個服務以單個應用形式運行，通過暴露API形式提供服務
- 更好的技術異構性。可以在不同的服務中使用最適合該服務的技術，如果系統中的一部分需要做性能提升，則可以使用更好的技術棧重構該部分。比如不同的部分使用不同存儲技術。
- 缺點
- 需要管理較多的服務
- 引入分佈式事務
4. 彈性
一個服務的故障不應該導致整個系統故障，微服務架構自然的引入了網絡這個故障因子，需要使用合理的方法來處理異常。
5. 方便的擴展
微服務架構可以輕鬆的針對系統中存在性能瓶頸的服務進行擴展。
6. 方便的部署
微服務架構中的各個服務的部署都是獨立的， 所以部署上線的粒度從整個系統降低到一個子服務，開發和測試的成本大大降低，可以做到快速部署上線，在出錯時也能快速回滾該服務。
7. 與組織結構匹配
在一個龐大的代碼庫上開發，這會使得團隊成員的職責權限變得模糊，開發效率低下；團隊是分佈式的時候，問題更明顯。
微服務架構可以很好的將架構與組織結構相匹配，避免出現過大的代碼庫，團隊成員的職責變得清晰，從而更容易獲得理想的團隊大小及生產力。
8. 方便的重寫
當使用多個小規模服務時，重寫某個服務或者是直接刪除該服務都是相對可操作性的。
但是在單體應用中想要在一天內刪除幾百行代碼，而確信不出問題，這恐怕不太可能？
微服務中的多個服務大小相似，所以重寫或移除一個或多個服務的阻礙也很小。
9. SOA（面向服務的架構）
SOA是一種設計方法或設計思想。它所設計的架構是由多個服務構成，服務之間通過網絡調用而通信，一個服務以獨立形式存在。
SOA可以用來應對臃腫的單體應用，提高軟件的可重用性。
書中說到，SOA是一個很好的想法，但人們做了很多實踐都無法在這件事上達成共識。實施SOA時會遇到這些問題：通信協議如何選擇，服務粒度如何確定等；目前也存在一些如何劃分系統的指導原則，但作者說基本都是錯誤的。
微服務架構就是踐行SOA的一種特定架構方案。
10. 共享庫
通常單體應用中會存在命名如util或common的模塊，用來存放常用的代碼。微服務架構中也可以通過庫的形式共享代碼。
11. 沒有銀彈
作者強調：微服務不是免費的午餐，更不是銀彈，選擇微服務就得面對所有分佈式系統需要面對的複雜性，這包含擴展、部署、測試、監控等待，還可能經常需要處理分佈式事務或者與CAP相關的問題，不要過於感到驚訝！
每個公司、組織及系統都不一樣，微服務是否適合你，或者說你能夠在多大程度上選擇微服務，取決於多種因素，書中後面章節會給出一些指導，指出常見的陷阱，幫你制定清晰的演化路線。
本書douban鏈接：點擊這裏