1. 微服務架構

1.1 微服務架構理解

微服務架構（Microservice Architecture）是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現(xiàn)對解決方案的解耦。你可以將其看作是在架構層次而非獲取服務的類上應用很多SOLID原則。微服務架構是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務當中，從而降低系統(tǒng)的耦合性，并提供更加靈活的服務支持。

• 概念：把一個大型的單個應用程序和服務拆分為數(shù)個甚至數(shù)十個的支持微服務，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協(xié)議。
• 定義：圍繞業(yè)務領域組件來創(chuàng)建應用，這些應用可獨立地進行開發(fā)、管理和迭代。在分散的組件中使用云架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單。
• 本質：用一些功能比較明確、業(yè)務比較精練的服務去解決更大、更實際的問題。

1.2 傳統(tǒng)開發(fā)模式和微服務的區(qū)別

傳統(tǒng)的web開發(fā)方式

通過對比比較容易理解什么是Microservice Architecture。和Microservice相對應的，這種方式一般被稱為Monolithic（單體式開發(fā)）。所有的功能打包在一個 WAR包里，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有邏輯。

優(yōu)點：

• 開發(fā)簡單，集中式管理
• 基本不會重復開發(fā)
• 功能都在本地，沒有分布式的管理和調用消耗

缺點：

• 效率低：開發(fā)都在同一個項目改代碼，相互等待，沖突不斷
• 維護難：代碼功功能耦合在一起，新人不知道何從下手
• 不靈活：構建時間長，任何小修改都要重構整個項目，耗時
• 穩(wěn)定性差：一個微小的問題，都可能導致整個應用掛掉
• 擴展性不夠：無法滿足高并發(fā)下的業(yè)務需求

常見的系統(tǒng)架構遵循的三個標準和業(yè)務驅動力：

• 提高敏捷性：及時響應業(yè)務需求，促進企業(yè)發(fā)展
• 提升用戶體驗：提升用戶體驗，減少用戶流失
• 降低成本：降低增加產品，客戶或業(yè)務方案的成本

基于微服務架構的設計

目的：有效的拆分應用，實現(xiàn)敏捷開發(fā)和部署

關于微服務的一個形象表達

X軸：運行多個負載均衡器之后的運行實例Y軸：將應用進一步分解為微服務（分庫）Z軸：大數(shù)據(jù)量時，將服務分區(qū)（分表）

1.3 微服務的具體特征

官方定義

• 一些列的獨立的服務共同組成系統(tǒng)
• 單獨部署，跑在自己的進程中
• 每個服務為獨立的業(yè)務開發(fā)
• 分布式管理
• 非常強調隔離性

大概的標準

• 分布式服務組成的系統(tǒng)
• 按照業(yè)務，而不是技術來劃分組織
• 做有生命的產品而不是項目
• 強服務個體和弱通信（ Smart endpoints and dumb pipes ）
• 自動化運維（ DevOps ）
• 高度容錯性
• 快速演化和迭代

1.4 怎么具體實踐微服務

客戶端如何訪問這些服務 - API Gateway

原來的單體開發(fā)，所有的服務都是本地的，UI可以直接調用，現(xiàn)在按功能拆分成獨立的服務，跑在獨立的一般都在獨立的虛擬機上的 Java進程了?？蛻舳薝I如何訪問他的？后臺有N個服務，前臺就需要記住管理N個服務，一個服務下線/更新/升級，前臺就要重新部署，這明顯不符合我們拆分的理念，特別當前臺是移動應用的時候，通常業(yè)務變化的節(jié)奏更快。另外，N個小服務的調用也是一個不小的網(wǎng)絡開銷。還有一般微服務在系統(tǒng)內部，通常是無狀態(tài)的，用戶登錄信息和權限管理最好有一個統(tǒng)一的地方維護管理（OAuth）。

所以一般在后臺N個服務和UI之間一般會一個代理或者叫 API Gateway，他的作用包括：

• 提供統(tǒng)一服務入口，讓微服務對前臺透明
• 聚合后臺的服務，節(jié)省流量，提升性能
• 提供安全，過濾，流控等API管理功能

其實這個API Gateway可以有很多廣義的實現(xiàn)辦法，可以是一個軟硬一體的盒子，也可以是一個簡單的MVC框架，甚至是一個Node.js的服務端。他們最重要的作 用是為前臺（通常是移動應用）提供后臺服務的聚合，提供一個統(tǒng)一的服務出口，解除他們之間的耦合，不過API Gateway也有可能成為單點故障點或者性能的瓶頸。用過Taobao Open Platform（淘寶開放平臺）的就能很容易的體會，TAO就是這個API Gateway。

