解析微服務架構

一、單塊架構系統以及其面臨的挑戰

概述

多年來，我們一直在技術的浪潮中乘風破浪，揚帆奮進，尋找更優秀的方法來構建IT系統，也一直在積極的學習並觀察先進的公司如何以不同的架構方式構建或者優化其IT系統，來積極應對市場的變化，迅速做出響應，從而爲客戶提供更多的價值。

微服務架構模式（Microservice Architect Pattern）是近兩年在軟件架構模式領域裏出現的一個新名詞。雖然其誕生的時間不長，但其在各種演講、文章、書籍上所出現的頻率已經讓很多人意識到它對軟件領域所帶來的影響。那到底什麼是微服務，當我們談論微服務時，它代表着一種什麼樣的含義？微服務適合應用在什麼場景下，以及它有什麼樣的優缺點？微服務和SOA到底有沒有區別？在接下來的幾部分裏，我將爲大家揭開微服務的神祕面紗。

不過，在我們開始探討微服務架構之前，讓我們先回顧一下三層應用架構的發展歷程並認識一下什麼是單塊架構應用。

三層應用架構的發展

對於任何一個軟件應用系統而言，其構建目標都是爲了滿足某類用戶的需求，即爲用戶傳遞價值。一直以來，軟件的架構設計是決定應用系統是否能夠被正確、有效實現的關鍵要素之一。架構設計描述了在應用系統的內部，如何根據業務、技術、組織，以及靈活性、可擴展性、可維護性等多種因素，將應用系統劃分成不同的部分，並使這些部分彼此之間相互分工、相互協作，從而爲用戶提供某種特定價值的方式。

應用的三層架構

現實生活中，“層”這個字的含義，對大家一點都不陌生。我們經常說樓房高多少層，蛋糕有幾層等。通常來說，層有好幾種定義，但其中最耳熟能詳的，莫過於“層”能幫助我們劃分出構成某整體事物的，上下相互支撐的的不同部分。譬如說，我們喜歡吃的蛋糕，一般是由三層組成：第一層的蛋糕體、第二層的奶油，和第三層的水果。從頂部至底部，每一層依賴於下一層，從底部到頂部，每一層又支撐着上一層。

在軟件架構模式的領域，經過多年的發展，也有了層的概念：

• 層能夠被單獨構造；

• 層具有區別於其他層的顯著特點；

• 層與層之間能夠互相連接、互相支撐、互相作用，相互協作構成一個整體。

• 層的內部，可以被替換成其他可工作的部分，但對整體的影響不大。

以WEB應用程序爲例，在WEB應用程序開發的早期，由於受到面向過程的思維及設計方式的影響，所有的邏輯代碼並沒有明顯的區分，因此代碼之間的調用相互交錯，錯綜複雜。譬如，我們早期使用的ASP、JSP以及PHP，都是將所有的頁面邏輯、業務邏輯以及數據庫訪問邏輯放在一起，這是我們通常提到的一層架構。

隨着JAVA，.NET等高級語言的快速發展，這些語言爲開發者提供了越來越方便的的數據訪問機制，如Java語言的JDBC、IO流，或者.NET的ADO.NET等。這時候，數據訪問部分的代碼逐漸有了清晰的結構，但表示邏輯和業務邏輯依然交織在一起，我們稱這個階段爲二層架構階段。

隨着面向對象分析、面向對象設計、面向對象原則、設計模式、企業架構模式等理念以及方法論的不斷髮展，從爲用戶提供功能、以及有效組織軟件結構的角度考慮，WEB 應用中不同職責的部分逐漸被定義在了不同的層次，每一層負責的部分更趨向於具體化，細緻化，於是軟件的三層架構逐漸出現了。三層架構通常包括表示層、業務邏輯層以及數據訪問層。

