從移動端的配置提及

出了什麼問題

大多數客戶端都有遠程配置的功能和需求,項目規模由小到大之後,對客戶端動態配置的需求就會迅速增長。就會出現新的問題和需求。javascript

  • 配置項逐漸增多,配置內容大小逐步增大
  • 客戶端版本逐漸曾多,版本之間的配置差別較大,配置管理混亂,牽一髮而動全身
  • 運營和產品對業務配置的需求逐漸增長,須要有獨特的配置關聯邏輯
  • 配置不斷龐大,下發到客戶端的時候需考慮流量問題
  • 配置服務端考慮併發問題
  • 配置動態下發,考慮不一樣的更新策略,考慮安全性

歷史及現狀

可能不少移動端的開發者都有這樣的經歷: 經過某一個接口,獲取某一業務功能的配置信息,有時候須要根據業務觸發的邏輯,在不一樣的時機調用接口,獲取配置,又有些時候須要把客戶端的一些信息,如版本號、時間、上次的緩存等等,傳入接口獲取最新配置,這其實就是最簡單的遠程配置需求,根據配置相關條件,經過不一樣的更新策略,獲取遠程配置。java

1.0階段

設計接口以下:git

$ curl https://api.xxx.com/v0/configuration/getMessageConfig?appVersion=1.0.0&platform=iOS&messageType=1 \
-H "SS-Cache-Version: XXXXXXXXX"

{
	"code":"0",
	"result":{
		"config_value":"******",
		"cache_version":"******"
	}
}
複製代碼

經過不斷開發新的接口,知足各個業務線對配置功能需求。 優勢:需求較少的時候,開發特別快 缺點:客戶端須要不斷開發新的API調用,服務端則須要不斷開發新接口,配置與客戶端的關聯信息發生變化,API則須要進行升級,而客戶端存在多版本並存的狀況,老版本API也沒法下線,佔用服務端資源。github

2.0階段

爲減輕服務端開發依賴,有的開發者經過使用第三方開發平臺進行配置分發。 例如,使用umeng的在線參數進行遠程配置算法

優勢: 無需服務端開發,第三方實現SDK與其服務端的通訊,不須要作客戶端開發shell

缺點: 沒法與客戶端信息作相關,只能經過約定配置參數名稱例如 配置項名稱+平臺名稱+客戶端版本做爲配置項名稱,作硬關聯,大量生成重複配置項。沒法控制更新策略。業務相關配置放置在第三方平臺,沒法保證數據安全。json

3.0階段

由此前的經歷和需求痛點,咱們設計出新的移動端配置中心。 主要有以下功能後端

  1. 支持配置客戶端信息與配置項相關,作到不一樣的客戶端獲取不一樣的配置項
  2. 支持配置增量更新
  3. 支持客戶端配置加密下發,保證安全
  4. 提供統一後臺配置界面,方便進行配置的管理
  5. 作到配置更新,主動推送到客戶端
  6. 支持配置回滾,刪除恢復

解決思路

根據以上需求,總體方案的解決思路能夠是以下這樣:api

  1. 移動端開發遠程配置組件,用於獲取最新的後端配置
  2. 客戶端與接口交互的時候,將諸如appid(存在對個應用)、appVersion、platform、channel(渠道)、systemVersion等基礎信息傳入接口,方便配置項與其關聯
  3. 客戶端與接口交互的時候,支持全量更新,支持經過生成增量包進行增量更新
  4. 服務端與客戶端進行數據傳輸的時候,進行通訊數據加密
  5. 對於服務端,客戶端提供定時配置同步策略,服務端經過推送和長鏈接通信主動推送配置
  6. 配置項後臺的增刪改查,都採起版本疊加,而不是從新覆蓋,支持回滾與刪除回覆
  7. 經過標籤系統,提供更靈活的配置項與客戶端的匹配關係

涉及方面

有了大概的解決思路之後,能夠對涉及到的方面進行總體盤點,其實這也是移動端基礎設施的摸查,涉及如下幾個方面: 數組

  • 客戶端配置組件,與配置中心交互,獲取配置信息,定時輪詢更新策略,內存緩存與本地持久化配置信息,增量包應用,接收服務端推送事件
  • 配置中心,提供對客戶端獲取配置的API接口服務,接口支持根據客戶端信息和標籤返回增量數據包/全量更新包
  • 後臺管理系統,提供應用管理和配置管理,支持新建配置,修改配置,回滾和刪除配置
  • 認證服務,客戶端經過認證服務之後,獲取通信管道加密的會話密鑰,提供接口數據加密功能
  • 標籤系統,提供對客戶端、設備、用戶等多個維度的標籤設置和獲取服務
  • 消息中心,提供根據標籤系統,將配置更新的事件推送到客戶端
  • 定時任務系統,提供定時服務,將配置生效、推送配置等設置爲定時任務

