微信小程序雲端解決方案探索之路 - GITC 主題演講

轉自：https://github.com/tencentyun/blog/issues/1

 

在剛結束的全球互聯網技術大會（GITC）裏面，我在前端專場給你們分享了「微信小程序雲端解決方案探索之路」，介紹到了咱們以前對小程序雲端解決方案的探索過程。

小程序特性思考

小程序剛推出的時候，不少人都以爲它就是 H5，由於開發小程序的三大語言和 HTML、CSS、JS 是一脈相承的，即便改變了擴展名也改不了其實質。

那麼小程序的實質究竟是不是 H5 呢？通過咱們的論證分析，咱們認爲小程序並非 H5 應用。主要緣由以下：

1. 在小程序裏面沒法使用 DOM 接口，因此 HTML5 生態中一切基於 DOM 的庫都沒法使用（如 jQuery）
2. 小程序並不是使用 URL 訪問，因此沒有域名的概念。這個特性有兩個影響
   • 不存在跨域問題，因此訪問控制是直接在微信 MP 上配置域名白名單
   • 不支持 Cookie 存儲，這將致使後面咱們重點研究了會話管理的實現

從上面兩個角度來考慮，咱們認爲小程序更偏向於傳統的 CS 架構。

那麼，小程序和傳統 CS 架構的區別在哪兒？主要包括下面兩點：

1. 網絡和續航
   小程序在移動端運行，網絡環境會比較複雜，頻繁的網絡鏈接可能會過分消耗資源致使續航降低，因此小程序對網絡和資源的優化都提出了要求。
2. 伸縮能力
   小程序寄託在微信平臺上運行，做爲一個十億級的社交平臺，業務可能會面臨爆炸式的增加。若是在爆點小程序不能快速伸縮應對，那麼將失去這樣一個重要的機會。因此小程序對其後臺架構的伸縮能力提出了比較高的要求。

門檻和挑戰

在上面一些結論下，咱們進行了一些嘗試，包括上傳下載、會話管理、WebSocket、視頻點播等等。此次重點來分享會話管理和 WebSocket，由於咱們面臨的挑戰主要集中在這兩個案例上。

會話管理

咱們最先開發了一個一筆到底的案例來實現會話管理，案例須要根據用戶保存用戶的做品，每次用戶登陸，均可以看到用戶本身的繪畫。

可是，由於小程序不支持 Cookie 傳輸，因此會話服務須要自行實現。

咱們會話管理的實現目標是：

1. 完成微信要求的鑑權流程，生成用戶會話
2. 利用會話肯定每一個請求對應哪一個微信用戶
3. 安全性和擴展性知足要求

咱們案例按照這個流程進行會話創建：

其中在小程序和服務器咱們分別提供 JS 和 Node SDK 來提供會話支持。這個案例完成了會話服務的功能性目標，能夠提供會話創建和驗證的能力。可是弊端在於，該能力只能被 Node 開發者使用，其餘語言的開發者沒法使用。同時，由於小程序的 appId 和 appSecret 存放在外網能夠訪問的服務器上，也有必定安全性問題。會話服務和咱們的業務耦合在一塊兒，也給後續的橫向擴展帶來了麻煩。

因而，咱們提出了改進的手段：

1. 會話管理服務器獨立提供
2. 提供多語言的 SDK
3. appId 和 appSecret 存放到數據庫中

其中多語言的 SDK 正式由於會話管理服務器的獨立而能夠快速開發到。

優化後，會話的創建流程以下圖所示：

而會話的驗證流程以下圖所示：

咱們的會話服務改進取得的效果仍是很明顯的：

1. 流程和安全性上徹底符合了微信的鑑權要求
2. 獨立會話服務器，能夠方便進行獨立的升級和擴展，也爲多語言 SDK 的開發打開了方便的大門

信道服務

咱們面臨的另一個挑戰就是 WebSocket。在進行案例分析以前，先跟你們分析一下微信支持 WebSocket 的緣由。

傳統的 HTTPS 鏈接請求，每一個請求都須要創建一次鏈接，耗費比較多的資源。同時微信有最大鏈接數的限制（5個），因此實時通訊的需求很差作，長鏈接的方案也只能串行傳輸，這種方案耗電高體驗差。

