yii 使用 有赞sdk_有赞移动如何做到并行灰度的复杂场景？
?
點擊關注“有贊coder”
獲取更多技術干貨哦～
作者：時文濤部門：電商移動使用場景
作為移動開發的我們經常會遇到兩種需求：
現狀
為了解決以上問題，就需要App側具備一定的動態化能力。目前增強App端的動態性方式，通常來說有下面幾類：
這種方案是最常見的，Webview 中嵌套 H5 頁面，通過 JSBridge 來與原生頁面進行交互，也是成本最低的方案，但是一般而言用戶的體驗會比較差，比較依賴用戶的網絡環境，通常用于 App 內展示頻率不高的頁面。
使用 Weex 和 RN 應該是現在電商 App 中使用較多的動態化框架，與原生相比，多了一層 JS 解析，渲染速度會比原生慢一點，但是在可接受的范圍內，帶來的動態發版的優勢是原生所不具備的優勢，同時相對于 H5 而言渲染性能要好很多，在 App 中經常會用于新業務中交互不復雜，對用戶體驗要求不是特別高的場景。
從實現方式看來，Tangram 的實現思路與 Weex 和 RN 十分相似，不同點只是 Weex 解析是使用 JS 解析成原生組件，Tangram 使用 Json 來解析成原生組件。
這種場景較為常見，但是有兩個較為明顯的缺點，第一點是不同的業務都需要新增接口來完成下發數據的控制，開發成本大，第二點是網絡請求是個異步的過程，每次去請求(尤其是在頁面跳轉時的判斷)會給用戶帶來不好的使用體驗。
在面向商家端的 App 上，商家需要保證線上功能的穩定性，在功能迭代較快的場景下，如何保證 App 端上線后可以動態調整，不影響用戶的使用呢？
在微商城 App 中，Hybrid 和 Weex 都有在使用，但是常用功能為了用戶體驗及改造成本，大家一般還是會使用原生開發。那么如何使得原生頁面的 App 端每次上新功能的時候，可以讓少部分的數據動態變更呢？
在這一點上后端的 Apllo 給了我們靈感，App 側其實也是可以使用類似的方案，來實現線上業務的降級配置的。當線上新功能出現問題時，使用配置中心進行降級處理，待 Weex 發版或熱修復下發后，重新打開新功能，可以最大限度的降低 App 端線上業務的影響。同時，業務方也可以利用配置的下發能力來限定功能的升降級范圍，以對業務進行灰度測試。為了補齊原生側的這部分能力，我們開始了對配置中心的設計。
我們需要一種怎樣的能力？
從開發的角度獲取了配置中心需要提供以下能力：
動態變更是配置中心最核心的需求
對開發而言，使用起來盡量簡潔，不需要去關注更新的時機和線程切換。
與 H5 和后端不同，App 端由于自身特性，線上往往都是多個版本共存的，這就造成了下發配置的時候需要對 App的版本做區分，一個 App 中同時會有很多基礎組件，如商品、訂單、IM等，這些組件往往需要有自己的配置和版本，對于組件配置的區分也是有必要的。
新版本配置有問題，可以快速回滾到上一個版本。
開發環境可調試，每個環境配置獨立。
架構設計
配置中心自開始開發以來，一共進行了兩次大的迭代，分為了 1.0 和 2.0 兩個版本：
配置中心 V1.0
后端設計
在配置中心后端下發的整個過程中，大體分為4個步驟：
- 組件匹配
- 配置單匹配
- 下發狀態匹配
- KV查詢下發
其中，組件是配置中心配置下發的場景下使用范圍抽象出的一個概念，可能是一個 App ，也可能是一個 SDK 。配置單則是配置下發的單位，每次發布會新建一份配置單，內部包含了多個 KV 數據，是下發時的最小單位。下發狀態匹配的流程，是為了通過檢查告知 SDK 是否需要更新本地緩存的配置，減少組件 KV 較多的情況下，每次更新重新啦取所有 KV 造成的重復讀寫和網絡流量的消耗。
具體配置中心的下發流程，可以參照下圖來進行理解：
除了以上下發流程的調整外，配置中心還通過接入移動基礎保障平臺來完成配置發布的審核，防止出現線上數據被誤操作導致故障的場景出現。SDK側設計
- 配置中心僅在 App 進行前后臺切換時檢測各個組件配置的更新狀態，以確保用戶在使用 App 時能快速獲取到最新的配置
- 將拉取到的配置緩存在本地，每次讀取配置時均從本地配置獲取配置的內容，調用 SDK 獲取配置 KV 值的過程中，從緩存中獲取
- 當 App 始終在前臺使用時，借助 IM 的長連接功能，將配置中心配置變更的消息推送到 SDK ，觸發 SDK 拉取更新 通過以上幾點，可以保證App端能夠及時準確的獲取到最新配置。
SDK側整個下發流程也就可以簡化為下圖所示：
配置中心 V1.0 的優點和缺點
雖然配置中心上線后大家在使用過程中沒有遇到線上問題，配置中心很好的完成了它的任務，但是這一版本的配置中心還是有著明顯的優缺點的：
優點：
缺點：
第一版上線時沒有太多考慮擴展性及數據同步方面的問題，所以當后續想加入一些邏輯時難以擴展(例如灰度機制的引入，就是在原來的匹配機制上硬性加入了一層判斷)。
由于下發的最小單位是配置單，所以判斷用戶是否有新的 KV 信息，必須要經過1次活多次 DB 查詢來篩選出對應配置單，這部分邏輯由于在加入灰度判斷后與 dfp (設備指紋)有關，所以無法進行有效的緩存，只能直接查 DB。
組件下發各層數據之間以表自動生成的 id 作為關聯查詢的條件，由于對自動生成的 id 有強依賴，所以是的跨環境同步的邏輯無法實現，如果需要實現只能整個復制。每次發布均需要將配置單內的所有 KV 復制一遍，造成部分資源浪費，同時不太容易追溯具體 KV 的修改記錄。
配置中心 V2.0
雖然配置中心 V1.0 的版本有部分缺點，但是對當前配置使用并沒有什么影響，盡管在使用過程中也有同學提出，A/B Test 的支持的需求，由于改動成本比較高，所以這項需求的優先度并沒有提的很高，直到項目并行越來越多，發現配置中心由部分場景開始難以滿足新的需求了。
隨著業務的告訴迭代，很多項目已經開始習慣于使用配置中心來進行新功能的降級以及灰度，在同一個組件同時有多個項目在灰度的過程中，由于灰度條件的限制不同，導致了大家需要相互妥協。也就是在這個時候開始，我們發現現有的設計已經無法滿足大家的需求了，大家目前需要的灰度范圍不是整個分發配置單，而是具體某個 KV 。所以經過了新一輪的需求的收集，我們決定對配置中心的組件進行一次升級，以滿足多項目并行的灰度場景和A/B Test 的測試場景。
在這次的組件升級中，我們對組件的下發流程進行了一次比較大的優化：
新版本檢查前置
組件的配置版本標示在檢查組件信息時即可獲取到，不再需要多次查詢DB。
組件的每個下發 KV 單獨控制
每個業務方再發布新的灰度 KEY 的時候，不再需要去檢查是否與其他項目沖突，灰度粒度下沉到 KV 級別。
在下發的每個查詢處理均加上了緩存，以提升查詢效率。
所有數據查詢均不依賴數據自增 id ，這部分是為新組件未來的擴展性考慮。
新組件發布后，配置中心的整個下發流程有了較大變化：
同時，在管理平臺發布新組件的邏輯處理流程也變得相對復雜了一些，著些新增的處理邏輯是為了減少 SDK 檢測配置更新時減少 DB 查詢等待的時間，變更后的 KV 發布時數據庫變更邏輯見下圖：
使用展示
在配置中心的最新版本中，每個 KV 都能清晰的展示出其 KV 的類型、功能及適用版本點擊進入后，可以查看到具體的具體的 KV 發布記錄，可以進行回滾、同步、復制等操作編輯 KV 的過程中，用戶可以選擇下發的范圍及下發 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, "")
經過簡單的配置，客戶端的業務邏輯即可實現動態切換的效果。
總結
以上是我們整個配置中心的建設方案，通過配置中心的使用，對原生 App 動態性的短板進行了補齊，也可以幫助業務方對新業務的線上灰度提供幫助，高效快捷的控制灰度范圍，希望可以和廣大開發同學一起交流改進。
擴展閱讀：基于weex的有贊無線開發框架、
有贊移動消息卡片動態化方案實踐
有贊移動端商品模塊的架構演變之路
有贊移動熱修復平臺建設
有贊移動 App 一鍵切換網關實踐
有贊零售小票打印圖片二值化方案
有贊 Android 崩潰保護的探索及實踐
有贊零售小票打印跨平臺解決方案
有贊移動 iOS 組件化(模塊化)架構設計實踐
有贊Flutter插件開發與發布
Vol.325
???
?總結
以上是生活随笔為你收集整理的yii 使用 有赞sdk_有赞移动如何做到并行灰度的复杂场景？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python编译成class_djang
- 下一篇： localdate计算相差天数_干掉 D