偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

微服務前端數(shù)據(jù)加載的優(yōu)秀實踐

開發(fā) 前端
目前在不少團隊里已經(jīng)逐步實踐落地了微服務架構(gòu),比如前端圈很流行的 BFF(Backend For Frontend)其實就是微服務架構(gòu)的一種變種。

 目前在不少團隊里已經(jīng)逐步實踐落地了微服務架構(gòu),比如前端圈很流行的 BFF(Backend For Frontend)其實就是微服務架構(gòu)的一種變種,即讓前端團隊維護一套“膠水層/接入層/API層”的服務,調(diào)用后臺團隊提供的若干個微服務,將微服務的結(jié)果進行邏輯組裝,從而包裝出對外的 API。

在這種架構(gòu)下,服務在大體上可以分為兩種角色:

  1. 前端服務(Frontend),包裝底層的微服務,對外直接暴露可調(diào)用的 API。例如在 BFF 架構(gòu)里,很可能就是一個 Node.js 寫成的 HTTP Server。
  2. 后臺微服務(Microservices),通常由后端團隊提供的單體服務,承載不同模塊的功能,提供一系列的內(nèi)部調(diào)用接口。

這篇文章主要分享這種架構(gòu)下,前端服務進行數(shù)據(jù)加載的幾種最佳實踐。

最簡單的情形

我們先考慮一種最簡單的情形,也就是每當有外部請求進來,那么前端服務都會向若干個后臺微服務請求數(shù)據(jù),然后進行邏輯處理,返回響應:

這種樸素的模型明顯存在一個問題:每個外部請求都會觸發(fā)多次內(nèi)部服務調(diào)用,這樣的做法非常浪費資源,因為對于大多數(shù)內(nèi)部微服務而言,請求的結(jié)果在一定的時間內(nèi)都是 可緩存 的。

比如用戶的頭像可能幾天幾周甚至幾個月才更新一次,這種情況下前端服務完全可以緩存用戶的頭像一段時間,這段時間內(nèi),讀取用戶頭像可以從直接從緩存內(nèi)讀取,而不需要請求后臺,很大程度上節(jié)省了后臺服務的負擔。

加入本地緩存

于是我們在前端服務中加入了本地內(nèi)存緩存(Local Cache),讓大多數(shù)請求都命中本地緩存,從而減少了后臺服務的負擔:

本地緩存通常是放置在內(nèi)存里的,而內(nèi)存空間比較有限,所以我們需要引入 緩存淘汰 的機制,限制內(nèi)存最大容量。具體的緩存淘汰算法就有很多了,比如 FIFO、LFU、LRU、MRU、ARC 等等,可以根據(jù)業(yè)務的實際情況來選擇合適的算法。

引入本地緩存之后,依然會有一個問題:緩存只能在單個服務實例(服務實例可以理解為服務器、K8S Pod之類的概念)上生效,而大多數(shù)前端服務為了能夠橫向擴容,一般都是無狀態(tài)的,所以會有大量并存的實例。

也就是說,本地緩存可能只會在某臺服務器上生效,而其他平行的服務器上沒有緩存,如果請求打到了沒有緩存的服務器上,那么依然無法命中緩存。