當咱們把目光轉向 WebSocket 以後，會發現 WebSocket 通訊全程只須要創建一次鏈接，就能夠實現雙向的實時通訊，更省電的狀況下得到更好的體驗。

這就是小程序支持 WebSocket 的一個重要緣由，能夠提升業務的體驗並增長續航。

鑑於不少同窗可能對 WebSocket 還不瞭解，這裏簡單介紹一下。

咱們的 HTTP 鏈接是在 TCP 的基礎上創建的，當服務器支持 WebSocket 的時候，能夠相應一個頭部，告知客戶端進行協議升級。升級協議後，會複用以前的 TCP 鏈接，在上面實現 WebSocket 協議實現雙向通訊。更加詳細的資料能夠參考 MDN 上的說明。

回到咱們的案例上來，咱們當時使用小程序提供的 WebSocket 作了一個實時的剪刀石頭布遊戲。

咱們使用 Socket.IO 實現其後端後，發如今小程序沒法使用 Socket.IO 的客戶端代碼支持。咱們只能本身去啃了一下 Socket.IO 的上層協議，實現了一個簡版的客戶端，從而實現剪刀石頭布這個遊戲邏輯。

這個案例驗證了在小程序上面 WebSocket 的可行性，可是因爲客戶端的實現是自行實現，和 Socket.IO 的後端配合可能會出現不可控的狀況。同時，咱們發現 WebSocket 的後端實現門檻比較高，而且進行橫向擴展的話會更加困難。

做爲雲服務廠商，咱們首先想到的方案是使用 PaaS 提供服務來支持 WebSocket 鏈接。這是怎麼一個思路呢？

上圖很好地解釋了 PaaS 形式和傳統 WebSocket 形式的不一樣之處，PaaS 其實是要實現一個三方通訊。

咱們看一下使用 PaaS 服務來創建 WebSocket 鏈接的過程：

創建鏈接後，小程序和業務服務器之間能夠經過下面的形式進行通訊：

通過 PaaS 的改造，咱們獲得了一個新的 WebSocket 方案。該方案的優劣在哪裏？

首先，優點比較明顯，由平臺來提供的服務，由平臺本身完成擴展能力的支持以及穩定性和性能的保障，業務無需擔憂。同時，業務也無需關心 WebSocket 協議的實現，由於業務服務器和信道服務以前的通訊都是傳統的 HTTP，這樣也能夠節約業務服務器的長鏈接資源。

可是這種方案也有它的侷限之處。業務服務器和信道服務器之間採起公網通訊，處於對信息安全的考慮，最好仍是走 HTTPS 通訊，這個過程的通訊延遲比較客觀。其次，三方通訊的調試便利性也不如傳統的鏈接方式。

對於上面兩個問題，其實咱們也有對應方案。若是業務服務器在騰訊雲機房運行，那麼可讓業務服務器和信道服務器之間經過內網 HTTP 傳輸，延遲大大下降。信道服務後續也會提供調試日誌供你們分析發現問題。

整體來講，PaaS 方案會幫助更多開發者解決掉了門檻較高的部分。

整合

咱們上面對於會話服務和信道服務都進行了一個有益的實踐，那麼這兩個服務是否能夠整合，信道服務裏面是否能夠支持會話識別？

事實上咱們能夠作這個事情。下面的表格描述了會話服務和信道服務與服務模塊之間的關係。

咱們能夠把客戶端的部分整合爲客戶端 SDK，把業務服務器的部分整合爲服務器 SDK，而且提供會話服務器的源碼開源。

那麼上面三個部分加起來，就是目前騰訊雲的開源項目 - Wafer。

Wafer 包含了會話服務和信道服務的支持，從全棧模塊來提供開源的資源，而且提供了豐富的文檔。有興趣的開發者可使用上面的鏈接來查看 Wafer 項目。

產品化實踐

Wafer 幫開發者解決了小程序開發過程當中信道服務和會話服務的門檻問題，可是做爲小程序開發者，還要關心後臺架構、資源採供、資源部署、擴展能力、安全性、域名申請等等與業務開發無關的部分。這部分，咱們提出了一個一站式部署的方案。

這個方案，會幫你分配好資源並自動部署下面的架構，讓開發者能夠專一於業務開發。

自動部署的過程其實挺複雜的，有興趣的同窗能夠參考下圖瞭解。

上面就是 Wafer 的產品化實踐 - 騰訊雲小程序一站式解決方案