每個服務之間如何通信 - IPC

所有的微服務都是獨立的Java進程跑在獨立的虛擬機上，所以服務間的通信就是IPC（inter process communication），已經有很多成熟的方案?，F(xiàn)在基本最通用的有兩種方式：

同步調用：① REST（JAX-RS，Spring Boot）② RPC（Thrift, Dubbo）

異步消息調用：(Kafka, Notify, MetaQ)

同步和異步的區(qū)別：

一般同步調用比較簡單，一致性強，但是容易出調用問題，性能體驗上也會差些，特別是調用層次多的時候。RESTful和RPC的比較也是一個很有意思的話題。一般REST基于HTTP，更容易實現(xiàn)，更容易被接受，服務端實現(xiàn)技術也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要求，只要封裝了HTTP的SDK就能調用，所以相對使用的廣一些。RPC也有自己的優(yōu)點，傳輸協(xié)議更高效，安全更可控，特別在一個公司內部，如果有統(tǒng)一個的開發(fā)規(guī)范和統(tǒng)一的服務框架時，他的開發(fā)效率優(yōu)勢更明顯些。就看各自的技術積累實際條件自己的選擇了。

而異步消息的方式在分布式系統(tǒng)中有特別廣泛的應用，他既能減低調用服務之間的耦合，又能成為調用之間的緩沖，確保消息積壓不會沖垮被調用方，同時能保證調用方的服務體驗，繼續(xù)干自己該干的活，不至于被后臺性能拖慢。不過需要付出的代價是一致性的減弱，需要接受數(shù)據(jù)最終一致性；還有就是后臺服務一般要 實現(xiàn)冪等性，因為消息發(fā)送出于性能的考慮一般會有重復（保證消息的被收到且僅收到一次對性能是很大的考驗）；最后就是必須引入一個獨立的broker，如果公司內部沒有技術積累，對broker分布式管理也是一個很大的挑戰(zhàn)。

如此多的服務如何實現(xiàn)？- 服務發(fā)現(xiàn)

在微服務架構中，一般每一個服務都是有多個拷貝來做負載均衡。一個服務隨時可能下線也可能應對臨時訪問壓力增加新的服務節(jié)點。服務之間如何相互感知？服務如何管理？這就是服務發(fā)現(xiàn)的問題了。一般有兩類做法，也各有優(yōu)缺點。基本都是通過zookeeper等類似技術做服務注冊信息的分布式管理。當服務上線時，服務提供者將自己的服務信息注冊到ZK（或類似框架），并通過心跳維持長鏈接，實時更新鏈接信息。服務調用者通過ZK尋址，根據(jù)可定制算法找到一個服務，還可以將服務信息緩存在本地以提高性能。當服務下線時，ZK會發(fā)通知給服務客戶端。

客戶端做服務發(fā)現(xiàn)：優(yōu)點是架構簡單，擴展靈活，只對服務注冊器依賴。缺點是客戶端要維護所有調用服務的地址有技術難度，一般大公司都有成熟的內部框架支持，比如Dubbo。

服務端做服務發(fā)現(xiàn)：優(yōu)點是簡單，所有服務對于前臺調用方透明，一般在小公司在云服務上部署的應用采用的比較多。

服務掛了如何解決 - 熔斷機制，限流，負載均衡...

前面提到，Monolithic方式開發(fā)一個很大的風險是把所有雞蛋放在一個籃子里，一榮俱榮一損俱損。而分布式最大的特性就是網(wǎng)絡是不可靠的。通過微服務拆分能降低這個風險，不過如果沒有特別的保障結局肯定是噩夢。所以當我們的系統(tǒng)是由一系列的服務調用鏈組成的時候，我們必須確保任一環(huán)節(jié)出問題都不至于影響整體鏈路。

相應的手段有很多：這些方法基本都很明確通用，比如Netflix的Hystrix：https://github.com/Netflix/Hystrix

• 重試機制
• 限流
• 熔斷機制
• 負載均衡
• 降級（本地緩存）

1.5 微服務的優(yōu)缺點

微服務的優(yōu)點：

關鍵點：復雜度可控，獨立按需擴展，技術選型靈活，容錯，可用性高

