2.1 什么是微服務架構

2012年，Fred George分享了題為Micro Services Architecture-small，short lived services rather than SOA的演講。在這次演講中，他描述了2005—2009年，他和團隊成員如何將100萬行的傳統J2EE程序，通過解耦、自動化驗證等實踐，逐漸分解成20多個5000行代碼的小服務。這是對微服務架構進行定義的最早版本。

從2014年起，微服務架構由Martin Fowler、Adrain Cockcroft、Neal Ford等人接力進行介紹、完善、演進、實踐，一直維持著較高的熱度，直到現在。

關于微服務架構的定義，可以參考Martin Fowler在2014年所寫的micro-services文章。在這篇文章里，Martin Fowler對微服務架構進行了定義，內容如下：

微服務架構是一種架構模式，它提倡將原本獨立的單體應用，拆分成多個小型服務。這些小型服務各自獨立運行，服務與服務間的通信采用輕量級通信機制（一般基于HTTP協議的RESTful API），達到互相協調、互相配合的目的。被拆分后的服務都圍繞著具體的業務進行構建，每個服務都能獨立地進行開發、部署、擴展。由于相互獨立且采用輕量級通信機制，因此各個小型服務能夠使用不同的語言開發，也可以使用不同的數據存儲技術。

圖2-2是單體應用架構與微服務架構的對比。

圖2-2左圖為單體應用架構。在單體應用中，所有的功能模塊都在一個應用程序中編碼和部署。使用集群部署，也是復制這個大型的單體應用程序來進行擴展。

圖2-2右圖為微服務架構。在微服務架構的項目中，會把每個獨立的功能模塊放在一個單獨的應用程序中編碼和部署，擴展性強。可以按照需求來對這些單獨的服務進行分布式部署，不用一股腦兒地把所有服務堆在一起。

微服務架構中各個服務的獨立不僅體現在對單體應用的拆分上，還體現在各個小型服務能夠使用不同的語言開發，也可以使用不同的數據存儲技術。圖2-3是單體應用架構與微服務架構中的數據存儲策略對比。

圖2-3左圖為單體應用架構的數據存儲策略。在單體應用中，更喜歡用單一的邏輯數據庫做持久化存儲，各個功能模塊使用的數據庫存儲策略相同。

圖2-3右圖為微服務架構的數據存儲策略。在微服務架構的項目中，更傾向于讓每個獨立的服務自行選擇數據庫存儲策略。比如，同一個數據庫技術的不同實例，A服務使用部署在192.168.10.113服務器上的MySQL數據庫作為存儲介質，B服務選擇部署在192.168.11.104服務器上的MySQL數據庫作為存儲介質。各個服務也可以選擇完全不同的數據庫系統，如H服務選擇Redis和MySQL作為存儲介質，J服務選擇MongoDB作為存儲介質，K服務選擇Elastic Search和Redis作為存儲介質。

Martin Fowler主要對微服務架構與單體應用進行比較，并暢想了微服務架構的未來。

當時，微服務架構基本上還處于理論階段。雖然也有微服務架構的項目落地，但是當時業界并沒有可供廣大開發人員進行微服務架構借鑒的最佳實踐，沒有一套完整的方案能夠供廣大開發人員使用，普通的開發人員或開發團隊想要落地一個微服務架構的項目是非常困難的。對于沒有足夠資金投入或技術能力不充足的技術團隊來說，想要實現微服務架構體系需要做好很多方面的工作才能實現，需要花費的成本還是比較高的。

隨后的幾年間，越來越多的微服務架構解決方案逐漸出現和開源，這對于眾多的技術團隊和技術人來說是一個非常大的福音。Java語言下，主流的就是Spring Cloud及其衍生出的一些框架。當然，這是后話了，相關的知識點會在后續章節中進行詳細介紹。