干货 | 日访问过亿，办公IM及开放式平台在携程的实践

关注

原创最新推荐文章于 2026-09-14 08:00:11 发布 1.7k 阅读 AI 写同款· GEO 优化 ›

信息论实战指南：给忙碌从业者的认知压缩与降噪工具信息论不仅是通信工程的数学基础，更是现代知识工作者应对信息过载的核心思维操作系统。它通过‘熵’量化信息价值，用‘信道容量’解释认知带宽限制，借‘冗余设计’实现跨角色精准传达。在产品经理写周报、程序员写注释、市场人写文案等真实场景中，信息论提供可立即落地的判断标尺——比如用‘惊讶度’替代抽象公式来识别高价值信息，按接收者身份动态配置30%或60%冗余以保障解码成功率。这种从原理到动作的转化，让信息论摆脱数学神殿，成为每个赶时间的人随身携带的‘信息秤’与‘认知滤网’。阅读详情

作者简介

Jim，携程高级研发经理，关注Java&Go技术栈后端研发。目前致力于TripPal开放平台的高可用、开放化进程及核心衍生服务。

简介

携程内部的办公IM项目最早在2016年立项，经历了初期简单办公场景下的纯IM服务，到支持简单办公组件的IM应用，又演变为一体化办公集成平台，进而演变为目前集成IM功能的开放式企业效率平台。本文总结了这些年的发展历程及未来的演进方向，并着重从高可用、高性能和可扩展的角度，探讨开放式平台的技术实现及发展方向。

一、什么是IM

IM（Instant Message）即时消息，是一种通过网络提供实时消息传输的在线沟通技术。在移动互联网时代，IM的使用变得越来越广泛，通过各种技术手段使得用户之间的交流成本变的极低，沟通效率和用户体验有极大的提升。而且IM的出现极大地改变了目前互联网应用的形态，多数互联网应用只要做到了一定规模，一定会有自身IM的需求，而不是单纯地仅仅依托第三方（例如微信、云信等）。

二、携程办公IM的发展历程

早期携程使用微软的IM软件lync和自研的纯IM软件CtripTeam来支持企业内的沟通需求，这些软件在维护性、拓展性和可用性上都或多或少存在一些缺陷。同时随着互联网的发展，也逐渐不适合日益增长的办公需求和用户体验。

2017年左右，使用基于ejabberd+erlang的自研IM服务的Cchat项目应运而生，该项目的主要目标是在采用自研IM的基础上，实现IM与办公的结合。在完善IM服务的基础上，支持了一些常规的办公场景，如电话、假单、考勤、OA等，通常采用嵌入外部页面、跳转外部地址等方式提供服务。这个改造项目奠定了携程办公IM继续发展的基础。

随着项目的深入，最初的系统交互模式及服务管理模式逐渐不适用越来越复杂的办公场景及服务治理需求。于是在2019年上马了TripPal的改造项目，在结合公司国际化战略的基础上，倾力打造小程序平台，服务号等基础服务。在梳理、优化原有服务的同时，打造了诸多衍生服务。

2020年中开始，在继续推进企业内办公一站式平台的基础上，我们需要支持更多的外部场景，实际需求促使我们向开放式平台转型，这在服务整体架构、安全性、扩展性等方面都提出了新的要求及挑战。

三、携程TripPal开放平台实践

3.1 总体架构

3.1.1 Gateway网关层

这一层是所有请求调用流量的入口，主要功能如下：

服务路由；
集中式限流、风控、日志监控等功能；
调用IDS (Identity Service) 验证请求的合法性，验证通过后，可以将用户ID、Token等基本信息，通过 HttpHeader 的方式向后端服务透传，后端服务可以直接使用UserID，也可以再次对Token进行认证；

3.1.2 IDS (Identity Service) 服务

IDS同时支持多种不同类型的访问令牌的鉴权，同时还负责令牌的颁发，以及RBAC+模块级别的接口控权。

另外，针对开放小程序，TripPal提供两种认证方式：

1）常规的Oauth第三方模式接入。

2）另一种是基于Oauth+开放平台签名的第三方认证，对于接入方相对简单。

3.1.3 微服务层

这一层是整个系统的业务层，具体包含三种类型的微服务：

TripPal开放平台内部系统微服务，只有在特定用户认证和权限验证通过之后，外部才能访问；
开放平台对外提供的OpenAPI；采用Oauth+RBAC的方式控制权限；
自研小程序后端服务，根据安全需要，所有使用Oauth+模块权限的第一方小程序服务端；

目前TripPal自身的核心微服务应用达到28个，提供全集团的多端（C端、B端）基础服务能力，服务全公司超过500个业务应用，在线C端用户均值超过2万，日访问量超过亿。

3.2 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技术栈，服务可靠性、弹性伸缩、安全性和性能获得了提升；同时对上层偏业务的服务进行了改造，极大地提升了接口响应，服务稳定性也得到了提升，为整个产品的研发提供了重要支撑。目前这套自研的IM3.0服务在生产环境稳定运行，整体资源消耗比2.0时期有较大下降。

