轉(zhuǎn)發(fā)：濟(jì)南小程序開(kāi)發(fā)公司

貝殼找房小程序至今為止已經(jīng)擁有了近2億的用戶，團(tuán)隊(duì)正在在朝著貝殼人的宗旨邁進(jìn)，給這個(gè)行業(yè)創(chuàng)造更多的價(jià)值，努力成為一個(gè)能夠服務(wù)2億家庭的品質(zhì)居住平臺(tái)。

經(jīng)過(guò)兩年多的發(fā)展，為了更好的適應(yīng)業(yè)務(wù)發(fā)展，貝殼小程序后端從最初的快速搭建到后來(lái)由php到golang的轉(zhuǎn)型與優(yōu)化，到現(xiàn)在微服務(wù)的落地和業(yè)務(wù)網(wǎng)關(guān)能力的提升，貝殼小程序平臺(tái)一直走在蛻變的路上。而貝殼找房小程序和app的上線，也意味著一直在房產(chǎn)行業(yè)里深耕的鏈家，從直營(yíng)模式到貝殼找房平臺(tái)化模式的正式轉(zhuǎn)變。

小程序平臺(tái)同樣傳承了公司平臺(tái)化的轉(zhuǎn)變理念和模式，把平臺(tái)化思路堅(jiān)決貫徹下去，在完成平臺(tái)需求的同時(shí)，沉淀平臺(tái)核心能力，賦能各個(gè)業(yè)務(wù)，甚至賦能給整個(gè)行業(yè)。

1 小程序平臺(tái)1.0

貝殼找房小程序起始于2018年，1.0時(shí)代小程序團(tuán)隊(duì)主要是在追趕功能，團(tuán)隊(duì)在半年時(shí)間內(nèi)完成了1年應(yīng)該完成的業(yè)務(wù)。半年期間小程序產(chǎn)研團(tuán)隊(duì)快速擴(kuò)增，此期間大量的進(jìn)行API層開(kāi)發(fā)，封裝各業(yè)務(wù)接口，以快速完成第一版的小程序?yàn)槟繕?biāo)。

1.1 極速上線小程序后臺(tái)服務(wù)

 

極速上線公司級(jí)小程序平臺(tái)要面對(duì)的問(wèn)題是什么呢？因?yàn)樨悮ば〕绦蚱脚_(tái)的特殊屬性，各個(gè)業(yè)務(wù)例如新房、二手、租賃、裝修都是分屬在各團(tuán)隊(duì)維護(hù)的，所以需要有平臺(tái)業(yè)務(wù)方來(lái)整體對(duì)小程序的性能做分析和監(jiān)控。

首先是每日性能監(jiān)控，團(tuán)隊(duì)做了第一版的性能分析日?qǐng)?bào)，把小程序內(nèi)所有域名的請(qǐng)求量、平均響應(yīng)時(shí)間、499以及5XX狀態(tài)碼的數(shù)量占比、并發(fā)峰值、qps高峰時(shí)間、穩(wěn)定性百分比等等，以穩(wěn)定性日?qǐng)?bào)的形式輸出給團(tuán)隊(duì)所有成員，并且詳細(xì)的列出了所有接口的情況，做到小程序內(nèi)所有的服務(wù)，平臺(tái)都能“心中有數(shù)”。二是小程序平臺(tái)自身接口的實(shí)時(shí)預(yù)警，接入了公司Fast監(jiān)控平臺(tái)，實(shí)時(shí)監(jiān)控各接口的性能指標(biāo)情況，包括域名錯(cuò)誤、SQL異常、第三方請(qǐng)求超時(shí)、業(yè)務(wù)日志ERROR、服務(wù)請(qǐng)求異常等等，保證極速上線的小程序能健康的運(yùn)行。

1.2 如何抗住100倍流量的九宮格？

