解密中國BAT等大廠前端技術體系-攜程篇（長文建議收藏）

• 2019 年 12 月 4 日
• 筆記

引言

進入2019年，大前端技術生態似乎進入到了一個相對穩定的環境，React在2013年發布至今已經6年時間了，Vue 1.0在2015年發布，至今也有4年時間了。

整個業界在前端框架不斷迭代中，也尋找到了許多突破方向，例如跨平台中的RN、Flutter，服務端GraphQL、Serverless，前端和客戶端的融合越來越緊密，前端在Node和Electron的加持下，也擴展了自己的版圖到服務端和桌面。

同時，隨著前端開發越來越複雜，整個前端研發也經歷了人工化->工具化->工程化->智慧化的演變。目前各個大廠在工程化實踐不斷迭代，出現了許多Low/No Code等前端智慧化解決方案，工程化實踐也深入到研發的各個環節，不斷提升前端研發的標準化能力。而且，隨著機器學習的加入，各類UI2Code的解決方案也開始出現，前端研發進入了一個完全不同的時代。

隨著端上能力的不斷增強，現在在端上做的事情越來越多。首先，數據可視化方向，各類圖表、地圖、3D等等數據可視化的嘗試變得越來越多。其次，伴隨著人工智慧的加持，在端上的人工智慧應用也變的普及，減少了服務端的交互，提高了系統的實時響應能力。最後，隨著Webassembly等技術的應用，有可能將前端運行能力再提升一個檔次，可以進行更為複雜的端上計算。

為了了解當前前端的發展趨勢，讓我們從中國各大互聯網大廠開始，了解他們的最新動態和未來規劃。

這是解密大廠前端技術體系的第四篇，前三篇已經講述了阿里、騰訊、百度在前端技術這幾年的技術發展，這一篇講講攜程。

攜程技術全景圖

移動技術產品

移動技術產品分為四大模組：

• 技術平台：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框架的穩定性問題。為了解決首屏渲染性能問題，我們先後開發了框架拆分和預載入、業務按需載入、業務預載入和漸進式渲染方案，稍後會就這些方案做詳細介紹。
• 發布運維，主要是提供發布系統和性能、錯誤監控平台，讓業務開發同事能夠有完備的系統去發現和解決線上問題。

Node平台

攜程在2017年9月份正式上線了Node.js應用，歷經2年時間，應用數實現了8倍增長，覆蓋公司33個業務部門。

Node.js的工程化建設，涵蓋開發、構建、測試、發布、運維各個環節：

• 開發：根據業務場景提供不同的腳手架工程（SSR、DA Service、Desktop Application），提供核心中間件、數據Mock平台、Docker化的開發環境。
• 構建：安裝依賴包，檢查依賴包版本，構建目標文件，同時提供程式碼靜態掃描，安全掃描的能力。
• 測試：提供自動化測試，集成測試，灰度測試和壓力測試
• 發布：提供攜程雲和公有雲發布能力，灰度發布和回滾能力，實現內部npm包開發發布流程與Git高度集成
• 運維：日誌監控和應用排障的能力

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 架構等。

寫在最後

攜程在組織架構上有基礎研發團隊進行保障，在大前端領域能夠收斂、沉澱眾多的基礎平台服務、技術框架，形成了一套比較完整、統一的基礎框架能力，很好的支撐了多App、多業務的快速發展。

本篇文章力圖從大前端各個方面去整理總結攜程當前的技術體系，但一定會有許多遺漏，同時開放資訊畢竟有限，希望相關同學可以一起多多交流。