携程技术分享：亿级流量的办公 IM 及开放平台技术实践

作者：JackJiang

2024-08-29
江苏
本文字数：4638 字
阅读完需：约 15 分钟

本文由携程技术 Jim 分享，原题“日访问过亿，办公 IM 及开放式平台在携程的实践”，下文进行了排版和内容优化。

1、引言

携程内部的办公 IM 项目最早在 2016 年立项，经历了初期简单办公场景下的纯 IM 服务，到支持简单办公组件的 IM 应用，又演变为一体化办公集成平台，进而演变为目前集成 IM 功能的开放式企业效率平台。

本文总结了携程办公 IM 这些年的发展历程及未来的演进方向，并着重从高可用、高性能和可扩展的角度，探讨开放式平台的技术实现及发展方向。

技术交流：

- 移动端 IM 开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源 IM 框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4690-1-1.html）

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，提高用户主动或被动的应用发现能力。

另一方面：构建符合应用间开放协议的软件联盟，打破应用壁垒，围绕服务集成、开放应用的核心原则，使得不同的互联网业务或行为在一定程度上实现数据/能力共享。一般情况下，一个复杂互联网业务通常由多个异构子业务/子应用构成，这样，通过应用拆分、开放共享等形式，在一定程度上使复杂的互联网业务更加精细化、轻量化、可扩展。