參考鏈接：

• Dubbo 常見問題總結(jié) javaguide
• 微服務(wù)/分布式 知識(shí)星球 javaguide
• SpringCloud面試題
• Spring Cloud面試題萬字解析

CAP 定理

參考鏈接：http://www.ruanyifeng.com/blog/2018/07/cap.html

image.png

1998年，加州大學(xué)的計(jì)算機(jī)科學(xué)家 Eric Brewer 提出，分布式系統(tǒng)有三個(gè)指標(biāo)。Eric Brewer 說，這三個(gè)指標(biāo)不可能同時(shí)做到。這個(gè)結(jié)論就叫做 CAP 定理。

1. Partition tolerance 分區(qū)容錯(cuò)

大多數(shù)分布式系統(tǒng)都分布在多個(gè)子網(wǎng)絡(luò)。每個(gè)子網(wǎng)絡(luò)就叫做一個(gè)區(qū)（partition）。分區(qū)容錯(cuò)的意思是，區(qū)間通信可能失敗。比如，一臺(tái)服務(wù)器放在中國(guó)，另一臺(tái)服務(wù)器放在美國(guó)，這就是兩個(gè)區(qū)，它們之間可能無法通信。
一般來說，分區(qū)容錯(cuò)無法避免，因此可以認(rèn)為 CAP 的 P 總是成立。CAP 定理告訴我們，剩下的 C 和 A 無法同時(shí)做到。

2. Consistency 一致性

不同系統(tǒng)的數(shù)據(jù)保持一致。

3. Availability 可用性

只要收到用戶的請(qǐng)求，服務(wù)器就必須給出回應(yīng)。

一致性和可用性：不可能同時(shí)成立

一致性和可用性，為什么不可能同時(shí)成立？答案很簡(jiǎn)單，因?yàn)榭赡芡ㄐ攀。闯霈F(xiàn)分區(qū)容錯(cuò)）。

為什么要網(wǎng)關(guān)？

微服務(wù)下一個(gè)系統(tǒng)被拆分為多個(gè)服務(wù)，但是像 安全認(rèn)證，流量控制，日志，監(jiān)控等功能是每個(gè)服務(wù)都需要的，沒有網(wǎng)關(guān)的話，我們就需要在每個(gè)服務(wù)中單獨(dú)實(shí)現(xiàn)，這使得我們做了很多重復(fù)的事情并且沒有一個(gè)全局的視圖來統(tǒng)一管理這些功能。

綜上：一般情況下，網(wǎng)關(guān)一般都會(huì)提供請(qǐng)求轉(zhuǎn)發(fā)、安全認(rèn)證（身份/權(quán)限認(rèn)證）、流量控制、負(fù)載均衡、容災(zāi)、日志、監(jiān)控這些功能。

上面介紹了這么多功能實(shí)際上網(wǎng)關(guān)主要做了一件事情：請(qǐng)求過濾 。權(quán)限校驗(yàn)、流量控制這些都可以通過過濾器實(shí)現(xiàn)，請(qǐng)求轉(zhuǎn)發(fā)也是通過過濾器實(shí)現(xiàn)的。

你知道有哪些常見的網(wǎng)關(guān)系統(tǒng)？

我所了解的目前經(jīng)常用到的開源 API 網(wǎng)關(guān)系統(tǒng)有：
Kong
Netflix zuul

限流的算法有哪些？

簡(jiǎn)單介紹 4 種非常好理解并且容易實(shí)現(xiàn)的限流算法！

1. 固定窗口計(jì)數(shù)器算法
2. 滑動(dòng)窗口計(jì)數(shù)器算法
3. 漏桶算法
4. 令牌桶算法

下圖的圖片不是 Guide 哥自己畫的哦！圖片來源于 InfoQ 的一篇文章《分布式服務(wù)限流實(shí)戰(zhàn)，已經(jīng)為你排好坑了》。

固定窗口計(jì)數(shù)器算法

規(guī)定我們單位時(shí)間處理的請(qǐng)求數(shù)量。比如我們規(guī)定我們的一個(gè)接口一分鐘只能訪問10次的話。使用固定窗口計(jì)數(shù)器算法的話可以這樣實(shí)現(xiàn)：給定一個(gè)變量counter來記錄處理的請(qǐng)求數(shù)量，當(dāng)1分鐘之內(nèi)處理一個(gè)請(qǐng)求之后counter+1，1分鐘之內(nèi)的如果counter=100的話，后續(xù)的請(qǐng)求就會(huì)被全部拒絕。等到 1分鐘結(jié)束后，將counter回歸成0，重新開始計(jì)數(shù)（ps：只要過了一個(gè)周期就講counter回歸成0）。