• 它解決了復雜性的問題。它會將一種怪異的整體應用程序分解成一組服務。雖然功能總量 不變，但應用程序已分解為可管理的塊或服務。每個服務都以RPC或消息驅動的API的形式定義了一個明確的邊界；Microservice架構模式實現(xiàn)了一個模塊化水平。
• 這種架構使每個服務都能夠由專注于該服務的團隊獨立開發(fā)。開發(fā)人員可以自由選擇任何有用的技術，只要該服務符合API合同。當然大多數(shù)組織都希望避免完全無政府狀態(tài)并限制技術選擇。然而這種自由意味著開發(fā)人員不再有義務使用在新項目開始時存在的可能過時的技術。在編寫新服務時，他們可以選擇使用當前的技術。此外由于服務相對較小，使用當前技術重寫舊服務變得可行。
• Microservice架構模式使每個微服務都能獨立部署。開發(fā)人員不需要協(xié)調部署本地服務的變更。這些變化可以在測試后盡快部署。例如UI團隊可以執(zhí)行A | B測試，并快速迭代UI更改。Microservice架構模式使連續(xù)部署成為可能。
• Microservice架構模式使每個服務都可以獨立調整。您可以僅部署滿足其容量和可用性限制的每個服務的實例數(shù)。此外您可以使用最符合服務資源要求的硬件。

微服務的缺點

關鍵點（挑戰(zhàn)）：多服務運維難度，系統(tǒng)部署依賴，服務間通信成本，數(shù)據(jù)一致性，系統(tǒng)集成測試，重復工作，性能監(jiān)控等

• 一個缺點是名稱本身。術語microservice過度強調服務規(guī)模。但重要的是要記住，這是一種手段而不是主要目標。微服務的目標是充分分解應用程序以便于敏捷應用程序開發(fā)和部署。
• 微服務器的另一個主要缺點是分布式系統(tǒng)而產生的復雜性。開發(fā)人員需要選擇和實現(xiàn)基于消息傳遞或RPC的進程間通信機制。此外他們還必須編寫代碼來處理部分故障，因為請求的目的地可能很慢或不可用。
• 微服務器的另一個挑戰(zhàn)是分區(qū)數(shù)據(jù)庫架構。更新多個業(yè)務實體的業(yè)務交易是相當普遍的。但是在基于微服務器的應用程序中，您需要更新不同服務所擁有的多個數(shù)據(jù)庫。使用分布式事務通常不是一個選擇，而不僅僅是因為CAP定理。許多今天高度可擴展的NoSQL數(shù)據(jù)庫都不支持它們。你最終不得不使用最終的一致性方法，這對開發(fā)人員來說更具挑戰(zhàn)性。
• 測試微服務應用程序也更復雜。服務類似的測試類將需要啟動該服務及其所依賴的任何服務（或至少為這些服務配置存根）。再次，重要的是不要低估這樣做的復雜性。
• Microservice架構模式的另一個主要挑戰(zhàn)是實現(xiàn)跨越多個服務的更改。例如我們假設您正在實施一個需要更改服務A，B和C的故事，其中A取決于B和B取決于C，在單片應用程序中您可以簡單地更改相應的模塊，整合更改并一次性部署。相比之下，在Microservice架構模式中，您需要仔細規(guī)劃和協(xié)調對每個服務的更改。例如，您需要更新服務C，然后更新服務B，然后再維修A，幸運的是大多數(shù)更改通常僅影響一個服務，而需要協(xié)調的多服務變更相對較少。
• 部署基于微服務的應用程序也更復雜。單一應用程序簡單地部署在傳統(tǒng)負載平衡器后面的一組相同的服務器上。每個應用程序實例都配置有基礎架構服務（如數(shù)據(jù)庫和消息代理）的位置（主機和端口）。相比之下，微服務應用通常由大量服務組成。例如每個服務將有多個運行時實例。更多的移動部件需要進行配置，部署，擴展和監(jiān)控。此外您還需要實現(xiàn)服務發(fā)現(xiàn)機制，使服務能夠發(fā)現(xiàn)需要與之通信的任何其他服務的位置（主機和端口）。傳統(tǒng)的基于故障單和手動操作的方法無法擴展到這種復雜程度。因此，成功部署微服務應用程序需要開發(fā)人員更好地控制部署方法，并實現(xiàn)高水平的自動化。

2. SpringCloud引入

SpringCloud并不是一個框架而是一個微服務整體架構，或者說SpringCloud是一個生態(tài)圈，里面包含了很多的服務，每一個服務獨立存在，相互之間互不干擾，可以直接運行。

其實SpringCloud就是一個完整的微服務架構，提供了所有功能，整個開發(fā)項目中所需要的架構功能微服務都有，也就是說整個springcloud就是一個完整的項目，這個架構已經搭建完畢了，用到了直接獲取即可，只需要往架構中注入自己的業(yè)務代碼就可以。

它具有微服務的以下幾大優(yōu)勢：

• 復雜度可控

