聊聊小背景
前幾天的早晨我早寫字樓門口干等了半小時，背后的原因竟然是健康碼的二維碼刷不出來，保安小哥還一直跟我講，支付寶出不來你用微信啊，用微信啊，，
他們用的相同的介面，我用微信有卵用啊，冷風中我甩了甩僅有的幾根秀發，揚長而去，，，
作為程式員的我就開始了內心的吐槽大會：這咋做的啊，不行呀，這就打不開了，肯定沒做優化，肯定沒用快取，肯定沒做壓力測驗，，，，，
下面作為技術的視角來分析下這個場景的實作，以及可以怎么去優化，這只是我YY哈，真實場景別人是怎么實作的我也不清楚哈，
需求剖析
每個人都有一個對應的健康碼，健康碼分為幾種顏色，也就對應了幾個狀態，本質上就是通過健康碼的顏色能否區分這個用戶是否去過高風險地址，
首先第一個問題就是需要根據多維度的資料去計算出這個碼的顏色，比如根據用戶的行動軌跡去分析，至于實際上有哪些維度我也不知道，大概猜測行動軌跡肯定是其中一點，
大概的存盤也很簡單，就是userId code等欄位，這個場景如果需要歷史資料可以單獨歸檔即可，只留最近一天的資料提供查詢即可，
實作剖析
最簡單的方案就是每次查詢實時去分析，這樣結果的真實性更高，不足點在于體驗不是很好，如果邏輯多的話肯定是無法在1s內給用戶回應的，所以在上面分析的時候我們設計了一張表進行存盤，肯定是提前計算好的，比如一天一次，半天一次之類的形式，
那我們基于已經有表的形式去做分析，這個業務場景就是很典型的讀多寫（凌晨寫）少的場景，如果不做任何改動，每次請求直接查詢表直接回應即可，在高并發場景下只能依賴資料庫的并發能力來扛住這些請求，很容易出現系統掛掉，回應慢的情況，也就是為什么我在門口等了半小時的原因，
增加快取
最好的方式就是加快取了，直接將碼的內容快取起來，前端根據內容生成健康碼即可，首先這種場景不能再查詢之后加快取，因為大部分人的監控碼可能也就早晨進公司的時候用一次，所以不適合查詢后再寫快取的操作，
需要在凌晨計算每個人健康碼的時候，同時將資料寫一份到快取中，當然這個可以根據平時的訪問的資料進行分析，哪部分人每天都會用到，只預先快取這一部分人的即可，
快取后，基本上90%的請求都能命中快取了，因為每天上班的這部分人基本上不會有太大的變化，剩下的請求用資料庫去扛，如果還是扛不住可以加大快取存盤量，用空間換時間，或者資料庫多搞幾個從節點即可，
內外部隔離
在架構設計中，隔離也是非常重要的一環，隔離的作用就是為了在出問題的時候將故障范圍降低到最小，
這健康碼的這個場景中，首先健康碼自己有一個專屬的APP，在支付寶刷不出來的時候我特意用它自己的APP去試了一下，同樣也是打不開，
也就是說查詢健康碼是一個獨立的服務，這個服務可能會被內部的產品，比如APP呼叫，也有可能會通過Open API暴露給外部渠道呼叫，比如支付寶，
這個健康碼需要做什么隔離？
資料庫隔離
可以獨立出一個或多個從節點給對應的服務進行隔離，比如內部服務用庫1，外部服務用庫2，相互不影響，
服務隔離
庫隔離了不能解決根據問題，服務還得隔離，區分內部服務，外部服務，Open API只連接外部服務，內部的網關只連接內部服務，
呼叫方限流
針對不同的呼叫方做不同的限制，內部服務允許80%的量都可以滿足，外部服務20%的量可以滿足，這樣在壓力大的情況下，自己內部的產品是影響最小的，也就是你在支付寶可能打不開健康碼，在我自己的APP可以打開，
不過這種還是得根據實際場景去分析，像健康碼這種場景，也許外部的訪問量遠遠超過了內部的量，因為大部分人可能都是用支付寶，微信啊去打開，所以可以根據實際場景去限制流量，
關于作者：尹吉歡，簡單的技術愛好者，《Spring Cloud微服務-全堆疊技術與案例決議》, 《Spring Cloud微服務 入門 實戰與進階》作者, 公眾號猿天地發起人，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/253600.html
標籤：其他
上一篇：SpringCloud Gateway 集成 WebSocket服務
下一篇：架構中那些需要注意的事兒