解密国内BAT等大厂前端技术体系-携程篇（长文建议收藏）

1 引言

为了了解当前前端的发展趋势，让咱们从国内各大互联网大厂开始，了解他们的最新动态和将来规划。这是解密大厂前端技术体系的第四篇，前三篇已经讲述了阿里、腾讯、百度在前端技术这几年的技术发展。

这一篇从携程讲起。

携程技术全景图

移动技术产品

移动技术产品分为四大模块：

• 技术平台：MCD（持续交付平台），APM（性能监控平台），MTS（日志排障平台）和MTP（无线技术平台）
• 通讯层：通讯工具，消息推送平台，服务端推送
• 框架层：涵盖App中通用能力，例如设备信息、位置信息、热更新、网络通讯、配置、用户行为埋点等等
• 业务层：通用的业务组件，例如分享功能、多媒体、日历、地图等等

大前端技术框架

携程在大前端技术框架层面主要面向不一样应用场景沉淀了三个技术框架：

• CRN框架：Ctrip React Native，基于RN定制化的框架，而且完善了周边的打包、部署、监控等等能力
• Node平台：Node服务的框架，涵盖从编码、编译、发布、监控全流程
• Hybrid平台：用于App内Hybrid WebView框架

新技术探索

• 新技术：HTTP/2，VOIP
• 新产品：小程序、快应用、VR/AR

MCD - 持续交付平台

MCD经历了屡次大型迭代，逐步成为携程内部持续交付平台，涵盖了集成阶段、测试阶段、发布阶段和运营阶段的全流程研发环节。

MCD 1.0

MCD1.0的出现解决了系统在线打包的问题，而且经过CI/CD实现定时打包、代码静态扫描、自动化验包-白屏监测的能力。

持续集成阶段接入了代码扫描和冒烟测试的功能，经过infer和sonar进行代码的静态检查，而且统一集成单元测试能力，提供单测的结果和覆盖率。

冒烟测试能够监测白屏状况，而且进行多机型兼容测试，经过内容和图像对比提早发现问题。

经过集成编译，持续减低App编译的时长，提升研发测试效率。

MCD 2.0

MCD 2.0从新定义了MCD，涵盖了更为普遍的范围，包含集成、测试、发布、运营环节。而且由各个模块各自打包生成Bundle，再经过Bundle集成达到2~3分钟极速出包的能力。

同时MCD也加强了许多能力：

• 发布升级：对于Hotfix、Bundle、Hybrid/RN等内容实现动态下发，实现白名单、灰度发布能力，经过差分方式提升下载效率，而且提供大盘实时查看下发状况。
• 配置中心：支持按照平台、版本、渠道、ABTest等不一样维度下发配置信息，实现App配置信息管理能力。
• 崩溃收集：App Crash/JS Error的收集，而且支持实时告警，多维度搜索，代码反查等能力。
• App Size管理：基于业务模块进行App包大小管理

APM - 性能监控平台

APM性能监控平台主要关注性能、崩溃、异常等数据的监控，携程在性能与异常监控上也作了许多工做：

• 网络性能：收敛了网络通讯SDK，统一了三端的网络通讯底层能力，网络SDK能够统一管理IP池、链路池、请求池，达到性能最优化。而且能够监控在网络请求全链路中的错误状况，实现业务场景联通成功率99%。

• 页面性能：在页面性能统计口径上采用TTI，经过遍历检测页面文本的变化来判断是否到达TTI。根据不一样的页面形态，制定了不一样的性能指标。

• 异常处理：收集异常卡顿的状况而且自动归属到不一样业务团队，崩溃信息收集能够固化下来用户的操做路径和相关信息。

MTS - 日志排障平台

收集App中全部相关数据，例如网络请求、页面跳转、图片请求、用户行为埋点、Cat日志、Web服务日志，而且经过时间轴将全部数据串联起来，能够帮助研发同窗快速还原现场排查问题。

在日志展现上以一次用户session为集合，按照时间轴显示不一样的页面信息，同时在每一个页面的详细信息中会提供当前页面全部的网络请求、用户行为埋点、研发自主埋点等等内容。

MTP - 无线技术平台

打造无线技术平台，将App中通用能力沉淀下来，而且复用到多个App中，避免重复造轮子，提升研发标准化与效率。同时平台治理提供例如注册服务、排查故障、服务熔断、查看调用等功能，方便平台化技术的运营。

