本文由鞏鵬軍分享，原題“IM兼容性基建”，本文有修訂。
1、引言
一個成熟的IM成品，在運營過程中隨著時間的推移，會發布不同的版本，但為了用戶體驗并不能強制要求用戶必須升級到最新版本，而服務端此時已經是最新版本了，所以為了讓這些不同客戶端版本的用戶都能正常使用（尤其IM這種產品，不同版本可能通信協議都會有變動，這就更要命了），則必須要針對不同客戶端版本的兼容處理。
本文將基于筆者的IM產品開發和運營實踐，為你分享如何實現不同APP客戶端版本與服務端通信的兼容性處理方案。
學習交流：
（本文已同步發布于：http://www.52im.net/thread-4202-1-1.html）
2、關于作者
鞏鵬軍：專注移動開發十多年，熱愛即時通訊技術。個人微信公眾號：“鞏鵬軍”。
作者在即時通訊網分享的另一篇《知識科普：IM聊天應用是如何將消息發送給對方的？（非技術篇）》，感興趣的讀者也可以看看。
3、一個App時怎么辦？
提示：“一個App”指的是同一個IM服務端，只服務于一個特定的IM產品。
首先想到的就是直接使用App版本號判斷新老版本并進行兼容處理。
如下圖所示：
一般來說，不同的IM客戶端（如iOS、Android、Windows、Mac）都是同步迭代，多端發版時間一致，App版本號也一樣。
所以用跨多端的App版本號可以很容易地讓服務端只用寫一遍判斷和兼容邏輯。
示例：假設從V2.1.0開始應用紅包消息，那么判斷客戶端是否支持紅包的邏輯就很簡單。
偽代碼如下：
booleanisSupportRedEnvelop(String appVersion) {
returngte(appVersion, "2.1.0");
}
附：版本號比對邏輯（未充分考慮異常情況）：
List<Integer> toNums(String version) {
Matcher matcher = Pattern
.compile("/[0-9]+\\.[0-9]+\\.[0-9]+")
.matcher(version);
String versionString = matcher.find()
? matcher.group(0).substring(1)
: "1.0.0";
List<Integer> verNums = Arrays
.stream(versionString.split("\\."))
.map(Integer::valueOf)
.collect(Collectors.toList());
returnverNums;
}
booleangte(String version, String target) {
List<Integer> appVerNums = toNums(version);
Integer appMajor = appVerNums.get(0);
Integer appMinor = appVerNums.get(1);
Integer appPatch = appVerNums.get(2);
List<Integer> targetNums = toNums(target);
Integer targetMajor = targetNums.get(0);
Integer targetMinor = targetNums.get(1);
Integer targetPatch = targetNums.get(2);
return(appMajor >= targetMajor) ||
(appMinor >= targetMinor) ||
(appPatch >= targetPatch);
}
4、多個App時怎么辦？
4.1概述
提示：“多個App”指的是同一個IM服務端，可能作為通用服務，作為多個不同APP產品中的聊天模塊使用的場景。
只有一個App時肯定是比較簡單的。但現實情況是一套IM系統通常會用于多個業務場景，這是很普遍的現象。業界的知名IM產品，比如釘釘、飛書、企業微信、美團大象等都是這樣。
底層邏輯大概是：IM系統比較復雜，功能繁多而且難以實現、更難以穩定，所以一個IM團隊維護一套IM系統，然后應用在多個業務場景就是最具性價比的選擇了。
4.2使用App版本
每個業務場景都會有自己的客戶端App，每個App都有自己的版本號，那么根據App版本號判斷新老版本的邏輯就不適用了（如下圖所示）。
一個App時可以這樣做兼容性判斷：
booleanisSupportRedEnvelop(String appVersion) {
returngte(appVersion, "2.1.0");
}
多個App時的兼容性判斷：
booleanisSupportRedEnvelop(String version) {
return
(app.equals("App1")&>e(version,"2.1.0"))||
(app.equals("App2")&>e(version,"2.2.3"))||
(app.equals("App3")&>e(version,"6.1"));
}
4.3使用App版本號的麻煩
隨著App的增多，需要的判斷也越多，這會很麻煩，也很容易出錯。
每個App推出新版本后，用戶不可能瞬間就升級到最新版本，根據經驗，每個App往往都會同時存在十個以上的不同版本。
這就會形成如下圖所示的局面：
5、多個App時，可將IM能力提煉為一套公用代碼
多個App時的問題總結起來就是：一套服務端代碼如何適應集成了不同IM能力的不同App客戶端？
我們來具體舉例分析一下，假設一個IM團隊維護的IM相關的客戶端模塊有IM Client SDK、聯系人、長連接、朋友圈等四個模塊（如下圖所示）。
如上圖所示：
- 1）App 1：集成了全部四個模塊；
- 2）App 2：只集成了三個模塊；
- 3）App 3：只集成了三個模塊。
因為三個App面向的客戶群不同，發版節奏不同，所以各自集成的IM的能力也不同。
比如下面這樣：
- 1）App 1：面向內部員工辦公溝通使用的App 1需要功能豐富，對于穩定性和Bug有一定的包容性，也容易溝通和修復再發版；
- 2）App 2：面向客服場景，用于企業的客服專員和企業的C端用戶溝通解決客訴問題，對于穩定性要求高，C端用戶升級率不好控制，發版節奏慢，最快只能和主業務App一致；
- 3）App 3：面向企業和B端供應商，比如美團和美團上的商戶，京東和京東平臺上的第三方商家，對于穩定性要求也比較高，B端商家的升級率好控制一點，發版節奏也可以快一些。
從上圖可以看出，因為IM核心能力是同一個團隊維護，所以Core包含的多個模塊的代碼必然是只有一套源代碼。不同App只是Core集成打包出來的產物，或者說不同App只是Core外面套了不同的殼而已，只要Core一樣，則App的IM能力就一樣（這就是本節標題所述的“多個App時，可將IM能力提煉為一套公用的代碼”這個意思）。
6、給每個App中使用的公用代碼（Core）一個版本號
如上節所述，我們將IM能力提煉為一套公用代碼（以下內容簡稱“Core”）。
那么，我們能不能給Core一個版本標識呢？
答案是肯定的：
站在App的角度，每個App相當于打上了Core版本標簽：
7、如何正確地解讀Core版呢？
7.1拋開App看Core版本
如果不看App版本，只看Core版本標簽：
7.2從一套服務端代碼看Core版本
同一個IM團隊，其IM Servers必然也是同一套代碼集，不考慮部署的區別。
那么上圖邏輯上等價于下圖：
7.3使用Core版本的兼容性判斷
站在Core的視角，多個App就像單個App類似，只是使用的版本標識不同。
具體如下：
- 1）單個App時，IM服務端要區分不同App版本；
- 2）多個App時，IM服務端要區分不同Core版本。
還拿是否支持紅包的判斷舉例。
一個App時：
booleanisSupportRedEnvelop(String appVersion){
returngte(appVersion, "2.1.0");
}
多個App時:
booleanisSupportRedEnvelop(Integer coreVersion){
returncoreVersion >= 2;
}
通過Core版本號，我們可以把兼容邏輯判斷簡化到和單個App一樣的簡單。
8、關于Core版本的命名和取值
關于Core版本號的取值，有下列可能的選項：
- 選項一：語義版本號 1.2.0；
- 選項二：整數 自然數 1 2 3；
- 選項三：整數 迭代日期 20220819 或 220819。
因為Core版本號不用給最終用戶看的，無需遵循常見的語義版本號規范。而且Core版本號只用于版本對比，所以整數會是一個比較好的選擇，方便比較，準確可靠。
用自然數 1、 2、 3作為Core版本號是可以的，每個迭代發布新的Core版本時遞增一下就可以了。
但是考慮到有多個終端平臺iOS、Android、Windows、Mac，如果某個平臺的Core發布后發現小Bug需要HotFix，那么要遞增版本號，就會擠占其它端的下一個自然數。究其原因，在于自然數是連續的，沒辦法在兩個常規的版本間插入一個HotFix版本。
選項三就可以解決這個問題：因為Core的迭代發布日期是稀疏的，若干天后才會發布一個Core版本，那么當某個端需要一個HotFix版本時，選擇HotFix當天的日期作為版本號即可。
總體上：多個端的主要版本號都是約定的統一的發布日期，多端一致，同時允許某個端臨時HotFix插入一個新的版本號，保留彈性。
參考 Google 對Android SDK API版本的實踐，我們可以把Core版本號命名為core_level，取值為Core的發布日期的整數表示。
9、多個App情況下的其它版本標識
1）platform：
一套Core，不同端在實際開發中，可能存在差異，為了針對具體端進行特定的兼容，需要知道當前是哪個端，可以約定platform字段表示端。取值可以是：ios、android、win、mac、linux等。
2）App版本號：
在IM相關邏輯的兼容性判斷中，只需使用跨App的多端一致的core_level了。但是為了和最終用戶、產品經理等溝通方便，保留App版本號app_version用于人和人之間溝通交流。core_level主要用于研發工程師之間，還有工程師和程序之間的溝通。兩者各取所長。
10、版本標識的傳輸方式
每個API和每條長連接數據包都攜帶Core版本，這樣服務端可以無狀態得處理每一個請求。如果需要在服務端主動推送時區分目標端的版本，可以在App登錄時將其攜帶的Core版本落庫存儲，然后推送時查詢使用。
10.1短連接（HTTP）
HTTP短連接通過新增Header字段方式傳輸：
curl "https://{domain}/api/v1/xxx"\
-H "platform: ios"\
-H "app_version: 8.0.25"\
-H "core_level: 220819"
10.2長連接（Socket）
長連接SDK通過類似HTTP Header的方式傳輸：
{
"platform":"ios",
"app_version":"8.0.25",
"core_level":"220819"
}
10.3短轉長
短轉長時HTTP Header會轉換為長連接數據body里的header通過長鏈傳遞。
這樣就同時存在長連接header和長連接body.header兩套字段，最終以長連接body.header為準即可。
10.4其它
IM系統里的瀏覽器和小程序，如果可以新增HTTP Header則新增Header傳輸，實在沒有辦法可以通過User-Agent傳輸該信息，服務端優先解析Header，沒有找到時再解析User-Agent。
服務端解析UA的正則表達式：
/ platform\/(ios|android|mac|win|linux) app_version\/([0-9]\.[0-9]+\.[0-9]+) core_level\/([1-9][0-9]+)( |$)/
以上正則表達式在線運行效果：點此查看。
11、本文小結
至此，我們找到了一個適用于多個App、多個子模塊、多個功能點、臨時BugFix的版本標識：Core版本號，這樣就可以很好地解決多App的IM能力兼容性問題。
以下是版本兼容性判斷偽碼：
booleanisSupportRedEnvelop(Integer coreLevel) {
returncoreLevel >= 220819;
}
12、參考資料
[1] Browser vs Engine Version
[2] Node.js ABI version number
[3] Android SDK API Level
[4] 零基礎IM開發入門(一)：什么是IM系統？
[5] 一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)
[6] 一套原創分布式即時通訊(IM)系統理論架構方案
[7] 從零到卓越：京東客服即時通訊系統的技術架構演進歷程
[8] 一套億級用戶的IM架構技術干貨(上篇)：整體架構、服務拆分等
[9] 基于實踐：一套百萬消息量小規模IM系統技術要點總結
[10] 一套十萬級TPS的IM綜合消息系統的架構實踐與思考
[11] 從新手到專家：如何設計一套億級消息量的分布式IM系統
[12] 閑魚億級IM消息系統的架構演進之路
[13] 深度解密釘釘即時消息服務DTIM的技術設計
[14] 一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐
[15] 企業微信的IM架構設計揭秘：消息模型、萬人群、已讀回執、消息撤回等
（本文已同步發布于：http://www.52im.net/thread-4202-1-1.html）