0x01：分布式

• CAP

C：consistency 一致性 分布式系統(tǒng)能夠同時訪問同一份數(shù)據(jù)副本

A：availability 可用性 非故障節(jié)點能夠在合理時間內(nèi)獲得合理的結(jié)果

P：Partition Tolerance 分區(qū)容錯性 分布式系統(tǒng)當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)時，服務(wù)仍然可用

網(wǎng)絡(luò)分區(qū)：分布式網(wǎng)絡(luò)中，由于某些節(jié)點故障，導(dǎo)致系統(tǒng)分成了幾個區(qū)域。比如調(diào)用鏈A->B->C，其中B節(jié)點故障，那么A，B分成了兩個分區(qū)。

而是在P為條件下，只能實現(xiàn)A或者C。也就是說，在發(fā)生網(wǎng)絡(luò)分區(qū)后，我們只能保證一致性或者可用性。

當(dāng)沒有發(fā)生網(wǎng)絡(luò)分區(qū)時，也就是沒有P為條件，那么自然可以同時滿足A和C。

• zookeeper：保證CP，zookeeper有l(wèi)eader節(jié)點，寫操作只能由leader來做，F(xiàn)ollower只能處理讀操作，這樣就保證數(shù)據(jù)的一致性。

• Eureka：保證AP，Eureka各個服務(wù)器節(jié)點都是平等的，只要有至少一個節(jié)點，就能夠保證可用。

• Nacos：保證AP和CP，默認(rèn)支持AP，通過命令進行切換為CP。

0x02：BASE理論

基本可用（Basically Available）

當(dāng)系統(tǒng)發(fā)生不可預(yù)知的故障時，允許損失部分可用性。

• 響應(yīng)時間的損失：原先0.5s就能返回的結(jié)果，允許2s內(nèi)返回
  

• 系統(tǒng)功能的損失：可以損失非核心功能，而保證核心功能的可用

軟狀態(tài)（Soft State）

允許存在中間狀態(tài)，允許在多個節(jié)點的數(shù)據(jù)副本存在時延

最終一致性（Eventually Consistent）

在一個時間期限后，要保證數(shù)據(jù)的最終一致性

0x03：分布式ID

對于單個數(shù)據(jù)庫我們使用id自增就能保證，id不重復(fù)。

對于兩個數(shù)據(jù)庫，我們分別設(shè)置起始值和步長就能避免id重復(fù)，但是這時在添加一個數(shù)據(jù)庫，則要重新修改初始值和步長。

• 號段模式：我們可以先從數(shù)據(jù)庫中取出一段數(shù)據(jù)，比如id為100到200，當(dāng)需要使用時，在本地直接提取使用，使用完這100個id后，再從數(shù)據(jù)庫中取200到300的id。

• redis：通過redis，在redis中使用incr自增，也能夠保證id的不重復(fù)。
  

• 雪花算法：對分布式id的bit進行分配，比如64bit的一個id，從左到右，第一位符號位，接下來41bit為時間戳，接下來10bit為工作機器id，接下來12bit為序列號。這樣就能夠保證id的不重復(fù)。
  

0x04：限流算法

• 固定窗口計數(shù)機算法

規(guī)定一分鐘之內(nèi)只能有100個請求，如果多了則丟棄該請求。該方法無法防止突增的請求，比如前30秒只有1個請求，后30秒突然進來99個請求，無法保證限流的速率。

• 滑動窗口計數(shù)機算法

將一分鐘劃分成60個格子，大小為30的窗口不斷移動，每秒的請求放到格子中，如果窗口中的請求超過閾值，就不再處理其他請求。

• 漏桶算法

輸出的水流是一定的，這樣就能保證輸出速率穩(wěn)定。把請求比作水，當(dāng)請求來時，則將水輸入到水桶上方，即使上方的水是突然激增的，那輸出也仍然是穩(wěn)定的。如果木桶大小固定，上方水滿了，則水將溢出，也就是說請求丟棄。

缺點是，我們總是以固定的速率流出，我們希望當(dāng)請求少時，固定速率流出自然沒問題，但是當(dāng)請求到峰值，我們希望流出速率大一些。

• 令牌桶算法

仍然是一個固定大小的桶，我們以固定速率生產(chǎn)令牌，當(dāng)請求來時，對于大的請求，消耗多點的令牌，小請求就少點令牌。如果桶內(nèi)令牌沒有了，則丟棄請求。這個算法就能解決動態(tài)去做“流出速率”，峰值時流出速度快，平時呢流出速率平穩(wěn)。

0x05：RPC