這種限流算法無法保證限流速率，因而無法保證突然激增的流量。比如我們限制一個(gè)接口一分鐘只能訪問10次的話，前半分鐘一個(gè)請(qǐng)求沒有接收，后半分鐘接收了10個(gè)請(qǐng)求。

固定窗口計(jì)數(shù)器算法

滑動(dòng)窗口計(jì)數(shù)器算法

算的上是固定窗口計(jì)數(shù)器算法的升級(jí)版?；瑒?dòng)窗口計(jì)數(shù)器算法相比于固定窗口計(jì)數(shù)器算法的優(yōu)化在于：它把時(shí)間以一定比例分片。例如我們的借口限流每分鐘處理60個(gè)請(qǐng)求，我們可以把 1 分鐘分為60個(gè)窗口。每隔1秒移動(dòng)一次，每個(gè)窗口一秒只能處理 不大于 60(請(qǐng)求數(shù))/60（窗口數(shù)） 的請(qǐng)求， 如果當(dāng)前窗口的請(qǐng)求計(jì)數(shù)總和超過了限制的數(shù)量的話就不再處理其他請(qǐng)求。

很顯然：當(dāng)滑動(dòng)窗口的格子劃分的越多，滑動(dòng)窗口的滾動(dòng)就越平滑，限流的統(tǒng)計(jì)就會(huì)越精確。

滑動(dòng)窗口計(jì)數(shù)器算法

漏桶算法

我們可以把發(fā)請(qǐng)求的動(dòng)作比作成注水到桶中，我們處理請(qǐng)求的過程可以比喻為漏桶漏水。我們往桶中以任意速率流入水，以一定速率流出水。當(dāng)水超過桶流量則丟棄，因?yàn)橥叭萘渴遣蛔兊?，保證了整體的速率。如果想要實(shí)現(xiàn)這個(gè)算法的話也很簡(jiǎn)單，準(zhǔn)備一個(gè)隊(duì)列用來保存請(qǐng)求，然后我們定期從隊(duì)列中拿請(qǐng)求來執(zhí)行就好了。

漏桶算法

令牌桶算法

令牌桶算法也比較簡(jiǎn)單。和漏桶算法算法一樣，我們的主角還是桶（這限流算法和桶過不去?。?。不過現(xiàn)在桶里裝的是令牌了，請(qǐng)求在被處理之前需要拿到一個(gè)令牌，請(qǐng)求處理完畢之后將這個(gè)令牌丟棄（刪除）。我們根據(jù)限流大小，按照一定的速率往桶里添加令牌。

令牌桶算法

為什么要分布式 id ？

這部分內(nèi)容來自：分布式id生成方案總結(jié)

ID是數(shù)據(jù)的唯一標(biāo)識(shí)，傳統(tǒng)的做法是利用UUID和數(shù)據(jù)庫的自增ID，在互聯(lián)網(wǎng)企業(yè)中，大部分公司使用的都是Mysql，并且因?yàn)樾枰聞?wù)支持，所以通常會(huì)使用Innodb存儲(chǔ)引擎，UUID太長(zhǎng)以及無序，所以并不適合在Innodb中來作為主鍵，自增ID比較合適，但是隨著公司的業(yè)務(wù)發(fā)展，數(shù)據(jù)量將越來越大，需要對(duì)數(shù)據(jù)進(jìn)行分表，而分表后，每個(gè)表中的數(shù)據(jù)都會(huì)按自己的節(jié)奏進(jìn)行自增，很有可能出現(xiàn)ID沖突。這時(shí)就需要一個(gè)單獨(dú)的機(jī)制來負(fù)責(zé)生成唯一ID，生成出來的ID也可以叫做分布式ID，或全局ID。

分布式ID都有哪些生成方式？

1. UUID
   優(yōu)點(diǎn)：簡(jiǎn)單
   缺點(diǎn)：字符串太長(zhǎng)，沒有規(guī)律，無序

2. 單獨(dú)的MySQL實(shí)例用來生成自增ID
   優(yōu)點(diǎn)：簡(jiǎn)單
   缺點(diǎn)：?jiǎn)喂?jié)點(diǎn)可能宕機(jī)

