從移動端的配置提及

出了什麼問題

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

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

歷史及現狀

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

1.0階段

設計接口以下：

$ 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也沒法下線，佔用服務端資源。

2.0階段

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

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

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

3.0階段

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

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

解決思路

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

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. 實現更多的更新發布場景，例如，更新配置項，可按照必定比例，逐步進行灰度更新，失敗可回退，提升可用性

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