??

?

點(diǎn)擊關(guān)注“有贊coder”

獲取更多技術(shù)干貨哦～

作者：時文濤部門：電商移動

使用場景

作為移動開發(fā)的我們經(jīng)常會遇到兩種需求：

展示邏輯線上需要隨時變更，例如登錄注冊頁面用戶協(xié)議鏈接的變更

新業(yè)務(wù)的灰度下發(fā)，如訂單等核心業(yè)務(wù)的重構(gòu)，如何去保證灰度到指定的商家或適當(dāng)?shù)幕叶缺壤?#xff0c;在確保線上業(yè)務(wù)的穩(wěn)定性的情況下來進(jìn)行數(shù)據(jù)的灰度下發(fā)

現(xiàn)狀

為了解決以上問題，就需要App側(cè)具備一定的動態(tài)化能力。目前增強(qiáng)App端的動態(tài)性方式，通常來說有下面幾類：

Hybrid
這種方案是最常見的，Webview 中嵌套 H5 頁面，通過 JSBridge 來與原生頁面進(jìn)行交互，也是成本最低的方案，但是一般而言用戶的體驗(yàn)會比較差，比較依賴用戶的網(wǎng)絡(luò)環(huán)境，通常用于 App 內(nèi)展示頻率不高的頁面。

Weex、RN
使用 Weex 和 RN 應(yīng)該是現(xiàn)在電商 App 中使用較多的動態(tài)化框架，與原生相比，多了一層 JS 解析，渲染速度會比原生慢一點(diǎn)，但是在可接受的范圍內(nèi)，帶來的動態(tài)發(fā)版的優(yōu)勢是原生所不具備的優(yōu)勢，同時相對于 H5 而言渲染性能要好很多，在 App 中經(jīng)常會用于新業(yè)務(wù)中交互不復(fù)雜，對用戶體驗(yàn)要求不是特別高的場景。

Tangram
從實(shí)現(xiàn)方式看來，Tangram 的實(shí)現(xiàn)思路與 Weex 和 RN 十分相似，不同點(diǎn)只是 Weex 解析是使用 JS 解析成原生組件，Tangram 使用 Json 來解析成原生組件。

通過接口動態(tài)控制返回的數(shù)據(jù)
這種場景較為常見，但是有兩個較為明顯的缺點(diǎn)，第一點(diǎn)是不同的業(yè)務(wù)都需要新增接口來完成下發(fā)數(shù)據(jù)的控制，開發(fā)成本大，第二點(diǎn)是網(wǎng)絡(luò)請求是個異步的過程，每次去請求(尤其是在頁面跳轉(zhuǎn)時的判斷)會給用戶帶來不好的使用體驗(yàn)。

在面向商家端的 App 上，商家需要保證線上功能的穩(wěn)定性，在功能迭代較快的場景下，如何保證 App 端上線后可以動態(tài)調(diào)整，不影響用戶的使用呢？

在微商城 App 中，Hybrid 和 Weex 都有在使用，但是常用功能為了用戶體驗(yàn)及改造成本，大家一般還是會使用原生開發(fā)。那么如何使得原生頁面的 App 端每次上新功能的時候，可以讓少部分的數(shù)據(jù)動態(tài)變更呢？
在這一點(diǎn)上后端的 Apllo 給了我們靈感，App 側(cè)其實(shí)也是可以使用類似的方案，來實(shí)現(xiàn)線上業(yè)務(wù)的降級配置的。當(dāng)線上新功能出現(xiàn)問題時，使用配置中心進(jìn)行降級處理，待 Weex 發(fā)版或熱修復(fù)下發(fā)后，重新打開新功能，可以最大限度的降低 App 端線上業(yè)務(wù)的影響。同時，業(yè)務(wù)方也可以利用配置的下發(fā)能力來限定功能的升降級范圍，以對業(yè)務(wù)進(jìn)行灰度測試。為了補(bǔ)齊原生側(cè)的這部分能力，我們開始了對配置中心的設(shè)計(jì)。

我們需要一種怎樣的能力？

從開發(fā)的角度獲取了配置中心需要提供以下能力：

配置可動態(tài)變更。
動態(tài)變更是配置中心最核心的需求

便捷易用
對開發(fā)而言，使用起來盡量簡潔，不需要去關(guān)注更新的時機(jī)和線程切換。

可以根據(jù)業(yè)務(wù)和版本做動態(tài)下發(fā)，而非單純的簡單 KV 配置
與 H5 和后端不同，App 端由于自身特性，線上往往都是多個版本共存的，這就造成了下發(fā)配置的時候需要對 App的版本做區(qū)分，一個 App 中同時會有很多基礎(chǔ)組件，如商品、訂單、IM等，這些組件往往需要有自己的配置和版本，對于組件配置的區(qū)分也是有必要的。

