微服務架構

 微服務（Microservice）

1.1　爲何須要微服務架構

　　隨着互聯網技術的發展，傳統的應用架構已知足不了實際需求，微服務架構就隨之產生。

1.1.1　傳統單體應用架構的問題

　　一般咱們所使用的傳統單體應用架構都是模塊化的設計邏輯，程序在編寫完成後會被打包並部署爲一個具體的應用，而應用的格式則依賴於相應的應用語言和框架。
　　例如，在網上商城系統中，Java Web工程一般會被打成WAR包部署在Web服務器上，而普通Java工程會以JAR包的形式包含在WAR包中，如圖1-1所示。

 

　　這種應用開發風格很常見，它易於開發和調試，而且易於部署。在用戶量很少時，此種架構方式徹底能夠知足需求，但隨着用戶人數的增長，一臺機器已經知足不了系統的負載，此時咱們就會考慮系統的水平擴展。一般狀況下，咱們只須要增長服務器的數量，並將打包好的應用拷貝到不一樣服務器（如Tomcat），而後經過負載均衡器（如Apache、Nginx）就能夠輕鬆實現應用的水平擴展，如圖1-2所示。

 　　在早期，單體架構的這種擴展方式能夠很好地知足使用需求，但隨着時間的推移，這種方式就會產生不少問題，具體表現以下。

　　1. 應用複雜度增長，更新、維護困難
　　一個簡單的應用會隨着時間的推移而逐漸變大。一旦應用變得龐大而又複雜，開發團隊將會面臨不少問題，其中最主要的問題就是這個應用太複雜，以致於任何單個開發者都很難進行二次開發或維護。
　　2. 易形成系統資源浪費
　　雖然使用負載均衡的方式能夠對項目中的服務容量進行水平擴展，但因爲傳統單體架構的代碼中只有一個包含全部功能的WAR包，因此在對服務容量擴容時，只能選擇重複地部署這個WAR包來擴展服務能力，而不只僅是擴展了所需的服務。這樣就會致使其餘不須要擴展的服務也進行了相應的擴展，但這些擴展是不須要的，所以這種方式會極大地浪費資源。
　　3. 影響開發效率
　　當一個應用越大時，啓動時間就會越長。開發和調試的過程當中，若是有很大一部分時間都要在等待中度過，那麼必然會對開發效率有極大的影響。
　　4. 應用可靠性低
　　傳統單體應用架構在運行時的可靠性比較低，當全部模塊都運行在一個進程中時，若是任何一個模塊中出現了一個Bug，可能會致使整個進程崩潰，從而影響到整個應用。
　　5. 不利於技術的更新
　　傳統單體應用架構一旦選定使用某些技術，則後期的開發和擴展將在這些技術的基礎上實現。若是須要更改某種技術，則可能須要將整個應用所有從新開發，這種成本是很是大的。
固然，傳統單體應用架構的問題還不僅這些，但出現這些問題的根本緣由能夠說就是因爲傳統單體架構中一個WAR包內包含了系統的全部服務功能所致使的。隨着業務變得愈來愈多，問題也就愈來愈多。

1.1.2　如何解決傳統應用架構的問題

　　針對傳統單體架構的問題，大部分企業經過SOA（ServiceOriented Architecture，面向服務的架構）來解決上述問題。SOA的思路是把應用中相近的功能聚合到一塊兒，以服務的形式提供出去，所以基於SOA架構的應用能夠理解爲一批服務的組合。

　　SOA將原來的單體架構按照功能細分爲不一樣的子系統，而後再由各個子系統依賴服務中間件（這裏指企業服務總線Enterprise Service Bus，簡稱ESB）來調用所需服務。
　　使用SOA能夠將系統切分紅多個組件服務，這種經過多個組件服務來完成請求的方式有不少好處，具體以下。
　　·把項目拆分紅若干個子項目，不一樣的團隊能夠負責不一樣的子項目，從而提升開發效率。
　　·把模塊拆分，使用接口通訊，下降了模塊之間的耦合度。
　　·爲企業的現有資源帶來了更好的重用性。
　　·可以在最新的和現有的應用之上建立應用。
　　·可以使客戶或服務消費者免予服務實現的改變所帶來的影響。
　　·可以升級單個服務或服務消費者而無需重寫整個應用，也無需保留已經再也不適用於新需求的現有系統。

