什么是微服務(wù)呢?
微服務(wù)架構(gòu)風(fēng)格就是一種把一個(gè)單一的應(yīng)用程序開發(fā)成為一組小型服務(wù)的方法，每個(gè)服務(wù)都運(yùn)行在自己的進(jìn)程當(dāng)中，服務(wù)之間通都是信采用的輕量級(jí)通信機(jī)制。這些服務(wù)圍繞著業(yè)務(wù)能力構(gòu)建并且可以通過全自動(dòng)部署機(jī)制去獨(dú)立部署。這些服務(wù)是共用一個(gè)最小型的集中式的管理的，服務(wù)可運(yùn)用不同的語言去開發(fā)，也可以使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)。所以微服務(wù)架構(gòu)應(yīng)該具備以下幾個(gè)特性：
每個(gè)微服務(wù)都可獨(dú)立運(yùn)行在自己的進(jìn)程里。
一系列獨(dú)立運(yùn)行的微服務(wù)共同地構(gòu)建起了整個(gè)系統(tǒng)。
每個(gè)服務(wù)都為獨(dú)立的業(yè)務(wù)開發(fā)，一個(gè)微服務(wù)可能只關(guān)注某個(gè)特定的功能，例如訂單管理，用戶管理等等。
微服務(wù)之間會(huì)通過一些輕量的通信機(jī)制去進(jìn)行通信，例如通過RESTful API進(jìn)行接口調(diào)用。
可以使用不同的語言與數(shù)據(jù)的存儲(chǔ)技術(shù)。
全自動(dòng)部署機(jī)制。
優(yōu)點(diǎn)：
第一個(gè)，易于開發(fā)和維護(hù)。一般來說一個(gè)微服務(wù)只會(huì)關(guān)注一個(gè)特定的業(yè)務(wù)功能，所以它業(yè)務(wù)清晰，代碼量會(huì)比較少。
第二個(gè)，單個(gè)微服務(wù)啟動(dòng)較快。因?yàn)閱蝹€(gè)微服務(wù)代碼量比較少，所以啟動(dòng)會(huì)比較快。
第三個(gè)，局部修改容易去部署。單體應(yīng)用一旦有修改，就得重新部署整個(gè)應(yīng)用，微服務(wù)就很好的解決了這樣的問題。
第四個(gè)，技術(shù)棧不受限。在微服務(wù)架構(gòu)里面，我們可以結(jié)合項(xiàng)目業(yè)務(wù)及團(tuán)隊(duì)的特點(diǎn)，合理地去選擇合適的技術(shù)棧。
第五個(gè)，按需伸縮?？梢愿鶕?jù)具體需求，去實(shí)現(xiàn)細(xì)粒度的擴(kuò)展。
缺點(diǎn)：
同樣的，微服務(wù)架構(gòu)所面臨的挑戰(zhàn)也是存在的，比如說，運(yùn)維要求高。如果有更多的服務(wù)就意味著更多的運(yùn)維投入。分布式本身固有的復(fù)雜性。由于使用微服務(wù)架構(gòu)是分布式系統(tǒng)，那么對(duì)于一個(gè)分布式系統(tǒng)來說，系統(tǒng)容錯(cuò)，網(wǎng)絡(luò)延遲，分布式事務(wù)等等，都會(huì)帶來嚴(yán)峻的挑戰(zhàn)。接口調(diào)整成本較高。微服務(wù)之間是通過接口進(jìn)行通信的。如果說修改某一個(gè)微服務(wù)的API，那么可能所有使用了該接口的微服務(wù)都需要做適用的調(diào)整。重復(fù)的勞動(dòng)。因?yàn)楹芏喾?wù)可能都會(huì)使用到相同的功能，然而這個(gè)功能并沒有達(dá)到分解為一個(gè)微服務(wù)的程度，這個(gè)時(shí)候，可能各個(gè)服務(wù)都會(huì)開發(fā)這一功能，從而就導(dǎo)致了代碼的重復(fù)。
SpringCloud架構(gòu)圖
SpringCloud特點(diǎn)
以下為 Spring Cloud 的核心特性：
分布式/版本化配置（Config）
服務(wù)注冊(cè)和發(fā)現(xiàn)（Eureka）
路由（Zuul/Gateway）
服務(wù)和服務(wù)之間的調(diào)用（Feign）
負(fù)載均衡（Ribbon）
斷路器（Hystrix）
分布式消息傳遞（Bus）
1.Eureka
1）、Eureka服務(wù)端：也稱服務(wù)注冊(cè)中心，同其他服務(wù)注冊(cè)中心一樣，支持高可用配置。如果Eureka以集群模式部署，當(dāng)集群中有分片出現(xiàn)故障時(shí)，那么Eureka就轉(zhuǎn)入自我保護(hù)模式。它允許在分片故障期間繼續(xù)提供服務(wù)的發(fā)現(xiàn)和注冊(cè)，當(dāng)故障分片恢復(fù)運(yùn)行時(shí)，集群中其他分片會(huì)把它們的狀態(tài)再次同步回來
2）、Eureka Server的高可用實(shí)際上就是將自己作為服務(wù)向其他注冊(cè)中心注冊(cè)自己，這樣就可以形成一組互相注冊(cè)的服務(wù)注冊(cè)中心，以實(shí)現(xiàn)服務(wù)清單的互相同步，達(dá)到高可用效果
2.Ribbon
Ribbon是一個(gè)基于HTTP和TCP的客戶端負(fù)載均衡器，它可以在通過客戶端中配置的ribbonServerList服務(wù)端列表去輪詢?cè)L問以達(dá)到服務(wù)均衡的作用。當(dāng)Ribbon和Eureka聯(lián)合使用時(shí)，Ribbon的服務(wù)實(shí)例清單RibbonServerList會(huì)被DiscoveryEnabledNIWSServerList重寫，擴(kuò)展成從Eureka注冊(cè)中心中獲取服務(wù)端列表。同時(shí)它也會(huì)用NIWSDiscoveryPing來取代IPing，它將職責(zé)委托給Eureka來去定服務(wù)端是否已經(jīng)啟動(dòng)
在客戶端負(fù)載均衡中，所有客戶端節(jié)點(diǎn)都維護(hù)著自己要訪問的服務(wù)端清單，而這些服務(wù)端的清單來自于服務(wù)注冊(cè)中心（比如Eureka）。在客戶端負(fù)載均衡中也需要心跳去維護(hù)服務(wù)端清單的健康性，只是這個(gè)步驟需要與服務(wù)注冊(cè)中心配合完成
3.Fegin
Fegin的關(guān)鍵機(jī)制是使用了動(dòng)態(tài)代理，F(xiàn)egin是和Ribbon以及Eureka緊密協(xié)作的
1）、首先Ribbon會(huì)從Eureka Client里獲取到對(duì)應(yīng)的服務(wù)注冊(cè)表，也就知道了所有的服務(wù)都部署在了哪些機(jī)器上，在監(jiān)聽哪些端口
2）、然后Ribbon就可以使用默認(rèn)的Round Robin算法，從中選擇一臺(tái)機(jī)器
3）、Fegin就會(huì)針對(duì)這臺(tái)機(jī)器，構(gòu)造并發(fā)起請(qǐng)求
4.Hystrix
在微服務(wù)架構(gòu)中，存在著那么多的服務(wù)單元，若一個(gè)單元出現(xiàn)故障，就很容易因依賴關(guān)系而引發(fā)故障的蔓延，最終導(dǎo)致整個(gè)系統(tǒng)的癱瘓，這樣的架構(gòu)相較傳統(tǒng)架構(gòu)更加不穩(wěn)定。為了解決這樣的問題，產(chǎn)生了斷路器等一系列的服務(wù)保護(hù)機(jī)制
在分布式架構(gòu)中，當(dāng)某個(gè)服務(wù)單元發(fā)生故障之后，通過斷路器的故障監(jiān)控，向調(diào)用方返回一個(gè)錯(cuò)誤響應(yīng)，而不是長時(shí)間的等待。這樣就不會(huì)使得線程因調(diào)用故障服務(wù)被長時(shí)間占用不釋放，避免了故障在分布式系統(tǒng)中的蔓延
Hystrix具備服務(wù)降級(jí)、服務(wù)熔斷、線程和信號(hào)隔離、請(qǐng)求緩存、請(qǐng)求合并以及服務(wù)監(jiān)控等強(qiáng)大功能
5.Zuul
Spring Cloud Zuul通過與Spring Cloud Eureka進(jìn)行整合，將自身注冊(cè)為Eureka服務(wù)治理下的應(yīng)用，同時(shí)從Eureka中獲得了所有其他微服務(wù)的實(shí)例信息
對(duì)于路由規(guī)則的維護(hù)，Zuul默認(rèn)會(huì)將通過以服務(wù)名作為ContextPath的方式來創(chuàng)建路由映射
Zuul提供了一套過濾器機(jī)制，可以支持在API網(wǎng)關(guān)無附上進(jìn)行統(tǒng)一調(diào)用來對(duì)微服務(wù)接口做前置過濾，已實(shí)現(xiàn)對(duì)微服務(wù)接口的攔截和校驗(yàn)
小結(jié)
Eureka：各個(gè)服務(wù)啟動(dòng)時(shí)，Eureka Client都會(huì)將服務(wù)注冊(cè)到Eureka Server，并且Eureka Client還可以反過來從Eureka Server拉取注冊(cè)表，從而知道其他服務(wù)在哪里
Ribbon：服務(wù)間發(fā)起請(qǐng)求的時(shí)候，基于Ribbon做負(fù)載均衡，從一個(gè)服務(wù)的多臺(tái)機(jī)器中選擇一臺(tái)
Feign：基于Feign的動(dòng)態(tài)代理機(jī)制，根據(jù)注解和選擇的機(jī)器，拼接請(qǐng)求URL地址，發(fā)起請(qǐng)求
Hystrix：發(fā)起請(qǐng)求是通過Hystrix的線程池來走的，不同的服務(wù)走不同的線程池，實(shí)現(xiàn)了不同服務(wù)調(diào)用的隔離，避免了服務(wù)雪崩的問題
Zuul：如果前端、移動(dòng)端要調(diào)用后端系統(tǒng)，統(tǒng)一從Zuul網(wǎng)關(guān)進(jìn)入，由Zuul網(wǎng)關(guān)轉(zhuǎn)發(fā)請(qǐng)求給對(duì)應(yīng)的服務(wù)