有版本回溯功能，一旦配置錯誤可以快捷撤回上一個版本
新版本配置有問題，可以快速回滾到上一個版本。

可區(qū)分環(huán)境
開發(fā)環(huán)境可調(diào)試，每個環(huán)境配置獨(dú)立。

架構(gòu)設(shè)計(jì)

配置中心自開始開發(fā)以來，一共進(jìn)行了兩次大的迭代，分為了 1.0 和 2.0 兩個版本：

配置中心 V1.0

后端設(shè)計(jì)

在配置中心后端下發(fā)的整個過程中，大體分為4個步驟：

• 組件匹配
• 配置單匹配
• 下發(fā)狀態(tài)匹配
• KV查詢下發(fā)

其中，組件是配置中心配置下發(fā)的場景下使用范圍抽象出的一個概念，可能是一個 App ，也可能是一個 SDK 。配置單則是配置下發(fā)的單位，每次發(fā)布會新建一份配置單，內(nèi)部包含了多個 KV 數(shù)據(jù)，是下發(fā)時的最小單位。下發(fā)狀態(tài)匹配的流程，是為了通過檢查告知 SDK 是否需要更新本地緩存的配置，減少組件 KV 較多的情況下，每次更新重新啦取所有 KV 造成的重復(fù)讀寫和網(wǎng)絡(luò)流量的消耗。

具體配置中心的下發(fā)流程，可以參照下圖來進(jìn)行理解：

除了以上下發(fā)流程的調(diào)整外，配置中心還通過接入移動基礎(chǔ)保障平臺來完成配置發(fā)布的審核，防止出現(xiàn)線上數(shù)據(jù)被誤操作導(dǎo)致故障的場景出現(xiàn)。

SDK側(cè)設(shè)計(jì)

• 配置中心僅在 App 進(jìn)行前后臺切換時檢測各個組件配置的更新狀態(tài)，以確保用戶在使用 App 時能快速獲取到最新的配置
• 將拉取到的配置緩存在本地，每次讀取配置時均從本地配置獲取配置的內(nèi)容，調(diào)用 SDK 獲取配置 KV 值的過程中，從緩存中獲取
• 當(dāng) App 始終在前臺使用時，借助 IM 的長連接功能，將配置中心配置變更的消息推送到 SDK ，觸發(fā) SDK 拉取更新 通過以上幾點(diǎn)，可以保證App端能夠及時準(zhǔn)確的獲取到最新配置。

SDK側(cè)整個下發(fā)流程也就可以簡化為下圖所示：

配置中心 V1.0 的優(yōu)點(diǎn)和缺點(diǎn)

雖然配置中心上線后大家在使用過程中沒有遇到線上問題，配置中心很好的完成了它的任務(wù)，但是這一版本的配置中心還是有著明顯的優(yōu)缺點(diǎn)的：

優(yōu)點(diǎn)：

匹配邏輯簡單明了，這也是配置中心第一版能快速上線的原因

在組件維護(hù)人員不多、項(xiàng)目并行場景少的情況下可以滿足初期的大多數(shù)需求

缺點(diǎn)：

第一版上線時沒有太多考慮擴(kuò)展性及數(shù)據(jù)同步方面的問題，所以當(dāng)后續(xù)想加入一些邏輯時難以擴(kuò)展(例如灰度機(jī)制的引入，就是在原來的匹配機(jī)制上硬性加入了一層判斷)。

由于下發(fā)的最小單位是配置單，所以判斷用戶是否有新的 KV 信息，必須要經(jīng)過1次活多次 DB 查詢來篩選出對應(yīng)配置單，這部分邏輯由于在加入灰度判斷后與 dfp (設(shè)備指紋)有關(guān)，所以無法進(jìn)行有效的緩存，只能直接查 DB。

組件下發(fā)各層數(shù)據(jù)之間以表自動生成的 id 作為關(guān)聯(lián)查詢的條件，由于對自動生成的 id 有強(qiáng)依賴，所以是的跨環(huán)境同步的邏輯無法實(shí)現(xiàn)，如果需要實(shí)現(xiàn)只能整個復(fù)制。每次發(fā)布均需要將配置單內(nèi)的所有 KV 復(fù)制一遍，造成部分資源浪費(fèi)，同時不太容易追溯具體 KV 的修改記錄。

配置中心 V2.0

