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

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

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

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

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

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

我自己是一名從事了多年開發的web前端老程序員，目前辭職在做自己的web前端私人定制課程，今年年初我花了一個月整理了一份最適合2019年學習的web前端學習干貨，各種框架都有整理，送給每一位前端小伙伴，想要獲取的可以關注我的頭條號并在后臺私信我：前端，即可免費獲取。

攜程技術全景圖

移動技術產品

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

• 技術平臺：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。根據不同的頁面形態，制定了不同的性能指標。

• 異常處理：收集異?？D的情況并且自動歸屬到不同業務團隊，崩潰信息收集可以固化下來用戶的操作路徑和相關信息。

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、多業務的快速發展。

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

這是大廠前端技術體系解密系列第四篇，后續還會有其他大廠的內容，精彩還將繼續，有興趣的同學可以關注小編，第一時間獲得信息。

原文鏈接：https://mp.weixin.qq.com/s/IbORf-lQOLyaS8sBO5ILOw
作者：奶爸碼農

推薦閱讀：陽高縣桑星緯手機發貨中心