第一章 微服務
什麼是微服務
很小，專注於做好一件事
單一職責原則：把因相同原因而變化的東西聚合到一起，而把因不同原因而變化的東西分離開來。
怎樣確定代碼庫足夠小？
- 如果你不再感覺你的代碼庫過大，可能它就足夠小了。
- 代碼庫的大小要與團隊的大小相匹配
自治性
一個微服務就是一個獨立的實體。它可以獨立地部署在PaaS（Platform as a Service，平臺即服務）上，也可以作爲一個操作系統的進程存在。
要儘量避免把多個服務部署到同一臺機器上。
特性：
- 服務之間均通過網絡調用進行通信，從而加強了服務之間的隔離性，避免緊耦合
- 服務可以彼此間獨立進行修改，並且某一個服務的部署不應該引起該服務消費方的變動
- 服務會暴露出API，然後服務之間通過這些API進行通信
主要好處
技術異構性
在一個由多服務構成的系統，可以在不同的服務中使用最合適該服務的技術。
彈性
在單塊系統中，如果服務不可用，那麼所有的功能都會不可用，這可以通過將同樣的實例運行在不同的機器上來降低功能完全不可用的概率。但微服務系統本身就可以解決這個問題。
擴展
單塊服務只能作爲一個整體進行擴展，而使用微服務，則可以只對需要擴展的服務進行擴展，這樣就可以把那些不需要擴展的服務運行在更小的、性能稍差的硬件上。
簡化部署
微服務中，可以服務進行獨立部署。
與組織結果相匹配
不同大小的服務由合適規模的團隊負責。
可組合性
服務（接口）的重用，而不僅僅是代碼的重用！
比如我在手機上使用微服務開發了一套接口用來定位，那麼這套接口也可以用在智能手錶上的定位功能。
對可替代的優化
使用微服務可以在需要的時候輕易地重寫服務，或者刪除不再使用的服務。
面向服務的架構
SOA（Service-Oriented Architecture，面向服務的架構）是一種設計方法，其中包括多個服務，而服務之間通過配合最終會提供一系列功能。一個服務通常以獨立的形式存在於操作系統進程中。服務之間通過網絡調用，而非採用進程內調用的方式進行通信。
實施SOA會遇到一些問題：
- 通信協議如何選擇
- 第三方中間件如何選擇
- 服務粒度如何確定
其它分解技術
共享庫
缺點：
- 無法使用異構的技術。一般來講，這些庫只能在同一種語言中，或者至少在同一個平臺上使用。
- 失去了獨立地對系統某一個部分進行擴展的能力。
- 除非使用的是動態鏈接庫，否則每當庫有更新的時候，都需要重新部署整個進程，以至於無法獨立地部署變更。
- 可能會成爲一個耦合點
服務之間可以並應該大量使用第三方庫來重用公共代碼，但有時候效果不太好。
模塊
OSGI（Open Source Gateway Initiative，開放服務網關協議），一個與具體技術相關地模塊分解技術。
OSGI是什麼：
OSGi技術是指一系列用於定義Java動態化組件系統的標準。這些標準通過爲大型分佈式系統以及嵌入式系統提供一種模塊化架構減少了軟件的複雜度。
作者對OSGI的經驗：它帶來的複雜度要遠遠大於它帶來的好處，即使對於很優秀的團隊來說也是不可避免的。
沒有銀彈
微服務不是一個通用的方法。