導(dǎo)讀：集成開(kāi)放平臺(tái)采用的是混合云部署架構(gòu)，包含兩個(gè)大的組件，管理控制臺(tái)和引擎。管理控制臺(tái)是SaaS的，部署在公有云，按租戶隔離。引擎部署在客戶私有云。一套SaaS版的管理控制臺(tái)如何適配不同客戶的引擎，本文將介紹我們的最佳實(shí)踐。

一、背景

集成開(kāi)放平臺(tái)采用的是混合云部署架構(gòu)，包含兩個(gè)大的組件，管理控制臺(tái)和引擎。管理控制臺(tái)是SaaS的，部署在公有云，按租戶隔離。引擎部署在客戶私有云。由于業(yè)務(wù)、管理的差異，不同的客戶其本地引擎的版本也存在差異，甚至版本跨度會(huì)比較大。隨著客戶的增多，不同客戶的版本差異越來(lái)越大，云端一套管理控制臺(tái)如何兼容不同客戶的后端版本，挑戰(zhàn)也越來(lái)越大。下面通過(guò)一個(gè)例子來(lái)闡述這些問(wèn)題。

二、問(wèn)題

客戶A的租戶環(huán)境是我們19年部署的一套環(huán)境，客戶B是我們另外一家客戶。A客戶的訴求是只需要保持穩(wěn)定就可以了，不需要對(duì)他們的環(huán)境做任何的升級(jí)，B客戶的訴求是我們的產(chǎn)品必須要不斷升級(jí)去滿足他們的需求。那么基于這種現(xiàn)狀，我們給客戶A在他們的服務(wù)器部署一套后端引擎，在客戶B的服務(wù)器上也給他們部署了一套后端引擎。基于客戶A的訴求客戶A的引擎版本可能一直穩(wěn)定在2.0版本，但是基于客戶B的訴求，我們需要給客戶B進(jìn)行產(chǎn)品升級(jí)，那么經(jīng)過(guò)一段時(shí)間的迭代客戶B的后端引擎版本可能已經(jīng)升級(jí)到了3.4.x.x了。但是這些客戶卻公用一套web端部署在公有云上。一套web端頁(yè)面對(duì)應(yīng)多個(gè)后端引擎造成的問(wèn)題就是客戶A進(jìn)入web端頁(yè)面之后有各種報(bào)錯(cuò)，因?yàn)閣eb頁(yè)面中很多的新的接口在客戶A的引擎中不存在。為了解決這一個(gè)問(wèn)題我們有2種方案。

三、解決方案

方案一：組件緯度加版本控制

通過(guò)在前端頁(yè)面的邏輯中判斷當(dāng)前引擎的版本號(hào)，來(lái)決定是否要請(qǐng)求某一個(gè)接口、顯示某一個(gè)模塊，用新的數(shù)據(jù)結(jié)構(gòu)還是老的數(shù)據(jù)結(jié)構(gòu)：

?優(yōu)點(diǎn)：1、可以公用部分組件以及部分頁(yè)面邏輯；

? ? ? ? ? ? 2、是最快速最直接的響應(yīng)需求的方式；

?缺點(diǎn)：1、因?yàn)閷懥撕芏嗉嫒葸壿嫊?huì)導(dǎo)致項(xiàng)目體積過(guò)大，影響打包速度；

? ? ? ? ? ? 2、引用的三方庫(kù)的升級(jí)對(duì)歷史版本可能會(huì)有影響；

? ? ? ? ? ? 3、公用組件的升級(jí)需要考慮對(duì)歷史版本的數(shù)據(jù)結(jié)構(gòu)的兼容，增加組件的復(fù)雜度，后期可能會(huì)更加難以維護(hù)

方案二：對(duì)不同版本的前端資源進(jìn)行物理隔離

我們把云端控制臺(tái)分為三部分console、ipass-console、mipconsole：

console是我們?cè)贫丝刂婆_(tái)網(wǎng)關(guān)主要是做身份驗(yàn)證、租戶管理等功能，租戶管理模塊維護(hù)了各租戶的引擎地址，主要把各租戶的管理控制臺(tái)(mipconsole)來(lái)的請(qǐng)求轉(zhuǎn)發(fā)到該租戶所對(duì)應(yīng)的服務(wù)端引擎。