全部小程序的統(tǒng)一帶來(lái)的風(fēng)險(xiǎn)就是流量的瞬間上漲，不僅僅是各小程序流量的整合，微信九宮格的流量也會(huì)瞬間涌入小程序平臺(tái)，于是項(xiàng)目組開(kāi)始了接口的優(yōu)化和拆分，首先對(duì)預(yù)估流量進(jìn)行了一次壓測(cè)，發(fā)現(xiàn)性能瓶頸在redis集群上，內(nèi)存使用率達(dá)到了90%以上，但實(shí)際瓶頸并不在于redis本身，在于當(dāng)前redis集群的內(nèi)存管控上，這里我提一下為什么DBA需要對(duì)redis集群進(jìn)行內(nèi)存管控呢？首先是貝殼業(yè)務(wù)線較多，每個(gè)微服務(wù)都可以申請(qǐng)獨(dú)立的redis集群，運(yùn)維成本是比較大的，另外如果內(nèi)存超過(guò)20G，高可用的切換后，恢復(fù)的時(shí)長(zhǎng)就可能會(huì)超過(guò)5分鐘，一定程度增加了故障發(fā)生的概率，所以這個(gè)內(nèi)存的管控上還是有必要的。

那該如何優(yōu)化呢？第一反應(yīng)是特定業(yè)務(wù)場(chǎng)景的擴(kuò)容，雖然說(shuō)有20G內(nèi)存的限制，但是如果業(yè)務(wù)場(chǎng)景特殊性，這個(gè)擴(kuò)容也是可以支持的，不過(guò)如果在應(yīng)用層面就能優(yōu)化，何樂(lè)而不為？我們通過(guò)監(jiān)控指標(biāo)發(fā)現(xiàn)redis集群的cpu占用和I/O使用都是在正常的范圍，唯獨(dú)內(nèi)存占用嚴(yán)重超標(biāo)，經(jīng)過(guò)分析發(fā)現(xiàn)是房源詳情大json和小程序首頁(yè)占用了較大的內(nèi)存，一方面我們選擇了合適的壓縮算法，對(duì)redis大value進(jìn)行壓縮，減少了redis的將近一半以上的內(nèi)存占用，另一方面，我們對(duì)小程序首頁(yè)的redis使用了pconnet長(zhǎng)連接，避免頻繁建立短連接的性能損耗。

簡(jiǎn)單的優(yōu)化，也給給團(tuán)隊(duì)帶來(lái)了一些思考，以后在對(duì)面redis的優(yōu)化，在平臺(tái)側(cè)要保持一定的容量buffer可擴(kuò)容，避免出現(xiàn)容量危機(jī)，另一方面，可以利用壓縮、切分等來(lái)提高性能。

1.3 沉淀核心服務(wù)

業(yè)務(wù)上，團(tuán)隊(duì)完成了核心的新房二手業(yè)主等業(yè)務(wù)的功能模塊開(kāi)發(fā)，在和app對(duì)齊的同時(shí)又豐富了微信體系內(nèi)的消息訂閱、推送等場(chǎng)景，此后又開(kāi)啟了小程序體系特有的業(yè)務(wù)場(chǎng)景開(kāi)發(fā)，微信體系內(nèi)的分享、滲透、拉新，以及碼上有客項(xiàng)目的啟動(dòng)，開(kāi)始通過(guò)小程序?yàn)樨悮资f(wàn)經(jīng)紀(jì)人提供自我營(yíng)銷能力。

技術(shù)上，也沉淀了一些核心能力，例如第一版小程序的分享能力的建設(shè)，經(jīng)紀(jì)人通過(guò)小程序進(jìn)行分享后，可以記錄核心的分享鏈條，包括經(jīng)紀(jì)人用戶關(guān)系、閱讀場(chǎng)景、停留時(shí)長(zhǎng)等等。

上圖是第一版用戶分享行為上報(bào)的核心鏈路，當(dāng)用戶掃碼以及授權(quán)后，會(huì)建立經(jīng)紀(jì)人和用戶之間的關(guān)系，計(jì)算出相關(guān)的業(yè)務(wù)指標(biāo)并落庫(kù)，經(jīng)紀(jì)人在后臺(tái)就可以看到用戶的訪問(wèn)信息、閱讀時(shí)長(zhǎng)等等，這部分能力隨著業(yè)務(wù)迭代進(jìn)行過(guò)幾次比較大的升級(jí)，當(dāng)前也通過(guò)大數(shù)據(jù)等手段完善了原有的分享能力。

