作者簡介

?

Jim，攜程高級(jí)研發(fā)經(jīng)理，關(guān)注Java&Go技術(shù)棧后端研發(fā)。目前致力于TripPal開放平臺(tái)的高可用、開放化進(jìn)程及核心衍生服務(wù)。

簡介

攜程內(nèi)部的辦公I(xiàn)M項(xiàng)目最早在2016年立項(xiàng)，經(jīng)歷了初期簡單辦公場景下的純IM服務(wù)，到支持簡單辦公組件的IM應(yīng)用，又演變?yōu)橐惑w化辦公集成平臺(tái)，進(jìn)而演變?yōu)槟壳凹蒊M功能的開放式企業(yè)效率平臺(tái)。本文總結(jié)了這些年的發(fā)展歷程及未來的演進(jìn)方向，并著重從高可用、高性能和可擴(kuò)展的角度，探討開放式平臺(tái)的技術(shù)實(shí)現(xiàn)及發(fā)展方向。

?

一、什么是IM

IM（Instant Message）即時(shí)消息，是一種通過網(wǎng)絡(luò)提供實(shí)時(shí)消息傳輸?shù)脑诰€溝通技術(shù)。在移動(dòng)互聯(lián)網(wǎng)時(shí)代，IM的使用變得越來越廣泛，通過各種技術(shù)手段使得用戶之間的交流成本變的極低，溝通效率和用戶體驗(yàn)有極大的提升。而且IM的出現(xiàn)極大地改變了目前互聯(lián)網(wǎng)應(yīng)用的形態(tài)，多數(shù)互聯(lián)網(wǎng)應(yīng)用只要做到了一定規(guī)模，一定會(huì)有自身IM的需求，而不是單純地僅僅依托第三方（例如微信、云信等）。

?

二、攜程辦公I(xiàn)M的發(fā)展歷程

早期攜程使用微軟的IM軟件lync和自研的純IM軟件CtripTeam來支持企業(yè)內(nèi)的溝通需求，這些軟件在維護(hù)性、拓展性和可用性上都或多或少存在一些缺陷。同時(shí)隨著互聯(lián)網(wǎng)的發(fā)展，也逐漸不適合日益增長的辦公需求和用戶體驗(yàn)。

2017年左右，使用基于ejabberd+erlang的自研IM服務(wù)的Cchat項(xiàng)目應(yīng)運(yùn)而生，該項(xiàng)目的主要目標(biāo)是在采用自研IM的基礎(chǔ)上，實(shí)現(xiàn)IM與辦公的結(jié)合。在完善IM服務(wù)的基礎(chǔ)上，支持了一些常規(guī)的辦公場景，如電話、假單、考勤、OA等，通常采用嵌入外部頁面、跳轉(zhuǎn)外部地址等方式提供服務(wù)。這個(gè)改造項(xiàng)目奠定了攜程辦公I(xiàn)M繼續(xù)發(fā)展的基礎(chǔ)。

隨著項(xiàng)目的深入，最初的系統(tǒng)交互模式及服務(wù)管理模式逐漸不適用越來越復(fù)雜的辦公場景及服務(wù)治理需求。于是在2019年上馬了TripPal的改造項(xiàng)目，在結(jié)合公司國際化戰(zhàn)略的基礎(chǔ)上，傾力打造小程序平臺(tái)，服務(wù)號(hào)等基礎(chǔ)服務(wù)。在梳理、優(yōu)化原有服務(wù)的同時(shí)，打造了諸多衍生服務(wù)。

2020年中開始，在繼續(xù)推進(jìn)企業(yè)內(nèi)辦公一站式平臺(tái)的基礎(chǔ)上，我們需要支持更多的外部場景，實(shí)際需求促使我們向開放式平臺(tái)轉(zhuǎn)型，這在服務(wù)整體架構(gòu)、安全性、擴(kuò)展性等方面都提出了新的要求及挑戰(zhàn)。

?

三、攜程TripPal開放平臺(tái)實(shí)踐

3.1 總體架構(gòu)

3.1.1 Gateway網(wǎng)關(guān)層

這一層是所有請求調(diào)用流量的入口，主要功能如下：

• 服務(wù)路由；

• 集中式限流、風(fēng)控、日志監(jiān)控等功能；

• 調(diào)用IDS (Identity Service) 驗(yàn)證請求的合法性，驗(yàn)證通過后，可以將用戶ID、Token等基本信息，通過 HttpHeader 的方式向后端服務(wù)透傳，后端服務(wù)可以直接使用UserID，也可以再次對Token進(jìn)行認(rèn)證；

3.1.2 IDS (Identity Service) 服務(wù)

