藉助雲開發 CloudBase 平臺打造第三方應用開發框架

導語

騰訊樂享，是騰訊推出的一站式企業社區，提供在線課堂、考試、學習地圖、直播、文檔、問卷調研等多項應用服務。

騰訊樂享從0開始對接企業微信開放平臺能力，做爲企業微信第三方應用上線已經4年了。現在騰訊樂享也要成爲服務方容許其餘 Saas 產品以第三方應用身份接入，那曾積累的經驗該如何傳授給即將接入應用的開發者呢？

騰訊樂享第三方應用開放平臺已經上線一段時間了，第一期接入的應用包括珊瑚積分、騰訊問卷、製做雲，這三個自己都已是成熟產品，也都有各自的開放接口，因此問題就在於如何把雙方平臺的開放接口鏈接起來實現打通。其中騰訊雲 iPaas 爲咱們對接珊瑚積分平臺與製做雲，騰訊問卷由雙方平臺一塊兒開發中轉站服務。

在這個過程當中，咱們發現了團隊內外的開發同事都在重複着對接樂享開放平臺的能力，且對接過程因爲你們的理解、實現不一致會遇到各類問題，那些年咱們對接企業微信踩過的坑正在蔓延。這時候公司內部各類推文都提到 CloudBase 雲開發，通過了解後發現這正適合用於搭建第三方應用開發框架，若是全部應用接入都使用統一框架，那不管開發效率、仍是後期維護都有極大的優點。

問題預研

一個第三方應用的接入，須要作什麼？

• 接受回調： 公司對應用的受權/取消受權通知、公司的通信錄變動通知、調用憑證的ticket推送等，都是由樂享服務方主動推送給應用方，須要應用方提供cgi來接收回調事件。尤爲ticket是換取接口調用憑證的重要字段，因此實現接收回調cgi是開始開發的第一步；
• 接口調用： 接口調用看似就是SDK能解決的問題，但saas的接口調用並無這麼簡單。接口有應用維度和企業維度，所需的憑證都不同，並且憑證不能頻繁獲取，須要緩存，企業憑證的緩存還受企業受權/取消受權事件影響，這些邏輯都是SDK不能知足的；
• 通信錄同步： 拉接口，寫 DB，彷佛有手就能寫好的業務邏輯，其實也是很考察開發者基本功的。同步過程是否平滑，同步腳本可否中斷重跑或續跑，髒數據如何清理等，沒有踩過足夠的坑就很容易遺漏這些細節；
• 登陸受權： 標準的 OAuth 協議接入，坑很少，但仍是涉及到身份校驗、受權跳轉、受權回調、token生成下發等一系列功能的開發，重複又沒挑戰的工做每每令人疲憊。

以上幾點提到的僅僅是對接開放平臺所須要作的，以 Web 應用的角度來看，除了須要選定一個服務端語言來開發，還要考慮總體架構，數據庫、緩存、對象存儲等基礎組件，劃分 VPC，部署應用等。所以，即使擁有再成熟的開放平臺，對不少開發團隊而言都是存在必定門檻的。而開發框架就是爲了下降這個門檻，吸引更多有想法的開發團隊簡單快速地實現本身的應用。在我最初的構想裏，開發者只須要實現應用自己的頁面和接口，無需關心這個應用是如何與樂享後臺交互的，藉助雲開發 CloudBase 的能力一鍵部署，就能成爲樂享的第三方應用，爲成千上萬個企業提供服務。而這個構想，如今也初具雛形了。

框架實現

一、數據庫

CloudBase 自帶非關係型數據庫，用法相似於 MongoDB，所以咱們能夠經過 cloudbaserc.json 配置爲應用初始化時建立以下數據表；

• companies： 公司表，用於記錄從樂享受權當前應用的公司信息，也是做爲saas應用必備的一個表。
• departments、users、department_user： 通信錄必備的三個表，記錄用戶與部門以及中間的關聯關係。這裏的 department_user 中間表其實非必須，由於 cloudbase 提供的是非關係型數據庫，每一個用戶的部門信息徹底能夠記錄在users表中，但最後的設計仍是像 MySQL 那樣建立了中間表，爲一個更遠的目標埋下小伏筆，後面會解釋。
• lx_suite_callback_logs： 記錄從樂享回調過來的日誌，方便定位問題；
• lx_suites： 主要用來記錄當前有效 ticket、應用訪問樂享接口的 token、各個企業訪問樂享接口的 token 等，其實至關於一個緩存使用，由於 CloudBase 目前尚未直接掛載 redis 的能力，所以先借用數據庫作緩存，因爲讀寫這個表的都是框架自帶的基礎雲函數，開發者無需關注，所以後續有更優雅的方案也能夠隨時升級改造。

