解密國內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公司，目前在美團負責餐飲相關大前端技術團隊，按期分享關於大前端技術、投資理財、我的成長的思考與總結。