3. 數(shù)據(jù)庫集群模式
   每個(gè)數(shù)據(jù)庫實(shí)例設(shè)置不同的起始值和自增步長(zhǎng)
   優(yōu)點(diǎn)：解決DB單點(diǎn)問題
   缺點(diǎn)：不利于后續(xù)擴(kuò)容

4. 號(hào)段模式
   號(hào)段模式是當(dāng)下分布式ID生成器的主流實(shí)現(xiàn)方式之一，號(hào)段模式可以理解為從數(shù)據(jù)庫批量的獲取自增ID，每次從數(shù)據(jù)庫取出一個(gè)號(hào)段范圍，例如 (1,1000] 代表1000個(gè)ID，具體的業(yè)務(wù)服務(wù)將本號(hào)段，生成1~1000的自增ID并加載到內(nèi)存。
   等這批號(hào)段ID用完，再次向數(shù)據(jù)庫申請(qǐng)新號(hào)段，對(duì)max_id字段做一次update操作，update max_id= max_id + step，update成功則說明新號(hào)段獲取成功，新的號(hào)段范圍是(max_id ,max_id +step]。

CREATE TABLE id_generator (
  id int(10) NOT NULL,
  max_id bigint(20) NOT NULL COMMENT '當(dāng)前最大id',
  step int(20) NOT NULL COMMENT '號(hào)段的布長(zhǎng)',
  biz_type  int(20) NOT NULL COMMENT '業(yè)務(wù)類型',
  version int(20) NOT NULL COMMENT '版本號(hào)',
  PRIMARY KEY (`id`)
) 

5. Redis
   利用redis String的 incr命令實(shí)現(xiàn)ID的原子性自增。

6. 雪花算法（SnowFlake）
   twitter公司內(nèi)部分布式項(xiàng)目采用的ID生成算法。

7. 滴滴出品（TinyID）

8. 百度 （Uidgenerator）

9. 美團(tuán)（Leaf）

參考鏈接：一口氣說出9種分布式ID生成方式，面試官有點(diǎn)懵了

了解RPC嗎？

RPC（Remote Procedure Call）—遠(yuǎn)程過程調(diào)用，它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請(qǐng)求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。比如兩個(gè)不同的服務(wù) A、B 部署在兩臺(tái)不同的機(jī)器上，那么服務(wù) A 如果想要調(diào)用服務(wù) B 中的某個(gè)方法該怎么辦呢？使用 HTTP請(qǐng)求 當(dāng)然可以，但是可能會(huì)比較慢而且一些優(yōu)化做的并不好。 RPC 的出現(xiàn)就是為了解決這個(gè)問題。

RPC原理是什么？

我這里這是簡(jiǎn)單的提一下。詳細(xì)內(nèi)容可以查看下面這篇文章：

http://www.importnew.com/22003.html

為了能夠幫助小伙伴們理解 RPC 原理，我們可以將整個(gè) RPC的 核心功能看作是下面 5個(gè)部分實(shí)現(xiàn)的：

• 客戶端（服務(wù)消費(fèi)端） ：調(diào)用遠(yuǎn)程方法的一端。
• 客戶端 Stub（樁） ： 這其實(shí)就是一代理類。代理類主要做的事情很簡(jiǎn)單，就是把你調(diào)用方法、類、方法參數(shù)等信息傳遞到服務(wù)端。
• 網(wǎng)絡(luò)傳輸 ： 網(wǎng)絡(luò)傳輸就是你要把你調(diào)用的方法的信息比如說參數(shù)啊這些東西傳輸?shù)椒?wù)端，然后服務(wù)端執(zhí)行完之后再把返回結(jié)果通過網(wǎng)絡(luò)傳輸給你傳輸回來。網(wǎng)絡(luò)傳輸?shù)膶?shí)現(xiàn)方式有很多種比如最近基本的 Socket或者性能以及封裝更加優(yōu)秀的 Netty（推薦）。
• 服務(wù)端 Stub（樁） ：這個(gè)樁就不是代理類了。我覺得理解為樁實(shí)際不太好，大家注意一下就好。這里的服務(wù)端 Stub 實(shí)際指的就是接收到客戶端執(zhí)行方法的請(qǐng)求后，去指定對(duì)應(yīng)的方法然后返回結(jié)果給客戶端的類。
• 服務(wù)端（服務(wù)提供端） ：提供遠(yuǎn)程方法的一端。

RPC原理圖

