58到家入駐微信錢包的技術(shù)優(yōu)化

一、需求緣起

---

大伙打開微信錢包，會發(fā)現(xiàn)58到家入駐了微信錢包的一級入口（如下圖），這個(gè)入口流量極大，微信要求被接入的H5必須能抗住n萬的qps（58到家的系統(tǒng)是偏交易的系統(tǒng)，雖然一天100w訂單其實(shí)也沒多少請求），這是之前的業(yè)務(wù)系統(tǒng)沒有遇到過的，要抗住這個(gè)n萬的qps的優(yōu)化思路是怎么樣的呢？

這里做一個(gè)思路分享，希望能對業(yè)界同仁有啟示作用。

二、業(yè)務(wù)分析

---

在微信錢包里，點(diǎn)擊進(jìn)入58到家，會發(fā)現(xiàn)其實(shí)是一個(gè)類別落地頁，根據(jù)不同城市開通的服務(wù)類別，展示不同類別的入口（如下圖）。

很容易想到，整個(gè)架構(gòu)與流程是這樣滴：

架構(gòu)分層：

（1）微信錢包端，嵌有到家H5頁面

（2）web-server層，生成H5頁面

（3）service層，提供“城市開通了哪些核心服務(wù)”的接口

（4）數(shù)據(jù)庫層，存儲了“城市開通了哪些核心服務(wù)”的數(shù)據(jù)

核心流程：

步驟一：微信端通過native的GPS定位或者微信的js-sdk獲取用戶當(dāng)前所在城市，并往web-server發(fā)送http請求

步驟二：web-server收到http請求，調(diào)用service層，獲取當(dāng)前城市開通了哪些核心服務(wù)的數(shù)據(jù)，以瓶裝返回html

步驟三：service收到RPC請求，調(diào)用mysql，獲取真正的數(shù)據(jù)

步驟四：mysql返回service，service返回web-server，web-server拼裝html，返回微信錢包

潛在的問題：

每秒鐘n萬的qps數(shù)據(jù)庫扛不住

三、優(yōu)化分析

---

看到這里，很多讀者就笑了，這個(gè)場景加個(gè)緩存不就搞定了么，好吧，是可以，但本文的重點(diǎn)并不是加一個(gè)緩存，還有其他的梗等著你。

場景分析：這個(gè)“城市開通了哪些核心服務(wù)”是一個(gè)幾乎只讀的場景，因?yàn)槌鞘幸_通新的服務(wù)是很低頻的，所以一大早就想到了cache的優(yōu)化（cache要注意高可用），優(yōu)化后的架構(gòu)分層如下：

cache存儲城市開通的核心服務(wù)列表，key value建立的是一個(gè)city-id到list<service-id>的映射關(guān)系。

幾乎100%的請求會命中緩存。

潛在的問題：服務(wù)與緩存之間的帶寬會不會成為瓶頸呢？

因?yàn)閹缀跏侵蛔x的請求，很容易想到將分布式緩存優(yōu)化為服務(wù)內(nèi)存緩存，優(yōu)化后的架構(gòu)分層如下：

每一個(gè)服務(wù)內(nèi)部都有一個(gè)map，存儲city-id到list<service-id>的映射關(guān)系，而不用通過cache來讀取數(shù)據(jù)。

還能不能進(jìn)一步優(yōu)化，例如進(jìn)一步降低網(wǎng)絡(luò)交互呢？

是可以的，服務(wù)層可以做數(shù)據(jù)的緩存map<cityid, list<sid>>，web-server層可以進(jìn)一步做頁面緩存優(yōu)化，架構(gòu)圖如下：

每一個(gè)站點(diǎn)層，直接做頁面緩存，上游傳入一個(gè)city-id，就直接將提前拼裝好的頁面返回，得到很高的性能。

有甚者，通過nginx/varnish/squid針對性的做一些“頁面靜態(tài)化的優(yōu)化”，直接每個(gè)city有一個(gè)對應(yīng)的html，能極大的提高吞吐量： 

四、頁面靜態(tài)化的適用場景

---

在做站點(diǎn)架構(gòu)的過程中，“動(dòng)靜分離”是一項(xiàng)很常見的優(yōu)化手段：

（1）對于不變的首頁、js、jpg、css，可以用專門的file-server來針對性優(yōu)化（cdn/nginx/varnish/squid）提供高速訪問

（2）對于動(dòng)態(tài)的頁面，有專門的tomcat/apache/iis/lighttpd集群來提供動(dòng)態(tài)站點(diǎn)生成

一般來說動(dòng)態(tài)站點(diǎn)時(shí)延會大大高于靜態(tài)站點(diǎn)，應(yīng)為每次生成動(dòng)態(tài)站點(diǎn)需要訪問服務(wù)（多次網(wǎng)絡(luò)傳輸）、訪問數(shù)據(jù)庫（可能有很慢的磁盤io），并且還有大量的計(jì)算邏輯，而靜態(tài)文件則可以直接返回。

“頁面靜態(tài)化”是一種將原本需要?jiǎng)討B(tài)生成的站點(diǎn)提前生成靜態(tài)站點(diǎn)的優(yōu)化技術(shù)，什么樣的業(yè)務(wù)場景可以進(jìn)行“頁面靜態(tài)化”優(yōu)化呢？

解答：總數(shù)據(jù)量不大，生成靜態(tài)頁面數(shù)量不多的業(yè)務(wù)，非常適合于“頁面靜態(tài)化”優(yōu)化

例如：到家開通的城市只有幾百個(gè)，那只需提前生成幾百個(gè)城市的“靜態(tài)化頁面”即可

又例如：一些二手車業(yè)務(wù)，整個(gè)公司可能只有幾萬量二手車庫存，也可以提前生成這幾萬量二手車的靜態(tài)頁面

再例如：像58同城這樣的信息模式業(yè)務(wù)，又幾十億的帖子量，就不太適合于靜態(tài)化

五、總結(jié)

---

“頁面靜態(tài)化”是一種將原本需要?jiǎng)討B(tài)生成的站點(diǎn)提前生成靜態(tài)站點(diǎn)的優(yōu)化技術(shù)，總數(shù)據(jù)量不大，生成靜態(tài)頁面數(shù)量不多的業(yè)務(wù)，非常適合于“頁面靜態(tài)化”優(yōu)化。