• 表示層

  表示層部分通常指當用戶使用應用程序時，看見的、聽見的、輸入的或者交互的部分。譬如，有可能是信息的顯示，音樂的的播放或者可以輸入的文本框，單選按鈕以及可點擊的按鈕等。通過這些元素，用戶同軟件進行交互並獲取期望的價值。目前的用戶接口大部分情況下爲WEB方式，當然也可以是桌面軟件的形式，例如. NET的WINFORM或者Java的SWING。

• 業務邏輯層

  業務邏輯部分是根據用戶輸入的信息，進行邏輯計算或者業務處理的部分。業務邏輯層則主要聚焦應用程序對業務問題的邏輯處理，以及業務流程的操作，它是大部分軟件系統區別與其他系統的核心。譬如，當用戶點擊一個按鈕後，它可能會觸發業務邏輯部分的代碼進行運算，生成用戶期望的結果。舉例來說，在一個電子商務平臺中，作爲用戶，當我們下單購買某個商品後，應用程序的業務邏輯層會對訂單如何進行處理，如何計算折扣、如何配送等進行處理。

• 數據訪問層

  在用戶同應用程序交互的過程中，會產生數據。這類數據需要通過某種機制被有效的保存，並在將來能夠被重複使用，或者提供給其他系統。這種機制或者方法就是數據訪問層最關注的部分。也就是說，它關注的是應用程序是如何有效的將數據存儲到數據庫、文件系統或者其他存儲介質中。有一點要注意的是，它關心的是對原始數據的操作（數據庫或者文本文件等存放數據的形式），而非原始數據的存儲介質本身。譬如，在一個電子商務平臺中，商品的信息是如何存儲，圖片的信息是如何獲取的等。

三層架構的出現，一方面是爲了解決應用程序中代碼間調用複雜、代碼職責不清的問題。其通過在各層間定義接口，並將接口與實現分離，可以很容易的用不同的實現來替換原有層次的實現，從而有效降低層與層之間的依賴。這種方式不僅有利於幫助團隊理解整個應用架構，降低後期維護成本，同時也有利於制定整個應用程序架構的標準。

另一方面，三層結構的出現從某種程度上也解決了企業內部如何有效的根據技能調配人員，提高生產效率的問題。在大環境下，有效的分層能使不同職責的人員各司其職，更聚焦與個人專業技能的發展和培養。三層結構的出現不僅標準化了複雜系統的邏輯劃分，更幫助企業解決了如何有效形成技術人員組織結構的問題，因此在很長的一段時間裏，它一直是軟件架構的經典模式之一。

非三層架構

有些人認爲，對於一個WEB應用程序，其被自動地分成了三層架構，因爲它有三個分離的部件，如圖所示：

這三個部分看起來雖然滿足“層”的概念，但它並不是我們所說的軟件架構的層。就像我們所說的奶油蛋糕，我們可以在蛋糕的底部加上穩固的底座，在蛋糕的外部加上漂亮的包裝盒，但仔細想想，底座可以用不同品牌的底座，可以用紙質材料的，也可以用樹脂材料的；包裝盒可以用紅色的一次性紙袋，也可以用藍色的帶着花紋的鐵盒，它們並不是我們蛋糕組成的必須一部分。

瀏覽器可以獨立存在與WEB應用程序之外，WEB應用程序也可以被不同的瀏覽器訪問，因此瀏覽器不是WEB應用程序的部分。雖然最近幾年，在瀏覽器端，我們可以使用很多JavaScript庫或者框架獨立開發前端應用，但它的範疇超出了我們目前討論的三層架構，更多的屬於富客戶端以及前後端分離的應用。

類似的，數據庫服務器也可以獨立存在於應用程序之外，因此它也不是應用程序的一部分。雖然有些應用程序的邏輯代碼，被設計成必須是在數據庫中運行，例如存儲過程或者觸發器，但這種用法並不推薦，原因是將業務邏輯放在了數據庫本身，大大增加了後期維護的複雜度和數據遷移的成本。

單塊架構應用

什麼是單塊架構應用