可以看到的是核心分享能力的沉淀，對(duì)業(yè)務(wù)可以有較大幫助，業(yè)務(wù)方可以通過(guò)用戶與經(jīng)紀(jì)人的行為分析，更精準(zhǔn)、更有效的給那些真正有購(gòu)房需求的用戶更大的幫助。分享能力的平臺(tái)化建設(shè)可以拓展的范圍也是可以預(yù)見(jiàn)的，除了之前核心B2C的場(chǎng)景，C2C也是未來(lái)可以深入的一個(gè)方向，其中包括用戶分享與用戶裂變的行為數(shù)據(jù)鏈能力的建設(shè)?？梢匝刂脚_(tái)化思路的方向，和大數(shù)據(jù)推薦團(tuán)隊(duì)合作，做一些定向的營(yíng)銷方案、打包推薦等等。

2 小程序平臺(tái)2.0

隨著業(yè)務(wù)量的上升，小程序用戶數(shù)量急劇增長(zhǎng)，面對(duì)越來(lái)越高的QPS，必須要保持敬畏之心，團(tuán)隊(duì)準(zhǔn)備開(kāi)啟2.0的升級(jí)，大膽的嘗試從php往golang的躍遷，率先在把之前php api層的流量往golang 網(wǎng)關(guān)切換，團(tuán)隊(duì)在golang層上也做了很多優(yōu)化。

首先說(shuō)下為什么要選擇在網(wǎng)關(guān)層引入golang。關(guān)于php和golang的選擇近些年的爭(zhēng)議不斷，當(dāng)然了PHP是最好的語(yǔ)言，也得益于PHP的易用性和穩(wěn)定性，才得以讓小程序能夠在這么短的時(shí)間內(nèi)完成1.0的上線。但是PHP在安全性、并發(fā)性等方面也有一些不足之處，那golang有什么自身的優(yōu)勢(shì)呢？首先是goruntine協(xié)程，它作為golang的主要代表成員之一，是golang中的并發(fā)執(zhí)行單位，它也是輕量級(jí)的線程，由Go（runtime）管理，Go程序會(huì)智能的將goroutine中的任務(wù)合理的分配給每個(gè)CPU。在面對(duì)高額QPS的請(qǐng)求，golang會(huì)更適合做網(wǎng)關(guān)。

2.1 golang改造，突破高并發(fā)瓶頸

在傳統(tǒng)golang項(xiàng)目中，團(tuán)隊(duì)做了第一次的壓測(cè)，效果并不理想，當(dāng)時(shí)我們進(jìn)行了pprof的性能分析。

上圖是cup的性能分析，發(fā)現(xiàn)高QPS下，系統(tǒng)GetLocalIp獲取函數(shù)占用了4.91s的大性能消耗，這個(gè)性能消耗是比較可怕的，另外Log的寫(xiě)入也有一定程度的性能消耗，占用了1.92s，同時(shí)大家也分析了一下高QPS下的內(nèi)存分配情況。

從上圖也可以看出。對(duì)于ip的獲取，使用內(nèi)存達(dá)到了20M，而分配的累計(jì)值達(dá)到了29G之多，所以采取了一些優(yōu)化方案，改變了獲取本地ip的方式，從緩存中獲取，一次寫(xiě)入多次讀取，并且把log的寫(xiě)入方式改成異步寫(xiě)入。之后，整體的性能和效果得到了一個(gè)較大的提升。

上圖可以看到單機(jī)下，golang網(wǎng)關(guān)的抗壓QPS可以達(dá)到11000QPS，而CPU的使用率還不到40%，而相同機(jī)器配置的PHP服務(wù)已在4000+QPS壓測(cè)的時(shí)候，機(jī)器CPU已經(jīng)達(dá)到80%，逼近極限，網(wǎng)關(guān)的改造達(dá)到了我們的心里預(yù)期。這也是為什么使用golang作為小程序網(wǎng)關(guān)的原因之一。

2.2 整體架構(gòu)-沉淀小程序平臺(tái)核心架構(gòu)

