Netflix是怎麼探索落地FaaS的？

嘉賓｜肖雨濃

編輯｜薛梁

2014 年，Serverless 架構進入大眾視線，當時業界普遍認為，Serverless 化可大幅降低 IT 成本，將雲的費用減少 10%-90%，同時還能提高服務部署效率。

經過這幾年的沉澱，部分公司已經在實踐 Serverless，取得的效果也很明顯。7 月 6 日在深圳舉辦的 ArchSummit 全球架構師峰會，我們邀請了 Netflix 首席軟體工程師肖雨濃來分享 Netflix 對 FaaS 技術的探索過程，希望能給技術工作者帶來收穫。

InfoQ：能否為大家介紹一下您目前的工作內容和職責是什麼？

肖雨濃：我目前在 Netflix 帶領 FaaS 和 API 平台團隊，Netflix API 是一個 tier-1 服務，通過這個服務，來自 Netflix 所有客戶的每一個單個需求都可以平滑經過。基於這個 API 服務，我們還可以將後端的上百個微服務整合進一個連貫的服務里，便與用戶訪問。我們當前正在構建一個 FaaS 平台來幫助工程師們快速開發，測試並維護這些 API 服務，通常情況下，這個平台會被定製到每一個設備里。

InfoQ：實踐 Serverless 過程中給 Netflix 帶來哪些方面的優化？在您看來 Serverless 架構適合哪些業務場景，不適合哪些場景？（Serverless 模式能給 Netflix 降低多少成本？）

Netflix 的產品在設計上就已經被賦予了創新的基因，除了不間斷的 A/B 測試之外，每周都會發布很多新功能。為了確保這樣高強度的工作成果，我們需要一個 API 服務平台來助理客戶端工程師快速而有效的將更改的需求部署到服務層。FaaS 通過把那些與服務相關的所有平台組件抽象為業務邏輯本身來實現這一目標的，這樣可以使工程師能夠更專註於開發優異的新功能，而不是編寫那些冗餘而又不得不寫的代碼。

此外，即使對於經驗豐富的伺服器工程師而言，運行服務的可用性超過四個 9 也是很困難的。 因此，我們集中操作的 Serverless 模式能夠為我們提供一個平台，即使沒有伺服器和運營經驗的工程師也可以開發高可用的服務。

InfoQ：能否進一步詳細介紹 API Platform 的架構？目前 API Platform 是如何落地 Serverless 的？

在更高層面上，API 平台由 FaaS 平台組成，該平台允許工程師將用戶業務邏輯的功能部署為高可用的生產服務。

InfoQ：Serverless 架構是否是微服務的極致？您團隊接下來的優化重點是什麼？

無伺服器在實踐場景里是可以考慮權衡點的。 通過採用 FaaS 模式，本質上是對交易速度和可能性的定製化。有些應用程序的 FaaS 服務表現得很好——Netflix API 的情況就是如此，我們運行的是相對統一的微服務，只需要訪問和改變下游服務的數據。 然而，如果服務需要定製化，例如需要改變服務平台的各個組成部分，像 RPC，數據訪問，緩存，認證等，那麼 FaaS 模式可能無法為這些服務提供足夠的靈活性。

我們目前的重點是完成將舊版 API 服務遷移到新堆棧。之後，我們的重點可能會包括很多方面，例如性能，既要降低成本，又要改善客戶體驗，以及基礎架構和平台改進等其他領域。

InfoQ：能否結合實例談談 Serverless 中，怎樣的函數依賴關係是合理的，從業務邏輯上如何評估哪些關鍵路徑需要報警，哪些允許失敗？（如何防止錯誤地消耗大量資源進而增加大量費用？）

函數被部署為獨立服務，這意味著我們不會在同一個實例上部署不同服務的函數。這對我們來說非常重要，因為我們不想讓一個行為不良的服務拖累所有的 Netflix 服務。這種隔離有助於防止所有 Netflix 服務出現大規模停機。我們還會對內部指標、警報和監控系統進行整合，從而讓我們了解每項服務的健康狀況。該服務平台包含先進的削減負荷技術，如並發限制和斷路，這些措施有助於防止大規模停機。我們還在運行時調試、分析和採樣方面投入大量精力，這為我們提供了必須的可觀察性，以便對服務進行大規模運維。該平台還有許多其他組件幫助我們更可靠地運行，來聽我的演講了解更多信息！《Going FaaSter: Function as a Service at Netflix》

就依賴性而言，我們允許用戶隨意導入第三方庫，當然，這意味著工程師需要對安全性和性能等方面進行判斷。

InfoQ：如何決策或對比使用公有雲 FaaS 服務或私有雲自建 FaaS 服務？

這歸結為典型的「自建 or 購買」問題。我認為面對這個決定時應該務實。當我們首次設計 FaaS 平台時，我們考慮了諸如 Lambda 和 App Engine 等公共選項。如果符合我們的場景，我們當然很樂意使用現成的解決方案。

事實證明，我們需要一個能與現有 Netflix 服務平台組件（如度量，警報，服務發現等）集成的平台，而且這種與高級 FaaS 平台的集成將是一個很困難的過程。

另外，我們需要全面了解是什麼樣的服務在使用 FaaS 平台。自建意味著可以完全控制操作系統，需要給運維人員提供調試服務和可視化工具。

顯然，自建 FaaS 平台需要花費大量的精力、時間和成本，所以我們不會輕易做這樣的決定。然而，當時我們找不到滿足要求的開源方案或公開的 FaaS 選項。

這並不意味著大家都要模仿 Netflix 的腳步。如果符合需求的開源或公開 FaaS 選項存在，那麼絕對要去使用。機會成本也是一個重要指標。技術只是達到目的的手段 - 我們當然應該使用最好的工具來完成這項工作，通常這意味著購買成熟的方案而不是自建。

