歷史的發展
12~13 年，飛豬核心業務主要基於 PC 平臺，前後端研發協作核心痛點在於動態模板的編寫，不同團隊前後端常圍繞 “套模板” 工作的歸屬引發矛盾。
到 14、15 年 All in 無線的過程中，為了解決從 PC 時代複雜行業數據到無線網關的快速轉換，飛豬成立了無線服務端團隊來完成數據到端側的膠水層工作，可很好解決系列問題，但是持續重複的包接口也讓無線服務端面臨的成長和沉澱問題，不太可持續的。
16、17 年無線服務端技術建設穩定後，也由於上述問題，接口封裝的工作逐步由下放到行業後端同學，隨著 H5/Weex/iOS/Android 多端發展，各自對接口的訴求難以一致，出現通過 Node BFF 層來承接膠水問題，但前端運維能力不強、長尾機器的浪費導致很難全量 BFF 化。
到 18 年飛豬平臺化改造完成，業務由縱向行業變成橫向平臺承接，需求的落地需要經過多方的協作和排期，中間層的碎片化也更加嚴重，對前後端協作成本帶來了更大的挑戰，同時不能通過單領域問題的解決方案(如下單頁解決方案)來解決其他業務層問題， 急需一輕量通用的方案來解決日益嚴重的膠水層的協作 。
建設目標
基於以上背景與問題分析，飛豬去年5月份啟動了 「天空之城」- Serverless 技術體系建設專項，項目總體目標：
構建飛豬 Serverless 研發基礎設施，賦能上層產品/平臺，推動前端/後端、業務/平臺、領域間研發協同向更高效、職能聚焦的模式演進，縮短創新業務研發落地週期，提高研發資源投入產出比。
- 中短期：清晰職能邊界（前端/後端、業務/平臺）、創新業務孵化（misc 類服務、平臺能力補缺）
- 中長期：降成本（研發、機器）、免運維（降低大促場景壓測等運維投入）、存量長尾遷移（建設 CaaS 能力）
最近半年
上半年完成了系列的基礎設施建設，經歷過集團基設施調研和多 BU 溝通，圍繞飛豬前後端合作開發以及業務的痛點制定解決目標，到空島研發平臺和網關的建設，和集團深度共建統一 FaaS 研發平臺，以及圍繞各種開發體驗、穩定性的建設，讓整體 Serverless 達到 可用 狀態。
但是當時整體距離飛豬 Serverless 體系 基建完善度以及好用 還存在一段距離，面臨著穩定性需強保障、BaaS 能力不全、工程鏈路不便捷、業務試點節奏感差這 4 個急需解決的問題。
在這個情況下，我們下半年【 啟動飛豬 Serverless 體系二期 】，在夯實 Serverless 技術體系建設上，尋找到前端研發體系升級和 Serverless 結合的突破口， 圍繞推進 Serverless 基礎設施升級、監控穩定性增強、研發體驗和工程化升級、前後端一體化業務最佳實踐 4 方面進行 。
現階段完成多業務場景試點探索，同時 Serverless 技術建設滿足業務的使用，完成試探期 -> 可用期階段，下一個主要目標為業務場景的範圍鋪開，用於產生更大的價值。
想借此總結給大家同步我們這最近半年的一些技術建設成果，可能有一些你需要的能力正好解你之急。很歡迎一起討論，如有理解偏差或者描述不清晰的點，歡迎大夥直接指出或者提出建議。
先說落地
談到技術體系，首先需要考慮到她對業務的價值體現，包括如何衡量其帶來的差異化價值。
首先給大夥同步 Serverless 在飛豬業務場景的落地效果， 目前一年飛豬 Serverless 累計在高鐵遊、交通搜索、飛豬發佈評論器、資源位管理平臺、簽證、WIFI、周邊遊、旅行任意門、旅行購、超級新發現、門票、POI、發現視頻、新人專區、找相似、泰坦、小程序 URL 管理、收藏/行程、船票、德鐵、PC 內容詳情全切 FaaS SSR、直播、統一目的地、投放平臺發券/圈人/發佈活動等 25 個場景使用探通，其中 S2 上線 10 個函數組，主要聚集在新業務新類型場景上面的落地工作，包括飛豬側各前端團隊也均使用中，同時也有 不少“特別代表性”的場景業務 ：
- Rax 一體化場景 ：我們完成了出境購 Rax + FaaS 一體化項目落地，中間有不少地方拉上集團同學一起支持完善，也是集團第一個 Weex 一體化業務的上線；
- 通用搜索能力架構 ：機票組同學他們利用 Serverless 來做 交通線的搜索架構 能力，設計好對應的搜索通用能力，賦能到後面的船票、德鐵搜索的使用；
- 中後臺一體化場景 ：利用 Ant Design Pro + Serverless 一體化能力以及數據庫連接快速上線飛豬參數透傳管控平臺，省去了應用、域名申請複雜流程，更輕量化使用
- 飛豬 SEO SSR 能力落地 ：飛豬側 SEO 平臺在去年給飛豬用戶拉新，搜索排名帶來了很大的價值，但是想快速落地一個 SSR 頁面，其實還是需要不少服務端的能力，目前跑通飛豬攻略頁面的 SSR 過程，可以像開發函數一樣來開發我們的 SSR，使用上也非常簡單，期待後面帶來更大價值
能力夯實
可以通過如下一圖近半年我們的一些建設事項，通過一體化開發模式來讓前端同學逐步具備產品化的開發思想，BaaS 能力的擴充將可做的事情向下再 down 一層，監控一體化建設讓 serverless 全鏈路得到可視保障，帶著業務訴求參與到集團 Serverless 共建更好促進整體的發展。
一體化研發模式升級
- Rax + FaaS 一體化能力方面 ：S2 我們在原有老[client/cloud]推動共建小組一起升級到前端為主 [src/apis] 的目錄結構，本地開發調試 SDK 以及網關請求前端 SDK 升級兼容完成並透傳 fcMtopInnerParams 參數模擬，在業務側我們完成 出境購 業務的落地上線
- Ant Design Pro + FaaS 一體化中後臺開發 ：由於目前不少飛豬小二平臺不少是通過在 Aone 申請 1+3 臺機器的方式來完成 Node 應用的部署，存在申請麻煩、機器浪費、上線複雜的問題，基於此我們 跑通 Ant Design Pro 體系下的 FaaS 一體化的本地調試、編譯、部署上線全流程，目前已沉澱到腳手架和研發平臺 ，我們可以像開發一個普通前端頁面一樣上線中後臺應用，無需申請機器和域名，目前飛豬渠道管理平臺跑完串通數據庫使用流程上線
- FaaS Rax SSR 一體化跑通 ：之前開發 SSR 的時候，需要讓一個前端變成一個全棧，同時需要考慮到 Node 選型，申請、搭建、部署、保障這些過程，這也導致其很難在內部大範圍使用的一原因，水瀾這邊 SSR 共建組同學產出通用能力，後續基於 nginx+lua+緩存 的動態代理策略，完成了飛豬側的全鏈路上線跑通，目前也可投入生產使用了，可很好的用於後續飛豬 SEO 和頁面性能提升場景，可見 旅遊攻略>>
這一類型的一體化開發模式，目前在飛豬處於代表場景業務跑通上線落地流程，後續量產我們需要加油搞起來，以便實現這個技術更大的價值 。
開發體驗完善
說到前端開發體驗，飛豬前端同學必然會想到「CLAM 工程體系」（有一種海邊敲著代碼 clam 的感覺）， 一組簡單命令完成項目初始化(clan init)、新建迭代和分支(clam newbranch)、本地開發調試(clam dev)、預發(clam prepub)、上線(clam publish)的全流程工程，無縫和底層平臺能力打通 。
基於此，我們完成了 Clam 和 FaaS 開發體系的打通，現在飛豬開發者無需去研發平臺申請對應的應用，一步一步點擊迭代， 直接通過 clam init faas 創建純 faas 項目、 clam init rax --faas 創建 RAX+FaaS 一體化項目，後續流程即可保持可以之前頁面開發體驗一致 ，可降低大夥的使用成本。
同時為了減少初步使用 FaaS 同學的上手成本，完成飛豬側 Serverless 使用文檔整理歸納，包含
新手教程、框架介紹、常用服務調用、BaaS 能力、一體化開發、運維排查開發全流程的使用文檔>>>
BaaS 能力建設
依稀記得當時上半年由於不少 BaaS 能力不好支持，特別是數據庫的使用，導致有一些場景只能望而卻步，這一塊也是我們推動集團共建同學需要強力支持的一塊，在下半年我們一起折騰出如下方案來滿足現有業務訴求：
代理方式連接數據庫 （過渡方案，已存場景使用）：我們開始時候跑通了利用 baas-sdk 的方式連接中心應用實現代理到數據庫的增刪改查操作，當做當時的一個不能使用數據庫的過渡方式使用，但是由於中心化的代理不敢強保障 C 端應用穩定性，更多推薦內部應用使用。
FaaS 直連數據庫 (推薦方案，較安全)：加上 C 端業務側有強訴求，需要使用數據庫能力，我們和 midway runtime 的同學 跑通了在 FaaS 函數 LifeCycle 生命週期啟動的時候，實現了對數據庫的直連，讓每個函數可以讀取到 Configuration 配置，同時也沉澱了一套我們認為的最佳的 FaaS 數據庫增刪改查建表的使方式，填補了集團在 FaaS 使用數據庫這一塊的空白 ，目前此類使用已在飛豬 C 端城市目的地統一以及內部中後臺渠道管理中使用跑通。
內網登錄能力調用 ：我們中後臺體系的第一個中間件的能力，使用方式和原有 midway 的方式很像，可以藉助此插件快速實現內網登錄能力的接入，可以讓我們快速上手使用。
穩定性和運維能力
穩定性一直在 Serverless 體系中最需要關注的一趴，由於屬於新興事物，更需要儘可能保障穩定性，讓新同學覺得這個體系是靠譜的，他的業務可以來生產使用，這樣方可促進其更好融合發展。
Serverless 監控一體化平臺 ：為了更好發現和排查問題，我們拉上原來 Node 監控同學一起弄了一個 Serverless 監控一體化的平臺，目前 1.0 版本已經發布發佈， 加上函數監控信息，引入健康分的概念，也加入重要功能全鏈路監控，通過流程圖的方式可一眼看到問題所在，加上了快速止血的入口 ，同時**整體能力已經接入到統一 FaaS 研發平臺 **。目前我們正在弄函數監控關注部分，同時在著手弄自定義日誌統計的能力，期待後續在監控側給大家帶來更大的價值
除了監控部分，讓函數如何在低運維成本下也是需要重點考慮的地方，基於此 Serverless 共建組推動 Serverless 機器同學一起上線了 函數動態縮擴容 的能力，同時也建立起 函數租戶管控平臺 ，便於後續函數容量、租戶、上線等管控工作。
與此，還有一個重要的飛豬 serverless 支持多單元化事項也一直在推動中，以便出現緊急問題可以實現 單元逃逸 。
網關側增強
在 上半年我們網關側的能力可滿足現有 C 端業務側使用，在 S2 我們做了部分增強工作，如網關前端 SDK 支持 H5 和 Rax1.0 網關信息的透傳，同時將飛豬側網關埋點數據和全鏈路監控實行了規範打通，滿足 serverless 全鏈路監控的使用
閱讀更多 sandag 的文章