另外一個問題就是,緩存邏輯和應用邏輯是耦合的,每一個接口的代碼里可能都會存在類似這樣的邏輯:

  1. var cachedData = cache.get(key) 
  2.  
  3. if (cachedData !== undefined) { 
  4.  
  5. return cachedData 
  6.  
  7. else { 
  8.  
  9. return fetch('...'
  10.  

Don't Repeat Yourself! 我們顯然需要把這段緩存邏輯抽象出來,避免重復代碼。

加入 Cache 層和中心化緩存

為了解決上面兩個問題,我們繼續(xù)改進我們的架構(gòu):

加入 中心化的遠程緩存 (比如 Redis、Memcache),讓遠程緩存可以作用到所有實例上面;

將緩存、RPC 等非應用層的邏輯 抽象為單獨的組件(Cache Layer) ,用來封裝后臺微服務的讀寫、本地緩存、遠程緩存相關(guān)的邏輯。

抽象出這樣一層 Cache Layer 之后,我們便可以進一步演進我們的服務。

加入緩存刷新機制

雖然我們有了中心化的緩存,但緩存畢竟只是短期內(nèi)有效的。一旦緩存失效,那就還是得向后臺服務請求數(shù)據(jù),在這種臨界條件下,請求耗時就會增加,出現(xiàn)耗時的毛刺現(xiàn)象(每隔一段時間,有小部分請求耗時變大)。

那么 有沒有辦法可以讓緩存一直保持“新鮮”呢 ?這就需要緩存刷新的機制了,大體上講,緩存刷新分為主動刷新和被動刷新兩種:

主動刷新

主動刷新即每當數(shù)據(jù)有更新的時候,刷新緩存,下游服務永遠只讀取緩存內(nèi)的數(shù)據(jù)。

讀多寫少的后臺服務非常適合這種模式,因為讀請求永遠不會打到數(shù)據(jù)庫里,而是被分流到性能、擴展性高幾個檔次的緩存組件上面,從而很大程度上減輕數(shù)據(jù)庫的壓力。

當然主動刷新也并不是完美無缺的,它意味著 前后端服務必須要在緩存組件上產(chǎn)生耦合 (比如需要約定緩存 key 的命名、數(shù)據(jù)結(jié)構(gòu)等),這就帶來了一定的隱患,一旦后端微服務錯誤地寫入了緩存,或者緩存組件出現(xiàn)可用性問題,結(jié)果很可能是災難性的。所以這種模式更適合單個服務內(nèi)部,而不是多個服務之間。

被動刷新

被動刷新即讀取緩存數(shù)據(jù)的時候,根據(jù)緩存的剩余有效期或者類似指標,決定要不要異步刷新緩存(類似 HTTP 協(xié)議的 stale-while-revalidate )。

這種模式相比于主動刷新,優(yōu)點是服務間的耦合更少一些,但缺點在于 1. 只能根據(jù)訪問熱點進行緩存,無法全量緩存;2. 只能根據(jù)相關(guān)指標被動刷新,降低了數(shù)據(jù)的即時性。

如果團隊的前端服務(如 BFF)和后臺服務是由兩套人員開發(fā)維護,比較適合使用這樣的緩存模式。當然具體選擇哪種模式,得根據(jù)實際情況來決定。

緩存是一個非常靈活并且萬金油的組件,這里篇幅有限就不再深入,更多關(guān)于緩存的設(shè)計模式,可以參考這里:

donnemartin/system-design-primer ​ github.com

請求收斂

對于大流量的業(yè)務而言,可能同時會有成百上千的請求打到同一個前端服務實例上,這些請求會觸發(fā)大量的對緩存、后臺服務的讀請求,大多數(shù)情況下,這些并發(fā)的讀請求是可以 收歸為少數(shù)幾個請求 的。

這種思路和 Facebook 開源的dataloader 非常相似,將并行的、參數(shù)相同的請求收歸到一起,從而降低后端服務的壓力(在 GraphQL 的使用場景下很容易出現(xiàn)這種問題)。

容災緩存

我們不妨考慮一種極端的情況:如果后臺服務全掛了,前端服務能不能使用緩存里的來“撐住”一段時間?這就是容災緩存的概念,即 在服務異常的時候,降級到使用緩存中的數(shù)據(jù)來響應外部請求,保證一定的可用性 。容災緩存的邏輯,同樣可以抽象到 Cache Layer 中。

 

責任編輯:張燕妮 來源: 前端那些事
相關(guān)推薦

2023-09-02 20:55:04

微服務架構(gòu)

2020-04-27 10:20:07

微服務架構(gòu)數(shù)據(jù)庫

2021-04-15 08:08:48

微前端Web開發(fā)

2022-01-24 10:26:46

Kubernetes微服務

2021-10-08 13:22:05

數(shù)字化轉(zhuǎn)型企業(yè)技術(shù)

2023-09-11 13:29:00

微服務架構(gòu)

2020-05-29 09:41:26

微服務數(shù)據(jù)工具

2022-04-08 09:00:00

微服務架構(gòu)安全防火墻

2022-05-13 14:01:46

微服務架構(gòu)安全微服務

2019-12-17 08:07:58

微服務架構(gòu)

2018-11-23 09:00:00

微服務微服務架構(gòu)日志

2019-12-16 17:59:22

軟件微服務技術(shù)

2022-10-20 10:02:16

前端測試開發(fā)

2022-10-17 15:21:18

2025-06-12 09:48:46

2021-09-27 09:00:00

開發(fā)微服務架構(gòu)

2021-01-20 10:53:41

云計算云存儲云遷移

2020-04-28 16:12:50

前端JavaScript代碼

2022-07-08 11:19:29

微服務Java框架

2021-10-13 13:52:13

數(shù)據(jù)驅(qū)動大數(shù)據(jù)服務器管理
點贊
收藏

51CTO技術(shù)棧公眾號