其實這個開發框架的理念，最重要就是把面向樂享接口開發的模式，轉化成面向數據庫開發。常說 web 應用開發就是基於數據庫的增刪改查，這就是框架帶來的優點。

二、接收回調

框架實現了雲函數<span>base_suite_callback</span>，這個雲函數負責監聽ticket變動、企業開通/關閉應用的通知，數據會落到<span>companies</span>、<span>lx_suites</span>、<span>lx_suite_callback_logs</span>表中。這個雲函數也是整個框架最重要的入口，一旦不可服務或響應超時將會帶來嚴重的影響，所以也會作好實例預熱，避免因爲冷啓動而致使企業受權信息丟失。

三、接口調用

樂享平臺具備十多個應用模塊，擁有上百個應用接口和十多個通信錄接口，全部接口都封裝在<span>base_lx_apis</span>下，提供函數說明，讓開發者簡單地調用樂享的能力。

除了接口封裝外，雲函數還實現 access_token 的緩存、刷新機制，由於要使用到存儲服務，這是簡單 SDK 沒法知足的。

還須要特別關注的是樂享提供的接口受權模式是<span>client credentials</span>，適用於服務端對服務端請求，若是直接讓客戶請求接口，將會產生嚴重的漏洞，企業數據會遭到惡意篡改、泄漏等風險。利用 CloudBase 提供的雲函數權限設置，能夠禁止客戶端直接調用，客戶端必須先調用開發者的雲函數，經過服務端調用才能訪問，保證了應用的安全性。在框架的示例代碼中，也提供了代碼 demo 引導開發者正確使用。

四、通信錄同步

框架提供全量同步的雲函數<span>base_sync_contact</span>，可經過定時任務或客戶端調用觸發。

全量同步通信錄的過程，很容易因爲代碼邏輯、腳本中斷等緣由致使數據錯亂的問題。

在這裏我引入了通信錄版本的概念，每次同步，對於<span>deprtments</span>表和<span>department_user</span>表都只會追加數據，而不會修改數據，等全量同步結束，確保數據一致，纔會更新當前公司的通信錄版本，刪除表中其餘版本的數據，保證每一時刻的通信錄數據都是可用的。

五、登陸受權

身份校驗邏輯主要放在客戶端代碼 Vue 裏面，以路由中間件的形式判斷當前用戶登陸狀態的公司ID，若缺失或與 url 上的公司 ID 不符，則重定向到指定公司所在的樂享受權頁面。這些代碼邏輯都是樂享積累的寶貴經驗，開發者直接使用可避免各類B端登陸態錯亂的狀況。

六、效果體驗

基於以上基礎能力的封裝，要在這個框架上開發應用已經足夠簡單了。
咱們也嘗試開發一個第三方學習素材管理平臺，只須要3步：

（1）新建數據表；

（2）實現素材管理相關的雲函數邏輯，裏面會調用到<span>base_lx_apis</span>雲函數來調用樂享接口，也會使用到對象存儲的 API；

（3）Vue 裏面加入相關路由頁面。

這就跟開發任何的 Web 應用同樣，開發者不會由於不知道如何打通樂享而停步不前。學習成本從學習樂享接口、學習 Saas 應用開發轉嫁到學習 CloudBase 的使用上。

一鍵部署

一鍵部署是 CloudBase Framework 提供的能力，經過簡單的操做，代碼就能在雲開發環境跑起來了。但要樂享主動向雲開發環境回調事件，還須要在樂享這邊配置雲開發環境對應的接收回調 cgi；配置 cgi 後，還要先讓樂享推送 ticket 才能讓公司受權應用；登陸受權也涉及到可信回調域名配置；應用入口也須要配置連接。開發者要看着說明文檔，從雲開發複製連接到樂享頁面上一個個配置，而後每一個功能調試驗證以確保沒手抖複製錯，過程參考下圖：

爲了解決人工初始化配置的問題，針對這個場景，在樂享側提供了應用初始化配置的接口。雲開發環境能夠直接使用 suite_id+suite_secret 去初始化指定字段的配置，包括回調 cgi、登陸受權可信域名、入口地址，配置完成後還會觸發樂享主動向應用推送 ticket，以確保以後企業能直接受權使用。這個初始化接口的調用放到了 CloudBase 一鍵部署的 postDeploy 鉤子中，無需人工操做且確保配置成功才部署成功，大大下降了框架的使用門檻。