CRN - Ctrip React Native

CRN是携程内部基于React Native进行深度定制的移动端跨平台/动态化框架，目前已经在实际的业务项目中大规模应用，页面规模超过100个，PV数目已经超过传统Hybrid H5页面的2倍多。

基于React Native框架优化，定制成适合携程业务的跨平台开发框架 - CRN，提供从开发、发布、运维的全生命周期支持。

• 开发框架，主要是提供在开发阶段的支持。包括工具&文档、组件和解决方案、跨平台打通和代码托管功能。 工具主要包括CLI和Packer，文档包括API文档和设计文档，跨平台主要是抹平平台差别组件间的API，代码托管是为了方便业务团队，特别是新加入CRN开发的团队，能够参考已有业务代码快速上手。

• 性能优化，主要是为了解决首屏渲染的性能问题和RN框架的稳定性问题。为了解决首屏渲染性能问题，咱们前后开发了框架拆分和预加载、业务按需加载、业务预加载和渐进式渲染方案，稍后会就这些方案作详细介绍。

• 发布运维，主要是提供发布系统和性能、错误监控平台，让业务开发同事可以有完备的系统去发现和解决线上问题。

详细信息能够查看：干货 | 近万字长文详述携程大规模应用RN的工程化实践

Node平台

携程在2017年9月份正式上线了Node.js应用，历经2年时间，应用数实现了8倍增加，覆盖公司33个业务部门。

Node.js的工程化建设，涵盖开发、构建、测试、发布、运维各个环节：

• 开发：根据业务场景提供不一样的脚手架工程（SSR、DA Service、Desktop Application），提供核心中间件、数据Mock平台、Docker化的开发环境。
• 构建：安装依赖包，检查依赖包版本，构建目标文件，同时提供代码静态扫描，安全扫描的能力。
• 测试：提供自动化测试，集成测试，灰度测试和压力测试
• 发布：提供携程云和公有云发布能力，灰度发布和回滚能力，实现内部npm包开发发布流程与Git高度集成
• 运维：日志监控和应用排障的能力

详细信息能够查看：干货 | 浅谈Node.js在携程的应用

GraphQL-BFF

GraphQL-BFF 的核心思路是，将多个 services 整合成一个中心化 data graph。

每一个 service 的数据结构契约，都放入了一个大而全的 GraphQL Schema 里；若是不作任何模块化和解耦，开发体验将会很是糟糕。每一个团队成员，都去修改同一份 Schema 文件。

这明显是不合理的。GraphQL-BFF 的开发模式，应该跟 service 的领域模型，有一一对应的关系。而后经过某种形式，多个 services 天然整合到一块儿。

技术选型上，开发语言选用了 TypeScript，跑在 Node.js v10.x 版本上，服务端框架是 Koa v2.x 版本，使用 apollo-server-koa 模块去运行 GraphQL 服务。

Apollo-GraphQL 是 Node.js 社区里，比较知名和成熟的 GraphQL 框架。作了不少的细节工做，也有一些相对前沿的探索，好比 Apollo Federation 架构等。

详细信息能够查看：干货 | 万字长文全面解析GraphQL，携程微服务背景下的先后端数据交互方案

写在最后

携程在组织架构上有基础研发团队进行保障，在大前端领域可以收敛、沉淀众多的基础平台服务、技术框架，造成了一套比较完整、统一的基础框架能力，很好的支撑了多App、多业务的快速发展。

本篇文章力图从大前端各个方面去整理总结携程当前的技术体系，但必定会有许多遗漏，同时开放信息毕竟有限，但愿相关同窗能够一块儿多多交流。

这是大厂前端技术体系解密系列第四篇，后续还会有其余大厂的内容，精彩还将继续，有兴趣的同窗能够关注本公众号【奶爸码农】第一时间得到信息。

推荐阅读

解密国内BAT等大厂前端技术体系-阿里篇（长文建议收藏）

解密国内BAT等大厂前端技术体系-百度篇（长文建议收藏）

解密国内BAT等大厂前端技术体系-腾讯篇（长文建议收藏）

『奶爸码农』从事互联网研发工做10+年，经历IBM、SAP、陆金所、携程等国内外IT公司，目前在美团负责餐饮相关大前端技术团队，按期分享关于大前端技术、投资理财、我的成长的思考与总结。