微服務的歷史背景     

      微服務架構的產生和流行並不是偶然的，它是多重因素推動下的必然結果，下麵通過對傳統MVC垂直架構面臨的挑戰進行相關分析，來瞭解微服務化所帶來的變化。

研發和運維成本高

1、代碼重覆率高

1）從技術架構角度看，傳統垂直架構的特點是本地API介面調用，不存在業務的拆分和互相調用，使用到上面功能就本地開發，不需要過度依賴於其他的功能模塊。

2）從考核角度看，共用很難推行。開發只需要對自己開發的模塊交付質量負責，沒有義務為他人提供並維護公共類庫，這個非常耗費成本。

3）時間依賴很難把控。對於公共類庫的使用者而言，依賴別人提供此功能，但是功能提供者可能有更重要的事情在做，交付時間無法滿足使用者。與其坐等別人提供，還不如自己開發效率更高。

4）跨地域、跨開發小組協調很困難，業務團隊可能跨地域研發，內部通常也會分成多個開發小組，各個開發小組之間的協調和溝通成本非常高。

    功能的重覆開發會導致研發成本的上升，代碼質量的下降，架構腐蝕，為後續系統的運維和新功能的開髮帶來了巨大的挑戰。

2、需求變更困難  

      代碼重覆率變高之後，已有功能變更或者新需求加入都會非常困難，以充值繳費功能為例，不同的充值渠道開發了相同的限額保護功能，當限額保護功能發生變更之後，所有重覆開發的限額保護功能都需要重新修改和測試，很容易出現修改不一致或者被遺漏，導致部分渠道充值功能正常，部分存在Bug的問題，如下圖所示：

   修改不一致導致的移動APP充值失敗示例，如下圖所示

圖--充值限額保護功能需求變更後

3、代碼維護困難

   在傳統的MVC架構中，業務流程是由一長串本地介面或者方法調用串聯起來的。臃腫而冗長，而且往往由一個人負責開發和維護，隨著業務的發展和需求變化，本地代碼再不斷的迭代和變更，最後形成了一個個垂直的功能孤島，只有原理的開發者才能理解介面調用的關係和功能需求，一旦原有的開發者離職或者調到其他項目組，這些功能模塊的運維就變得非常困難，如下圖所示：

圖--垂直架構導致的功能孤島

4、部署效率低

      部署效率低主要體現在一下三個方面：

1） 業務沒有拆分，很多功能模塊都能打到同一個war包中，一旦有一個功能發生變更，就需要重新打包和部署。

2）巨無霸應用由於包含功能模塊過多，編譯、打包時間比較長，一旦編譯過程出錯，需要根據錯誤重新修改代碼再編譯，耗時較長。

3)  測試工作量較大，因為存在大量重覆的功能類庫，需要針對所有調用方法進行測試，測試工作量大，另外，由於業務混在一起打包，需要針對集成打包進行專項測試，客觀上也增加了測試工作量。

微服務帶來的變化

      採用微服務架構面臨的第一個問題就是如何將一個單一應用拆分為多個服務。 有一個一般的原則是，單一服務提供的功能是可以獨立被替換和升級的。 也就是說如果有 A 和 B 兩個功能，如果 A 功能發生變化時同時 B 功能也需要變化，那麼 A 和 B 這兩個功能應該被劃在一個服務中。

      微服務架構應用的成功經驗近年已越來越多，例如國外的 Amazon，Netflix，國內如阿裡都採用微服務架構取得了很多正面的成功案例。 但通過上文所述微服務架構特征看出，其實微服務架構模式有利有弊，需要根據實際的業務、團隊、環境進行仔細權衡利弊。 其中的服務拆分帶來的額外開發、測試、運維、監控的複雜度，在現有的環境、團隊下是否能夠很好的支持。

     另外，有人可能會說，我一開始不採用微服務架構方式，而是在單一進程內基於清晰定義的模塊化方式，模塊之間通過介面調用，到了適當階段，必要的時候再將模塊拆分為服務。 其實這個想法顯得過於理想，因為進程內良好定義的介面通常不是很好的服務化介面。 一開始沒有考慮服務化的設計方法，那麼後期拆分時依然是一個痛苦的過程。