雖然軟件的三層架構幫助我們將應用在邏輯上分成了三層，但它並不是物理上的分層。這也就意味着，即便我們將應用架構分成了 所謂的三層，經過開發團隊對不同層的代碼實現，經歷過編譯（如果非靜態語言，可以跳過編譯階段）、打包、部署後，不考慮負載均衡以及水平擴展的情況，最終還是運行在同一個機器的同一個進程中。對於這種功能集中、代碼和數據中心化、一個發佈包、部署後運行在同一進程的應用程序，我們通常稱之爲單塊架構應用。典型的單塊架構應用，莫過於傳統的J2EE項目所構建的產品或者項目，它們存在的形態一般是WAR包或者EAR包。當部署這類應用時，通常是將整個一塊都作爲一個整體，部署在同一個WEB容器，如Tomcat或者Jetty中。當這類應用運行起來後，所有的功能也都運行在同一個進程中。

類似的，基於Ruby On Rails的單塊架構應用，一般邏輯上分爲控制器層、模型層以及視圖層，同時代碼存放在遵循一定層級結構 的目錄中。當部署這類應用的時候，通常是使用SSH或者其他一些工具，如Capistrano將整個目錄部署在Passenger或者其他WEB容器中。當這類應用運行起來後，所有的功能也都運行在同一個進程中。

因此，對於單塊架構應用的定義，其實是基於分層軟件架構設計的系統基礎之上，從部署模式、運行模式角度去考慮的一種定義方式。

單塊架構應用的優勢

• 易於開發

  對單塊架構的應用程序而言，開發方式相對較簡單。首先從概念上，現有的大部分工具、應用服務器、框架都是這類單塊架構應用程序，容易理解而且爲人所熟知。如果從實踐角度出發，現有的集成開發工具比較適合單塊架構的應用程序，像NetBeans、Eclipse、IDEA等，它們都能夠有效加載並配置整個應用程序的依賴，方便開發人員開發、運行、調試等。

• 易於測試

  單塊架構應用程序也非常容易被測試，因爲所有的功能都運行在一個進程中，啓動集成開發環境或者將發佈包部署到某一環境，一旦啓動該進程，就可以立即開始系統測試或者功能測試。

• 易於部署

  對單塊架構的應用程序而言，部署也比較容易。實際上，由於所有的功能最終都會打成一個包，因此只需複製該軟件包到服務器相應的位置即可。當然，部署的方式可以有很多種，最簡單的可以使用SCP遠程拷貝到指定的目錄下，當然也可以使用某些自動化的工具來完成。

• 易於水平伸縮

  對單塊架構的應用程序而言，水平伸縮也比較容易。實際上，由於所有的功能最終都會打成一個包，且只能運行在一個進程中，因此單塊架構的水平伸縮，更確切的理解其實是克隆，即新建一個服務器節點，配置好該節點的運行環境，複製軟件包到相應的位置，運行改應用程序。當然，必須要確保負載均衡器能採取某種分發策略，有效的將請求分發到新創建的節點。

單塊架構面臨的挑戰

隨着最近幾年互聯網行業的迅猛發展，隨着公司或者組織業務的不斷擴張，需求不斷的增加以及用戶量的不斷增加，單塊架構的優勢已逐漸無法適應互聯網時代的快速變化，面臨着越來越多的挑戰。譬如說，一方面，隨着業務的擴大，如何爲用戶提供可靠的服務，如何有效處理用戶增多後導致併發請求數增多，導致的響應慢的問題，以及如何有效解決用戶增多後帶來的大數據量的問題等。另外一方面，隨着公司或者組織業務的不斷擴張，需求不斷的增加，越來越多的人加入開發團隊，代碼庫也在急劇膨脹。在這種情況下，單塊架構的可維護性、靈活性在降低，而測試成本、構建成本以及維護成本卻在顯著增加。

1.維護成本增加

隨着應用程序的功能越來越多，團隊越來越大，相應的溝通成本、管理成本、人員協調成本必然會顯著增加。譬如說，對於使用Java編寫的中型應用而言，當代碼量爲幾萬行時，可能只需要幾人左右的團隊維護。當代碼量上升到幾十萬行級別時，可能需要幾十人甚至是上百人的團隊。