上圖是小程序平臺(tái)2.0時(shí)代的架構(gòu)圖，相比1.0，我們?cè)贏PI層之上加入了golang“網(wǎng)關(guān)”，這里的網(wǎng)關(guān)我加了引號(hào)，主要原因是在2.0時(shí)代，它只參與了其他業(yè)務(wù)的代理透?jìng)?，沒(méi)有網(wǎng)關(guān)的實(shí)際能力，其中直播、貝殼金服、內(nèi)容的業(yè)務(wù)完全經(jīng)過(guò)代理層轉(zhuǎn)發(fā)。API層、服務(wù)層則和1.0保持一致。

2.3 爭(zhēng)當(dāng)業(yè)務(wù)線“保衛(wèi)官”

這里要提一下網(wǎng)關(guān)層在小程序平臺(tái)的必要性，微信對(duì)原生小程序內(nèi)的HTTP請(qǐng)求是有域名限制的，因此新業(yè)務(wù)已經(jīng)沒(méi)有辦法再分配更多的域名，故而新的業(yè)務(wù)方想要接入小程序的話，只能接入小程序的網(wǎng)關(guān)，走統(tǒng)一域名。而小程序的網(wǎng)關(guān)自然而然的成為了接入小程序平臺(tái)的“必經(jīng)之路”，我們接下來(lái)要開(kāi)啟網(wǎng)關(guān)能力建設(shè)了，因?yàn)榫W(wǎng)關(guān)的能力也是真正能夠賦能給業(yè)務(wù)方的，讓大家放心的接入，小程序平臺(tái)可以成為業(yè)務(wù)線的“保衛(wèi)官”。

3 小程序平臺(tái)3.0

完成2.0時(shí)代的優(yōu)化之后，要更多關(guān)注的是清晰的系統(tǒng)架構(gòu)，關(guān)注數(shù)據(jù)量大之后系統(tǒng)瓶頸的解決、以及關(guān)注系統(tǒng)穩(wěn)定性的建設(shè)。

3.1 整體架構(gòu)-邊界清晰，能力健全

伴隨著公司微服務(wù)理念的推進(jìn)，小程序平臺(tái)也逐漸往微服務(wù)方向發(fā)展，把臃腫的大單體拆分為邊界明確、功能模塊清晰的一個(gè)個(gè)微服務(wù)，不僅僅在代碼層面解耦，部署環(huán)境、數(shù)據(jù)庫(kù)、redis等都進(jìn)行了拆分和解耦，讓小程序平臺(tái)慢慢變成一個(gè)更為健壯的體系。

上圖是小程序平臺(tái)3.0的整體架構(gòu)圖，從上至下，分了5層結(jié)構(gòu)：

• 平臺(tái)網(wǎng)關(guān)層：主要接收來(lái)自小程序前端的請(qǐng)求，經(jīng)過(guò)路由轉(zhuǎn)發(fā)給各業(yè)務(wù)api
• 業(yè)務(wù)API層：負(fù)責(zé)接收網(wǎng)關(guān)轉(zhuǎn)發(fā)的請(qǐng)求，處理自己的業(yè)務(wù)邏輯
• 平臺(tái)服務(wù)層：小程序平臺(tái)核心能力，包括多端用戶&Token管理、多端消息、小程序搜索等
• 存儲(chǔ)層：包括了Mysql、Redis以及3.0后新增的TIDB和Hive，下文會(huì)對(duì)存儲(chǔ)的改進(jìn)做一個(gè)介紹
• 中臺(tái)支撐層：公司級(jí)中臺(tái)能力，用來(lái)支撐整個(gè)系統(tǒng)的基礎(chǔ)能力，包括房源、客源、人力中臺(tái)等

3.2 微服務(wù)落地

關(guān)于微服務(wù)的理念，本文不再詳情的描述，近些年來(lái)微服務(wù)已經(jīng)是炙手可熱的話題了，相比傳統(tǒng)單體架構(gòu)，程序的組件是相互依賴的，二不是松散耦合。對(duì)微服務(wù)架構(gòu)而言，每個(gè)模塊都是獨(dú)立的，可以在不影響其他模塊的情況下對(duì)單獨(dú)的模塊進(jìn)行修改，避免了大單體帶來(lái)的影響，如下圖所示。

