《微服務設計》閱讀筆記(一)微服務
《微服務設計》，Building Microservices，作者Sam Newman，譯者崔力強、張駿，人民郵電出版社，2016年。
筆記中有些內容直接引用原書。
================================================================
第一章 微服務
微服務強調內聚性，根據Robert C. Martin對單一職責的論述：「把因相同原因而變化的東西放在一起，而把因不同原因而變化的東西分離開來」強調了內聚性。
微服務是獨立的服務，並且根據業務邊界來確定服務的邊界。注意，這裡強調的是服務邊界，而不是技術邊界。傳統的如N層架構，MVC架構都是基於技術邊界來劃分，這種分法看來是不適合劃分微服務的。
微服務強調微，微即是小，多小的代碼量能稱為微服務。按澳大利亞RealEstate.com.au的John Eaves認為，一個微服務應該可以在兩周內完全重寫。作者給出的回答太含糊：「足夠小即可，不要過小。」相比之下，前者的定義更好度量。後者的定義頗為主觀。另外，一個微服務對應一個小團隊，團隊大的話就說明微服務不夠微。這又歸結到團隊大小的度量問題，那麼團隊多少人算大，多少人算小呢。有一個兩個Pizza的論斷。一個小團隊點的外賣應該兩個Pizza就夠了。
微服務的自治性。確保微服務的隔離性：
1. 服務之間只通過網路通信。這樣能夠使得服務可以獨立修改，不會因為修改一個服務內部的實現而導致另外的服務不可用或跟著修改（這裡指的是修改內部實現，而不是對外部介面的修改）。
2. 服務對外提供的API形式保持技術獨立性。這是為了不限制其它服務的實現技術，如編程語言，操作系統等，無需與服務提供方的實現保持一致。
微服務帶來的益處：
1. 技術異構性。根據微服務所對應的業務選擇技術，而不必受限於其依賴的服務所實現的技術。容易保持系統中的異構架構。而且由於架構的異構性，並且服務的修改或重構對其它服務沒有影響（在保證服務介面不變的情況下），因此可以對其中的一個或部分服務嘗試新技術。
當然，異構架構和新技術的嘗試都是有限制的，無節制的過多的使用太多不同的技術會帶來更多的複雜性。過多的操作系統種類，過多的語言，過多的運行環境與應用框架等等。
2. 彈性。這裡的彈性指的是單點故障不會導致整個系統故障。單塊系統中某組件故障後，很容易導致級聯故障，從而使得系統不可用，解決方法可以通過多個機器節點上同時部署相同實例避免單點故障。而微服務本身就是通過網路隔離，不會像在一個機器中的單塊系統那樣產生連鎖反應。由於微服務在每次進行外部調用時，應該會自然地考慮到外部服務不可用的情況處理。而單塊系統中API調用時則很難對每次調用考慮周全，並且經常會引發級聯故障。
3. 擴展。微服務對單塊系統進行了切分，使得可以對相應的瓶頸微服務進行多實例部署來擴展，而不必整個單塊系統擴展。對整個單塊系統的擴展顯然要比只對其中的一部分進行擴展要消耗更多的機器資源，因為好鋼並不是全部用在刀刃上。
4. 簡化部署。由於微服務功能單一，隔離性好，更改後部署如果出現問題很容易定位，也容易快速回滾。單塊系統中牽一髮動全身，害怕局部改動對全局產生重大負面影響，因此部署需要做足充分的準備工作。
5. 與組織結構相匹配。分散式的大團隊由於溝通、組織等問題，沒有小團隊的效率高。因此微服務的設計理念和小團隊的理念很匹配，可以提高生產率和質量。
6. 可組合性。單塊系統由於內部耦合比微服務之間耦合緊密的多，因此想通過組合內部功能完成其它系統功能，比微服務的組合性要差很多。
7. 對可替代性的優化。單塊系統想要重寫以改進性能，比微服務改寫某個服務提升性能要複雜困難許多。
面向服務架構（SOA，Service-Oriented Architecture）是一種方法，在現實中實施並不好。面臨通信協議選擇，服務粒度確定，第三方中間件選擇等問題。可以把微服務架構認為是SOA的一種特定方法。
其它分解技術還有共享庫和模塊，
1. 共享庫：要使用共享庫必須得選擇相同的實現語言或者至少在同一個平台，喪失了技術獨立性。如果是靜態庫，則每次靜態庫發生變化，使用的軟體又需要重新編譯和部署，影響關聯頗大。而且，由於進程內調用API，使得級聯故障發生的可能性大增。當然，共享庫即使在微服務中，也是有生存空間的。例如，很多不同領域的業務都使用該功能，就可以將該功能作為共享庫給各個微服務使用。
2. 模塊：一些語言提供了模塊分解技術如Erlang，它的模塊化能力非常牛，支持對模塊進行停止、重啟或熱升級等。但你只能使用Erlang，並且也存在故障級聯的問題。語言之外就是OSGI（Open Source Gateway Initiative）了，它過於強調模塊生命周期管理了，而生命周期管理在實際項目中用處並不大。而且，一個進程內也導致模塊耦合度太高。OSGI帶來的複雜度遠大於帶來的好處。
微服務不是銀彈，它天然是分散式系統架構，因此會伴隨著分散式系統的複雜性。需要考慮部署、測試、監控、擴展、保持彈性、分散式事務、CAP問題等等。
BrianZhang：《微服務設計》閱讀筆記（二）演化式架構師
BrianZhang：《微服務設計》閱讀筆記(三)如何建模服務BrianZhang：《微服務設計》閱讀筆記（四）集成BrianZhang：《微服務設計》閱讀筆記（五）分解單塊系統BrianZhang：《微服務設計》閱讀筆記（六）部署BrianZhang：《微服務設計》閱讀筆記（七）測試BrianZhang：《微服務設計》閱讀筆記（八） 監控BrianZhang：《微服務設計》閱讀筆記（九）安全BrianZhang：《微服務設計》閱讀筆記（十）康威定律和系統設計BrianZhang：《微服務設計》閱讀筆記（十一）規模化微服務BrianZhang：《微服務設計》閱讀筆記（十二完結篇）總結軟體開發之路
推薦閱讀：
※Git的理念
※輕鬆理解UML用例圖時序圖類圖的教程
※哈希演算法集合類庫HashLib
※排列組合KwCombinatorics