SpringCloud簡介與微服務架構(gòu)
1. 微服務架構(gòu)
1.1 微服務架構(gòu)理解
微服務架構(gòu)（Microservice Architecture）是一種架構(gòu)概念，旨在通過將功能分解到各個離散的服務中以實現(xiàn)對解決方案的解耦。你可以將其看作是在架構(gòu)層次而非獲取服務的類上應用很多SOLID原則。微服務架構(gòu)是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務當中，從而降低系統(tǒng)的耦合性，并提供更加靈活的服務支持。
概念：把一個大型的單個應用程序和服務拆分為數(shù)個甚至數(shù)十個的支持微服務，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協(xié)議。定義：圍繞業(yè)務領(lǐng)域組件來創(chuàng)建應用，這些應用可獨立地進行開發(fā)、管理和迭代。在分散的組件中使用云架構(gòu)和平臺式部署、管理和服務功能，使產(chǎn)品交付變得更加簡單。本質(zhì)：用一些功能比較明確、業(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ā)
功能都在本地，沒有分布式的管理和調(diào)用消耗
缺點：
效率低：開發(fā)都在同一個項目改代碼，相互等待，沖突不斷
維護難：代碼功功能耦合在一起，新人不知道何從下手
不靈活：構(gòu)建時間長，任何小修改都要重構(gòu)整個項目，耗時
穩(wěn)定性差：一個微小的問題，都可能導致整個應用掛掉
擴展性不夠：無法滿足高并發(fā)下的業(yè)務需求
常見的系統(tǒng)架構(gòu)遵循的三個標準和業(yè)務驅(qū)動力：
提高敏捷性：及時響應業(yè)務需求，促進企業(yè)發(fā)展
提升用戶體驗：提升用戶體驗，減少用戶流失
降低成本：降低增加產(chǎn)品，客戶或業(yè)務方案的成本
基于微服務架構(gòu)的設(shè)計
目的：有效的拆分應用，實現(xiàn)敏捷開發(fā)和部署
關(guān)于微服務的一個形象表達
X軸：運行多個負載均衡器之后的運行實例
Y軸：將應用進一步分解為微服務（分庫）
Z軸：大數(shù)據(jù)量時，將服務分區(qū)（分表）
1.3 微服務的具體特征
官方定義
一些列的獨立的服務共同組成系統(tǒng)
單獨部署，跑在自己的進程中
每個服務為獨立的業(yè)務開發(fā)
分布式管理
非常強調(diào)隔離性
大概的標準
分布式服務組成的系統(tǒng)
按照業(yè)務，而不是技術(shù)來劃分組織
做有生命的產(chǎn)品而不是項目
強服務個體和弱通信（ Smart endpoints and dumb pipes ）
自動化運維（ DevOps ）
高度容錯性
快速演化和迭代
1.4 怎么具體實踐微服務
客戶端如何訪問這些服務 - API Gateway
原來的單體開發(fā)，所有的服務都是本地的，UI可以直接調(diào)用，現(xiàn)在按功能拆分成獨立的服務，跑在獨立的一般都在獨立的虛擬機上的 Java進程了。客戶端UI如何訪問他的？后臺有N個服務，前臺就需要記住管理N個服務，一個服務下線/更新/升級，前臺就要重新部署，這明顯不符合我們拆分的理念，特別當前臺是移動應用的時候，通常業(yè)務變化的節(jié)奏更快。另外，N個小服務的調(diào)用也是一個不小的網(wǎng)絡(luò)開銷。還有一般微服務在系統(tǒng)內(nèi)部，通常是無狀態(tài)的，用戶登錄信息和權(quán)限管理最好有一個統(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），已經(jīng)有很多成熟的方案。現(xiàn)在基本最通用的有兩種方式：
同步調(diào)用：① REST（JAX-RS，Spring Boot）② RPC（Thrift, Dubbo）
異步消息調(diào)用：(Kafka, Notify, MetaQ)
同步和異步的區(qū)別：
一般同步調(diào)用比較簡單，一致性強，但是容易出調(diào)用問題，性能體驗上也會差些，特別是調(diào)用層次多的時候。RESTful和RPC的比較也是一個很有意思的話題。一般REST基于HTTP，更容易實現(xiàn)，更容易被接受，服務端實現(xiàn)技術(shù)也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要求，只要封裝了HTTP的SDK就能調(diào)用，所以相對使用的廣一些。RPC也有自己的優(yōu)點，傳輸協(xié)議更高效，安全更可控，特別在一個公司內(nèi)部，如果有統(tǒng)一個的開發(fā)規(guī)范和統(tǒng)一的服務框架時，他的開發(fā)效率優(yōu)勢更明顯些。就看各自的技術(shù)積累實際條件自己的選擇了。
而異步消息的方式在分布式系統(tǒng)中有特別廣泛的應用，他既能減低調(diào)用服務之間的耦合，又能成為調(diào)用之間的緩沖，確保消息積壓不會沖垮被調(diào)用方，同時能保證調(diào)用方的服務體驗，繼續(xù)干自己該干的活，不至于被后臺性能拖慢。不過需要付出的代價是一致性的減弱，需要接受數(shù)據(jù)最終一致性；還有就是后臺服務一般要 實現(xiàn)冪等性，因為消息發(fā)送出于性能的考慮一般會有重復（保證消息的被收到且僅收到一次對性能是很大的考驗）；最后就是必須引入一個獨立的broker，如果公司內(nèi)部沒有技術(shù)積累，對broker分布式管理也是一個很大的挑戰(zhàn)。
如此多的服務如何實現(xiàn)？- 服務發(fā)現(xiàn)
在微服務架構(gòu)中，一般每一個服務都是有多個拷貝來做負載均衡。一個服務隨時可能下線也可能應對臨時訪問壓力增加新的服務節(jié)點。服務之間如何相互感知？服務如何管理？這就是服務發(fā)現(xiàn)的問題了。一般有兩類做法，也各有優(yōu)缺點。基本都是通過zookeeper等類似技術(shù)做服務注冊信息的分布式管理。當服務上線時，服務提供者將自己的服務信息注冊到ZK（或類似框架），并通過心跳維持長鏈接，實時更新鏈接信息。服務調(diào)用者通過ZK尋址，根據(jù)可定制算法找到一個服務，還可以將服務信息緩存在本地以提高性能。當服務下線時，ZK會發(fā)通知給服務客戶端。
客戶端做服務發(fā)現(xiàn)：優(yōu)點是架構(gòu)簡單，擴展靈活，只對服務注冊器依賴。缺點是客戶端要維護所有調(diào)用服務的地址有技術(shù)難度，一般大公司都有成熟的內(nèi)部框架支持，比如Dubbo。
服務端做服務發(fā)現(xiàn)：優(yōu)點是簡單，所有服務對于前臺調(diào)用方透明，一般在小公司在云服務上部署的應用采用的比較多。
服務掛了如何解決 - 熔斷機制，限流，負載均衡...
前面提到，Monolithic方式開發(fā)一個很大的風險是把所有雞蛋放在一個籃子里，一榮俱榮一損俱損。而分布式最大的特性就是網(wǎng)絡(luò)是不可靠的。通過微服務拆分能降低這個風險，不過如果沒有特別的保障結(jié)局肯定是噩夢。所以當我們的系統(tǒng)是由一系列的服務調(diào)用鏈組成的時候，我們必須確保任一環(huán)節(jié)出問題都不至于影響整體鏈路。
相應的手段有很多：這些方法基本都很明確通用，比如Netflix的Hystrix：https://github.com/Netflix/Hystrix
重試機制
限流
熔斷機制
負載均衡
降級（本地緩存）
1.5 微服務的優(yōu)缺點
微服務的優(yōu)點：
關(guān)鍵點：復雜度可控，獨立按需擴展，技術(shù)選型靈活，容錯，可用性高
它解決了復雜性的問題。它會將一種怪異的整體應用程序分解成一組服務。雖然功能總量 不變，但應用程序已分解為可管理的塊或服務。每個服務都以RPC或消息驅(qū)動的API的形式定義了一個明確的邊界；Microservice架構(gòu)模式實現(xiàn)了一個模塊化水平。
這種架構(gòu)使每個服務都能夠由專注于該服務的團隊獨立開發(fā)。開發(fā)人員可以自由選擇任何有用的技術(shù)，只要該服務符合API合同。當然大多數(shù)組織都希望避免完全無政府狀態(tài)并限制技術(shù)選擇。然而這種自由意味著開發(fā)人員不再有義務使用在新項目開始時存在的可能過時的技術(shù)。在編寫新服務時，他們可以選擇使用當前的技術(shù)。此外由于服務相對較小，使用當前技術(shù)重寫舊服務變得可行。
Microservice架構(gòu)模式使每個微服務都能獨立部署。開發(fā)人員不需要協(xié)調(diào)部署本地服務的變更。這些變化可以在測試后盡快部署。例如UI團隊可以執(zhí)行A | B測試，并快速迭代UI更改。Microservice架構(gòu)模式使連續(xù)部署成為可能。
Microservice架構(gòu)模式使每個服務都可以獨立調(diào)整。您可以僅部署滿足其容量和可用性限制的每個服務的實例數(shù)。此外您可以使用最符合服務資源要求的硬件。
微服務的缺點
關(guān)鍵點（挑戰(zhàn)）：多服務運維難度，系統(tǒng)部署依賴，服務間通信成本，數(shù)據(jù)一致性，系統(tǒng)集成測試，重復工作，性能監(jiān)控等
一個缺點是名稱本身。術(shù)語microservice過度強調(diào)服務規(guī)模。但重要的是要記住，這是一種手段而不是主要目標。微服務的目標是充分分解應用程序以便于敏捷應用程序開發(fā)和部署。
微服務器的另一個主要缺點是分布式系統(tǒng)而產(chǎn)生的復雜性。開發(fā)人員需要選擇和實現(xiàn)基于消息傳遞或RPC的進程間通信機制。此外他們還必須編寫代碼來處理部分故障，因為請求的目的地可能很慢或不可用。
微服務器的另一個挑戰(zhàn)是分區(qū)數(shù)據(jù)庫架構(gòu)。更新多個業(yè)務實體的業(yè)務交易是相當普遍的。但是在基于微服務器的應用程序中，您需要更新不同服務所擁有的多個數(shù)據(jù)庫。使用分布式事務通常不是一個選擇，而不僅僅是因為CAP定理。許多今天高度可擴展的NoSQL數(shù)據(jù)庫都不支持它們。你最終不得不使用最終的一致性方法，這對開發(fā)人員來說更具挑戰(zhàn)性。
測試微服務應用程序也更復雜。服務類似的測試類將需要啟動該服務及其所依賴的任何服務（或至少為這些服務配置存根）。再次，重要的是不要低估這樣做的復雜性。
Microservice架構(gòu)模式的另一個主要挑戰(zhàn)是實現(xiàn)跨越多個服務的更改。例如我們假設(shè)您正在實施一個需要更改服務A，B和C的故事，其中A取決于B和B取決于C，在單片應用程序中您可以簡單地更改相應的模塊，整合更改并一次性部署。相比之下，在Microservice架構(gòu)模式中，您需要仔細規(guī)劃和協(xié)調(diào)對每個服務的更改。例如，您需要更新服務C，然后更新服務B，然后再維修A，幸運的是大多數(shù)更改通常僅影響一個服務，而需要協(xié)調(diào)的多服務變更相對較少。
部署基于微服務的應用程序也更復雜。單一應用程序簡單地部署在傳統(tǒng)負載平衡器后面的一組相同的服務器上。每個應用程序?qū)嵗寂渲糜谢A(chǔ)架構(gòu)服務（如數(shù)據(jù)庫和消息代理）的位置（主機和端口）。相比之下，微服務應用通常由大量服務組成。例如每個服務將有多個運行時實例。更多的移動部件需要進行配置，部署，擴展和監(jiān)控。此外您還需要實現(xiàn)服務發(fā)現(xiàn)機制，使服務能夠發(fā)現(xiàn)需要與之通信的任何其他服務的位置（主機和端口）。傳統(tǒng)的基于故障單和手動操作的方法無法擴展到這種復雜程度。因此，成功部署微服務應用程序需要開發(fā)人員更好地控制部署方法，并實現(xiàn)高水平的自動化。
2. SpringCloud引入
理解
SpringCloud并不是一個框架而是一個微服務整體架構(gòu)，或者說SpringCloud是一個生態(tài)圈，里面包含了很多的服務，每一個服務獨立存在，相互之間互不干擾，可以直接運行。
其實SpringCloud就是一個完整的微服務架構(gòu)，提供了所有功能，整個開發(fā)項目中所需要的架構(gòu)功能微服務都有，也就是說整個springcloud就是一個完整的項目，這個架構(gòu)已經(jīng)搭建完畢了，用到了直接獲取即可，只需要往架構(gòu)中注入自己的業(yè)務代碼就可以。
SpringCloud具有微服務的以下幾大優(yōu)勢
復雜度可控
在將應用分解的同時，規(guī)避了原本復雜度無止境的積累。每一個微服務專注于單一功能，并通過定義良好的接口清晰表述服務邊界。由于體積小、復雜度低，每個微服務可由一個小規(guī)模開發(fā)團隊完全掌控，易于保持高可維護性和開發(fā)效率
獨立部署
具備獨立的運行進程，所以每個微服務也可以獨立部署。
當某個服務發(fā)生變更時無需編譯、部署整個應用。
由微服務組成的應用相當于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時降低對生產(chǎn)環(huán)境所造成的風險，最終縮短應用交付周期
技術(shù)選型靈活
微服務架構(gòu)下，技術(shù)選型是去中心化的。每個團隊可以根據(jù)自身服務的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。
由于每個微服務相對簡單，故需要對技術(shù)棧進行升級時所面臨的風險就較低，甚至完全重構(gòu)一個微服務也是可行的
容錯能力
在微服務架構(gòu)下，故障會被隔離在單個服務中。若設(shè)計良好，其他服務可通過 重試、平穩(wěn)退化等機制實現(xiàn)應用層面的容錯
擴展性
每個服務可以根據(jù)實際需求獨立進行擴展
3. SpringCloud各大組件淺析（過去）
3.1 舉例業(yè)務場景
如上圖，假設(shè)現(xiàn)在開發(fā)一個電商網(wǎng)站，要實現(xiàn)支付訂單功能流程如下
創(chuàng)建一個訂單后，如果用戶立刻支付了這個訂單，我們需要將這個訂單狀態(tài)更新為
已支付扣減相對應的商品庫存
通知倉儲中心進行發(fā)貨
給用戶這次購物添加加相對應的積分
針對上述流程我們需要有訂單服務、庫存服務、倉儲服務、積分服務，整個流程的大體思路如下：
用戶針對一個訂單完成支付后，就會去找訂單服務，更新訂單狀態(tài)
訂單服務調(diào)用庫存服務，完成相應的功能
訂單服務調(diào)用倉儲服務，完成相應的功能
訂單服務調(diào)用積分服務，完成相應的功能
3.2 服務注冊與發(fā)現(xiàn) - Netflix Eureka
首先考慮一個問題，訂單服務要調(diào)用庫存服務、倉儲服務、積分服務，如何調(diào)用呢？
訂單服務根本不知道上述服務在哪臺服務器上，所以沒法調(diào)用，而Eureka的作用就是來告訴訂單服務它想調(diào)用的服務在哪臺服務器上，Eureka有客戶端和服務端，每一個服務上面都有Eureka客戶端，可以把本服務的相關(guān)信息注冊到Eureka服務端上，那么我們的訂單服務就可以就可以找到庫存服務、倉儲服務、積分服務了
我們上述的業(yè)務使用Eureka后如下圖：
總結(jié)：
Eurake客戶端：負責將這個服務的信息注冊到Eureka服務端中
Eureka服務端：相當于一個注冊中心，里面有注冊表，注冊表中保存了各個服務所在的機器和端口號，可通過Eureka服務端找到各個服務
3.3 服務負載與調(diào)用 - Feign
通過上面的Eureka，現(xiàn)在訂單服務確實知道庫存服務、積分服務、倉儲服務在哪了，但是我們?nèi)绾稳フ{(diào)用這些服務呢，如果我們自己去寫很多代碼調(diào)用那就太麻煩了，而SpringCloud已經(jīng)為我們準備好了一個核心組件：Feign，接下來看如何通過Feign讓訂單服務調(diào)用庫存服務，注意Feign也是用在消費者端的。
訂單服務與倉庫服務Service
沒有底層的建立連接、構(gòu)造請求、解析響應的代碼，直接就是用注解定義一個 FeignClient接口，然后調(diào)用那個接口就可以了。人家Feign Client會在底層根據(jù)你的注解，跟你指定的服務建立連接、構(gòu)造請求、發(fā)起靕求、獲取響應、解析響應，等等。這一系列臟活累活，人家Feign全給你干了。
問題來了，F(xiàn)eign是如何做到的呢？其實Feign的一個機制就是使用了動態(tài)代理：
首先，如果你對某個接口定義了@FeignClient注解，F(xiàn)eign就會針對這個接口創(chuàng)建一個動態(tài)代理
接著你要是調(diào)用那個接口，本質(zhì)就是會調(diào)用 Feign創(chuàng)建的動態(tài)代理，這是核心中的核心
Feign的動態(tài)代理會根據(jù)你在接口上的@RequestMapping等注解，來動態(tài)構(gòu)造出你要請求的服務的地址
最后針對這個地址，發(fā)起請求、解析響應
3.4 服務負載與調(diào)用 - Netflix Ribbon
上面可以通過Eureka可以找到服務，然后通過Feign去調(diào)用服務，但是如果有多臺機器上面都部署了庫存服務，我應該使用Feign去調(diào)用哪一臺上面的服務呢，這個時候就需要Ribbon了，它在服務消費者端配置和使用，作用就是負載均衡，默認使用的負載均衡算法是輪詢算法，Ribbon會從Eureka服務端中獲取到對應的服務注冊表，然后就知道相應服務的位置，然后Ribbon根據(jù)設(shè)計的負載均衡算法去選擇一臺機器，F(xiàn)eigin就會針對這些機器構(gòu)造并發(fā)送請求。
3.5 服務熔斷降級 - Netflix Hystrix
在微服務架構(gòu)里一個系統(tǒng)會有多個服務，以本文的業(yè)務場景為例：訂單服務在一個業(yè)務流程里需要調(diào)用三個服務，現(xiàn)在假設(shè)訂單服務自己最多只有100個線程可以處理請求，如果積分服務出錯，每次訂單服務調(diào)用積分服務的時候，都會卡住幾秒鐘，然后拋出—個超時異常。
分析下這樣會導致什么問題呢？如果系統(tǒng)在高并發(fā)的情況下，大量請求涌過來的時候，訂單服務的100個線程會卡在積分服務這塊，導致訂單服務沒有一個多余的線程可以處理請求，這種問題就是微服務架構(gòu)中恐怖的服務器雪崩問題，這么多的服務互相調(diào)用要是不做任何保護的話，某一個服務掛掉會引起連鎖反應導致別的服務掛掉。
服務也不應該掛掉啊，我們只要讓存儲服務和倉儲服務正常工作就可以了，至于積分服務我們后期可以手動給用戶加上積分，這個時候就輪到Hystrix了，Hystrix是隔離、熔斷以及降級的一個框架，說白了就是Hystrix會搞很多小線程池然后讓這些小線程池去請求服務，返回結(jié)果，Hystrix相當于是個中間過濾區(qū)，如果我們的積分服務掛了，那我們請求積分服務直接就返回了，不需要等待超時時間結(jié)束拋出異常，這就是所謂的熔斷，但是也不能啥都不干就返回啊，不然我們之后手動加積分咋整啊，那我們每次調(diào)用積分服務就在數(shù)據(jù)庫里記錄一條消息，這就是所謂的降級，Hystrix隔離、熔斷和降級的全流程如下：
3.6 服務網(wǎng)關(guān) - Netflix Zuul
該組件是負責網(wǎng)絡(luò)路由的，假設(shè)你后臺部署了幾百個服務，現(xiàn)在有個前端兄弟，人家請求是直接從瀏覽器那兒發(fā)過來的。打個比方：人家要請求一下庫存服務，你難道還讓人家記著這服務的名字叫做inventory-service，并且部署在5臺機器上，就算人家肯記住這一個，那你后臺可有幾百個服務的名稱和地址呢？難不成人家請求一個，就得記住一個？
上面這種情況，壓根兒是不現(xiàn)實的。所以一般微服務架構(gòu)中都必然會設(shè)計一個網(wǎng)關(guān)在里面，像android、ios、pc前端、微信小程序、H5等等，不用去關(guān)心后端有幾百個服務，就知道有一個網(wǎng)關(guān)，所有請求都往網(wǎng)關(guān)走，網(wǎng)關(guān)會根據(jù)請求中的一些特征，將請求轉(zhuǎn)發(fā)給后端的各個服務。
3.7 總結(jié)
Eureka：服務啟動的時候，服務上的Eureka客戶端會把自身注冊到Eureka服務端，并且可以通過Eureka服務端知道其他注冊的服務。
Ribbon：服務間發(fā)起請求的時候，服務消費者方基于Ribbon服務做到負載均衡，從服務提供者存儲的多臺機器中選擇一臺，如果一個服務只在一臺機器上面，那就用不到Ribbon選擇機器了，如果有多臺機器，那就需要使用Ribbon選擇之后再去使用。
Feign：Feign使用的時候會集成Ribbon，Ribbon去Eureka服務端中找到服務提供者的所在的服務器信息，然后根據(jù)隨機策略選擇一個，拼接Url地址后發(fā)起請求。
Hystrix：發(fā)起的請求是通過Hystrix的線程池去訪問服務，不同的服務通過不同的線程池，實現(xiàn)了不同的服務調(diào)度隔離，如果服務出現(xiàn)故障，通過服務熔斷，避免服務雪崩的問題 ，并且通過服務降級，保證可以手動實現(xiàn)服務正常功能。
Zuul：如果前端調(diào)用后臺系統(tǒng)，統(tǒng)一走zull網(wǎng)關(guān)進入，通過zull網(wǎng)關(guān)轉(zhuǎn)發(fā)請求給對應的服務。
4. SpringCloud組件升級（工作使用）
source:?https://www.cnblogs.com/mpolaris/p/14300886.html
喜歡，在看
+轉(zhuǎn)發(fā)