3.0架構(gòu)里的平臺(tái)服務(wù)層，就是小程序平臺(tái)具體的微服務(wù)落地場(chǎng)景了，進(jìn)入到3.0時(shí)代，貝殼小程序已經(jīng)不僅僅只是微信小程序了，百度小程序、快手小程序、快應(yīng)用、QB小程序也先后加入到了小程序平臺(tái)的行列里，之前多端小程序的處理方式基本上就是在各個(gè)函數(shù)里做兼容，代碼越發(fā)的臃腫，更為可怕的是開(kāi)發(fā)和測(cè)試過(guò)程要覆蓋的場(chǎng)景也是越來(lái)越多，不斷的在鞭策我們做出改變。

首先是把小程序生態(tài)內(nèi)特有的服務(wù)劃分出來(lái)，于是多端用戶體系和多端消息體系和小程序搜索服務(wù)成為第一批需要下沉的微服務(wù)，從之前的purist項(xiàng)目中拆分出來(lái)，每個(gè)微服務(wù)都擁有新的服務(wù)器和redis資源，相互隔離、邊界清晰。

當(dāng)然了，不僅僅只是做了領(lǐng)域邊界的拆分，更重要的是領(lǐng)域邊界拆分過(guò)程中的一些優(yōu)化和升級(jí)。例如在下沉多端用戶服務(wù)的同時(shí)，我們還做了小程序Token自動(dòng)化整合，原本針對(duì)每一個(gè)小程序都進(jìn)行了一次token刷新的開(kāi)發(fā)，這無(wú)形之中是在不停的浪費(fèi)開(kāi)發(fā)資源和效率，而這些小程序或者公眾的Token失效機(jī)制大同小異，于是我們?cè)诼涞囟喽擞脩粑⒎?wù)的同時(shí)，還進(jìn)行了token的管理自動(dòng)化，一旦有新的小程序或者公眾號(hào)引入的時(shí)候，只需要在appllo配置即可，避免了重復(fù)的開(kāi)發(fā)的同時(shí)還能更好的賦能業(yè)務(wù)。下圖是小程序Token自動(dòng)化刷新方案。

微信搜索服務(wù)是小程序平臺(tái)的另一個(gè)微服務(wù)，這個(gè)服務(wù)也是微信生態(tài)內(nèi)特有的，所以他是屬于平臺(tái)的另一個(gè)核心服務(wù)，早期的微信搜索做的比較簡(jiǎn)單，以貝殼房?jī)r(jià)服務(wù)為例，貝殼房?jī)r(jià)指數(shù)數(shù)據(jù)目前存儲(chǔ)于HIVE底表中，大數(shù)據(jù)工具的查詢效率往往是比較低的，不適合C端用戶直接查詢，這樣就導(dǎo)致了用戶微信內(nèi)搜索召回不了貝殼的服務(wù)數(shù)據(jù)，無(wú)疑是貝殼的損失。

這次微服務(wù)下沉的過(guò)程中，團(tuán)隊(duì)對(duì)微信搜索也做了優(yōu)化，我們打算對(duì)城市、城市+小區(qū)/樓盤(pán)、小區(qū)/樓盤(pán)/商圈，三個(gè)維度對(duì)微信的請(qǐng)求數(shù)據(jù)做了緩存預(yù)熱，但是小區(qū)、樓盤(pán)的數(shù)據(jù)量其實(shí)是非常大的，全量的預(yù)熱不太現(xiàn)實(shí)，所以我們采取了熱點(diǎn)詞的緩存預(yù)熱方案，首次搜索的時(shí)候以貝殼檢索熱詞預(yù)熱，落地微信請(qǐng)求后獲取微信熱詞服務(wù)，后續(xù)可以直接用微信的熱點(diǎn)詞來(lái)做緩存預(yù)熱，如下圖所示：

3.3 mysql大數(shù)據(jù)瓶頸優(yōu)化

小程序平臺(tái)業(yè)務(wù)數(shù)據(jù)也在劇增，不少核心表的數(shù)據(jù)量已經(jīng)過(guò)億，慢查詢、慢響應(yīng)越來(lái)越多。數(shù)據(jù)庫(kù)的優(yōu)化勢(shì)在必行，我們想到了分庫(kù)、分表等方案，還有一點(diǎn)非常重要的就是引入了新的工具TIDB。

