本文由攜程技術Jim分享，原題“日訪問過億，辦公IM及開放式平臺在攜程的實踐”，下文進行了排版和內容優化。
1、引言
攜程內部的辦公IM項目最早在2016年立項，經歷了初期簡單辦公場景下的純IM服務，到支持簡單辦公組件的IM應用，又演變為一體化辦公集成平臺，進而演變為目前集成IM功能的開放式企業效率平臺。
本文總結了攜程辦公IM這些年的發展歷程及未來的演進方向，并著重從高可用、高性能和可擴展的角度，探討開放式平臺的技術實現及發展方向。
2、關于作者
Jim：攜程高級研發經理，關注Java & Go技術棧后端研發。目前致力于TripPal開放平臺的高可用、開放化進程及核心衍生服務。
3、什么是IM
IM（Instant Message）即時消息，是一種通過網絡提供實時消息傳輸的在線溝通技術。
在移動互聯網時代，IM的使用變得越來越廣泛，通過各種技術手段使得用戶之間的交流成本變的極低，溝通效率和用戶體驗有極大的提升。而且IM的出現極大地改變了目前互聯網應用的形態，多數互聯網應用只要做到了一定規模，一定會有自身IM的需求，而不是單純地僅僅依托第三方（例如微信、云信等）。
PS：關于什么是IM，您也可詳讀專題文章《零基礎IM開發入門(一)：什么是IM系統？》。
4、 攜程辦公IM的發展歷程
早期攜程使用微軟的IM軟件lync和自研的純IM軟件CtripTeam來支持企業內的溝通需求，這些軟件在維護性、拓展性和可用性上都或多或少存在一些缺陷。同時隨著互聯網的發展，也逐漸不適合日益增長的辦公需求和用戶體驗。
2017年左右，使用基于ejabberd+erlang的自研IM服務的Cchat項目應運而生，該項目的主要目標是在采用自研IM的基礎上，實現IM與辦公的結合。在完善IM服務的基礎上，支持了一些常規的辦公場景，如電話、假單、考勤、OA等，通常采用嵌入外部頁面、跳轉外部地址等方式提供服務。這個改造項目奠定了攜程辦公IM繼續發展的基礎。
隨著項目的深入，最初的系統交互模式及服務管理模式逐漸不適用越來越復雜的辦公場景及服務治理需求。于是在2019年上馬了TripPal的改造項目，在結合公司國際化戰略的基礎上，傾力打造小程序平臺，服務號等基礎服務。在梳理、優化原有服務的同時，打造了諸多衍生服務。
2020年中開始，在繼續推進企業內辦公一站式平臺的基礎上，我們需要支持更多的外部場景，實際需求促使我們向開放式平臺轉型，這在服務整體架構、安全性、擴展性等方面都提出了新的要求及挑戰。
5、攜程TripPal開放平臺總體架構
5.1Gateway網關層
這一層是所有請求調用流量的入口，主要功能如下：
- 1）服務路由；
- 2）集中式限流、風控、日志監控等功能；
- 3）調用IDS (Identity Service) 驗證請求的合法性。
第 3）步中驗證通過后，可以將用戶ID、Token等基本信息，通過 HttpHeader 的方式向后端服務透傳，后端服務可以直接使用UserID，也可以再次對Token進行認證
5.2IDS (Identity Service) 服務
IDS同時支持多種不同類型的訪問令牌的鑒權，同時還負責令牌的頒發，以及RBAC+模塊級別的接口控權。
另外，針對開放小程序，TripPal提供兩種認證方式：
1）常規的Oauth第三方模式接入：
2）另一種是基于Oauth+開放平臺簽名的第三方認證，對于接入方相對簡單：
5.3微服務層
這一層是整個系統的業務層，具體包含三種類型的微服務：
- 1）TripPal開放平臺內部系統微服務：只有在特定用戶認證和權限驗證通過之后，外部才能訪問；
- 2）開放平臺對外提供的OpenAPI：采用Oauth+RBAC的方式控制權限；
- 3）自研小程序后端服務：根據安全需要，所有使用Oauth+模塊權限的第一方小程序服務端。
目前TripPal自身的核心微服務應用達到28個，提供全集團的多端（C端、B端）基礎服務能力，服務全公司超過500個業務應用，在線C端用戶均值超過2萬，日訪問量超過億。
6、 TripPal的IM服務
目前TripPal使用完全自研的基于Java實現的類ejabberd架構，底層采用的XMPP協議進行通訊。
Tips：
XMPP全稱是ExtensibleMessageing and Presence Protocol，可擴展消息與存在協議。是目前網絡上開源，最靈活，應用最廣泛的一種即時消息通信協議。
1999年Jeremie Miller，首先提出了Jabber，一種為實現即時消息和存在的開放技術，后續基于這個協議，開發了一個開源的服務實現jabberd。后續，IETF國際標準組織介入，成立Extensible Messageing and Presence Protocol（XMPP）工作組，并開始標準化工作。
2000年，jabberd服務器1.0版本發布，那時Jabber協議的基本特點（基于XML的流，消息，存在，聯系人列表等）都被固定下來。
2004年，IETF出版了RFC 3902和RFC3921，定義了XMPP的核心功能，成為推薦標準。
后續在2011年，IETF出版了RFC6120和RFC 6121，更新了XMPP的核心定義，替代了之前的RFC 3920和3921。
目前XMPP協議被XMPP Standards Foundation負責管理運作，集中于在IETF定義的基礎XMPP規范之上，如何開發開放的協議擴展。
IM服務端做了大量的系統性的優化，從底層的數據庫調優、底層通訊服務升級，到上層消息、群、群成員等核心功能的大幅改造。
底層通訊服務由之前的erlang完整遷移至java技術棧，服務可靠性、彈性伸縮、安全性和性能獲得了提升。同時對上層偏業務的服務進行了改造，極大地提升了接口響應，服務穩定性也得到了提升，為整個產品的研發提供了重要支撐。
目前這套自研的IM 3.0服務在生產環境穩定運行，整體資源消耗比2.0時期有較大下降。
7、 TripPal辦公衍生服務
7.1概述
在實際的企業辦公場景下，尤其是大型企業復雜組織架構和管理模式的場景下，TripPal逐漸摸索出了自己的一套行之有效且契合攜程場景的辦公智能應用，如搜索中臺，消息卡片，智能審批中臺，角色服務，工作流引擎等。
本文簡單介紹其中3個服務。
7.2智能審批中臺
智能審批中臺在集成攜程自有的審批系統的同時也集成了自研的智能審批配置服務，該服務支持用戶自定義整個審批單及審批流的全部細節。
7.3角色服務
角色服務在靈活定義角色范圍及基礎角色的基礎上，支持用戶靈活調整，動態管理，且自動接入審批中臺，同時打通應用對接渠道。
整個角色服務在產品定義上分為如下表4個主要概念：
7.4在線文檔
在線文檔服務主要提供文檔的在線協作能力，支持用戶同時/實時的查看、編輯、保存和分享的能力。同時結合IM實現通知和反饋等功能。
技術實現上，在線文檔是采用CRDT算法實現的無沖突merge（LastWrite Wins）、多端最終一致的分布式方案，同時兼具高可用、可容錯的特性，在服務器發生故障時，允許Shift至另一臺機器上繼續執行，即使服務端完全宕機，客戶端依然能夠離線工作。
8、 TripPal高可用的實踐
目前TripPal部署在3個機房，分為公有云1個機房及私有云2個機房。
總體架構在應用多機房部署、數據層跨機房DRC的基礎上，采用就近訪問的原則進行服務訪問，其中一旦發生任意2個機房全掛的情況，都能保證系統內的核心應用仍能提供服務。
其中公有云機房的一期部署方案已經完成，二期部署方案和測試計劃預計于7月完成，屆時可以和大家分享一下混合云方案的一些細節和歷程。
9、 開放平臺的未來架構及演進方向
9.1概述
開放平臺主要面向兩類群體，開發者和用戶。
所以主要有兩個方向：
1）一是便捷開發，主要圍繞降低開發者門檻、較低研發成本，打通不同開發者、應用之間的壁壘，實現生態共享。
2）另一方面，針對實際用戶，在提高用戶體驗、數據安全的同時，實現用戶服務能力整合和主動發現。
9.2開發者
在這方面，目前主流開放平臺已經對開發者提供了強大的支持。
主要形式分為以下3種。
1）前端信任：
前端信任的目的是通過減少或杜絕開發者后端跟開放平臺OpenAPI交互的方式，來降低開發者接入門檻，減少工作量。主要的做法是通過權限控制、簽名、加密等手段使得小程序能夠在前端拿到可信數據。
2）低代碼(Low-Code)：
由于大量的互聯網業務屬于簡單交互或模型化交互，以此為出發點，基于構建合理模型、簡單業務函數等形式，可以允許開發者通過拖拽組件、簡單偽業務代碼等形式提供編程入口，可以大幅度降低開發者的研發門檻和成本，打破用戶和開發者界線，提高開放平臺整體生態的活力。
3）ServerLess：
基于云原生的ServerLess結合低代碼，開放開發者的云端編程入口，同時提供云端基礎組件，允許開發者無需部署實際的后端應用服務，極大降低的開發者的運營維護門檻。
9.3用戶層面
目前業界主流開放平臺在對用戶本身的服務能力整合和挖掘上，投入的都比較少，也沒有比較成熟的實踐，我們認為在這方面可以圍繞兩個點展開。
一方面：第三方應用治理模式向商城化的轉型。常規開放平臺的應用治理和推廣，基本是應用方獨立管理和推廣，但是隨著應用數量的大幅度增加，以及應用方單方面推廣難度較大等原因，亟需開放平臺從生態整體角度進行支持和治理。這樣可以在安全性、可維護性、便捷性等維度上對應用進行正向反饋，實現開放平臺應用生態的可持續性和能力共享。同時，在特定場景下，結合用戶分析、大數據及AI，提高用戶主動或被動的應用發現能力。
另一方面：構建符合應用間開放協議的軟件聯盟，打破應用壁壘，圍繞服務集成、開放應用的核心原則，使得不同的互聯網業務或行為在一定程度上實現數據/能力共享。一般情況下，一個復雜互聯網業務通常由多個異構子業務/子應用構成，這樣，通過應用拆分、開放共享等形式，在一定程度上使復雜的互聯網業務更加精細化、輕量化、可擴展。
9.4開放平臺標準化、互通
目前國內外各大互聯網公司、機構和組織都搭建了多種開放平臺，用于提供各種各樣的信息服務，在可以預見的未來，各個平臺之間會有一個整合、標準化、互通的可能性。
那么構建標準開放協議，使得開放平臺向底層沉淀的過程則至關重要。
10、 本文小結
通過實現基本IM開放平臺架構，以及各種衍生服務，我們總結出了IM開放平臺的一些核心能力。
主要是：
- 1）服務集成：根據不同的業務場景集成并提供相應場景下的基礎服務能力；
- 2）開放應用：提供第三方接入能力；
- 3）高性能、高可用。
11、參考資料
[1] 零基礎IM開發入門(一)：什么是IM系統？
[2] 從零到卓越：京東客服即時通訊系統的技術架構演進歷程
[3] 瓜子IM智能客服系統的數據架構設計（整理自現場演講，有配套PPT）
[4] 從游擊隊到正規軍(一)：馬蜂窩旅游網的IM系統架構演進之路
[5] 一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐
[6] 淺談IM系統的架構設計
[7] 簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端
[8] 一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)
[9] 一套原創分布式即時通訊(IM)系統理論架構方案
[10] 一套億級用戶的IM架構技術干貨(上篇)：整體架構、服務拆分等
[11] 從新手到專家：如何設計一套億級消息量的分布式IM系統
[12] 企業微信的IM架構設計揭秘：消息模型、萬人群、已讀回執、消息撤回等
[13] 阿里IM技術分享(三)：閑魚億級IM消息系統的架構演進之路
[14] 基于實踐：一套百萬消息量小規模IM系統技術要點總結
[15] 跟著源碼學IM(十)：基于Netty，搭建高性能IM集群（含技術思路+源碼）
[16] 一套十萬級TPS的IM綜合消息系統的架構實踐與思考
[17] 直播系統聊天技術(八)：vivo直播系統中IM消息模塊的架構實踐
[18] 融云技術分享：全面揭秘億級IM消息的可靠投遞機制
[19] 得物從0到1自研客服IM系統的技術實踐之路
[20] 一套分布式IM即時通訊系統的技術選型和架構設計
[21] 微信團隊分享：來看看微信十年前的IM消息收發架構，你做到了嗎
（本文已同步發布于：http://www.52im.net/thread-4690-1-1.html）