系列文章目錄：
《領域驅動設計》（Eric Evans）：告訴我們用代碼呈現真實世界的重要性，並且告訴我們如何更好地建模。
持續交付理論：如何更有效及更高效地發布軟件品，並指出保持每次提交均可發布的重要性。
六邊形架構理論（Alistair Cockburn）：把我們從分層架構中拯救出來，從而能更好地體現業務邏輯。（http://alistair.cockburn.us/Hexagonal+architecture）
隨着領域驅動設計、持續交付、按需要虛擬化、基礎設施自動化、小型自治團隊、大型集群系統這些實踐的流行，微服務也就應運而生。
什么是微服務？
微服務就是一些協同工作的小而自治的服務。
1.小，專注
單一職責原則：把因相同原因而變化的東西聚合在一起，把因不同原因而變化的東西分享開來。（Single Resonsibility Principle，http://programmer.97things.oreilly.com/wiki/index.php/The_Single_Responsibility_Principle）
微服務將內聚性應用在獨立的服務上，根據業務的邊界來確定服務的邊界，可避免代碼庫過大衍生的問題。
討論：多小才算小？
使用代碼行來衡量是有問題的。大家都認為自己的系統過於龐大，卻不知道什么才算是小。ok，那么就一直拆分，直到你不再感覺它過於龐大，那么它有可能就足夠小了。另外，如果你的小團隊無法正常維護，那么它就太大了。
小的優點與缺點：獨立性帶來的好處越多，但管理也越復雜。
2.自治性
一個微服務是一個獨立的實體，它可以獨立部署，獨立修改，服務之間通過暴露API來進行通信，API的實現技術應避免與具體技術相關，以保證技術的選擇不受限制。
自治性其實就是要求你的服務與其他的服務之間很好的解藕，判斷是否解藕的黃金法則：你是否能夠修改一個服務並對其進行部署，而不影響其他任何服務？
微服務的好處
1.技術異構性
對於微服務而言，我們可以根據需要采用最適合這個服務所需要的技術。
對於微服務系統而言，總會存在一些地方讓我們可以嘗試新技術，這種可以快速采用新技術的能力對很多組織而言是非常有價值的。
2.彈性
如果系統中的一個組件不可用，但並沒有傳染到其他的組件，沒有導致級聯故障，系統的其他部分還可以正常工作。
3.擴展
龐大的單塊服務只能作為一個整體進行擴展，即使系統中只有一小部分存在性能問題，也需要對整個服務進行擴展。如果使用較小的多個服務，則可以對只需要進行擴展的服務進行擴展，這樣就可以把那些不需要擴展的服務運行在更小的、性能稍差的硬件上。
4.簡化部署
在有幾百萬行代碼的單塊應用中，即使只修改了一行代碼，也需要重新部署整個應用程序才能發布該變更。這種部署影響很大、風險很高，於是部署的頻率就會降低，兩次部署的差異越大，出錯的可能性就更大！
在微服務架構中，各個服務的部署都是獨立的，這樣就可以更快地對特定部分的代碼進行部署，如果真出了問題，也只會影響一個服務，並且容易快速回滾，這樣就意味着客戶可以快速使用我們的新功能。
5.與組織結構相匹配
可以避免出現龐大的代碼庫，從而獲得理想的團隊大小及生產力。
6.可組合性
分布式系統和面向服務架構的主要好處是易於重用已有功能。不同於以往的單純的Web、PC端程序，人們有更多的選擇使用同一個功能。微服務中會開放很多接口供外部調用，當情況發生改變時，可以使用不同的方式構建應用。
7.可替代
在單塊系統中，刪除一百行代碼會讓人心惶惶，而在微服務系統中，可以輕易地重寫服務，或刪除不再使用的服務。
面向服務的架構（SOA）
SOA是一種設計方法，它通過提供服務向外提供一系列功能，服務之間通過網絡調用，而非采用進程內調用的方式進行通信。
SOA可以用來應用龐大的單塊應用程序，從而提高軟件的復用性，比如多個終端共享一個服務。但大多數人對SOA的理解未達成共識，而微服務就是實現SOA的一種新方法，就像XP或Scrum是敏捷軟件開發的一種特定方法一樣。
其他分解技術
1.共享庫
有些共享庫不屬於任何一個業務領域，並且可以在整個組織中進行重用。但還是需要小心，如果使用共享庫來做服務之間的通信的話，那么它會成為一個藕合點。
2.模塊
有些語言提供自己的模塊分解技術，它允許對模塊進行生命周期管理，這就可以把模塊部署到運行的進程中並且可以不在停止整個進程的前提下對某個模塊進行修改，但很少有人這么做，因為盡管在單塊進程中創建隔離性很好的模塊是可能的，但是它們這些模塊會迅速和其他代碼藕合在一起。
同時，在單進程中采用模塊化技術，也會大大限制我們采用新技術和獨立服務進行擴展的能力。
參考
《微服務設計》（Sam Newman 著 / 崔力強 張駿 譯）