　　雖然使用SOA解決了單體架構中的問題，但多數狀況下，SOA中相互獨立的服務仍然會部署在同一個運行環境中（相似於一個Tomcat實例下，運行了不少web應用）。和單體架構相似，隨着業務功能的增多，SOA的服務會變得愈來愈複雜。本質上看，單體架構的問題並無由於使用SOA而變得更好。
　　針對單體架構和SOA的問題，許多公司（如Amazon、eBay和NetFlix）經過採用微處理結構模式解決了系統架構中的問題。其思路不是開發一個巨大的單體式的應用，而是將應用分解爲小的、互相鏈接的微服務。隨着微服務的使用，微服務架構的思想也隨之產生。

 

1.2　微服務架構是什麼 

 1.2.1　微服務架構的概念

　　微服務架構是一種架構風格和架構思想，它倡導咱們在傳統軟件應用架構的基礎上，將系統業務按照功能拆分爲更加細粒度的服務，所拆分的每個服務都是一個獨立的應用，這些應用對外提供公共的API，能夠獨立承擔對外服務的職責，經過此種思想方式所開發的軟件服務實體就是「微服務」，而圍繞着微服務思想構建的一系列體系結構（包括開發、測試、部署等），咱們能夠將它稱之爲「微服務架構」。

　　從圖1-4中能夠看出，微服務架構已將傳統單體架構中的訂單服務、商品服務和用戶服務拆分爲了獨立的服務，其中的每個服務都是一個獨立的應用，能夠訪問本身的數據庫，這些服務對外提供公共的API，而且服務之間能夠相互調用。
　　注意:微服務和微服務架構是兩個不一樣的概念。微服務強調的是服務的大小，它關注的是某一個點，而微服務架構是一種架構思想，須要從總體注意微服務和微服務架構是兩個不一樣的概念。微服務強調的是服務的大小，它關注的是某一個點，而微服務架構是一種架構思想，須要從總體上對軟件系統進行全面的考慮。

1.2.2　微服務架構的優勢

　　與傳統單體應用架構相比，微服務架構有不少優勢，具體表現以下。
　　1. 複雜度可控
　　微服務架構在將應用分解的同時，規避了本來複雜度無止境的積累。每個微服務專一於單一功能，並經過定義良好的接口清晰地表述服務邊界。因爲體積小、複雜度低，每一個微服務可由一個小規模開發團隊徹底掌控，易於保持高可維護性，並提升了開發效率。
　　2. 可獨立部署
　　因爲微服務具有獨立的運行進程，因此每一個微服務均可以獨立部署。當某個微服務發生變動時，無需編譯、部署整個應用。由微服務組成的應用至關於具有一系列可並行的發佈流程，使得發佈更加高效，同時下降了對生產環境所形成的風險，最終縮短應用交付週期。
　　3. 技術選型靈活
　　微服務架構下，技術的選型是多樣化的。每一個團隊均可以根據自身服務的需求和行業發展的現狀，自由選擇最適合的技術。因爲每一個微服務相對簡單，當須要對技術進行升級時，所面臨的風險較低，甚至徹底重構一個微服務也是可行並容易的。
　　4. 易於容錯
　　當架構中的某一組件發生故障時，在單一進程的傳統架構下，故障頗有可能在進程內擴散，致使整個應用不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其餘服務可經過重試、平穩退化等機制實現應用層面的容錯。
　　5. 易於擴展
　　單個服務應用也能夠實現橫向擴展，這種擴展能夠經過將整個應用完整地複製到不一樣的節點中實現。當應用的不一樣組件在擴展需求上存在差別時，微服務架構便體現出其靈活性，由於每一個服務能夠根據實際需求獨立進行擴展。
　　6. 功能特定
　　每一個微服務都有本身的業務邏輯和適配器，而且一個微服務通常只完成某個特定的功能，例如商品服務只管理商品、客戶服務只管理客戶等。這樣開發人員能夠徹底地專一於某一個特定功能的開發，而不用過多地考慮其餘，從而提升開發效率。
除此以外，微服務架構還有不少其餘優點，因爲篇幅有限，這裏就不一一列舉了，但從微服務架構的優點能夠看出，使用微服務能夠很好地解決傳統單體架構中的問題。

