58到家入駐微信錢包的技術優化
一、需求緣起
大夥打開微信錢包,會發現58到家入駐了微信錢包的一級入口(如下圖),這個入口流量極大,微信要求被接入的H5必須能抗住n萬的qps(58到家的系統是偏交易的系統,雖然一天100w訂單其實也沒多少請求),這是之前的業務系統沒有遇到過的,要抗住這個n萬的qps的優化思路是怎麽樣的呢?
這裏做一個思路分享,希望能對業界同仁有啟示作用。
二、業務分析
在微信錢包裏,點擊進入58到家,會發現其實是一個類別落地頁,根據不同城市開通的服務類別,展示不同類別的入口(如下圖)。
很容易想到,整個架構與流程是這樣滴:
架構分層:
(1)微信錢包端,嵌有到家H5頁面
(2)web-server層,生成H5頁面
(3)service層,提供“城市開通了哪些核心服務”的接口
(4)數據庫層,存儲了“城市開通了哪些核心服務”的數據
核心流程:
步驟一:微信端通過native的GPS定位或者微信的js-sdk獲取用戶當前所在城市,並往web-server發送http請求
步驟二:web-server收到http請求,調用service層,獲取當前城市開通了哪些核心服務的數據,以瓶裝返回html
步驟三:service收到RPC請求,調用mysql,獲取真正的數據
步驟四:mysql返回service,service返回web-server,web-server拼裝html,返回微信錢包
潛在的問題:
每秒鐘n萬的qps數據庫扛不住
三、優化分析
看到這裏,很多讀者就笑了,這個場景加個緩存不就搞定了麽,好吧,是可以,但本文的重點並不是加一個緩存,還有其他的梗等著你。
場景分析:這個“城市開通了哪些核心服務”是一個幾乎只讀的場景,因為城市要開通新的服務是很低頻的,所以一大早就想到了cache的優化(cache要註意高可用),優化後的架構分層如下:
cache存儲城市開通的核心服務列表,key value建立的是一個city-id到list<service-id>的映射關系。
幾乎100%的請求會命中緩存。
潛在的問題:服務與緩存之間的帶寬會不會成為瓶頸呢?
因為幾乎是只讀的請求,很容易想到將分布式緩存優化為服務內存緩存,優化後的架構分層如下:
每一個服務內部都有一個map,存儲city-id到list<service-id>的映射關系,而不用通過cache來讀取數據。
還能不能進一步優化,例如進一步降低網絡交互呢?
是可以的,服務層可以做數據的緩存map<cityid, list<sid>>,web-server層可以進一步做頁面緩存優化,架構圖如下:
每一個站點層,直接做頁面緩存,上遊傳入一個city-id,就直接將提前拼裝好的頁面返回,得到很高的性能。
有甚者,通過nginx/varnish/squid針對性的做一些“頁面靜態化的優化”,直接每個city有一個對應的html,能極大的提高吞吐量:
四、頁面靜態化的適用場景
在做站點架構的過程中,“動靜分離”是一項很常見的優化手段:
(1)對於不變的首頁、js、jpg、css,可以用專門的file-server來針對性優化(cdn/nginx/varnish/squid)提供高速訪問
(2)對於動態的頁面,有專門的tomcat/apache/iis/lighttpd集群來提供動態站點生成
一般來說動態站點時延會大大高於靜態站點,應為每次生成動態站點需要訪問服務(多次網絡傳輸)、訪問數據庫(可能有很慢的磁盤io),並且還有大量的計算邏輯,而靜態文件則可以直接返回。
“頁面靜態化”是一種將原本需要動態生成的站點提前生成靜態站點的優化技術,什麽樣的業務場景可以進行“頁面靜態化”優化呢?
解答:總數據量不大,生成靜態頁面數量不多的業務,非常適合於“頁面靜態化”優化
<廣告>
如果你讀到了這裏,說明對微信平臺還是有點興趣的,58到家微信平臺團隊目前只有一個女生負責(技術圈混,絕不騙人),奇缺人,歡迎有誌之士加入。
一些說明:base北京,核心團隊,技術導向,Java方向,和58沈劍一個團隊
加入方式:(1)直接在文章下面留言(2)在公眾號回復“招聘”獲取加盟密鑰
</廣告完畢>
例如:到家開通的城市只有幾百個,那只需提前生成幾百個城市的“靜態化頁面”即可
又例如:一些二手車業務,整個公司可能只有幾萬量二手車庫存,也可以提前生成這幾萬量二手車的靜態頁面
再例如:像58同城這樣的信息模式業務,又幾十億的帖子量,就不太適合於靜態化
五、總結
“頁面靜態化”是一種將原本需要動態生成的站點提前生成靜態站點的優化技術,總數據量不大,生成靜態頁面數量不多的業務,非常適合於“頁面靜態化”優化
以上內容均來自微信公眾號“架構師之路”胡劍老師的文章,歡迎關註。
58到家入駐微信錢包的技術優化