3.3 TripPal办公衍生服务

在实际的企业办公场景下，尤其是大型企业复杂组织架构和管理模式的场景下，TripPal逐渐摸索出了自己的一套行之有效且契合携程场景的办公智能应用，如搜索中台，消息卡片，智能审批中台，角色服务，工作流引擎等。

本文简单介绍其中3个服务：

1）智能审批中台

智能审批中台在集成携程自有的审批系统的同时也集成了自研的智能审批配置服务，该服务支持用户自定义整个审批单及审批流的全部细节。

2）角色服务

角色服务在灵活定义角色范围及基础角色的基础上，支持用户灵活调整，动态管理，且自动接入审批中台，同时打通应用对接渠道。

整个角色服务在产品定义上分为如下表4个主要概念：

系统概念	介绍	管理模式
角色范围(Scope)	圈定基础角色的作用范围，如：平台研发中心	基于父子关系的层级管理
基础角色(Base Role)	由管理员管理并定义的基础角色，如：管理员、负责人、PMO等	平台或企业管理员手动管理
固定角色（Role）	由[角色范围+基础角色]构成的对象，如：平台研发中心管理员	由角色创建者进行管理
抽象Role	无角色范围，仅基于基础角色创建的角色，指定某些Scope上应该自动创建该角色的基础角色	由角色创建者进行管理

3）在线文档

在线文档服务主要提供文档的在线协作能力，支持用户同时/实时的查看、编辑、保存和分享的能力。同时结合IM实现通知和反馈等功能。

技术实现上，在线文档是采用CRDT算法实现的无冲突merge（LastWrite Wins）、多端最终一致的分布式方案，同时兼具高可用、可容错的特性，在服务器发生故障时，允许Shift至另一台机器上继续执行，即使服务端完全宕机，客户端依然能够离线工作。

四、TripPal高可用的实践

目前TripPal部署在3个机房，分为公有云1个机房及私有云2个机房。总体架构在应用多机房部署、数据层跨机房DRC的基础上，采用就近访问的原则进行服务访问，其中一旦发生任意2个机房全挂的情况，都能保证系统内的核心应用仍能提供服务。其中公有云机房的一期部署方案已经完成，二期部署方案和测试计划预计于7月完成，届时可以和大家分享一下混合云方案的一些细节和历程。

五、开放平台的未来架构及演进方向

开放平台主要面向两类群体，开发者和用户。所以主要有两个方向，一是便捷开发，主要围绕降低开发者门槛、较低研发成本，打通不同开发者、应用之间的壁垒，实现生态共享。另一方面，针对实际用户，在提高用户体验、数据安全的同时，实现用户服务能力整合和主动发现。

5.1 开发者

在这方面，目前主流开放平台已经对开发者提供了强大的支持，主要形式分为：

1）前端信任

前端信任的目的是通过减少或杜绝开发者后端跟开放平台OpenAPI交互的方式，来降低开发者接入门槛，减少工作量。主要的做法是通过权限控制、签名、加密等手段使得小程序能够在前端拿到可信数据。

2）低代码(Low-Code)

由于大量的互联网业务属于简单交互或模型化交互，以此为出发点，基于构建合理模型、简单业务函数等形式，可以允许开发者通过拖拽组件、简单伪业务代码等形式提供编程入口，可以大幅度降低开发者的研发门槛和成本，打破用户和开发者界线，提高开放平台整体生态的活力。

3）ServerLess

基于云原生的ServerLess结合低代码，开放开发者的云端编程入口，同时提供云端基础组件，允许开发者无需部署实际的后端应用服务，极大降低的开发者的运营维护门槛。

5.2 用户层面

目前业界主流开放平台在对用户本身的服务能力整合和挖掘上，投入的都比较少，也没有比较成熟的实践，我们认为在这方面可以围绕两个点展开。

一方面，第三方应用治理模式向商城化的转型。常规开放平台的应用治理和推广，基本是应用方独立管理和推广，但是随着应用数量的大幅度增加，以及应用方单方面推广难度较大等原因，亟需开放平台从生态整体角度进行支持和治理。这样可以在安全性、可维护性、便捷性等维度上对应用进行正向反馈，实现开放平台应用生态的可持续性和能力共享。同时，在特定场景下，结合用户分析、大数据及AI，提高用户主动或被动的应用发现能力。

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

5.3 开放平台标准化、互通

目前国内外各大互联网公司、机构和组织都搭建了多种开放平台，用于提供各种各样的信息服务，在可以预见的未来，各个平台之间会有一个整合、标准化、互通的可能性。那么构建标准开放协议，使得开放平台向底层沉淀的过程则至关重要。

六、总结

通过实现基本IM开放平台架构，以及各种衍生服务，我们总结出了IM开放平台的一些核心能力：