另外，隨着應用程序功能的增多，當出現缺陷時，有可能引起缺陷的原因組合就會比較多，這也會導致分析缺陷、定位缺陷、修復缺陷的成本相應增高，也就意味着缺陷的平均修復週期可能會花費更長時間。

另外，隨着代碼量的增大，在開發人員對全局功能缺乏深度理解的情況下，修復一個缺陷，還有可能引入其他的缺陷，在自動化測試機制不完善的情況下，很可能導致該過程陷入“修復越多，缺陷越多”的惡性循環。

2.持續交付週期長

隨着應用程序的功能越來越多，代碼越來越複雜，構建和部署時間也會相應的增長。在現有部署流水線穩定工作的情況下，對單塊架構應用程序做任何細微的修改以及代碼提交，都會觸發部署流水線，對整個應用程序進行代碼編譯、運行單元測試、代碼檢查、構建並生成部署包、驗證功能等，這也就意味着流水線的反饋週期變長，單位時間內構建的效率變低了。

另一方面，團隊人員的增多，部署流水線運行的時間增加，開發人員能夠提交代碼的時間窗口就相應減少，（因爲流水線運行的過程中，是禁止提交代碼的），可能出現長時間等待代碼提交，卻無法提交的情況，極大破壞了團隊的靈活性並降低了團隊工作效率。幾年前，我曾經工作在一個50萬代碼行的單塊架構應用上，整個應用由一個50人左右的分佈式團隊負責。通常情況下，從開發人員提交代碼到運行單元測試、構建發佈包、運行功能測試、標記爲可發佈狀態大概需要40分鐘，時間稍微有點長，但團還能忍受。關鍵的問題是開發人員通常都是集中在下午3點左右，完成一定功能的情況下提交代碼，結果就導致3點至5點那個時間段，成了代碼提交的瓶頸，極大影響了該應用的持續集成和構建的效率。

3.新人培養週期長

隨着應用程序的功能越來越多，代碼變得越來越複雜的同時，對於新加入團隊的成員而言，瞭解行業背景、熟悉應用程序業務、配置本地開發環境，這些看似簡單的任務，將會花費更長的時間。我曾經有個朋友，在加入一家世界500強的知名IT公司後，被安排到了一個百萬級代碼的產品組裏。他花了將近1個月的時間來熟悉產品文檔、配置開發環境後，纔在本地成功的運行起了這個應用。在他從事這份新工作的頭一個月裏，我們好幾次聊到他的新工作，得到的答案都是一樣，“看文檔，裝環境”。對個人而言，花一個月時間來配置本地開發環境，其中的滋味和感受大家可想而知，我估計人世間比這更痛苦的事情也沒幾件了。而對公司或者部門而言，本期望員工花費數天就能配置好的環境，卻花了一個月才能完成，這更是極大的浪費。更有甚者，在第一次配置完開發環境後，好幾年都不願意再升級或者重裝系統，真是一招被蛇咬，十年怕井繩。

4.技術選型成本高

傳統的單塊架構系統傾向採用統一的技術平臺或方案來解決所有問題。通常，技術棧的決策是在團隊開發之前經過架構師、技術經理慎重評估後選定的，每個團隊成員都必須使用相同的開發語言、持久化存儲及消息系統，而且要使用類似的工具。隨着應用程序的複雜性逐漸增加以及功能越來越多，如果團隊希望嘗試引入新的框架、技術，或者對現有技術棧升級，通常會面臨不小的風險。