IDS同時(shí)支持多種不同類型的訪問令牌的鑒權(quán)，同時(shí)還負(fù)責(zé)令牌的頒發(fā)，以及RBAC+模塊級(jí)別的接口控權(quán)。

另外，針對開放小程序，TripPal提供兩種認(rèn)證方式：

1）常規(guī)的Oauth第三方模式接入。

2）另一種是基于Oauth+開放平臺(tái)簽名的第三方認(rèn)證，對于接入方相對簡單。

?

3.1.3 微服務(wù)層

這一層是整個(gè)系統(tǒng)的業(yè)務(wù)層，具體包含三種類型的微服務(wù)：

• TripPal開放平臺(tái)內(nèi)部系統(tǒng)微服務(wù)，只有在特定用戶認(rèn)證和權(quán)限驗(yàn)證通過之后，外部才能訪問；

• 開放平臺(tái)對外提供的OpenAPI；采用Oauth+RBAC的方式控制權(quán)限；

• 自研小程序后端服務(wù)，根據(jù)安全需要，所有使用Oauth+模塊權(quán)限的第一方小程序服務(wù)端；

目前TripPal自身的核心微服務(wù)應(yīng)用達(dá)到28個(gè)，提供全集團(tuán)的多端（C端、B端）基礎(chǔ)服務(wù)能力，服務(wù)全公司超過500個(gè)業(yè)務(wù)應(yīng)用，在線C端用戶均值超過2萬，日訪問量超過億。

?

3.2 IM服務(wù)

目前TripPal使用完全自研的基于Java實(shí)現(xiàn)的類ejabberd架構(gòu)，底層采用的XMPP協(xié)議進(jìn)行通訊。

Tips：

XMPP全稱是ExtensibleMessageing and Presence Protocol，可擴(kuò)展消息與存在協(xié)議。是目前網(wǎng)絡(luò)上開源，最靈活，應(yīng)用最廣泛的一種即時(shí)消息通信協(xié)議。

1999年Jeremie Miller，首先提出了Jabber，一種為實(shí)現(xiàn)即時(shí)消息和存在的開放技術(shù)，后續(xù)基于這個(gè)協(xié)議，開發(fā)了一個(gè)開源的服務(wù)實(shí)現(xiàn)jabberd。后續(xù)，IETF國際標(biāo)準(zhǔn)組織介入，成立Extensible Messageing and Presence Protocol（XMPP）工作組，并開始標(biāo)準(zhǔn)化工作。

2000年，jabberd服務(wù)器1.0版本發(fā)布，那時(shí)Jabber協(xié)議的基本特點(diǎn)（基于XML的流，消息，存在，聯(lián)系人列表等）都被固定下來。

2004年，IETF出版了RFC 3902和RFC3921，定義了XMPP的核心功能，成為推薦標(biāo)準(zhǔn)。

后續(xù)在2011年，IETF出版了RFC6120和RFC 6121，更新了XMPP的核心定義，替代了之前的RFC 3920和3921。

目前XMPP協(xié)議被XMPP Standards Foundation負(fù)責(zé)管理運(yùn)作，集中于在IETF定義的基礎(chǔ)XMPP規(guī)范之上，如何開發(fā)開放的協(xié)議擴(kuò)展。

IM服務(wù)端做了大量的系統(tǒng)性的優(yōu)化，從底層的數(shù)據(jù)庫調(diào)優(yōu)、底層通訊服務(wù)升級(jí)，到上層消息、群、群成員等核心功能的大幅改造。底層通訊服務(wù)由之前的erlang完整遷移至java技術(shù)棧，服務(wù)可靠性、彈性伸縮、安全性和性能獲得了提升；同時(shí)對上層偏業(yè)務(wù)的服務(wù)進(jìn)行了改造，極大地提升了接口響應(yīng)，服務(wù)穩(wěn)定性也得到了提升，為整個(gè)產(chǎn)品的研發(fā)提供了重要支撐。目前這套自研的IM3.0服務(wù)在生產(chǎn)環(huán)境穩(wěn)定運(yùn)行，整體資源消耗比2.0時(shí)期有較大下降。

?

3.3 TripPal辦公衍生服務(wù)

在實(shí)際的企業(yè)辦公場景下，尤其是大型企業(yè)復(fù)雜組織架構(gòu)和管理模式的場景下，TripPal逐漸摸索出了自己的一套行之有效且契合攜程場景的辦公智能應(yīng)用，如搜索中臺(tái)，消息卡片，智能審批中臺(tái)，角色服務(wù)，工作流引擎等。

本文簡單介紹其中3個(gè)服務(wù)：

1）智能審批中臺(tái)