雖然配置中心 V1.0 的版本有部分缺點(diǎn)，但是對當(dāng)前配置使用并沒有什么影響，盡管在使用過程中也有同學(xué)提出，A/B Test 的支持的需求，由于改動成本比較高，所以這項(xiàng)需求的優(yōu)先度并沒有提的很高，直到項(xiàng)目并行越來越多，發(fā)現(xiàn)配置中心由部分場景開始難以滿足新的需求了。

隨著業(yè)務(wù)的告訴迭代，很多項(xiàng)目已經(jīng)開始習(xí)慣于使用配置中心來進(jìn)行新功能的降級以及灰度，在同一個組件同時有多個項(xiàng)目在灰度的過程中，由于灰度條件的限制不同，導(dǎo)致了大家需要相互妥協(xié)。也就是在這個時候開始，我們發(fā)現(xiàn)現(xiàn)有的設(shè)計(jì)已經(jīng)無法滿足大家的需求了，大家目前需要的灰度范圍不是整個分發(fā)配置單，而是具體某個 KV 。所以經(jīng)過了新一輪的需求的收集，我們決定對配置中心的組件進(jìn)行一次升級，以滿足多項(xiàng)目并行的灰度場景和A/B Test 的測試場景。
在這次的組件升級中，我們對組件的下發(fā)流程進(jìn)行了一次比較大的優(yōu)化：

新版本檢查前置
組件的配置版本標(biāo)示在檢查組件信息時即可獲取到，不再需要多次查詢DB。

組件的每個下發(fā) KV 單獨(dú)控制
每個業(yè)務(wù)方再發(fā)布新的灰度 KEY 的時候，不再需要去檢查是否與其他項(xiàng)目沖突，灰度粒度下沉到 KV 級別。

在下發(fā)的每個查詢處理均加上了緩存，以提升查詢效率。

所有數(shù)據(jù)查詢均不依賴數(shù)據(jù)自增 id ，這部分是為新組件未來的擴(kuò)展性考慮。

新組件發(fā)布后，配置中心的整個下發(fā)流程有了較大變化：

同時，在管理平臺發(fā)布新組件的邏輯處理流程也變得相對復(fù)雜了一些，著些新增的處理邏輯是為了減少 SDK 檢測配置更新時減少 DB 查詢等待的時間，變更后的 KV 發(fā)布時數(shù)據(jù)庫變更邏輯見下圖：

使用展示

在配置中心的最新版本中，每個 KV 都能清晰的展示出其 KV 的類型、功能及適用版本點(diǎn)擊進(jìn)入后，可以查看到具體的具體的 KV 發(fā)布記錄，可以進(jìn)行回滾、同步、復(fù)制等操作編輯 KV 的過程中，用戶可以選擇下發(fā)的范圍及下發(fā) KV 的格式

對于客戶端而言(以 Android 為例)：只需要初始化和獲取 KV 值兩部分代碼即可使用配置中心。接入示例：

ConfigCenter.init(this).setConfigKey(configKey,moduleVersion,CONFIG_FILE,CLIENT_ID,CLIENT_SECRET,otherInfo)

取值示例：

var result =
ConfigCenter.getInstance().getStringByKey(STUDY_CONFIG_CENTER_KEY, configKey, "")

經(jīng)過簡單的配置，客戶端的業(yè)務(wù)邏輯即可實(shí)現(xiàn)動態(tài)切換的效果。

總結(jié)

以上是我們整個配置中心的建設(shè)方案，通過配置中心的使用，對原生 App 動態(tài)性的短板進(jìn)行了補(bǔ)齊，也可以幫助業(yè)務(wù)方對新業(yè)務(wù)的線上灰度提供幫助，高效快捷的控制灰度范圍，希望可以和廣大開發(fā)同學(xué)一起交流改進(jìn)。

擴(kuò)展閱讀：

基于weex的有贊無線開發(fā)框架、

有贊移動消息卡片動態(tài)化方案實(shí)踐

有贊移動端商品模塊的架構(gòu)演變之路

有贊移動熱修復(fù)平臺建設(shè)

有贊移動 App 一鍵切換網(wǎng)關(guān)實(shí)踐

有贊零售小票打印圖片二值化方案

有贊 Android 崩潰保護(hù)的探索及實(shí)踐

有贊零售小票打印跨平臺解決方案

有贊移動 iOS 組件化(模塊化)架構(gòu)設(shè)計(jì)實(shí)踐

有贊Flutter插件開發(fā)與發(fā)布

Vol.325

??

?

?

總結(jié)

以上是生活随笔為你收集整理的yii 使用 有赞sdk_有赞移动如何做到并行灰度的复杂场景？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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