本文由携程技术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开放平台的一些核心能力。（本文已同步发布于：http://www.52im.net/thread-4690-1-1.html）
主要是：
- 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消息收发架构，你做到了吗
