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、多業務的快速發展。
本篇文章力圖從大前端各個方面去整理總結攜程當前的技術體系，但一定會有許多遺漏，同時開放信息畢竟有限，希望相關同學可以一起多多交流。
這是大廠前端技術體系解密系列第四篇，后續還會有其他大廠的內容，精彩還將繼續，有興趣的同學可以關注本公眾號【奶爸碼農】第一時間獲得信息。
推薦閱讀
『奶爸碼農』從事互聯網研發工作10+年，經歷IBM、SAP、陸金所、攜程等國內外IT公司，目前在美團負責餐飲相關大前端技術團隊，定期分享關於大前端技術、投資理財、個人成長的思考與總結。