做為遠(yuǎn)程調(diào)用框架，目的是希望調(diào)用遠(yuǎn)程方法就像本地方法一樣簡單。

• 客戶端：通過簡單注解或者使用類調(diào)用遠(yuǎn)程方法

• 客戶端代理類：通過動態(tài)代理，讓客戶端執(zhí)行的方法最終讓代理類來執(zhí)行。代理類拿到服務(wù)名/方法名，參數(shù)等信息封裝到request中，然后通過網(wǎng)絡(luò)調(diào)用發(fā)送給服務(wù)端

• 網(wǎng)絡(luò)調(diào)用：最簡單的可以用socket，當(dāng)然netty更流行，編寫Netty的客戶端與服務(wù)端

• 服務(wù)端：Netty中拿到request，知道了方法名，可以通過反射創(chuàng)建實現(xiàn)了該方法的類，然后調(diào)用之，得到結(jié)果后，再通過Netty服務(wù)端傳送給客戶端

• 注冊中心：我們可以用zk，創(chuàng)建節(jié)點，節(jié)點為服務(wù)名，節(jié)點下數(shù)據(jù)為機器ip地址。服務(wù)端啟動時，首先將自己能夠提供的服務(wù)注冊到zk上。客戶端根據(jù)服務(wù)名從zk中找到具體的ip地址，然后根據(jù)ip地址發(fā)送訪問。

0x06：網(wǎng)關(guān)

微服務(wù)下多個服務(wù)，對于權(quán)限管理，流量控制，日志，監(jiān)控等和業(yè)務(wù)無關(guān)的東西提取出來，統(tǒng)一管理，因此就有網(wǎng)關(guān)。

網(wǎng)關(guān)可以做：鑒權(quán)，限流，請求路由，日志，監(jiān)控。

0x07：微服務(wù)

• 服務(wù)注冊與發(fā)現(xiàn)：Eureka，nacos

微服務(wù)有很多消費者，提供者，我們不希望將他們之間的調(diào)用寫死，因為針對某個服務(wù)，可能有多個機器去運行他，那么我們希望有一個人能夠統(tǒng)一管理，那么注冊中心可以解決我們的問題。服務(wù)提供者將自己的服務(wù)注冊到注冊中心，消費者只需根據(jù)服務(wù)名從注冊中心拿到提供者地址。并且對于網(wǎng)關(guān)，負(fù)載均衡，熔斷降級，消息隊列等等組件，他們都希望自己能夠獲得注冊在注冊中心的某些信息，從而進行操作。

比如監(jiān)控功能，就需要拿到注冊中心的所有提供者消費者信息，來判斷他們的健康情況。

總之，注冊中心統(tǒng)一對服務(wù)的管理，當(dāng)我們需要使用或者查看這些服務(wù)狀態(tài)時，只需訪問注冊中心即可。

• 負(fù)載均衡：Ribbon

nacos自己集成了Ribbon，要使用負(fù)載均衡，首先我們要講restTemplate通過@Bean注解注冊到spring中，然后或者使用注解，或者通過代碼指定負(fù)載均衡策略即可，然后調(diào)用restTemplate.getForObject或者restTemplate.postForObject即可調(diào)用另一個服務(wù)的方法。

Openfeign：有人覺得直接寫restTemplate.postForObject，這樣不美觀，我就是想調(diào)用另一個服務(wù)就跟調(diào)用本地方法一樣，那么這個Openfeign就可以幫助我們。我們寫一個接口，接口中方法指明另一個服務(wù)的接口，然后我們在controller調(diào)用的時候，加個注解，直接調(diào)用接口的方法，看起來多像在本地調(diào)用方法啊！

• 熔斷和降級：Hystrix，sentinel

當(dāng)服務(wù)調(diào)用鏈路A->B->C，其中服務(wù)C發(fā)生故障，導(dǎo)致B有大量請求堆積，最終耗盡B的所有資源，B掛掉，然后A也堆積大量請求，A也掛掉，這就是服務(wù)雪崩。

為了防止服務(wù)雪崩，我們需要熔斷器，當(dāng)某個服務(wù)故障時，切斷調(diào)用鏈路，告知上一個服務(wù)，當(dāng)前服務(wù)已經(jīng)故障了。

服務(wù)降級，比如某服務(wù)訪問量過大，我們一次處理不了那么多請求，我們可以做服務(wù)降級。比如突然有1000訂單，我們一下子處理不了，那么我們可以讓一部分請求走降級，返回稍后重試的提示信息。

sentinel不僅僅有熔斷降級等功能，他還提供了多種其他功能，如限流，負(fù)載保護，實時監(jiān)控，調(diào)用鏈路等。