目前一鍵部署流程如圖所示：

整個一鍵部署流程也還有幾個環節能夠優化的；

並非必須到 github 上點擊一鍵部署，後續能夠直接把部署按鈕放在樂享的公司管理後臺，讓公開的開發者直接從樂享跳轉到騰訊雲進行部署配置。

基於第1點的優化，若是雲開發部署頁容許經過url或表單傳遞配置參數，那樂享側能夠直接帶上，省去開發者複製粘貼的功夫。

第四、5步下載自定義私鑰並注入雲函數中，目前雲開發還無法直接經過 cloudbaserc.json 去配置，後續能支持就更好了。

能力擴展

框架設計的初衷是爲了讓開發者快速從零開始搭建一個樂享第三方應用。但隨着實現過程的思考和理解，我認爲這個框架的使用場景不該侷限於此，它還應該服務於其餘成熟應用和平臺的對接。

有開放接口的應用或平臺之間對接，每每因爲接口不適配而陷入僵局，誰都不肯意修改本身的接口去適配對方。最後的解決辦法只能是其中一方讓步去從零搭建一箇中間服務，看着雙方的接口文檔去作開發。

若是樂享能提供這套框架，那框架又能提供什麼呢？

對外受權

上面說起的登陸受權，是指樂享對部署這個框架的服務（簡稱A服務）進行受權。但若是是兩個平臺對接，還須要A服務對第三方平臺受權。儘管開發者已經不須要實現服務A被受權登陸的過程了，但我以爲還能夠再作點什麼，讓二次開發更簡單，例如封裝好對外受權的 OAuth、smal 協議。

回調通知傳遞

樂享回調除了預先實現的邏輯外，保留可配置的hook，讓開發者配置自定義雲函數或者消息隊列。開發者經過雲函數或消息隊列再去處理的時候，就不須要擔憂消息是否僞造、是否過時、是否重放等問題。

數據直寫業務數據庫

框架已經實現了從樂享拉接口把通信錄數據寫入雲開發環境的數據庫中了，但對雲開發環境外的業務徹底沒有意義（即使 VPC 打通，離開了雲開發環境也沒有 SDK 去讀寫數據庫，本身實現也太難了）。因而框架應該具有從樂享拉接口把通信錄數據寫入指定數據庫中，並且不該該只支持 MongoDB 這樣的非關係型數據庫，也要支持最經常使用的 mysql，所以通信錄的表設計保留了<span>department_user</span>中間表。框架應容許配置 mysql 鏈接，讓數據能夠直寫業務數據庫。

私有化部署

做爲 Saas 產品，私有化部署是永恆的話題。產品自己要私有化就已經不容易，每每要考慮服務降級的手段來知足私有化，更不會考慮第三方應用這種可開可關的功能了。但若是是基於cloudbase開發的第三方應用，那企業一鍵部署帶走又何樂而不爲呢？

低代碼開發

若是說第三方應用開發框架是一個起步，那下一個目標可能就是低代碼開發平臺。不管採用哪一個方式開發，目前對每一個基礎能力的封裝都是必須的、可複用的，走出了第一步，才能爲下一個目標帶來可能性。

總結

從開發企業微信第三方應用，到開發開放平臺給第三方應用接入，身份替換給了我不少經驗。cloudbase 的出現正好讓我好好思考總結，把一些設計理念能實現出來，也歡迎你們與我一塊兒交流探討。

PS：從設計這個框架開始，我命名了這個項目爲「樂享再就業計劃」。想着哪天退休了，我就以樂享服務商的身份用這個框架爲樂享作各類外包項目。樂享永不退，作到八十歲。

附錄

Github代碼倉庫：

https://github.com/TencentLexiang/cloudbase-template

產品介紹

雲開發（Tencent CloudBase，TCB）是騰訊雲提供的雲原生一體化開發環境和工具平臺，爲開發者提供高可用、自動彈性擴縮的後端雲服務，包含計算、存儲、託管等 serverless 化能力，可用於雲端一體化開發多種端應用（小程序，公衆號，Web 應用，Flutter 客戶端等），幫助開發者統一構建和管理後端服務和雲資源，避免了應用開發過程當中繁瑣的服務器搭建及運維，開發者能夠專一於業務邏輯的實現，開發門檻更低，效率更高。
開通雲開發：https://console.cloud.tencent.com/tcb?tdl_anchor=techsite
產品文檔：https://cloud.tencent.com/product/tcb?from=12763
技術文檔：https://cloudbase.net?from=10004技術交流羣、最新資訊關注微信公衆號【騰訊雲開發CloudBase】