建站
咨詢
售后
建站咨詢
新聞中心
在前面的幾篇文章當(dāng)中我們聊到了 隔離設(shè)計(jì)、令牌桶算法、漏桶算法、自適應(yīng)限流和熔斷，可用性的建設(shè)遠(yuǎn)不止這些，這一部分的內(nèi)容在進(jìn)階訓(xùn)練營(yíng)中也講了 7 個(gè)小時(shí)，其他部分如果感興趣的話推薦購(gòu)買源課程觀看。
成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比灣里網(wǎng)站開(kāi)發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式灣里網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋灣里地區(qū)。費(fèi)用合理售后完善，十余年實(shí)體公司更值得信賴。
由于前面的文章大部分都在講限流相關(guān)的內(nèi)容，所以我們先看一下不同的限流方式的對(duì)比
限流對(duì)比
微服務(wù)可用性設(shè)計(jì)總結(jié)
接下來(lái)我們就一起來(lái)串聯(lián)我們之前講到的和課程上講到的一些內(nèi)容總結(jié)一下可用性應(yīng)該怎么做。
微服務(wù)可用性設(shè)計(jì)總結(jié)
如上圖所示，我們從一個(gè)簡(jiǎn)單的用戶訪問(wèn)出發(fā)，用戶訪問(wèn)到我們的服務(wù)一般是先通過(guò)我們的移動(dòng)客戶端或者是瀏覽器，然后請(qǐng)求再依次通過(guò) CDN、防火墻、API網(wǎng)關(guān)、BFF以及各個(gè)后端服務(wù)，整條鏈路還是比較長(zhǎng)的。
我們上圖其實(shí)已經(jīng)一部分體現(xiàn)了隔離設(shè)計(jì)，所以后面我就不再提了。
1. 移動(dòng)客戶端/瀏覽器
客戶端是觸及用戶的第一線，所以這一層做的可用性優(yōu)化尤為的重要
降級(jí): 降級(jí)的本質(zhì)是提供給用戶有損服務(wù)，所以在觸及用戶的第一線如何安撫好或者說(shuō)如何騙過(guò)用戶的眼睛尤為重要
- 本地緩存，客戶端需要有一些本地緩存數(shù)據(jù)，不僅可以加速用戶首屏的加載時(shí)間，還可以在后端服務(wù)出現(xiàn)故障的時(shí)候起到一定的緩沖作用
- 降級(jí)數(shù)據(jù)兼容，服務(wù)端有時(shí)為了降級(jí)會(huì)返回一些 mock 數(shù)據(jù)或者是空數(shù)據(jù)，這些數(shù)據(jù)一定要和客戶端的對(duì)接好，如果沒(méi)有對(duì)接好很容易就會(huì)出現(xiàn)異?；蛘呤前灼?/li>
流控: 在服務(wù)出現(xiàn)問(wèn)題的時(shí)候，用戶總是會(huì)不斷的主動(dòng)嘗試重試，如果不加以限制會(huì)讓我們本就不堪重負(fù)的后端服務(wù)雪上加霜
- 所以在客戶端需要做類似熔斷的流控措施，常見(jiàn)的思路有指數(shù)級(jí)退讓，或者是通過(guò)服務(wù)端的返回獲取冷卻的時(shí)間
2. BFF/Client
BFF 是我們后端服務(wù)的橋頭堡，當(dāng)請(qǐng)求來(lái)到 BFF 層的時(shí)候，BFF 既是服務(wù)端，又是客戶端，因?yàn)樗话阈枰?qǐng)求很多其他的后端服務(wù)來(lái)完成數(shù)據(jù)的編排，提供客戶端想要的數(shù)據(jù)
超時(shí)控制： 超時(shí)控制需要注意的兩點(diǎn)是默認(rèn)值和超時(shí)傳遞
- 默認(rèn)值，基礎(chǔ)庫(kù)需要有一些默認(rèn)值，避免客戶端用戶漏填，錯(cuò)填，舉個(gè)例子，如果開(kāi)發(fā)填寫一個(gè)明顯過(guò)大的值 100s 才超時(shí)，這時(shí)候我們基礎(chǔ)庫(kù)可以直接拋出錯(cuò)誤，或者是警告只有手動(dòng)忽略才可以正常啟動(dòng)。我之前有一個(gè)應(yīng)用就是因?yàn)橥浥渲贸瑫r(shí)時(shí)間，依賴的服務(wù) hang 住導(dǎo)致我的服務(wù)也無(wú)法正常服務(wù)了，即使我之前做了緩存也沒(méi)有用，因?yàn)橹暗倪壿嬍侵挥姓?qǐng)求報(bào)錯(cuò)才會(huì)降級(jí)使用緩存數(shù)據(jù)。
- 超時(shí)傳遞，例如我們上圖，假設(shè)我們整個(gè)請(qǐng)求的超時(shí)時(shí)間配置的 500ms，BFF 里面首先經(jīng)過(guò)一些邏輯判斷消耗了 100ms，然后去請(qǐng)求 redis，我們給 redis 配置的超時(shí)時(shí)間 max_con 是 500ms，這時(shí)候就不能用 500ms 作為超時(shí)時(shí)間，得用 min(請(qǐng)求剩余的超時(shí)時(shí)間，max_con)也就是 400ms 作為我們的超時(shí)時(shí)間，同樣我們請(qǐng)求下游的服務(wù)也需要將超時(shí)時(shí)間攜帶到 header 信息里面，這樣下游服務(wù)就可以繼承上游的超時(shí)時(shí)間來(lái)進(jìn)行超時(shí)判斷。
負(fù)載均衡： 一般我們比較常用的負(fù)載均衡策略就是輪訓(xùn)，或者說(shuō)加個(gè)權(quán)重，這個(gè)比較大的問(wèn)題就是，我們的服務(wù)性能并不是每個(gè)實(shí)例都一樣，收到宿主機(jī)的型號(hào)，當(dāng)前機(jī)器上服務(wù)的數(shù)量等等因素的影響，并且由于我們的服務(wù)是在隨時(shí)漂移和變化的，所以我們沒(méi)有辦法為每個(gè)實(shí)例配上合適的權(quán)重。
- 所以我們可以根據(jù)一些統(tǒng)計(jì)數(shù)據(jù)，例如 cpu、load 等信息獲取當(dāng)前服務(wù)的負(fù)載情況，然后根據(jù)不同的負(fù)載情況進(jìn)行打分，然后來(lái)進(jìn)行流量的分配，這樣就可以將我們的流量比較合理的分配到各個(gè)實(shí)例上了。
重試： 重試一定要注意避免雪崩
- 當(dāng)我們的服務(wù)出現(xiàn)一些錯(cuò)誤的時(shí)候，我們可以通過(guò)重試來(lái)解決，例如如果部分實(shí)例過(guò)載導(dǎo)致請(qǐng)求很慢，我們通過(guò)重試，加上面的負(fù)載均衡可以將請(qǐng)求發(fā)送到正常的實(shí)例，這樣可以提高我們的 SLA
- 但是需要的注意的是，重試只能在錯(cuò)誤發(fā)生的地方進(jìn)行重試，不能級(jí)聯(lián)重試，級(jí)聯(lián)重試很容易造成雪崩，一般的做法就是約定一個(gè) code 只要出現(xiàn)這個(gè) code 我們就知道下游已經(jīng)嘗試過(guò)重試了，我們就不要再重試了
熔斷： 一般來(lái)說(shuō)如果只是部分實(shí)例出現(xiàn)了問(wèn)題，我們通過(guò)負(fù)載均衡階段+重試一般就可以解決，但如果服務(wù)整體出現(xiàn)了問(wèn)題，作為客戶端就需要使用熔斷的措施了。
- 熔斷常見(jiàn)的有開(kāi)啟，關(guān)閉，半開(kāi)啟的狀態(tài)，例如 hystrix-go 的實(shí)現(xiàn)，但是這種方式比較死板，只要觸發(fā)了熔斷就一個(gè)請(qǐng)求都無(wú)法放過(guò)，所以就又學(xué)習(xí)了 Google SRE 的做法，同構(gòu)計(jì)算概率來(lái)進(jìn)行判斷，沒(méi)有了半開(kāi)啟的狀態(tài)，開(kāi)啟的時(shí)候也不會(huì)說(shuō)是一刀切。
降級(jí)： 當(dāng)我們請(qǐng)求一些不那么重要的服務(wù)出現(xiàn)錯(cuò)誤時(shí)，我們可以通過(guò)降級(jí)的方式來(lái)返回請(qǐng)求，降級(jí)一般在 BFF 層做，可以有效的防止污染其他服務(wù)的緩存。常見(jiàn)的討論有返回 mock 數(shù)據(jù)，緩存數(shù)據(jù)，空數(shù)據(jù)等
3. Server
BFF 其實(shí)也是服務(wù)端，但是為了流暢的講解，主要將其作為了客戶端的角色。服務(wù)端主要的是限流的措施，當(dāng)流量從 BFF 來(lái)到我們的服務(wù)之后，我們會(huì)使用令牌桶算法嘗試獲取 token，如果 token 不夠就丟棄，如果 token 足夠就完成請(qǐng)求邏輯。
我們的 token 是從哪里來(lái)的呢?
攔截器會(huì)定時(shí)的向 Token Server 上報(bào)心跳數(shù)據(jù)，包含了一些統(tǒng)計(jì)信息，同時(shí)從 Token Server 獲取一定數(shù)量的 Token，當(dāng) Token Server 接收到請(qǐng)求之后會(huì)通過(guò)最大最小公平分享的算法，根據(jù)每個(gè)服務(wù)實(shí)例上報(bào)的統(tǒng)計(jì)信息進(jìn)行 Token 的分配。
這個(gè)其實(shí)就是之前沒(méi)有講到的分布式限流的思路，在單個(gè)服務(wù)實(shí)例上又使用了單機(jī)限流的算法
總結(jié)
到這里我們的可用性相關(guān)的知識(shí)點(diǎn)就算是告一段落了，前面的文章主要講解了限流的相關(guān)知識(shí)點(diǎn)，雖然其他的沒(méi)有細(xì)說(shuō)，但是這一篇總結(jié)也算是都涉及到了，包括隔離設(shè)計(jì)、限流(單機(jī)限流、自適應(yīng)限流、分布式限流)、超時(shí)控制、降級(jí)、熔斷、負(fù)載均衡、重試。OK，話不多說(shuō)，我們下篇文章見(jiàn)。
本文轉(zhuǎn)載自微信公眾號(hào)「mohuishou」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系mohuishou公眾號(hào)。
當(dāng)前題目：Go可用性(七)總結(jié):一張圖串聯(lián)可用性知識(shí)點(diǎn)
文章路徑：http://www.dlmjj.cn/article/coijeph.html