1. 服務(wù)消費(fèi)方（client）調(diào)用以本地調(diào)用方式調(diào)用服務(wù)；
2. client stub接收到調(diào)用后負(fù)責(zé)將方法、參數(shù)等組裝成能夠進(jìn)行網(wǎng)絡(luò)傳輸?shù)南Ⅲw；
3. client stub找到服務(wù)地址，并將消息發(fā)送到服務(wù)端；
4. server stub收到消息后進(jìn)行解碼；
5. server stub根據(jù)解碼結(jié)果調(diào)用本地的服務(wù)；
6. 本地服務(wù)執(zhí)行并將結(jié)果返回給server stub；
7. server stub將返回結(jié)果打包成消息并發(fā)送至消費(fèi)方；
8. client stub接收到消息，并進(jìn)行解碼；
9. 服務(wù)消費(fèi)方得到最終結(jié)果。

下面再貼一個(gè)網(wǎng)上的時(shí)序圖：

RPC原理時(shí)序圖

有哪些常見的 RPC 框架？

• RMI（JDK自帶）： JDK自帶的RPC。詳細(xì)內(nèi)容可以參考：從懵逼到恍然大悟之Java中RMI的使用
• Dubbo: Dubbo是 阿里巴巴公司開源的一個(gè)高性能優(yōu)秀的服務(wù)框架，使得應(yīng)用可通過高性能的 RPC 實(shí)現(xiàn)服務(wù)的輸出和輸入功能，可以和 Spring框架無縫集成。詳細(xì)內(nèi)容可以參考：高性能優(yōu)秀的服務(wù)框架-dubbo介紹
• gRPC： Google 公布的開源軟件，基 HTTP 2.0 協(xié)議，并支持常見的眾多編程語言。
• Thrift： Apache Thrift是Facebook開源的跨語言的RPC通信框架，目前已經(jīng)捐獻(xiàn)給Apache基金會(huì)管理，由于其跨語言特性和出色的性能，在很多互聯(lián)網(wǎng)公司得到應(yīng)用，有能力的公司甚至?xí)趖hrift研發(fā)一套分布式服務(wù)框架，增加諸如服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)等功能。詳細(xì)內(nèi)容可以參考： 【Java】分布式RPC通信框架Apache Thrift 使用總結(jié)
• Hessian： Hessian是一個(gè)輕量級(jí)的remotingonhttp工具，使用簡(jiǎn)單的方法提供了RMI的功能。 相比WebService，Hessian更簡(jiǎn)單、快捷。采用的是二進(jìn)制RPC協(xié)議，因?yàn)椴捎玫氖嵌M(jìn)制協(xié)議，所以它很適合于發(fā)送二進(jìn)制數(shù)據(jù)。詳細(xì)內(nèi)容可以參考： Hessian的使用以及理解

如果讓你自己設(shè)計(jì) RPC 框架你會(huì)如何設(shè)計(jì)？

一個(gè)典型的使用 RPC 的場(chǎng)景如下，一般情況下 RPC 框架不僅要提供服務(wù)發(fā)現(xiàn)功能，還要提供負(fù)載均衡、容錯(cuò)等功能，這個(gè)的 RPC 框架才算真正合格。

一個(gè)完整的RPC框架使用示意圖

簡(jiǎn)單說一下思路：

1. 注冊(cè)中心首先是要有的，推薦使用 Zookeeper。注冊(cè)中心主要用來保存相關(guān)的信息比如遠(yuǎn)程方法的地址。
2. 既然要要互相調(diào)用方法就要發(fā)請(qǐng)求，推薦nio 的 netty框架。
3. 發(fā)請(qǐng)求發(fā)送什么數(shù)據(jù)呢？我們就要考慮序列化協(xié)議了。
4. 另外，動(dòng)態(tài)代理也是需要的。因?yàn)?RPC 的主要目的就是讓我們調(diào)用遠(yuǎn)程方法像調(diào)用本地方法一樣簡(jiǎn)單，使用動(dòng)態(tài)代理屏蔽遠(yuǎn)程接口調(diào)用的細(xì)節(jié)比如網(wǎng)絡(luò)傳輸。推薦一篇我覺得非常不錯(cuò)的動(dòng)態(tài)代理的文章：《10分鐘看懂動(dòng)態(tài)代理設(shè)計(jì)模式》
5. 負(fù)載均衡也是需要的。為啥？舉個(gè)例子我們的系統(tǒng)中的某個(gè)服務(wù)的訪問量特別大，我們將這個(gè)服務(wù)部署在了多臺(tái)服務(wù)器上，當(dāng)客戶端發(fā)起請(qǐng)求的時(shí)候，多臺(tái)服務(wù)器都可以處理這個(gè)請(qǐng)求。那么，如何正確選擇處理該請(qǐng)求的服務(wù)器就很關(guān)鍵。假如，你就要一臺(tái)服務(wù)器來處理該服務(wù)的請(qǐng)求，那該服務(wù)部署在多臺(tái)服務(wù)器的意義就不復(fù)存在了。負(fù)載均衡就是為了避免單個(gè)服務(wù)器響應(yīng)同一請(qǐng)求，容易造成服務(wù)器宕機(jī)、崩潰等問題，我們從負(fù)載均衡的這四個(gè)字就能明顯感受到它的意義。。