ipass-console主要包含登錄、租戶管理等模塊。從ipass-console租戶管理模塊的頁(yè)面可以進(jìn)入不同租戶的管理控制臺(tái)。

mipconsole是各租戶管理控制臺(tái)頁(yè)面。包含接口中心、事件中心、服務(wù)編排、數(shù)據(jù)集成、儀表盤等功能。

ipass-console發(fā)送請(qǐng)求到console控制臺(tái)網(wǎng)關(guān)，網(wǎng)關(guān)會(huì)直接操作console控制臺(tái)的數(shù)據(jù)庫(kù)，由于各租戶的服務(wù)端引擎是私有化部署部署在客戶自己的服務(wù)器上，所以不同租戶的引擎地址不一樣，mipconsole發(fā)送請(qǐng)求到console控制臺(tái)網(wǎng)關(guān)，網(wǎng)關(guān)會(huì)把該請(qǐng)求轉(zhuǎn)發(fā)到租戶的服務(wù)端引擎，引擎接收到請(qǐng)求會(huì)操作引擎端數(shù)據(jù)庫(kù)。由于ipass-console不需要跟后端引擎做關(guān)聯(lián)的所以不需要做版本區(qū)分。但是mipconsole是各租戶的管理控制臺(tái)的功能。那么mipconsole是如何做到對(duì)各個(gè)租戶的管理控制臺(tái)的web端資源做到物理隔離的呢？答案是通過(guò)git的分支來(lái)做到對(duì)不同租戶的web端資源來(lái)進(jìn)行物理隔離。

下面我們結(jié)合上面我們的問(wèn)題來(lái)進(jìn)行闡述：

1、web端各版本資源的物理隔離：

我們?nèi)绾瓮ㄟ^(guò)git分支來(lái)做不同的租戶之間web端資源的完全隔離呢？首先我們把客戶A的租戶的前端資源當(dāng)作一個(gè)基線分支，基于這個(gè)基線分支切出一個(gè)開(kāi)發(fā)分支，在這個(gè)開(kāi)發(fā)分支上開(kāi)發(fā)客戶B的新需求，當(dāng)?shù)谝慌男枨箝_(kāi)發(fā)完成并且測(cè)試驗(yàn)收通過(guò)之后，我們會(huì)基于這個(gè)開(kāi)發(fā)分支打一個(gè)tag，并且把開(kāi)發(fā)分支合回基線分支，在基線分支編譯出一個(gè)正式靜態(tài)資源包放在我們主工程ipass-console的web目錄下。下次在有新的需求時(shí)在基于最新的基線分支切出開(kāi)發(fā)分支，重復(fù)上述過(guò)程。

如果后期在迭代過(guò)程中發(fā)現(xiàn)之前某一個(gè)版本有bug，那么我們會(huì)基于那個(gè)版本的最新的tag切出一個(gè)hotfix分支修復(fù)該bug，修復(fù)完成并測(cè)試通過(guò)之后基于當(dāng)前的hotfix分支生成一個(gè)新的tag，同時(shí)基于當(dāng)前的分支編譯生成一個(gè)新的靜態(tài)資源包替換之前老的資源包。bug的修改不會(huì)新增靜態(tài)資源包，只有無(wú)法兼容的新需求（需要寫版本判斷的這種）才會(huì)新增一個(gè)靜態(tài)資源包。這就是mipconsole各個(gè)租戶管理控制臺(tái)的前端資源的物理隔離方案。

2、web端各版本資源的加載、解析：

console是我們?cè)贫丝刂婆_(tái)網(wǎng)關(guān)，因?yàn)椴煌淖鈶粢娴刂凡灰粯?#xff0c;所以前端無(wú)法直接訪問(wèn)引擎地址，所以前端會(huì)先發(fā)請(qǐng)求云端控制臺(tái)網(wǎng)關(guān) ，網(wǎng)關(guān)在把請(qǐng)求轉(zhuǎn)發(fā)到相應(yīng)租戶的引擎服務(wù)去。在項(xiàng)目初始化的時(shí)候console會(huì)去遍歷主工程（ipass-console）下的web目錄下資源目錄的文件夾名稱生成一個(gè)前端靜態(tài)資源目錄與后端引擎版本號(hào)的一個(gè)映射文件，緩存在內(nèi)存中。當(dāng)console接收到前端的請(qǐng)求地址是以/cloud/ 開(kāi)頭的就會(huì)根據(jù)請(qǐng)求的參數(shù)租戶corp_id和環(huán)境env_id去數(shù)據(jù)庫(kù)里查詢當(dāng)前環(huán)境所對(duì)應(yīng)的引擎版本號(hào)，然后通過(guò)引擎的版本號(hào)去映射文件里面匹配到前端的靜態(tài)資源的文件夾名稱，把匹配到的靜態(tài)資源文件下的index.html返回給瀏覽器，瀏覽器下載了index.html后js會(huì)自動(dòng)解析并導(dǎo)航到對(duì)應(yīng)頁(yè)面。這樣進(jìn)入某一個(gè)的租戶的管理控制臺(tái)之后瀏覽器只會(huì)加載某一個(gè)版本的前端靜態(tài)資源。