應用解耦

      微服務化之前，一個大型應用系統通常會包含多個子應用，不同應用主鍵存在很多重覆的公共代碼，所有應用公用一套資料庫，它的架構如下圖所示：

                           圖--傳統應用架構

   將服務A和B服務化之後，應用作為消費者直接調用服務A和服務B，這樣就實現了對原有重覆代碼的收編，同時系統之間的調用關係也更加清晰，如下圖所示：

圖--服務化之後的調用關係

      基於服務註冊中心的訂閱發佈機制，可以實現服務消費者和提供者之間的解耦，消費者不需要配置服務提供者的地址信息，即可以實現位置無關的透明化路由，它的開發體驗與本地API介面調用相似，但是卻實現了遠程服務調用。通過服務註冊中心，可以管理服務的訂閱和發佈關係，查看服務提供者和服務消費者的詳細信息。有了服務訂閱關係，業務和服務之間的調用管理系統變得透明化，不合理的介面依賴、調用關係一目瞭然。

分而治之

      當垂直應用越來越多時，應用之間的交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的底層微服務，使前端應用更快的響應多變的市場需求。

      應用的差分分為水平拆分和垂直差分兩種，水平差分以業務領域為維度，抽象出幾個不同的業務域，每個業務域作為一個獨立的服務中心提供對外服務。領域服務可以獨立地伸縮和升級，快速的響應需求變化，同時與其他業務領域解耦，它的原理如下圖所示：

圖--水平切分

    應用的垂直拆分主要包含前臺邏輯拆分、業務邏輯和數據訪問層拆分，拆分之後效果如下圖所示：

圖--垂直切分

    經過水平和垂直拆分之後，可以將複雜的巨無霸應用拆分成多個獨立的微服務，系統從大道小，分而治之。

敏捷交付

     軟體解決方案的敏捷性，指的是它能快速進行變更的能力，敏捷性是微服務架構特性中最顯著的一點：敏捷性的產生，是將運行中的系統解耦成一系列功能單一服務的結果。微服務架構能夠對系統中其他部分的依賴加以限制，這種特性能夠讓基於微服務架構的應用在應對BUG或是對新特性需求時，能夠快速地進行變更。這一點與傳統的垂直架構悄悄相反，在傳統架構中經常發生的一種情況是：“要對應用程式中某個小部分進行變更，就必須對整體架構進行重新的編譯和構建，並且進行重新的全量部署。”

微服務架構解析

    微服務架構（MSA）是一種架構風格，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。

    傳統架構和微服務架構的對比如下圖所示：

圖：傳統框架與微服務框架的對比圖

微服務架構劃分原則

      實際上微服務本身沒有嚴格的定義，劃分原則也有不同的實踐，但是比較通用的劃分原則是：微服務通常是簡單、原子的微型服務，它的功能單一，只負責處理一件事，與代碼行數並沒有直接關係，與需要處理的業務複雜度有關，有些複雜的功能，儘管功能單一，但是代碼量可能是成百上千行，因為不能以代碼量作為劃分微服務的維度。

微服務的“微”並不是一個真正可衡量、看的見摸得著的“微”。這個“微”所表達的是一種設計思想和指導方針，是需要團隊或者組織共同努力找到的一個平衡點，在實踐團隊成員可以接受。

微服務總結起來就是小，且關註於做一件事情。

特點總結

      隨著業務需求的快速發展變化，敏捷性、靈活性和可擴展性需求不斷增長，迫切需要一種更加快速高效的軟體交付方式。微服務就是一種可以滿足這種需求的軟體架構風格。負責應用被分解成多個更小的服務，每個服務有自己的歸檔文件、單獨部署，然後共同組成一個複雜的應用。總結起來，微服務有如下的特點：

1）單一職責原則：每個服務應該負責單獨的功能，正式SOLID原則之一。

2）獨立部署、升級、擴展和替換：每個服務都可以單獨部署及重新部署而不影響整個系統。這使得服務很容易升級，每個服務都可以沿用著 “Art of Scalability” 一書定義的X軸和Z軸進行擴展。

3）支持異構/多種語言：每個服務的實現細節都與其他服務無關，這使得服務之間能夠解耦，團隊可以針對每個服務選擇最合適的開發語言、工具和方法。

4）輕量級：微服務通常有輕量級的分散式服務框架承載，採用了P2P通信，無中心節點，性能可以線性增長；第三方軟體依賴減少，減少類衝突和冗餘依賴，集成和升級更方便。

    基於上述特點，微服務架構的有點總結如下：