另一方面，互聯網行業不僅市場變化快，而且技術變化也快。譬如，短短几年幾年時間，光前端JavaScript的框架，就出現了好幾十個，從早一點的Backbone、Ember到AngularJS、Ractive等等。類似的，後端的框架、工具等也是層出不窮，有興趣的朋友可以參考下ThoughtWorks的技術雷達(該技術雷達是ThoughtWorks對業界技術、工具、語言等發展趨勢的分析以及預測報告)。因此，對單塊架構的應用而言，初始的技術選型嚴重限制了其將來採用不同語言或框架的能力。如果想嘗試新的編程語言或者框架，沒有完備的功能測試集，很難平滑的完成替換，而且系統規模越大，風險越高。

5.可伸縮性差

如果應用程序的所有功能代碼都運行在同一個服務器上，將會導致應用程序的擴展非常困難。如果迫切的需要擴展，那麼垂直擴展可能是最容易的（錢不是問題）。在大多數情況下，如果捨得砸錢上IBM的服務器、Oracle的數據庫或者來自EMC的存儲設備，不用改變一行代碼，整個世界都變好了。不幸的是，伴隨着業務的增長，數據的增長，垂直擴展會變得越來越吃力，成本越來越高。這也是爲什麼在業很多公司開始嘗試使用開源，放棄這些昂貴的IOE產品的原因。這下明白爲什麼近幾年去IOE的呼聲越來越高了吧。

當考慮水平擴展時，通常的做法是建立一個集羣，通過在集羣中不斷的添加新節點，然後藉助前端的負載均衡器，將用戶的請求按照某種算法，譬如輪轉法、散列法或者最小連接法等合理的將請求分配到不同的節點上。但是，由於所有程序代碼都運行在服務器上的同一個進程中，會導致應用程序的水平擴展成本非常高。譬如說，如果應用程序某部分的功能是內存密集型的，如需要緩存大量數據，而另外一部分功能是CPU密集型的，如需要進行大量的運算，那麼每次實施水平擴展，運行該應用的服務器都必須有足夠的內存和強勁的CPU來滿足需求。因此，鑑於每個服務器都要提供該應用系統所需要的各種資源，基礎設施的整體花費可能會非常高。當然，如果某些節點保持狀態，如用戶登陸後的會話信息等，更增加了水平擴展的難度。

6.構建全功能團隊難

最後，非常微妙的是，隨着應用程序的功能越來越多，代碼變得越來越複雜，其應用程序的複雜結構也會逐漸映射到研發團隊的結構上。康威定律指出：一個組織的設計成果，其結構往往對應於這個組織中的溝通結構。單塊架構的開發模式在分工時往往以技能爲單位，比如UX團隊、服務端團隊和數據庫團隊，這樣的分工可能會導致任何功能上的改變都需要跨團隊溝通和協調。譬如說，用戶體驗工程師（UX）更專注負責用戶接口部分，業務層開發者則負責建立服務器後端的業務邏輯，數據庫工程師和DBA們更關注數據訪問組件和數據庫。鑑於這些問題，隨着時間的推移，不僅代碼越來越難以管理，其對團隊結構的影響也越來越明顯。

綜上所述，隨着業務的不斷擴大，需求功能的持續增加，單塊架構已經很難滿足業務快速變化的需要。一方面，代碼的可維護性、擴展性、靈活性在降低；而另一方面，系統的測試成本、構建成本以及維護成本卻在顯著增加。因此，隨着項目或者產品規模的不斷擴大，單塊架構應用的改造與重構勢在必行。

總結

互聯網時代的產品通常有幾類特點：創新成本低、需求變化快，用戶羣體龐大，它和幾年前我們熟悉的單塊架構應用有着本質的不同。隨着市場變化快、用戶需求變化快、用戶訪問量增加的同時，單塊架構應用的維護成本、人員的培養成本、缺陷修復成本、技術架構演進的成本、系統擴展成本等都在增加，因此單塊架構曾經的優勢已逐漸無法適應互聯網時代的快速變化，面臨着越來越多的挑戰。

作者簡介

