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