InfoQ：對於 CI/CD 與 FaaS 的結合，有什麼樣比較好的建議？

提供強大的一流測試框架非常重要。我們在設計 FaaS 平台的時候考慮到了測試，創建了一個測試框架，其中包含一流的模擬功能以及與開發人員工具緊密集成的特性，使工程師可以非常方便地使用 FaaS 平台編寫單元，集成和端到端測試。

我們的測試框架主要優點之一，是允許在本地或在 Jenkins 上單獨測試其功能，而無需將代碼部署到雲中。這種易用性使我們的客戶能夠編寫測試，而這有助於提高服務的可靠性。

InfoQ：目前業界全面落地 Serverless 尚且遙遠，且沒有統一的構建標準，如何確保你們的實踐方向是正確的？能否分享歷年過程中你們的經驗教訓？

目前大多數 Serverless 解決方案都適用於批量和事件驅動的任務，這些任務對延遲不敏感。然而我們認為 Serverless 也應該被考慮用於生產服務，因為它能通過抽象化平台和基礎設施來減少操作和代碼複雜性。

對於我們來說，Netflix API 組織中有明確的需求，需要 FaaS 模式來支持服務型工作負載。我們相信通過與其他公司的交流，大家對服務型 FaaS 平台會有濃厚的興趣，大多數團隊服務都只是為達到目的一種手段，沒人激勵他們，也沒人關心服務是如何部署的，只需要它們可靠的執行業務邏輯。

我認為 FaaS 是一種自然演變，許多年前，大多數服務使用定製軟體在整個堆棧中運行，並在每個公司內部數據中心運行。現在，我們正朝著一種模式邁進，在這個模型中，我們將組件進一步商品化，並進一步向前推進。我們開始使用 IaaS 商業化硬體和數據中心（例如 AWS EC2），然後轉向將平台與 PaaS 的某些部分商業化（例如 Heroku 或 Google Cloud Platform）。這種自然演變促使 FaaS 出現，一切都由平台提供，而只有業務邏輯是函數本身的。

InfoQ：隨著容器和 Kubernetes 技術的興起，當前有很多基於這兩種技術構建的 Serverless 架構，比如 Fn、Kubeless、OpenFaaS、IronFunctions 等，您如何看待容器技術尤其是 Kubernetes 為 Serverless 架構帶來的機遇？

如此多 FaaS 平台構建於 K8s 之上的原因之一，是 K8s 將基礎架構和平台抽象為在容器上構建可擴展和可靠的服務所需的事實。這是非常強大的，因為它意味著 FaaS 框架可以專註於函數運行時。

這一塊將繼續演變，我希望看到更多的 FaaS 框架出現，尤其是能夠滿足大規模服務風格工作負載需求的那些（能夠考慮到豐富的指標，自動調整，性能優化）。 我相信 K8s 將以更大規模運行的能力發展，這將使它更適合超過 5000 個物理節點的使用情況。

InfoQ：在涉及整體架構的重構中，您認為應當採用漸進的方式逐步替換還是完全重寫？如何防止技術人陷入下一個酷技術的陷阱？

工程師應該務實，對體系結構進行漸進式改變。立即改變一切只會增加項目的複雜性，風險和時間成本。漸進式改變意味著我們可以縮短反饋周期，為業務更快實現收益，並通過一次只更改少數組件來降低風險。

我們應該權衡每個決定的利害關係，尋求公司內部的廣泛一致，並尋求異議。在採用新技術時要謹慎，捫心自問，「為什麼選擇這項技術？」如果你不能以滿足團隊或組織的方式來回答這個問題，那麼你應該三思而後行。仔細考慮採用新技術的意義是什麼，擁有更廣泛的用戶和支持基礎？提供了一套好的工具來進行運維和調試？文檔是否明確？維護周期有多長？採用新技術對整個組織的影響是什麼？平台團隊現在需要在整個組織中支持這項新技術嗎？

例如，我們 FaaS 平台採用了容器技術，原因很特殊。它可以確保工程師隨時隨地運行服務，並為我們提供不可變的構建組建。這個決定會對團隊有一些影響，需要在 Netflix 內部創建一個新團隊，負責構建一個容器編排系統。決定使用一項新技術經常會給整個公司帶來不確定的後果。

InfoQ：在 FaaS 服務的開發過程中，工程師最關注點的是什麼？

對於開發體驗，我們專註於 FaaS 平台的人體工程學。這是工程師使用 FaaS 平台的最大反饋。 因此，我們專註於構建開發者工具，使工程師能夠在其開發機器上本地開發和調試其功能，包括尾部日誌和附加調試程序的功能。

InfoQ：將越來越多的核心功能部署雲上的時代，您認為工程師應該將精力更多地放在哪些方面？

工程師應該將重點放在與團隊有關的事情上，大多數情況下，這不再意味著基礎架構或服務平台。對於使用 FaaS 平台的工程師來說，這能讓他們更專註於產品創新，為 Netflix 超過 1.25 億的會員提高用戶體驗。

受訪嘉賓簡介

肖雨濃，目前是 Netflix 位於美國加利福尼亞州洛斯蓋多斯 (鎮) 的首席軟體工程師，帶領 Netflix API 平台設計和架構團隊。在此前，他任職於 AWS 和 Joyent，主要方向是分散式系統，並幫助規劃和構建了多款雲計算產品，例如 AWS IAM 和 Manta。與此同時，他也在維護開源項目 Node.JS 框架的校正。Yunong 獲得了滑鐵盧大學計算機工程榮譽學位。

還將在 ArchSummit 全球架構師峰會深圳站上帶來《Going FaaSter: Function as a Service at Netflix》的演講，識別下圖二維碼，了解更多峰會詳情！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！