在將應用分解的同時，規(guī)避了原本復雜度無止境的積累。每一個微服務專注于單一功能，并通過定義良好的接口清晰表述服務邊界。由于體積小、復雜度低，每個微服務可由一個小規(guī)模開發(fā)團隊完全掌控，易于保持高可維護性和開發(fā)效率

• 獨立部署

具備獨立的運行進程，所以每個微服務也可以獨立部署。當某個服務發(fā)生變更時無需編譯、部署整個應用。由微服務組成的應用相當于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時降低對生產環(huán)境所造成的風險，最終縮短應用交付周期

• 技術選型靈活

微服務架構下，技術選型是去中心化的。每個團隊可以根據(jù)自身服務的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術棧。由于每個微服務相對簡單，故需要對技術棧進行升級時所面臨的風險就較低，甚至完全重構一個微服務也是可行的

• 容錯能力

在微服務架構下，故障會被隔離在單個服務中。若設計良好，其他服務可通過 重試、平穩(wěn)退化等機制實現(xiàn)應用層面的容錯

• 擴展性

每個服務可以根據(jù)實際需求獨立進行擴展

3. SpringCloud五大組件淺析

3.1 舉例業(yè)務場景

如上圖，假設現(xiàn)在開發(fā)一個電商網(wǎng)站，要實現(xiàn)支付訂單功能流程如下

• 創(chuàng)建一個訂單后，如果用戶立刻支付了這個訂單，我們需要將這個訂單狀態(tài)更新為已支付
• 扣減相對應的商品庫存
• 通知倉儲中心進行發(fā)貨
• 給用戶這次購物添加加相對應的積分

針對上述流程我們需要有訂單服務、庫存服務、倉儲服務、積分服務，整個流程的大體思路如下：

• 用戶針對一個訂單完成支付后，就會去找訂單服務，更新訂單狀態(tài)
• 訂單服務調用庫存服務，完成相應的功能
• 訂單服務調用倉儲服務，完成相應的功能
• 訂單服務調用積分服務，完成相應的功能

3.2 服務發(fā)現(xiàn) - Netflix Eureka（類似zookeeper）

首先考慮一個問題，訂單服務要調用庫存服務、倉儲服務、積分服務，如何調用呢？

訂單服務根本不知道上述服務在哪臺服務器上，所以沒法調用，而Eureka的作用就是來告訴訂單服務它想調用的服務在哪臺服務器上，Eureka有客戶端和服務端，每一個服務上面都有Eureka客戶端，可以把本服務的相關信息注冊到Eureka服務端上，那么我們的訂單服務就可以就可以找到庫存服務、倉儲服務、積分服務了

我們上述的業(yè)務使用Eureka后如下圖：

總結：

• Eurake客戶端：負責將這個服務的信息注冊到Eureka服務端中Eureka
• 服務端：相當于一個注冊中心，里面有注冊表，注冊表中保存了各個服務所在的機器和端口號，可通過Eureka服務端找到各個服務

3.3 WebService客戶端Feign（類似Dubbo）

通過上面的Eureka，現(xiàn)在訂單服務確實知道庫存服務、積分服務、倉儲服務在哪了，但是我們如何去調用這些服務呢，如果我們自己去寫很多代碼調用那就太麻煩了，而SpringCloud已經為我們準備好了一個核心組件：Feign，接下來看如何通過Feign讓訂單服務調用庫存服務，注意Feign也是用在消費者端的。

訂單服務與倉庫服務Service

沒有底層的建立連接、構造請求、解析響應的代碼，直接就是用注解定義一個 FeignClient接口，然后調用那個接口就可以了。人家Feign Client會在底層根據(jù)你的注解，跟你指定的服務建立連接、構造請求、發(fā)起靕求、獲取響應、解析響應，等等。這一系列臟活累活，人家Feign全給你干了。

問題來了，F(xiàn)eign是如何做到的呢？其實Feign的一個機制就是使用了動態(tài)代理：

• 首先，如果你對某個接口定義了@FeignClient注解，F(xiàn)eign就會針對這個接口創(chuàng)建一個動態(tài)代理
• 接著你要是調用那個接口，本質就是會調用 Feign創(chuàng)建的動態(tài)代理，這是核心中的核心
• Feign的動態(tài)代理會根據(jù)你在接口上的@RequestMapping等注解，來動態(tài)構造出你要請求的服務的地址
• 最后針對這個地址，發(fā)起請求、解析響應

3.4 客服端負載均衡 - Netflix Ribbon