為什么要選用TIDB呢？

這里首先要提一下，2020年TIDB已經(jīng)被越來(lái)越多的國(guó)人所知，它是云原生的分布式數(shù)據(jù)庫(kù)，存儲(chǔ)引擎是FaceBook開(kāi)源的高性能存儲(chǔ)引擎RocksDB，不僅支持OLTP也支持OLAP，更重要的是它高度兼容Mysql協(xié)議，也就是說(shuō)我們可以在不分表的基礎(chǔ)上，實(shí)現(xiàn)Mysql的彈性擴(kuò)容，極大的減小了我們的業(yè)務(wù)代碼變動(dòng)，此外TIDB支持靈活和彈性擴(kuò)展，數(shù)據(jù)按Region分片，有自帶的調(diào)度管理組件，同時(shí)TIDB還提供了TISpark這樣的OLTP工具，滿足了我們實(shí)時(shí)、準(zhǔn)確的大數(shù)據(jù)查詢服務(wù)。我們首先在SLA要求不超過(guò)99.99%的非核心業(yè)務(wù)場(chǎng)景率先做了遷移，平滑遷移的非常順利，后續(xù)我們又在一些新業(yè)務(wù)場(chǎng)景上使用了TIDB。

帶來(lái)的收益也是比較明顯的：

解決了單點(diǎn)問(wèn)題，架構(gòu)更加清晰，可維護(hù)性、可擴(kuò)展性也增強(qiáng)了。底層數(shù)據(jù)庫(kù)切換，應(yīng)用無(wú)感知，并且切換成本低。能夠滿足高性能OLTP的業(yè)務(wù)場(chǎng)景例如分享服務(wù)的實(shí)時(shí)的PV和UV計(jì)算，如果是通過(guò)傳統(tǒng)大數(shù)據(jù)方案，大多數(shù)只能滿足T+1的場(chǎng)景，而TIspark滿足了業(yè)務(wù)OLAP的需求。

3.4 系統(tǒng)穩(wěn)定性建設(shè)

系統(tǒng)穩(wěn)定性建設(shè)的原則包括了大系統(tǒng)小做、被依賴服務(wù)的穩(wěn)定性、用戶體驗(yàn)的容錯(cuò)性以及有非常強(qiáng)健的穩(wěn)定性處理方案等等。

系統(tǒng)穩(wěn)定性架構(gòu)設(shè)計(jì)的一大原則是大系統(tǒng)小做，怎么理解呢？舉個(gè)簡(jiǎn)單的例子，比如上述提到的用戶登錄服務(wù)，如果公司要求加入風(fēng)控邏輯，在沒(méi)有微服務(wù)拆分之前，這個(gè)邏輯是要涉及到整體發(fā)版的，然后就會(huì)把所有代碼都帶著發(fā)版了，但是這樣可能會(huì)造成用戶消息功能受影響，所以說(shuō)微服務(wù)的落地和系統(tǒng)穩(wěn)定性的建設(shè)就遙相呼應(yīng)了，把子服務(wù)拆開(kāi)，做獨(dú)立的服務(wù)。

二是被依賴服務(wù)的穩(wěn)定性就要求我們做的服務(wù)和平臺(tái)能夠讓所以業(yè)務(wù)方用的放心、用的可靠，強(qiáng)健的穩(wěn)定性處理方案就包括了一些及時(shí)止損和保護(hù)用戶體驗(yàn)的方案。所以首先，如何成為一個(gè)可靠的小程序平臺(tái)，是我們要做的重要的事情。