王磊，ThoughtWorks公司首席諮詢師。開源軟件的愛好者和貢獻者，社區活動的參與者，Practical RubyGems的譯者， GDCR西安的組織者。於2012年加入ThoughtWorks,爲國內外諸多客戶提供項目交付和諮詢服務；在加入ThoughtWorks之前，曾就職過多家知名外企，具有豐富的敏捷項目實戰經驗。目前致力於微服務架構、虛擬化容器、持續交付、以及Devops的研究與實踐。

二、解析微服務架構

微服務的誕生

微服務架構（Microservice Architect）是一種架構模式，它提倡將單塊架構的應用劃分成一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間採用輕量級的通信機制互相溝通。每個服務都圍繞着具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。

微服務架構雖然誕生的時間並不長，但其在各種演講、文章、書籍上所出現的頻率已經讓很多人意識到它對軟件架構領域所帶來的影響。

背景

其實，微服務的誕生並非偶然。它是互聯網高速發展，敏捷、精益、持續交付方法論的深入人心，虛擬化技術與DevOPS文化的快速發展以及傳統單塊架構無法適應快速變化等多重因素的推動下所誕生的產物：

1. 互聯網行業的快速發展

過去的十年中，互聯網對我們的生活產生了翻天覆地的變化。購物、打車、訂餐、支付，甚至美甲、洗車等，想到的，想不到的活動都可以通過互聯網完成，越來越多的傳統行業公司也開始依賴互聯網技術打造其核心競爭優勢。互聯網時代的產品通常有兩類特點：需求變化快和用戶羣體龐大。在這種情況下，如何從系統架構的角度出發，構建靈活、易擴展的系統，快速應對需求的變化；同時，隨着用戶量的增加，如何保證系統的可伸縮性、高可用性，成爲系統架構面臨的挑戰。

2. 敏捷、精益方法論的深入人心

縱觀IT行業過去的十年，敏捷、精益、持續交付等價值觀、方法論的提出以及實踐，讓很多組織意識到應變市場變化、提高響應力的重要性。精益創業（Lean Startup）幫助組織分析並建立最小可實行產品（Minimum Viable Product），通過迭代持續改進；敏捷方法幫助組織消除浪費，通過反饋不斷找到正確的方向；持續交付幫助組織構建更快、更可靠、可頻繁發佈的交付機制。經過這些方法論以及實踐的推行和嘗試後，從宏觀上而言，大部分組織已經基本上形成了一套可遵循、可參考、可實施的交付體系。這時候，逐漸完善並改進各個細節的需求就會更加強烈。所謂細節，就是類似如何找到靈活性高、擴展性好的架構方式、如何用更有效的技術、工具解決業務問題等。

3. 虛擬化技術與DevOPS文化的快速發展

虛擬化技術和基礎設施自動化(Infrastructure As Code)的快速發展極大的簡化了基礎設施的創建、配置以及系統的安裝和部署。譬如雲平臺的成熟以及像 Chef 、 Puppet、 Ansible 等工具的使用，讓更多的基礎設施能夠通過自動化的方式動態創建。同時，容器化技術的發展以及 Docker 的出現，更是將虛擬化技術推向了一個史無前例的高潮。另外，DevOPS文化的推行打破了傳統開發與運維之間的壁壘，幫助組織形成更高效的、開發與運維高度協作的交付團隊。這些技術與文化的快速發展，極大程度上解決了傳統環境創建難、配置難以及‘最後一公里’的部署難、交付難等問題，成爲推動微服務誕生、發展的重要因素之一。

4. 單塊架構系統面臨的挑戰

幾年前我們熟悉的傳統IT系統，也可以稱之爲單塊架構系統，是以技術分層，譬如邏輯層、數據層等。但隨着用戶需求個性化、產品生命週期變短、市場需求不穩定等因素的出現，單塊架構系統面臨着越來越多的挑戰。因此，如何找到一種更有效的、更靈活、更適應當前互聯網時代需求的系統架構方式，成爲大家關注的焦點。

所以說，微服務的誕生決不是偶然，是多重因素推動下的必然產物。

微服務與SOA

SOA簡述