智能審批中臺(tái)在集成攜程自有的審批系統(tǒng)的同時(shí)也集成了自研的智能審批配置服務(wù)，該服務(wù)支持用戶自定義整個(gè)審批單及審批流的全部細(xì)節(jié)。

2）角色服務(wù)

角色服務(wù)在靈活定義角色范圍及基礎(chǔ)角色的基礎(chǔ)上，支持用戶靈活調(diào)整，動(dòng)態(tài)管理，且自動(dòng)接入審批中臺(tái)，同時(shí)打通應(yīng)用對接渠道。

整個(gè)角色服務(wù)在產(chǎn)品定義上分為如下表4個(gè)主要概念：

系統(tǒng)概念	介紹	管理模式
角色范圍(Scope)	圈定基礎(chǔ)角色的作用范圍，如：平臺(tái)研發(fā)中心	基于父子關(guān)系的層級(jí)管理
基礎(chǔ)角色(Base Role)	由管理員管理并定義的基礎(chǔ)角色，如：管理員、負(fù)責(zé)人、PMO等	平臺(tái)或企業(yè)管理員手動(dòng)管理
固定角色（Role）	由[角色范圍+基礎(chǔ)角色]構(gòu)成的對象，如：平臺(tái)研發(fā)中心管理員	由角色創(chuàng)建者進(jìn)行管理
抽象Role	無角色范圍，僅基于基礎(chǔ)角色創(chuàng)建的角色，指定某些Scope上應(yīng)該自動(dòng)創(chuàng)建該角色的基礎(chǔ)角色	由角色創(chuàng)建者進(jìn)行管理

3）在線文檔

在線文檔服務(wù)主要提供文檔的在線協(xié)作能力，支持用戶同時(shí)/實(shí)時(shí)的查看、編輯、保存和分享的能力。同時(shí)結(jié)合IM實(shí)現(xiàn)通知和反饋等功能。

技術(shù)實(shí)現(xiàn)上，在線文檔是采用CRDT算法實(shí)現(xiàn)的無沖突merge（LastWrite Wins）、多端最終一致的分布式方案，同時(shí)兼具高可用、可容錯(cuò)的特性，在服務(wù)器發(fā)生故障時(shí)，允許Shift至另一臺(tái)機(jī)器上繼續(xù)執(zhí)行，即使服務(wù)端完全宕機(jī)，客戶端依然能夠離線工作。

?

四、TripPal高可用的實(shí)踐

目前TripPal部署在3個(gè)機(jī)房，分為公有云1個(gè)機(jī)房及私有云2個(gè)機(jī)房。總體架構(gòu)在應(yīng)用多機(jī)房部署、數(shù)據(jù)層跨機(jī)房DRC的基礎(chǔ)上，采用就近訪問的原則進(jìn)行服務(wù)訪問，其中一旦發(fā)生任意2個(gè)機(jī)房全掛的情況，都能保證系統(tǒng)內(nèi)的核心應(yīng)用仍能提供服務(wù)。其中公有云機(jī)房的一期部署方案已經(jīng)完成，二期部署方案和測試計(jì)劃預(yù)計(jì)于7月完成，屆時(shí)可以和大家分享一下混合云方案的一些細(xì)節(jié)和歷程。

?

五、開放平臺(tái)的未來架構(gòu)及演進(jìn)方向

開放平臺(tái)主要面向兩類群體，開發(fā)者和用戶。所以主要有兩個(gè)方向，一是便捷開發(fā)，主要圍繞降低開發(fā)者門檻、較低研發(fā)成本，打通不同開發(fā)者、應(yīng)用之間的壁壘，實(shí)現(xiàn)生態(tài)共享。另一方面，針對實(shí)際用戶，在提高用戶體驗(yàn)、數(shù)據(jù)安全的同時(shí)，實(shí)現(xiàn)用戶服務(wù)能力整合和主動(dòng)發(fā)現(xiàn)。

5.1 開發(fā)者

在這方面，目前主流開放平臺(tái)已經(jīng)對開發(fā)者提供了強(qiáng)大的支持，主要形式分為：

1）前端信任

前端信任的目的是通過減少或杜絕開發(fā)者后端跟開放平臺(tái)OpenAPI交互的方式，來降低開發(fā)者接入門檻，減少工作量。主要的做法是通過權(quán)限控制、簽名、加密等手段使得小程序能夠在前端拿到可信數(shù)據(jù)。

2）低代碼(Low-Code)

