1.1 為什么需要微服務

微服務架構是過去幾年架構設計領域的熱點，接下來就先討論一下微服務是什么，以及微服務架構帶來的收益。

1.1.1 傳統單體服務的問題

業務發展初期，業務流量很小，對業務迭代效率的要求很高，使用單體服務開發靈活，部署簡單。隨著業務的快速發展，業務復雜度越來越高，同時業務開發人員也急劇增加，單體服務逐漸暴露出來一些問題，主要問題如下。

（1）開發效率低

業務邏輯都集中在單個服務中，所有的開發者都在一個項目里面進行修改，代碼并入時經常會出現相互等待和代碼并入沖突的現象，嚴重影響開發效率。另外，多人同時操作一份代碼，出錯的概率也會增加。

上線方面，同一時刻有多個特性需要上線觀察，為了保證線上服務的穩定性，一般要求特性上線以灰度的方式進行，不同特性之間串行上線。業務迭代比較快時，多個特性同時需要上線，就需要排隊順序等待，這樣就會嚴重影響業務的迭代效率。

（2）可維護性差

業務邏輯都集中在一個服務里面，單個開發者不太可能完全掌控整個業務，因此業務修改和問題追查定位都非常困難。由于很少有人能夠對業務非常熟悉，增加新功能或者修改原有功能時更多像是在打補丁，導致代碼質量和可維護性越來越差，各種功能耦合在一起，新人接手的時候都不知道從何下手。

（3）架構擴展性差

不同模塊可能有不同的架構要求，單體服務很難照顧到大家的差異化需求，如果想針對某個模塊進行新架構和新語言的調整與支持，也比較困難。

（4）部署不靈活

任何一處很小的改動，都需要對整個服務進行編譯、部署和上線，這可能會影響整個系統的穩定性，同時很難對某個特定的模塊進行單獨的容量規劃和部署設計。

（5）健壯性差

單體服務的所有模塊都在一起，某個模塊出現嚴重問題，會導致整個業務不可用。當業務代碼規模很龐大時，系統的故障點會很多，嚴重影響業務的健壯性和可用性。

1.1.2 微服務的定義

微服務就是為了解決單體服務的上述問題而生的，按照微服務權威專家Martin Fowler的定義，微服務架構是將單個服務拆分成一系列小服務，這些小服務都擁有獨立的進程，通過HTTP RESTful API之類的輕量級通信方式進行通信，而作為獨立的業務服務，則可采用一些自動化部署機制獨立部署，每個服務可以使用不同的開發語言和數據存儲技術，實現去中心化的服務管理。

微服務架構的核心訴求是支撐業務敏捷開發和部署，因此微服務架構的本質是如何優雅地支持微服務的“拆分”和“組合”，如何進行合理的架構拆分，如何最大限度地減少微服務之間溝通的成本，這是微服務架構的關鍵所在。

1.1.3 微服務與康威定律

微服務作為一個新技術，雖然在最近幾年才受到越來越多的重視和推崇，但很早之前就有充足的理論基礎。微服務的很多理念在《康威定律》中被充分闡述過?？低芍赋?，設計系統的組織，其產生的設計等同于組織之內、組織之間的溝通結構，康威定律對系統架構設計有重要的指導價值，核心要點如下。

1）架構設計必須解決溝通問題，好的設計應該降低溝通復雜度。這里蘊含高內聚、低耦合、服務隔離等架構設計的一些思想。

2）一個系統沒法一次做完美，迭代升級應該是常態。這里蘊含持續集成、敏捷開發、自動部署、容錯設計等思想。

3）人員組織結構一般會與系統設計趨同，你想要什么樣的系統就需要什么樣的組織結構。

4）大系統終究會拆解成小系統，“合久必分，分而治之”；互聯網大多會變成大系統，微服務是架構發展的一個非常自然的演變狀態。

康威定律完美詮釋了微服務架構的必要性和合理性，人與人溝通復雜，當問題復雜時，需要拆分組織來解決溝通問題；組織結構影響設計，通過組織拆分來改善溝通，從而形成拆分的設計（微服務架構）；被拆分的子系統設計是內聚的，對外邊界是簡單明確的，如果它能降低溝通成本，設計就是合理的；不要指望一個系統是大而完美的，它一定是迭代出來的。

微服務不只是個技術問題，更多的是關于組織和團隊的問題，系統架構和組織之間存在映射關系，如果組織結構不支持，則無法建立高效的系統架構，反之也是這樣。

1.1.4 微服務的收益

互聯網業務的兩個顯著特點是業務發展快和業務高并發，微服務在這兩個方面均有很大的收益，通過有效支撐業務創新和高并發架構，微服務架構成為傳統架構演進時的必然選擇。

通過將單個服務拆分成多個微服務，多個微服務可以獨立開發、獨立測試、獨立運維，不同團隊可以并行開發，互不影響，可以有力地支撐業務的快速迭代，方便業務創新和試錯。

互聯網業務通過業務模式創新和運營模式創新，用戶和流量變化很快，需要從架構層面支撐業務流量的伸縮變化。微服務架構將單個服務拆分為多個子服務，每個微服務均可以獨立進行容量評估，非常靈活，可以很好地支撐業務的高并發需求。