1. 微服務(wù)架構(gòu)

1.1 微服務(wù)架構(gòu)理解

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

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

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

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

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

常見的系統(tǒng)架構(gòu)遵循的三個(gè)標(biāo)準(zhǔn)和業(yè)務(wù)驅(qū)動(dòng)力：

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

基于微服務(wù)架構(gòu)的設(shè)計(jì)

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

關(guān)于微服務(wù)的一個(gè)形象表達(dá)

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

1.3 微服務(wù)的具體特征

官方定義

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

大概的標(biāo)準(zhǔn)

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

1.4 怎么具體實(shí)踐微服務(wù)

客戶端如何訪問這些服務(wù) - API Gateway

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

所以一般在后臺(tái)N個(gè)服務(wù)和UI之間一般會(huì)一個(gè)代理或者叫 API Gateway，他的作用包括：

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

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

每個(gè)服務(wù)之間如何通信 - IPC

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

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

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

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

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

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

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

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

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

服務(wù)端做服務(wù)發(fā)現(xiàn)：優(yōu)點(diǎn)是簡(jiǎn)單，所有服務(wù)對(duì)于前臺(tái)調(diào)用方透明，一般在小公司在云服務(wù)上部署的應(yīng)用采用的比較多。

服務(wù)掛了如何解決 - 熔斷機(jī)制，限流，負(fù)載均衡...

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

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

• 重試機(jī)制
• 限流
• 熔斷機(jī)制
• 負(fù)載均衡
• 降級(jí)（本地緩存）

1.5 微服務(wù)的優(yōu)缺點(diǎn)

微服務(wù)的優(yōu)點(diǎn)：

關(guān)鍵點(diǎn)：復(fù)雜度可控，獨(dú)立按需擴(kuò)展，技術(shù)選型靈活，容錯(cuò)，可用性高

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

微服務(wù)的缺點(diǎn)

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

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

2. SpringCloud引入

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

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

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

• 復(fù)雜度可控

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

• 獨(dú)立部署

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

• 技術(shù)選型靈活

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

• 容錯(cuò)能力

在微服務(wù)架構(gòu)下，故障會(huì)被隔離在單個(gè)服務(wù)中。若設(shè)計(jì)良好，其他服務(wù)可通過 重試、平穩(wěn)退化等機(jī)制實(shí)現(xiàn)應(yīng)用層面的容錯(cuò)

• 擴(kuò)展性

每個(gè)服務(wù)可以根據(jù)實(shí)際需求獨(dú)立進(jìn)行擴(kuò)展

3. SpringCloud五大組件淺析

3.1 舉例業(yè)務(wù)場(chǎng)景

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

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

針對(duì)上述流程我們需要有訂單服務(wù)、庫存服務(wù)、倉儲(chǔ)服務(wù)、積分服務(wù)，整個(gè)流程的大體思路如下：

• 用戶針對(duì)一個(gè)訂單完成支付后，就會(huì)去找訂單服務(wù)，更新訂單狀態(tài)
• 訂單服務(wù)調(diào)用庫存服務(wù)，完成相應(yīng)的功能
• 訂單服務(wù)調(diào)用倉儲(chǔ)服務(wù)，完成相應(yīng)的功能
• 訂單服務(wù)調(diào)用積分服務(wù)，完成相應(yīng)的功能

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

首先考慮一個(gè)問題，訂單服務(wù)要調(diào)用庫存服務(wù)、倉儲(chǔ)服務(wù)、積分服務(wù)，如何調(diào)用呢？

訂單服務(wù)根本不知道上述服務(wù)在哪臺(tái)服務(wù)器上，所以沒法調(diào)用，而Eureka的作用就是來告訴訂單服務(wù)它想調(diào)用的服務(wù)在哪臺(tái)服務(wù)器上，Eureka有客戶端和服務(wù)端，每一個(gè)服務(wù)上面都有Eureka客戶端，可以把本服務(wù)的相關(guān)信息注冊(cè)到Eureka服務(wù)端上，那么我們的訂單服務(wù)就可以就可以找到庫存服務(wù)、倉儲(chǔ)服務(wù)、積分服務(wù)了

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

總結(jié)：

• Eurake客戶端：負(fù)責(zé)將這個(gè)服務(wù)的信息注冊(cè)到Eureka服務(wù)端中Eureka
• 服務(wù)端：相當(dāng)于一個(gè)注冊(cè)中心，里面有注冊(cè)表，注冊(cè)表中保存了各個(gè)服務(wù)所在的機(jī)器和端口號(hào)，可通過Eureka服務(wù)端找到各個(gè)服務(wù)

3.3 WebService客戶端Feign（類似Dubbo）

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

訂單服務(wù)與倉庫服務(wù)Service

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

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

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

3.4 客服端負(fù)載均衡 - Netflix Ribbon

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

3.5 斷路器 - Netflix Hystrix

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

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

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

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

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

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

3.7 總結(jié)Eureka：

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

到此這篇關(guān)于SpringCloud簡(jiǎn)介與微服務(wù)架構(gòu)的文章就介紹到這了,更多相關(guān)SpringCloud簡(jiǎn)介與微服務(wù)架構(gòu)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論