在2.0時(shí)代golang項(xiàng)目引入平臺(tái)，但它并不是真正意義上的網(wǎng)關(guān)，嚴(yán)格說(shuō)來(lái)，它只是做了業(yè)務(wù)透?jìng)? 因?yàn)椴](méi)有網(wǎng)關(guān)的實(shí)際能力，3.0后在網(wǎng)關(guān)層做了一些優(yōu)化，為了保證業(yè)務(wù)系統(tǒng)跑在平臺(tái)網(wǎng)關(guān)上更為安全和穩(wěn)定，團(tuán)隊(duì)在golang網(wǎng)關(guān)層引入了go-sentinel、API管理和路由管理，完成了核心的限流、熔斷功能，變成了真正意義上的網(wǎng)關(guān)層。相比傳統(tǒng)的計(jì)數(shù)器、令牌桶限流算法等，sentinel顯得更為強(qiáng)大，它是面向分布式服務(wù)架構(gòu)的輕量級(jí)流量控制，不僅能夠解決固定窗口算法流量激增超過(guò)臨界點(diǎn)的問(wèn)題，也解決了令牌桶漏出速率必須是固定參數(shù)的問(wèn)題，在保證平臺(tái)能夠有秒殺場(chǎng)景的支撐能力的同時(shí)，也有了更完備的實(shí)時(shí)監(jiān)控能力。

經(jīng)過(guò)平臺(tái)網(wǎng)關(guān)的請(qǐng)求，會(huì)在Header里帶上微信生態(tài)的用戶信息，例如open_id、union_id等等，屏蔽業(yè)務(wù)方和微信側(cè)的直接交互，在業(yè)務(wù)方快速接入小程序平臺(tái)的同時(shí)也避免了多業(yè)務(wù)方同時(shí)請(qǐng)求微信、百度或者快手等小程序帶來(lái)的接口失效等問(wèn)題。

上圖是小程序平臺(tái)網(wǎng)關(guān)的一些能力，有一些是還在建設(shè)中的，比如熔斷、降級(jí)方案，觸發(fā)到熔斷后如何做用戶體驗(yàn)更好的產(chǎn)品呢？或者說(shuō)如果做一個(gè)更為穩(wěn)定的系統(tǒng)呢？

上圖是我們的一個(gè)api降級(jí)方案，有一個(gè)降級(jí)中間件和降級(jí)服務(wù)來(lái)完成api降級(jí)策略，當(dāng)用戶請(qǐng)求的時(shí)候，即使是請(qǐng)求的服務(wù)異常觸發(fā)到了熔斷的策略，也能夠讓用戶無(wú)感，返回給前端上一次正確的請(qǐng)求結(jié)果，當(dāng)然了這個(gè)使用成本也是有的，因?yàn)檫@里的數(shù)據(jù)一致性就不能完全保證了，所以說(shuō)熔斷降級(jí)方案還要和具體的業(yè)務(wù)場(chǎng)景結(jié)合起來(lái)，千萬(wàn)不要為了降級(jí)而降級(jí)。

4 未來(lái)展望

1. 微服務(wù)領(lǐng)域的細(xì)化不難看出，我們?cè)谖⒎?wù)上只是簡(jiǎn)單的做了一些大模塊的拆分，其實(shí)大模塊內(nèi)的領(lǐng)域我們并沒(méi)有做精細(xì)化的劃分，這是未來(lái)我們要做的事情，我們更希望通過(guò)領(lǐng)域驅(qū)動(dòng)的模型來(lái)協(xié)助我們做更深入且合理的設(shè)計(jì)
2. 系統(tǒng)穩(wěn)定性建設(shè)-流量預(yù)警我們現(xiàn)在接入了很多監(jiān)控，服務(wù)異常、響應(yīng)時(shí)長(zhǎng)的監(jiān)控等等，不過(guò)還缺乏一些流量的監(jiān)控體系，例如流量環(huán)比劇增或者劇降等等，之前發(fā)生了不少的問(wèn)題都是由于沒(méi)有流量監(jiān)控導(dǎo)致問(wèn)題發(fā)生了很久之后才被人工發(fā)現(xiàn)，顯然代價(jià)是比較高的，流量預(yù)警能幫助我們更快的發(fā)現(xiàn)一些未知的問(wèn)題。
3. 更多核心服務(wù)能力的整合平臺(tái)化的道路漫長(zhǎng)而艱巨，我們也需要不停的成長(zhǎng)，相信未來(lái)一定能看到一個(gè)更為健康強(qiáng)壯的小程序平臺(tái)。

作者: 平臺(tái)小程序團(tuán)隊(duì)