1.2.3　微服務架構的不足

　　微服務架構除了有上面所講的各類優勢外，還存在着一些不足，這些不足的具體表現以下。

　　1. 開發人員必須處理建立分佈式系統的複雜性
　　·開發工具（或IDE）是面向構建傳統的單體應用程序的，不爲開發分佈式應用程序提供全面功能上的支持。
　　·測試更加困難。在微服務架構中，服務數量衆多，每一個服務都是獨立的業務單元，服務主要經過接口進行交互，如何保證依賴的正常，是測試面臨的主要挑戰。·開發人員必須實現服務間的通訊機制。
　　·實現用例跨多個服務時，須要面對使用分佈式事務管理的困難。
　　·實現跨多個服務的用例，須要團隊之間進行仔細的協調。

　　2. 部署的複雜性
　　在部署和管理時，由許多不一樣服務類型組成的系統的操做比較複雜，這將要求開發、測試及運維人員有相應的技術水平。

　　3. 增長內存消耗
　　微服務架構用多個服務實例取代了1個單體應用程序實例，若是每一個服務都運行在本身的JVM中，那麼有多少個服務實例，就會有多少個實例在運行時的內存開銷。

1.2.4　微服務架構與SOA的區別

1.3　如何構建微服務架構

 1.3.1　微服務的拆分

　　對於通常的公司而言，實踐微服務有很是大的技術挑戰，因此並非全部的公司都適合將單體架構拆分紅微服務架構。通常來講，微服務架構比較適合將來有必定的擴展複雜度，且有很大用戶增量預期的應用，例如一些新興的互聯網公司應用。這些公司在創業初期，不可能買大量的或很貴的機器，可是又必須考慮應對成功後巨量的用戶問題，這時微服務架構就成了最好的選擇。除此以外，對於那些項目規模較大、業務複雜度較高，且須要長期跟進的項目，也適合考慮使用微服務架構。
　　在決定使用微服務架構後，所面臨的另外一個問題就是如何將系統拆分爲微服務。對於微服務的拆分，能夠參考以下幾點建議。
　　·經過業務功能分解並定義與業務功能相對應的服務。
　　·將域驅動設計分解爲多個子域。
　　·按照動詞或用例分解，並定義負責特定操做的服務，例如一個負責完成訂單的航運服務。
　　·經過定義一個對給定類型的實體或資源的全部操做負責的服務來分解名詞或資源，例如一個負責管理用戶帳戶的帳戶服務。

1.3.2　微服務架構的組件

　　在正式學習如何搭建微服務架構以前，咱們先來了解一下微服務架構中涉及的一些常見組件名稱及其做用。
　　·服務註冊中心：註冊系統中全部服務的地方。
　　·服務註冊：服務提供方將本身調用地址註冊到服務註冊中心，讓服務調用方可以方便地找到本身。
　　·服務發現：服務調用方從服務註冊中心找到本身須要調用服務的地址。
　　·負載均衡：服務提供方通常以多實例的形式提供服務，使用負載均衡可以讓服務調用方鏈接到合適的服務節點。
　　·服務容錯：經過斷路器（也稱熔斷器）等一系列的服務保護機制，保證服務調用者在調用異常服務時快速地返回結果，避免大量的同步等待。
　　·服務網關：也稱爲API網關，是服務調用的惟一入口，能夠在這個組件中實現用戶鑑權、動態路由、灰度發佈、負載限流等功能。
　　·分佈式配置中心：將本地化的配置信息（properties、yml、yaml等）註冊到配置中心，實現程序包在開發、測試、生產環境的無差異性，方便程序包的遷移。

1.3.3　微服務架構的搭建

 