了解Dubbo嗎 ？

Apache Dubbo (incubating) |?d?b??| 是一款高性能、輕量級(jí)的開源Java RPC 框架，它提供了三大核心能力：面向接口的遠(yuǎn)程方法調(diào)用，智能容錯(cuò)和負(fù)載均衡，以及服務(wù)自動(dòng)注冊(cè)和發(fā)現(xiàn)。簡(jiǎn)單來說 Dubbo 是一個(gè)分布式服務(wù)框架，致力于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案，以及SOA服務(wù)治理方案。

Dubbo 目前已經(jīng)有接近 31.2k 的 Star ，Dubbo的Github 地址：https://github.com/apache/incubator-dubbo 。

Dubbo 是由阿里開源，后來加入了 Apache 。正式由于 Dubbo 的出現(xiàn)，才使得國(guó)內(nèi)越來越多的公司開始使用以及接受分布式架構(gòu)。

Dubbo 提供了哪些負(fù)載均衡策略？

在集群負(fù)載均衡時(shí)，Dubbo 提供了多種均衡策略，默認(rèn)為 random 隨機(jī)調(diào)用?？梢宰孕袛U(kuò)展負(fù)載均衡策略，參見：負(fù)載均衡擴(kuò)展。

1. Random LoadBalance(默認(rèn)，基于權(quán)重的隨機(jī)負(fù)載均衡機(jī)制)

• 隨機(jī)，按權(quán)重設(shè)置隨機(jī)概率。
• 在一個(gè)截面上碰撞的概率高，但調(diào)用量越大分布越均勻，而且按概率使用權(quán)重后也比較均勻，有利于動(dòng)態(tài)調(diào)整提供者權(quán)重。

基于權(quán)重的隨機(jī)負(fù)載均衡機(jī)制

2. RoundRobin LoadBalance(不推薦，基于權(quán)重的輪詢負(fù)載均衡機(jī)制)

• 輪循，按公約后的權(quán)重設(shè)置輪循比率。
• 存在慢的提供者累積請(qǐng)求的問題，比如：第二臺(tái)機(jī)器很慢，但沒掛，當(dāng)請(qǐng)求調(diào)到第二臺(tái)時(shí)就卡在那，久而久之，所有請(qǐng)求都卡在調(diào)到第二臺(tái)上。

基于權(quán)重的輪詢負(fù)載均衡機(jī)制

3. LeastActive LoadBalance(最少活躍調(diào)用負(fù)載均衡機(jī)制)

• 最少活躍調(diào)用數(shù)，相同活躍數(shù)的隨機(jī)，活躍數(shù)指調(diào)用前后計(jì)數(shù)差。
• 使慢的提供者收到更少請(qǐng)求，因?yàn)樵铰奶峁┱叩恼{(diào)用前后計(jì)數(shù)差會(huì)越大。

4. ConsistentHash LoadBalance(一致性 Hash負(fù)載均衡機(jī)制)

• 一致性 Hash，相同參數(shù)的請(qǐng)求總是發(fā)到同一提供者。(如果你需要的不是隨機(jī)負(fù)載均衡，是要一類請(qǐng)求都到一個(gè)節(jié)點(diǎn)，那就走這個(gè)一致性hash策略。)
• 當(dāng)某一臺(tái)提供者掛時(shí)，原本發(fā)往該提供者的請(qǐng)求，基于虛擬節(jié)點(diǎn)，平攤到其它提供者，不會(huì)引起劇烈變動(dòng)。

談?wù)勀銓?duì)微服務(wù)領(lǐng)域的了解和認(rèn)識(shí)

現(xiàn)在大公司都在用并且未來的趨勢(shì)都是 Spring Cloud，而阿里開源的 Spring Cloud Alibaba 也是 Spring Cloud 規(guī)范的實(shí)現(xiàn) 。

