分佈式與微服務

分佈式#

CAP#

C:consistency 一致性 分佈式系統能夠同時訪問同一份數據副本

A:availability 可用性 非故障節點能夠在合理時間內獲得合理的結果

P:Partition Tolerance 分區容錯性 分佈式系統當發生網絡分區時,服務仍然可用

網絡分區:分佈式網絡中,由於某些節點故障,導致系統分成了幾個區域。比如調用鏈 A->B->C,其中 B 節點故障,那麼 A,B 分成了兩個分區。

而是在 P 爲條件下,只能實現 A 或者 C。也就是說,在發生網絡分區後,我們只能保證一致性或者可用性。

當沒有發生網絡分區時,也就是沒有 P 爲條件,那麼自然可以同時滿足 A 和 C。

zookeeper:保證 CP,zookeeper 有 leader 節點,寫操作只能由 leader 來做,Follower 只能處理讀操作,這樣就保證數據的一致性。

Eureka:保證 AP,Eureka 各個服務器節點都是平等的,只要有至少一個節點,就能夠保證可用。

Nacos:保證 AP 和 CP,默認支持 AP,通過命令進行切換爲 CP。

BASE 理論#

分佈式 ID#

對於單個數據庫我們使用 id 自增就能保證,id 不重複。

對於兩個數據庫,我們分別設置起始值和步長就能避免 id 重複,但是這時在添加一個數據庫,則要重新修改初始值和步長。

號段模式:我們可以先從數據庫中取出一段數據,比如 id 爲 100 到 200,當需要使用時,在本地直接提取使用,使用完這 100 個 id 後,再從數據庫中取 200 到 300 的 id。

redis:通過 redis,在 redis 中使用 incr 自增,也能夠保證 id 的不重複。

雪花算法:對分佈式 id 的 bit 進行分配,比如 64bit 的一個 id,從左到右,第一位符號位,接下來 41bit 爲時間戳,接下來 10bit 爲工作機器 id,接下來 12bit 爲序列號。這樣就能夠保證 id 的不重複。

限流算法#

固定窗口計數機算法#

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

滑動窗口計數機算法#

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

漏桶算法#

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

缺點是,我們總是以固定的速率流出,我們希望當請求少時,固定速率流出自然沒問題,但是當請求到峯值,我們希望流出速率大一些。

令牌桶算法#

仍然是一個固定大小的桶,我們以固定速率生產令牌,當請求來時,對於大的請求,消耗多點的令牌,小請求就少點令牌。如果桶內令牌沒有了,則丟棄請求。這個算法就能解決動態去做 “流出速率”,峯值時流出速度快,平時呢流出速率平穩。

RPC#

做爲遠程調用框架,目的是希望調用遠程方法就像本地方法一樣簡單。

客戶端:通過簡單註解或者使用類調用遠程方法

客戶端代理類:通過動態代理,讓客戶端執行的方法最終讓代理類來執行。代理類拿到服務名 / 方法名,參數等信息封裝到 request 中,然後通過網絡調用發送給服務端

網絡調用:最簡單的可以用 socket,當然 netty 更流行,編寫 Netty 的客戶端與服務端

服務端:Netty 中拿到 request,知道了方法名,可以通過反射創建實現了該方法的類,然後調用之,得到結果後,再通過 Netty 服務端傳送給客戶端

註冊中心:我們可以用 zk,創建節點,節點爲服務名,節點下數據爲機器 ip 地址。服務端啓動時,首先將自己能夠提供的服務註冊到 zk 上。客戶端根據服務名從 zk 中找到具體的 ip 地址,然後根據 ip 地址發送訪問。

網關#

微服務下多個服務,對於權限管理,流量控制,日誌,監控等和業務無關的東西提取出來,統一管理,因此就有網關。

網關可以做:鑑權,限流,請求路由,日誌,監控。

微服務#

服務註冊與發現:Eureka,nacos#

微服務有很多消費者,提供者,我們不希望將他們之間的調用寫死,因爲針對某個服務,可能有多個機器去運行他,那麼我們希望有一個人能夠統一管理,那麼註冊中心可以解決我們的問題。服務提供者將自己的服務註冊到註冊中心,消費者只需根據服務名從註冊中心拿到提供者地址。並且對於網關,負載均衡,熔斷降級,消息隊列等等組件,他們都希望自己能夠獲得註冊在註冊中心的某些信息,從而進行操作。

比如監控功能,就需要拿到註冊中心的所有提供者消費者信息,來判斷他們的健康情況。

總之,註冊中心統一對服務的管理,當我們需要使用或者查看這些服務狀態時,只需訪問註冊中心即可。

負載均衡:Ribbon#

nacos 自己集成了 Ribbon,要使用負載均衡,首先我們要講 restTemplate 通過 @Bean 註解註冊到 spring 中,然後或者使用註解,或者通過代碼指定負載均衡策略即可,然後調用 restTemplate.getForObject 或者 restTemplate.postForObject 即可調用另一個服務的方法。

Openfeign:有人覺得直接寫 restTemplate.postForObject,這樣不美觀,我就是想調用另一個服務就跟調用本地方法一樣,那麼這個 Openfeign 就可以幫助我們。我們寫一個接口,接口中方法指明另一個服務的接口,然後我們在 controller 調用的時候,加個註解,直接調用接口的方法,看起來多像在本地調用方法啊!

熔斷和降級:Hystrix,sentinel#

當服務調用鏈路 A->B->C,其中服務 C 發生故障,導致 B 有大量請求堆積,最終耗盡 B 的所有資源,B 掛掉,然後 A 也堆積大量請求,A 也掛掉,這就是服務雪崩。

爲了防止服務雪崩,我們需要熔斷器,當某個服務故障時,切斷調用鏈路,告知上一個服務,當前服務已經故障了。

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

sentinel 不僅僅有熔斷降級等功能,他還提供了多種其他功能,如限流,負載保護,實時監控,調用鏈路等。

網關:gateway,zuul#

網關可以做路由映射,過濾器。

鏈路跟蹤:zipkin#

每個服務是一個圓點,服務調用之間有連線,做出來的效果,真好看。。。😄

作者:KeBoom

出處:https://www.cnblogs.com/keboom/p/14842578.html

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://www.cnblogs.com/keboom/p/14842578.html