小程序模板網(wǎng)

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

發(fā)布時間:2018-05-02 15:59 所屬欄目:小程序開發(fā)教程

在剛結(jié)束的 全球互聯(lián)網(wǎng)技術(shù)大會(GITC) 里面,我在前端專場給大家分享了「微信小程序云端解決方案探索之路」,介紹到了我們之前對小程序云端解決方案的探索過程。

小程序特性思考

小程序剛推出的時候,很多人都覺得它就是 H5,因為開發(fā)小程序的三大語言和 HTML、CSS、JS 是一脈相承的,即使改變了擴展名也改不了其實質(zhì)。

那么小程序的實質(zhì)到底是不是 H5 呢?經(jīng)過我們的論證分析,我們認為 小程序并不是 H5 應(yīng)用 。主要原因如下:

  1. 在小程序里面無法使用 DOM 接口,所以 HTML5 生態(tài)中一切基于 DOM 的庫都無法使用(如 jQuery)
  2. 小程序并非使用 URL 訪問,所以沒有域名的概念。這個特性有兩個影響
    • 不存在跨域問題,所以訪問控制是直接在微信 MP 上配置域名白名單
    • 不支持 Cookie 存儲,這將導(dǎo)致后面我們重點研究了會話管理的實現(xiàn)

從上面兩個角度來考慮,我們認為 小程序更偏向于傳統(tǒng)的 CS 架構(gòu) 。

那么,小程序和傳統(tǒng) CS 架構(gòu)的區(qū)別在哪兒?主要包括下面兩點:

  1. 網(wǎng)絡(luò)和續(xù)航 小程序在移動端運行,網(wǎng)絡(luò)環(huán)境會比較復(fù)雜,頻繁的網(wǎng)絡(luò)連接可能會過度消耗資源導(dǎo)致續(xù)航下降,所以小程序?qū)W(wǎng)絡(luò)和資源的優(yōu)化都提出了要求。
  2. 伸縮能力

小程序寄托在微信平臺上運行,作為一個十億級的社交平臺,業(yè)務(wù)可能會面臨爆炸式的增長。如果在爆點小程序不能快速伸縮應(yīng)對,那么將失去這樣一個重要的機會。所以小程序?qū)ζ浜笈_架構(gòu)的伸縮能力提出了比較高的要求。

門檻和挑戰(zhàn)

在上面一些結(jié)論下,我們進行了一些嘗試,包括上傳下載、會話管理、WebSocket、視頻點播等等。這次重點來分享會話管理和 WebSocket,因為我們面臨的挑戰(zhàn)主要集中在這兩個案例上。

會話管理 <a name="session"></a>

我們最早開發(fā)了一個 一筆到底 的案例來實現(xiàn)會話管理,案例需要根據(jù)用戶保存用戶的作品,每次用戶登錄,都可以看到用戶自己的繪畫。

但是,因為小程序不支持 Cookie 傳輸,所以會話服務(wù)需要自行實現(xiàn)。

我們會話管理的實現(xiàn)目標(biāo)是:

  1. 完成微信要求的鑒權(quán)流程,生成用戶會話
  2. 利用會話確定每個請求對應(yīng)哪個微信用戶
  3. 安全性和擴展性滿足要求

我們案例按照這個流程進行會話建立:

會話建立流程

其中在小程序和服務(wù)器我們分別提供 JS 和 Node SDK 來提供會話支持。這個案例完成了會話服務(wù)的功能性目標(biāo),可以提供會話建立和驗證的能力。但是弊端在于,該能力只能被 Node 開發(fā)者使用,其他語言的開發(fā)者無法使用。同時,因為小程序的 appId 和 appSecret 存放在外網(wǎng)可以訪問的服務(wù)器上,也有一定安全性問題。會話服務(wù)和我們的業(yè)務(wù)耦合在一起,也給后續(xù)的橫向擴展帶來了麻煩。

于是,我們提出了改進的手段:

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

其中多語言的 SDK 正式因為會話管理服務(wù)器的獨立而可以快速開發(fā)到。

優(yōu)化后,會話的建立流程如下圖所示:

會話建立流程

而會話的驗證流程如下圖所示:

會話檢查流程

我們的會話服務(wù)改進取得的效果還是很明顯的:

  1. 流程和安全性上完全符合了微信的鑒權(quán)要求
  2. 獨立會話服務(wù)器,可以方便進行獨立的升級和擴展,也為多語言 SDK 的開發(fā)打開了方便的大門

信道服務(wù) <a name="tunnel"></a>

我們面臨的另外一個挑戰(zhàn)就是 WebSocket。在進行案例分析之前,先跟大家分析一下微信支持 WebSocket 的原因。

傳統(tǒng)的 HTTPS 連接請求,每個請求都需要建立一次連接,耗費比較多的資源。同時微信有最大連接數(shù)的限制(5個),所以實時通信的需求不好做,長連接的方案也只能串行傳輸,這種方案耗電高體驗差。

當(dāng)我們把目光轉(zhuǎn)向 WebSocket 之后,會發(fā)現(xiàn) WebSocket 通信全程只需要建立一次連接,就可以實現(xiàn)雙向的實時通信,更省電的情況下獲得更好的體驗。

這就是小程序支持 WebSocket 的一個重要原因,可以提高業(yè)務(wù)的體驗并增加續(xù)航。

鑒于很多同學(xué)可能對 WebSocket 還不了解,這里簡單介紹一下。

WebSocket 示意圖

我們的 HTTP 連接是在 TCP 的基礎(chǔ)上建立的,當(dāng)服務(wù)器支持 WebSocket 的時候,可以相應(yīng)一個頭部,告知客戶端進行協(xié)議升級。升級協(xié)議后,會復(fù)用之前的 TCP 連接,在上面實現(xiàn) WebSocket 協(xié)議實現(xiàn)雙向通信。更加詳細的資料可以參考 MDN 上的說明。