以下是我們的項(xiàng)目工程目錄：

1、 資源工程的各個(gè)版本的分支，如下圖：

2、主工程、各個(gè)版本靜態(tài)資源包以及各個(gè)靜態(tài)資源包所對(duì)應(yīng)的后端引擎版本號(hào)，如下圖：

V3.1.0.0 、V3.2.0.0代表的是前端資源的版本號(hào)，minVersion 代表后端引擎的最小版本號(hào)。如果當(dāng)前后端引擎的版本號(hào)3.1.1.1 大于等于3.1.0.0小于3.1.22.0則對(duì)應(yīng)加載3.1.0.0版本的前端資源。前端版本資源與后端版本資源是一對(duì)多的關(guān)系，以實(shí)際的正式發(fā)版時(shí)的后端版本號(hào)做為前端匹配的最小版本號(hào)。

3、各個(gè)版本資源包所對(duì)應(yīng)的tag號(hào)，如下圖：

四、總結(jié)

針對(duì)多租戶的前端工程管理的方案困擾了我們很久，市面上也沒(méi)有我們這種業(yè)務(wù)場(chǎng)景所以我們也沒(méi)有可以參考的標(biāo)準(zhǔn)解決方案，我們一直在思考尋找最適合我們的解決方案，在這期間我們發(fā)現(xiàn)現(xiàn)在比較流行的微前端的思想或許可以解決我們的問(wèn)題，但是當(dāng)我們?nèi)ヮA(yù)研這些流行的微前端框架single-spa、qiankun等發(fā)現(xiàn)都不太適合我們的業(yè)務(wù)場(chǎng)景，于是我們基于這些思想預(yù)研出了最適合我們自己業(yè)務(wù)場(chǎng)景的方案。在我們的工作中對(duì)于一些比較好技術(shù)和框架我們不能生搬硬套，而是要基于我們實(shí)際的業(yè)務(wù)場(chǎng)景來(lái)考慮是否適合我們，我們可以借鑒別人好的思想來(lái)形成我們自己的技術(shù)方案和技術(shù)體系。

------ END ------

作者簡(jiǎn)介

郭同學(xué)：?前端工程師，目前負(fù)責(zé)集成開(kāi)放平臺(tái)的研發(fā)工作。

也許您還想看：

技術(shù)分享｜Java SDK動(dòng)態(tài)數(shù)據(jù)源和上下文機(jī)制

技術(shù)分享｜NodeJS分布式鏈路追蹤實(shí)現(xiàn)

技術(shù)分享 | Java SDK 元數(shù)據(jù)驅(qū)動(dòng)的事件通信架構(gòu)

技術(shù)分享｜Hangfire深度實(shí)踐

技術(shù)分享 | APT結(jié)合JavaPoet生成模板化Java源代碼文件

技術(shù)分享 | 玩轉(zhuǎn)高效UI自動(dòng)化測(cè)試

更多明源云·天際開(kāi)放平臺(tái)場(chǎng)景案例與開(kāi)發(fā)小知識(shí)，可以關(guān)注明源云天際開(kāi)發(fā)者社區(qū)公眾號(hào)：

【建模】文檔服務(wù)提供高保真打印模式

明源云·天際硬核技術(shù)認(rèn)可：獲華為鯤鵬技術(shù)認(rèn)證書(shū)

天際·開(kāi)發(fā)者社區(qū)“重裝發(fā)布”！

總結(jié)

以上是生活随笔為你收集整理的技术分享 | 混合云模式下SaaS端前端最佳实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。