早在1996年，Gartner就提出面向服務架構（SOA）。SOA闡述了“對於複雜的企業IT系統，應按照不同的、可重用的粒度劃分，將功能相關的一組功能提供者組織在一起爲消費者提供服務”，其目的是爲了解決企業內部不同IT資源之間無法互聯而導致的信息孤島問題。

2002年，SOA被稱作"現代應用開發領域最重要的課題之一"，其正在幫助企業從資源利用的角度出發，將IT資源整合成可操作的、基於標準的服務，使其能被重新組合和應用。

但是，由於SOA本身的廣義性以及抽象性，在其誕生的相當長一段時間內，人們對SOA存在着不同的認知和理解。

直到2000年左右， ESB(Enterprise Service Bus) 、 WebService 、 SOAP 等這類技術的出現，才使得SOA漸漸落地。同時，更多的廠商像IBM、Oracle等也分別提出基於SOA的解決方案或者產品。

微服務與SOA

實際上，微服務架構並不是一個全新的概念。仔細分析SOA的概念，就會發現，其和我們今天所談到的微服務思想幾乎一致。那在SOA誕生這麼多年後，爲什麼又提出了微服務架構呢？

鑑於過去十幾年互聯網行業的高速發展，以及敏捷、持續集成、持續交付、DevOPS，雲技術等的深入人心，服務架構的開發、測試、部署以及監控等，相比我們提到的傳統的SOA實現，已經大相徑庭，主要區別如下表所示：

SOA實現 | 微服務架構實現 | ----|----------| 企業級，自頂向下開展實施|團隊級，自底向上開展實施| 服務由多個子系統組成，粒度大|一個系統被拆分成多個服務，粒度細| 企業服務總線，集中式的服務架構|無集中式總線，鬆散的服務架構| 集成方式複雜（ESB/WS/SOAP）|集成方式簡單（HTTP/REST/JSON）| 單塊架構系統，相互依賴，部署複雜|服務都能獨立部署|

相比傳統SOA的服務實現方式，微服務更具有靈活性、可實施性以及可擴展性，其強調的是一種獨立測試、獨立部署、獨立運行的軟件架構模式。

微服務架構的定義

其實，即便了解了上面的介紹，也很難對微服務下一個準確的定義。就像NoSQL，我們談論了好幾年的NoSQL，知道NoSQL代表着什麼樣的含義，也可以根據不同的應用場景選擇不同的NoSQL數據庫，但是我們還是很難對它下一個準確的定義。類似的，關於什麼是‘函數式編程’，也或多或少存在同樣的窘境。我們可以輕鬆的選擇不同的函數式編程語言，可以輕鬆的寫出函數式編程風格的代碼，但很難對什麼是函數式編程下一個準確的定義。

實際上，從業界的討論來看,微服務本身並沒有一個嚴格的定義。不過，ThoughtWorks的首席科學家，馬丁 -福勒先生對微服務的這段描述，似乎更加具體、貼切，通俗易懂：

Microservice

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

微服務架構

微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間採用輕量級的通信機制互相溝通（通常是基於HTTP協議的RESTful API）。每個服務都圍繞着具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。另外，應當儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。

總結下來，微服務架構中的核心部分包括以下幾點：

• 小, 且專注於做⼀件事情

• 獨立的進程中

• 輕量級的通信機制

• 鬆耦合、獨立部署

總結

隨着市場的快速發展，業務的不斷擴大，單塊架構應用面臨着越來越多的挑戰，其改造與重構勢在必行。而微服務架構的誕生，是互聯網高速發展，虛擬化技術應用以及持續交付、DevOPS深入人心的綜合產物。隨着用戶需求個性化、產品生命週期變短，微服務架構是未來軟件軟件架構朝着靈活性、擴展性、伸縮性以及高可用性發展的必然方向。同時，以Docker爲代表的容器虛擬化技術的盛行，將大大降低微服務實施的成本，爲微服務落地以及大規模使用提供了堅實的基礎和保障。

轉自：http://sanwen8.cn/p/1ddl9fZ.html