我們通常把 Spring Cloud 理解為一系列開源組件的集合，但是 Spring Cloud并不是等同于 Spring Cloud Netflix 的 Ribbon（負(fù)載均衡）、Feign（遠(yuǎn)程調(diào)用）、Eureka（服務(wù)注冊(cè)與發(fā)現(xiàn)，已經(jīng)停止更新）、Hystrix（熔斷）、Zuul （網(wǎng)關(guān)）； 這一套組件，而是抽象了一套通用的開發(fā)模式。它的目的是通過抽象出這套通用的模式，讓開發(fā)者更快更好地開發(fā)業(yè)務(wù)。但是這套開發(fā)模式運(yùn)行時(shí)的實(shí)際載體，還是依賴于 RPC、網(wǎng)關(guān)、服務(wù)發(fā)現(xiàn)、配置管理、限流熔斷、分布式鏈路跟蹤等組件的具體實(shí)現(xiàn)。

更多關(guān)于 Spring Cloud Netflix 的內(nèi)容參見： 大白話入門 Spring Cloud

Spring Cloud Alibaba 是官方認(rèn)證的新一套 Spring Cloud 規(guī)范的實(shí)現(xiàn),Spring Cloud Alibaba 是一套國(guó)產(chǎn)開源產(chǎn)品集合，后這對(duì)于國(guó)內(nèi)的開發(fā)者是非常棒的一件事。阿里的這一舉動(dòng)勢(shì)必會(huì)推動(dòng)國(guó)內(nèi)微服務(wù)技術(shù)的發(fā)展，因?yàn)樵跊]有 Spring Cloud Alibaba 之前，我們的第一選擇是 Spring Cloud Netflix，但是它們的文檔都是英文的，出問題后排查也比較困難， 在國(guó)內(nèi)并不是有特別多的人精通。Spring Cloud Alibaba 由阿里開源組件和阿里云產(chǎn)品組件兩部分組成，其致力于提供微服務(wù)一站式解決方案，方便開發(fā)者通過 Spring Cloud 編程模型輕松開發(fā)微服務(wù)應(yīng)用。

Spring Cloud Alibaba也是很值得學(xué)習(xí)的，其組成包括：

1. Sentinel：輕量級(jí)的流量控制、熔斷降級(jí) Java 庫
2. 2.dubbo：Apache Dubbo 是一個(gè)基于 Java 的高性能開源 RPC 框架。
3. nacos：Nacos 致力于幫助您發(fā)現(xiàn)、配置和管理微服務(wù)。
4. seata：Seata 是一種易于使用，高性能，基于 Java 的開源分布式事務(wù)解決方案。
5. RocketMQ:阿里巴巴開源的一款高性能、高吞吐量的分布式消息中間件。

Spring Cloud 和dubbo區(qū)別?

1. 服務(wù)調(diào)用方式：dubbo是RPC；springcloud是Rest Api

2. 注冊(cè)中心：dubbo 是zookeeper；springcloud是eureka，也可以是zookeeper

3. 服務(wù)網(wǎng)關(guān)：dubbo本身沒有實(shí)現(xiàn)，只能通過其他第三方技術(shù)整合；springcloud有Zuul路由網(wǎng)關(guān)，作為路由服務(wù)器，進(jìn)行消費(fèi)者的請(qǐng)求分發(fā),springcloud支持?jǐn)嗦菲?，與git完美集成配置文件支持版本控制，事物總線實(shí)現(xiàn)配置文件的更新與服務(wù)自動(dòng)裝配等等一系列的微服務(wù)架構(gòu)要素。

Spring Cloud 組成

1. 注冊(cè)中心：Eureka
2. 網(wǎng)關(guān)：Zuul， Spring Cloud Gateway
3. 負(fù)載均衡：Ribbon
   Nginx是反向代理同時(shí)可以實(shí)現(xiàn)負(fù)載均衡，nginx攔截客戶端請(qǐng)求采用負(fù)載均衡策略根據(jù)upstream配置進(jìn)行轉(zhuǎn)發(fā)，相當(dāng)于請(qǐng)求通過nginx服務(wù)器進(jìn)行轉(zhuǎn)發(fā)。Ribbon是客戶端負(fù)載均衡，從注冊(cè)中心讀取目標(biāo)服務(wù)器信息，然后客戶端采用輪詢策略對(duì)服務(wù)直接訪問，全程在客戶端操作。
4. 斷路器：Hystrix
5. Feign
   SpringCloud調(diào)用接口方式：Feign，RestTemplate
6. Spring Cloud Bus
7. 分布式配置中心：Spring Cloud Config