回到我們的案例上來,我們當(dāng)時使用小程序提供的 WebSocket 做了一個實時的 剪刀石頭布 游戲。

游戲截圖

我們使用 Socket.IO 實現(xiàn)其后端后,發(fā)現(xiàn)在小程序無法使用 Socket.IO 的客戶端代碼支持。我們只能自己去啃了一下 Socket.IO 的上層協(xié)議,實現(xiàn)了一個簡版的客戶端,從而實現(xiàn)剪刀石頭布這個游戲邏輯。

這個案例驗證了在小程序上面 WebSocket 的可行性,但是由于客戶端的實現(xiàn)是自行實現(xiàn),和 Socket.IO 的后端配合可能會出現(xiàn)不可控的情況。同時,我們發(fā)現(xiàn) WebSocket 的后端實現(xiàn)門檻比較高,并且進行橫向擴展的話會更加困難。

作為云服務(wù)廠商,我們首先想到的方案是使用 PaaS 提供服務(wù)來支持 WebSocket 連接。這是怎么一個思路呢?

PaaS 服務(wù)支持 WebSocket

上圖很好地解釋了 PaaS 形式和傳統(tǒng) WebSocket 形式的不同之處,PaaS 實際上是要實現(xiàn)一個三方通信。

我們看一下使用 PaaS 服務(wù)來建立 WebSocket 連接的過程:

建立 WS 連接

建立連接后,小程序和業(yè)務(wù)服務(wù)器之間可以通過下面的形式進行通信:

WS 通信

經(jīng)過 PaaS 的改造,我們得到了一個新的 WebSocket 方案。該方案的優(yōu)劣在哪里?

首先,優(yōu)勢比較明顯,由平臺來提供的服務(wù),由平臺自己完成擴展能力的支持以及穩(wěn)定性和性能的保障,業(yè)務(wù)無需擔(dān)心。同時,業(yè)務(wù)也無需關(guān)心 WebSocket 協(xié)議的實現(xiàn),因為業(yè)務(wù)服務(wù)器和信道服務(wù)之前的通信都是傳統(tǒng)的 HTTP,這樣也可以節(jié)約業(yè)務(wù)服務(wù)器的長連接資源。

但是這種方案也有它的局限之處。業(yè)務(wù)服務(wù)器和信道服務(wù)器之間采取公網(wǎng)通信,處于對信息安全的考慮,最好還是走 HTTPS 通信,這個過程的通信延遲比較客觀。其次,三方通信的調(diào)試便利性也不如傳統(tǒng)的連接方式。

對于上面兩個問題,其實我們也有對應(yīng)方案。如果業(yè)務(wù)服務(wù)器在騰訊云機房運行,那么可以讓業(yè)務(wù)服務(wù)器和信道服務(wù)器之間通過內(nèi)網(wǎng) HTTP 傳輸,延遲大大降低。信道服務(wù)后續(xù)也會提供調(diào)試日志供大家分析發(fā)現(xiàn)問題。

總體來說,PaaS 方案會幫助更多開發(fā)者解決掉了門檻較高的部分。

整合

我們上面對于會話服務(wù)和信道服務(wù)都進行了一個有益的實踐,那么這兩個服務(wù)是否可以整合,信道服務(wù)里面是否可以支持會話識別?

事實上我們可以做這個事情。下面的表格描述了會話服務(wù)和信道服務(wù)與服務(wù)模塊之間的關(guān)系。

服務(wù)與模塊關(guān)系

我們可以把客戶端的部分整合為客戶端 SDK,把業(yè)務(wù)服務(wù)器的部分整合為服務(wù)器 SDK,并且提供會話服務(wù)器的源碼開源。

那么上面三個部分加起來,就是目前騰訊云的開源項目 - Wafer 。

Wafer 包含了會話服務(wù)和信道服務(wù)的支持,從全棧模塊來提供開源的資源,并且提供了豐富的文檔。有興趣的開發(fā)者可以使用上面的連接來查看 Wafer 項目。

產(chǎn)品化實踐


Wafer 定位

Wafer 幫開發(fā)者解決了小程序開發(fā)過程中信道服務(wù)和會話服務(wù)的門檻問題,但是作為小程序開發(fā)者,還要關(guān)心后臺架構(gòu)、資源采供、資源部署、擴展能力、安全性、域名申請等等與業(yè)務(wù)開發(fā)無關(guān)的部分。這部分,我們提出了一個一站式部署的方案。

一站式部署

這個方案,會幫你分配好資源并自動部署下面的架構(gòu),讓開發(fā)者可以專注于業(yè)務(wù)開發(fā)。

整體架構(gòu)

自動部署的過程其實挺復(fù)雜的,有興趣的同學(xué)可以參考下圖了解。

 

 

QR Code

總結(jié)

從 16 年 9 月份開始,團隊開始接觸微信小程序,對它的一個特性進行了思考和驗證。在后面案例開發(fā)的過程中,碰到了會話服務(wù)和信道服務(wù)的兩個門檻,
不斷優(yōu)化,最終整合成了開源項目 Wafer 及其 產(chǎn)品化方案 ,希望這些方案可以對小程序開發(fā)者提供幫助。


易優(yōu)小程序(企業(yè)版)+靈活api+前后代碼開源 碼云倉庫:starfork
本文地址:http://22321a.com/wxmini/doc/course/24185.html 復(fù)制鏈接 如需定制請聯(lián)系易優(yōu)客服咨詢:800182392 點擊咨詢
QQ在線咨詢