由于大量的互聯(lián)網(wǎng)業(yè)務(wù)屬于簡單交互或模型化交互，以此為出發(fā)點(diǎn)，基于構(gòu)建合理模型、簡單業(yè)務(wù)函數(shù)等形式，可以允許開發(fā)者通過拖拽組件、簡單偽業(yè)務(wù)代碼等形式提供編程入口，可以大幅度降低開發(fā)者的研發(fā)門檻和成本，打破用戶和開發(fā)者界線，提高開放平臺(tái)整體生態(tài)的活力。

3）ServerLess

基于云原生的ServerLess結(jié)合低代碼，開放開發(fā)者的云端編程入口，同時(shí)提供云端基礎(chǔ)組件，允許開發(fā)者無需部署實(shí)際的后端應(yīng)用服務(wù)，極大降低的開發(fā)者的運(yùn)營維護(hù)門檻。

5.2 用戶層面

目前業(yè)界主流開放平臺(tái)在對用戶本身的服務(wù)能力整合和挖掘上，投入的都比較少，也沒有比較成熟的實(shí)踐，我們認(rèn)為在這方面可以圍繞兩個(gè)點(diǎn)展開。

一方面，第三方應(yīng)用治理模式向商城化的轉(zhuǎn)型。常規(guī)開放平臺(tái)的應(yīng)用治理和推廣，基本是應(yīng)用方獨(dú)立管理和推廣，但是隨著應(yīng)用數(shù)量的大幅度增加，以及應(yīng)用方單方面推廣難度較大等原因，亟需開放平臺(tái)從生態(tài)整體角度進(jìn)行支持和治理。這樣可以在安全性、可維護(hù)性、便捷性等維度上對應(yīng)用進(jìn)行正向反饋，實(shí)現(xiàn)開放平臺(tái)應(yīng)用生態(tài)的可持續(xù)性和能力共享。同時(shí)，在特定場景下，結(jié)合用戶分析、大數(shù)據(jù)及AI，提高用戶主動(dòng)或被動(dòng)的應(yīng)用發(fā)現(xiàn)能力。

另一方面，構(gòu)建符合應(yīng)用間開放協(xié)議的軟件聯(lián)盟，打破應(yīng)用壁壘，圍繞服務(wù)集成、開放應(yīng)用的核心原則，使得不同的互聯(lián)網(wǎng)業(yè)務(wù)或行為在一定程度上實(shí)現(xiàn)數(shù)據(jù)/能力共享。一般情況下，一個(gè)復(fù)雜互聯(lián)網(wǎng)業(yè)務(wù)通常由多個(gè)異構(gòu)子業(yè)務(wù)/子應(yīng)用構(gòu)成，這樣，通過應(yīng)用拆分、開放共享等形式，在一定程度上使復(fù)雜的互聯(lián)網(wǎng)業(yè)務(wù)更加精細(xì)化、輕量化、可擴(kuò)展。

5.3 開放平臺(tái)標(biāo)準(zhǔn)化、互通

目前國內(nèi)外各大互聯(lián)網(wǎng)公司、機(jī)構(gòu)和組織都搭建了多種開放平臺(tái)，用于提供各種各樣的信息服務(wù)，在可以預(yù)見的未來，各個(gè)平臺(tái)之間會(huì)有一個(gè)整合、標(biāo)準(zhǔn)化、互通的可能性。那么構(gòu)建標(biāo)準(zhǔn)開放協(xié)議，使得開放平臺(tái)向底層沉淀的過程則至關(guān)重要。

六、總結(jié)

通過實(shí)現(xiàn)基本IM開放平臺(tái)架構(gòu)，以及各種衍生服務(wù)，我們總結(jié)出了IM開放平臺(tái)的一些核心能力：

• 服務(wù)集成，根據(jù)不同的業(yè)務(wù)場景集成并提供相應(yīng)場景下的基礎(chǔ)服務(wù)能力

• 開放應(yīng)用，提供第三方接入能力

• 高性能，高可用

【參考文獻(xiàn)】

[1] Facebook messager技術(shù)文檔：Scalingthe Messages Application Back End‘’

[2]?Facebook messager技術(shù)文檔：BuildingMobile-First Infrastructure for Messenger

[3]?淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)

[4]?一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案

[5]?微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)

【推薦閱讀】

• 多業(yè)務(wù)線億級(jí)體量，攜程是怎么做賬務(wù)中臺(tái)的

• 分布式緩存與DB秒級(jí)一致設(shè)計(jì)實(shí)踐

• 攜程多語言平臺(tái)-Shark系統(tǒng)的高可用演進(jìn)之路

• 攜程Elasticsearch數(shù)據(jù)同步實(shí)踐

?“攜程技術(shù)”公眾號(hào)

? 分享，交流，成長

總結(jié)

以上是生活随笔為你收集整理的干货 | 日访问过亿，办公IM及开放式平台在携程的实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。