上面可以通過Eureka可以找到服務，然后通過Feign去調用服務，但是如果有多臺機器上面都部署了庫存服務，我應該使用Feign去調用哪一臺上面的服務呢，這個時候就需要Ribbon了，它在服務消費者端配置和使用，作用就是負載均衡，默認使用的負載均衡算法是輪詢算法，Ribbon會從Eureka服務端中獲取到對應的服務注冊表，然后就知道相應服務的位置，然后Ribbon根據(jù)設計的負載均衡算法去選擇一臺機器，F(xiàn)eigin就會針對這些機器構造并發(fā)送請求。

3.5 斷路器 - Netflix Hystrix

在微服務架構里一個系統(tǒng)會有多個服務，以本文的業(yè)務場景為例：訂單服務在一個業(yè)務流程里需要調用三個服務，現(xiàn)在假設訂單服務自己最多只有100個線程可以處理請求，如果積分服務出錯，每次訂單服務調用積分服務的時候，都會卡住幾秒鐘，然后拋出—個超時異常。

分析下這樣會導致什么問題呢？如果系統(tǒng)在高并發(fā)的情況下，大量請求涌過來的時候，訂單服務的100個線程會卡在積分服務這塊，導致訂單服務沒有一個多余的線程可以處理請求，這種問題就是微服務架構中恐怖的服務器雪崩問題，這么多的服務互相調用要是不做任何保護的話，某一個服務掛掉會引起連鎖反應導致別的服務掛掉。

服務也不應該掛掉啊，我們只要讓存儲服務和倉儲服務正常工作就可以了，至于積分服務我們后期可以手動給用戶加上積分，這個時候就輪到Hystrix了，Hystrix是隔離、熔斷以及降級的一個框架，說白了就是Hystrix會搞很多小線程池然后讓這些小線程池去請求服務，返回結果，Hystrix相當于是個中間過濾區(qū)，如果我們的積分服務掛了，那我們請求積分服務直接就返回了，不需要等待超時時間結束拋出異常，這就是所謂的熔斷，但是也不能啥都不干就返回啊，不然我們之后手動加積分咋整啊，那我們每次調用積分服務就在數(shù)據(jù)庫里記錄一條消息，這就是所謂的降級，Hystrix隔離、熔斷和降級的全流程如下：

3.6 服務網(wǎng)關 - Netflix Zuul （類似于服務端的Nginx）

該組件是負責網(wǎng)絡路由的，假設你后臺部署了幾百個服務，現(xiàn)在有個前端兄弟，人家請求是直接從瀏覽器那兒發(fā)過來的。打個比方：人家要請求一下庫存服務，你難道還讓人家記著這服務的名字叫做inventory-service，并且部署在5臺機器上，就算人家肯記住這一個，那你后臺可有幾百個服務的名稱和地址呢？難不成人家請求一個，就得記住一個？

上面這種情況，壓根兒是不現(xiàn)實的。所以一般微服務架構中都必然會設計一個網(wǎng)關在里面，像android、ios、pc前端、微信小程序、H5等等，不用去關心后端有幾百個服務，就知道有一個網(wǎng)關，所有請求都往網(wǎng)關走，網(wǎng)關會根據(jù)請求中的一些特征，將請求轉發(fā)給后端的各個服務。

3.7 總結Eureka：

• Eureka：服務啟動的時候，服務上的Eureka客戶端會把自身注冊到Eureka服務端，并且可以通過Eureka服務端知道其他注冊的服務。
• Ribbon：服務間發(fā)起請求的時候，服務消費者方基于Ribbon服務做到負載均衡，從服務提供者存儲的多臺機器中選擇一臺，如果一個服務只在一臺機器上面，那就用不到Ribbon選擇機器了，如果有多臺機器，那就需要使用Ribbon選擇之后再去使用。
• Feign：Feign使用的時候會集成Ribbon，Ribbon去Eureka服務端中找到服務提供者的所在的服務器信息，然后根據(jù)隨機策略選擇一個，拼接Url地址后發(fā)起請求。
• Hystrix：發(fā)起的請求是通過Hystrix的線程池去訪問服務，不同的服務通過不同的線程池，實現(xiàn)了不同的服務調度隔離，如果服務出現(xiàn)故障，通過服務熔斷，避免服務雪崩的問題 ，并且通過服務降級，保證可以手動實現(xiàn)服務正常功能。
• Zuul：如果前端調用后臺系統(tǒng)，統(tǒng)一走zull網(wǎng)關進入，通過zull網(wǎng)關轉發(fā)請求給對應的服務。

到此這篇關于SpringCloud簡介與微服務架構的文章就介紹到這了,更多相關SpringCloud簡介與微服務架構內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！