總體設計

API設計

客戶端與配置中心進行API交互,接口定義以下: queryConfiguration 入參:

  • clientInfo,包含appid、appVersion、platform、channel等
  • cacheInfo
{
	"clientInfo":{
		"appid":"***",
		"appVersion":"1.0.0",
		"platform":"1", //1爲iOS 2爲Android
		"channel":"AppStore"
	},
	"cacheInfo":[{
			"configName":"routerConfigMap",
			"version":"*****"
		},
		{
			"configName":"conditionConfiguration",
			"version":"*****"
		}
	]
}
複製代碼

返回值:

  • configurationData,一個數組,包含配置項全量或者增量數據包
code 含義 備註
0 增量包 返回增量包數據
1 全量數據 返回配置全量數據
2 已刪除 表示該配置項已刪除
{
    configurationData:[
        {
            "configName":"routerConfigMap",
            "version":"*****",
            "code":0,
			  "hash":"*****",
            "patch":[]
        },
        {
            "configName":"orderActivity",
            "version":"xxxxxx",
            "code":1,
			  "hash":"*****",
            "value":"xxxxx"
        },
        {
            "configName":"conditionConfiguration",
            "version":"xxxxxx",
            "code":2
        },
    ]
}
複製代碼

客戶端與API交互流程圖

配置中心管理平臺

App管理平臺

配置平臺

配置管理後臺,提供對應用的管理與配置項的管理,配置項與基本客戶端信息關聯。 配置項存儲與客戶端信息進行關聯映射,關係有OR和AND兩種,每一個配置項設置關聯條件。例如配置項的關聯條件爲:

configId <—> appId AND appVersion AND channel AND platform OR tag

新建、更新或者刪除某一配置,能夠設置定時生效,Job系統會定時執行操做,並調用消息中心,按照關聯條件,進行推送通知給客戶端,客戶端接到更新事件後,再調用API接口完成配置項更新。

服務端查詢配置項流程

這個流程裏有三個關鍵點:

  1. 根據clientInfo查詢匹配的配置列表,其中,AND關係和OR關係,須要經過構建一個配置id與條件的字典表,查詢的時候將AND或者OR的條件相關的配置id所有查詢出來,而後進行AND計算(取交集),OR計算取並集,其中appVersion是一個範圍,例如設置某一配置項的appVersion爲」<=2.3.0 & >=2.1.0」, 根據語義化版本,進行單獨匹配,語義化版本 2.0.0 | Semantic Versioning的規範請詳細查看文檔
  2. 若是客戶端上傳有cacheInfo,將緩存的配置id列表上傳,那麼,根據條件查出的最新配置id列表爲A,上傳的緩存配置id列表爲B,分別計算出A與B的交集,逐個對比hash值,算出增量包,再算出屬於A但不屬於B的部分,屬於新增配置項,作全量包,再算出屬於B不屬於A的,屬於要刪除的部分。進行上述計算,只須要定義一套數組的交集、並集與補集的計算,就可計算出結果。
  3. 生成增量包的時候,須要根據客戶端配置id和對應hash值,找到舊版本的配置項,再跟最新的配置項作文本對比生成增量包。文本增量算法有google官方實現的一套:GitHub - google/diff-match-patch: Diff Match Patch is a high-performance library in multiple languages that manipulates plain text.

推送更新消息

這個比較簡單,經過後臺增刪改查的配置項,根據其標籤和客戶端信息,使用消息中心,將更新事件靜默推送到設備,而設備客戶端信息和標籤,與設備惟一標示的綁定關係,在標籤系統維護。

總結改進

新的配置中心,知足了現階段的需求,經過將配置項的關聯條件抽象成標籤,再加上增量更新,知足了節省流量的需求。 將來還有進一步改進的空間:

  1. 配置後臺經過jsonschema來效驗配置的格式,方式配置錯誤
  2. 客戶端的配置組件改善通信方式,使用推拉結合的方式,目前的推送基於消息中心,將來可使用UDP+心跳方式維持客戶端與服務端的數據同步
  3. 實現更多的更新發布場景,例如,更新配置項,可按照必定比例,逐步進行灰度更新,失敗可回退,提升可用性

多謝您花費寶貴的時間閱讀,但願可以與你們多多交流

相關文章
相關標籤/搜索