　　在圖1-5中，部署了一系列的微服務，每一個微服務都會訪問本身的數據庫（Database）。當這些微服務啓動時，會將其信息註冊到服務註冊中心（Service Registry），在客戶端發送請求時，請求首先會被API網關（API GateWay）攔截，API網關會讀取請求數據，並從註冊中心獲取對應的服務信息，而後API網關會根據服務信息調用所需的微服務。
　　小提示:圖1-5中展現的只是一個簡單的微服務架構，然而要判斷一個架構是不是微服務架構，還須要知足如下幾點要求。
　　·根據業務模塊劃分服務種類。
　　·每一個服務可獨立部署且相互隔離。
　　·經過輕量級API調用服務。
　　·服務需保證良好的高可用性。
　　只有知足以上幾點要求的架構，才能稱之爲微服務架構，因此在搭建微服務架構時，必定要注意這些問題。

1.3.4　微服務架構的技術選型

　　在微服務架構中，不一樣的組件（包括微服務實例、註冊中心和API網關等組件）須要根據不一樣的狀況來選取相應的技術，那麼咱們可使用哪些技術呢？本小節將對微服務架構中各個組件可以使用的技術，以及本書所選用的技術進行簡單介紹。
　　1. 微服務實例的開發
　　微服務的開發能夠選用的框架技術有Spring團隊的SpringBoot、Jboss公司的WildFly Swarm和Java EE官方的微服務框架KumuluzEE等。
　　2. 服務的註冊與發現
　　架構中服務的註冊與發現功能，可使用的技術有SpringCloud Eureka、Apache Zookeeper、Consul、Etcd和Dubbo等，它們都是用於服務註冊和發現的技術。
　　3. 負載均衡
　　負載均衡可使用的技術有Spring Cloud Ribbon和Dubbo等。
　　4. 服務容錯
　　服務容錯的技術能夠選用Hystrix，在Spring Cloud的子項目中包含Spring Cloud Hystrix。
　　5. API網關
　　架構中的API網關服務，可使用的技術有Spring CloudZuul、Spring Reactor、Netty或NodeJS等。
　　6. 分佈式配置中心
　　分佈式配置中心可使用Spring Cloud Config。
　　7. 調試
　　微服務應用的測試工做可使用Swagger。Swagger是當前最受歡迎的REST API文檔生成工具之一，它提供了強大的頁面測試功能來調試每一個RESTful API。
　　8. 部署
　　微服務的官方文檔中推薦使用Docker來打包和部署微服務。因爲Docker是一個開源的應用容器引擎，具備可移植性強、啓動速度快等特色，因此適合跑一些輕量的應用。
　　9. 持續集成
　　爲了實現服務的自動化部署，咱們能夠經過Jenkins搭建自動化部署系統，並使用Docker進行容器化封裝。
　　在上面的技術選型中，從微服務註冊與發現、負載均衡、容錯、API網關和分佈式配置中心組件的可選技術內，咱們都看到了Spring Cloud的身影。實際上，Spring Cloud的子項目中，已經提供了構建微服務所需的全部解決方案。

 

　　從圖1-6中能夠看出，咱們會使用Spring Boot實現微服務實例的開發，使用Spring Cloud Eureka來實現服務的註冊與發現，使用Spring Cloud Hystrix的斷路器功能來實現服務容錯，使用Spring Cloud Ribbon實現服務間的負載均衡，使用SpringCloud Zuul實現服務網關，使用Spring Cloud Config做爲分佈式配置中心，使用Swagger對微服務進行測試，並使用Jenkins的持續集成功能來實現自動化部署。
　　微服務架構中各個組件的技術選型有不少，對於已經實施過微服務而且項目自成體系的公司來講，Spring Cloud可能並無太大的吸引力，但對於還未實施微服務或項目沒有自成體系的公司來講，Spring Cloud將是一個很是好的選擇。
　　小提示:除了Spring Cloud以外，Dubbo也是目前國內比較流行的分佈式服務框架，它們都具有分佈式服務治理相關的功能，都可以提供服務註冊、發現、路由和負載均衡的能力。相比之下，Spring Cloud提供了更加完整的一套企業級分佈式雲應用的解決方案，包含了微服務組件中的方方面面，並可以結合Spring Boot、Docker實現快速開發的目的，而Dubbo只有Spring Cloud的一部分功能。因爲兩者具體的實現方式不一樣，所以並無好壞之分。企業在選用時，需根據自身狀況選擇。 

 

文章來源:微服務架構基礎SSD 1