在冷風中我凌亂了半小時，只因健康碼刷不出來

聊聊小背景

前幾天的早晨我早寫字樓門口乾等了半小時，背後的緣由居然是健康碼的二維碼刷不出來，保安小哥還一直跟我講，支付寶出不來你用微信啊，用微信啊。。

他們用的相同的接口，我用微信有卵用啊，冷風中我甩了甩僅有的幾根秀髮，揚長而去。。。

做爲程序員的我就開始了心裏的吐槽大會：這咋作的啊，不行呀，這就打不開了，確定沒作優化，確定沒用緩存，確定沒作壓力測試。。。。。

下面做爲技術的視角來分析下這個場景的實現，以及能夠怎麼去優化。這只是我YY哈，真實場景別人是怎麼實現的我也不清楚哈。

需求剖析

每一個人都有一個對應的健康碼，健康碼分爲幾種顏色，也就對應了幾個狀態。本質上就是經過健康碼的顏色可否區分這個用戶是否去太高風險地址。

首先第一個問題就是須要根據多維度的數據去計算出這個碼的顏色，好比根據用戶的行動軌跡去分析。至於實際上有哪些維度我也不知道，大概猜想行動軌跡確定是其中一點。

大概的存儲也很簡單，就是userId code等字段，這個場景若是須要歷史數據能夠單獨歸檔便可，只留最近一天的數據提供查詢便可。

實現剖析

最簡單的方案就是每次查詢實時去分析，這樣結果的真實性更高，不足點在於體驗不是很好，若是邏輯多的話確定是沒法在1s內給用戶響應的，因此在上面分析的時候咱們設計了一張表進行存儲，確定是提早計算好的，好比一天一次，半天一次之類的形式。

那咱們基於已經有表的形式去作分析，這個業務場景就是很典型的讀多寫（凌晨寫）少的場景。若是不作任何改動，每次請求直接查詢表直接響應便可。在高併發場景下只能依賴數據庫的併發能力來扛住這些請求，很容易出現系統掛掉，響應慢的狀況，也就是爲何我在門口等了半小時的緣由。

增長緩存

最好的方式就是加緩存了，直接將碼的內容緩存起來，前端根據內容生成健康碼便可。首先這種場景不能再查詢以後加緩存，由於大部分人的監控碼可能也就早晨進公司的時候用一次，因此不適合查詢後再寫緩存的操做。

須要在凌晨計算每一個人健康碼的時候，同時將數據寫一份到緩存中，固然這個能夠根據平時的訪問的數據進行分析，哪部分人天天都會用到，只預先緩存這一部分人的便可。

緩存後，基本上90%的請求都能命中緩存了，由於天天上班的這部分人基本上不會有太大的變化。剩下的請求用數據庫去扛，若是仍是扛不住能夠加大緩存存儲量，用空間換時間。或者數據庫多搞幾個從節點便可。

內外部隔離

在架構設計中，隔離也是很是重要的一環。隔離的做用就是爲了在出問題的時候將故障範圍下降到最小。

這健康碼的這個場景中，首先健康碼本身有一個專屬的APP，在支付寶刷不出來的時候我特地用它本身的APP去試了一下，一樣也是打不開。

也就是說查詢健康碼是一個獨立的服務，這個服務可能會被內部的產品，好比APP調用，也有可能會經過Open API暴露給外部渠道調用，好比支付寶。

這個健康碼須要作什麼隔離？

• 數據庫隔離

能夠獨立出一個或多個從節點給對應的服務進行隔離，好比內部服務用庫1，外部服務用庫2，相互不影響。

• 服務隔離

庫隔離了不能解決根據問題，服務還得隔離。區份內部服務，外部服務。Open API只鏈接外部服務，內部的網關只鏈接內部服務。

• 調用方限流

針對不一樣的調用方作不一樣的限制，內部服務容許80%的量均可以知足。外部服務20%的量能夠知足。這樣在壓力大的狀況下，本身內部的產品是影響最小的。也就是你在支付寶可能打不開健康碼，在我本身的APP能夠打開。

不過這種仍是得根據實際場景去分析，像健康碼這種場景，也許外部的訪問量遠遠超過了內部的量，由於大部分人可能都是用支付寶，微信啊去打開。因此能夠根據實際場景去限制流量。

關於做者：尹吉歡，簡單的技術愛好者，《Spring Cloud微服務-全棧技術與案例解析》, 《Spring Cloud微服務 入門 實戰與進階》做者, 公衆號猿天地發起人。