無服務器架構的一些深層次的探討

什麼是「無服務器」？

Serverlessconf 的全部與會者依然還在忙着給「無服務器」下定義，並達成了一些共識：

• 無服務器不只僅是函數即服務 (FaaS, Functions As A Service)，還包含諸如數據庫、身份驗證、API 網關、編排，甚至具體到某一領域的其餘服務，例如視頻轉碼即服務或認知服務。總的來講，全部與這些服務有關的基礎架構都不須要咱們自行管理。
• 無服務器意味着（近似於）100% 的利用率。若是和 PaaS 相比的話，PaaS 應用程序要麼以特定的規模運行，要麼以很是慢的速度進行伸縮，但會由於伸縮操做自己形成必定的開銷（例若有未使用的實例處於閒置狀態，等待接受請求）。做爲對比，若是無服務器服務暫不使用，此時不會產生任何成本，但若是有必要能夠（幾乎）瞬時伸縮至數百萬用戶，服務的成本直接取決於使用量。

事件驅動，而非數據驅動

會上的另外一個重要議題是：無服務器應用促成了一種圍繞事件自己，而非圍繞數據來設計的架構。將應用程序訂閱到某個事件隊列，這是管理服務通訊的一種好方法，藉此咱們能夠輕鬆地爲現有隊列添加新服務，或修改 / 添加功能，而不須要將數據流直接綁定給應用，進而產生強耦合。

Rob Gruhl 介紹了 Nordstrom 公司正在從事的一個有趣項目：他們正在經過一個集中且統一的事件日誌管理零售系統內部的數據流動。應用程序能夠經過流生成和使用事件，任何須要對當前狀態得到高性能視圖的應用程序都可訂閱至事件流，藉此構建本身的狀態數據庫（一種數據庫視圖）。隨後便可根據需求爲請求提供服務。同時這些應用還可生成供其它服務使用的事件。這樣的方式完全避免了爲實現某些狀態的中心化存儲而使用核心數據庫系統的作法，可在改善伸縮性的同時實現微服務之間的解耦。

他們提供了一個名爲 Hello Retail 的演示應用，攝影師能夠藉助該應用爲新產品拍照。當新產品加入後，系統會從已知攝影師清單中選擇一位攝影師，發送手機短信請求對方拍攝新照片。當攝影師（用短信）回覆後，系統會開始處理照片，將其加入圖庫，隨後註冊爲新產品對應的照片。

來自 Capital One 的 Srini Uppalapati 介紹了 Capital One 的核心金融系統，他們目前正在將這套系統遷移到雲端，而且這一過程當中大量使用了無服務器相關技術。他們核心交易系統的遷移主要分爲兩個階段：

1. 按部就班撤銷經過大型機系統執行的讀取操做：逐漸將大型機系統產生的事件以流的形式發送至雲端數據庫，並供面向用戶的應用和數據科學家使用。
2. 消除消費者應用中的寫操做，將核心業務邏輯搬入雲端。

目前他們已經完成了第一階段的任務。在 Srini 所介紹的架構中，他們使用 AWS Lambda 對老數據以及來自大型機的實時事件進行批處理，並將數據裝入 S3 以便歸檔，消費者應用使用了 DynamoDB，分析工做使用了 Redshift。

這個系統在架構和應用層面有一些極爲有趣的特色，直接使用「一手」事件是一種對邏輯和狀態進行解耦的強大方法：單向數據流使得一切變得更簡單。在應用層面上，以 ELM 架構和 React/Redux 爲例，經過遷入雲端，咱們能夠將雲函數與核心事件流配合使用，打造實用的大規模雲應用程序。

企業正在快速接受

上文曾經提到，Nordstrom 和 Capital One 正在經過幾個重要項目證實無服務器技術在企業領域的運用前景。最令我吃驚的是，Serverlessconf 大會上還提到了不少其餘正在這樣作的大企業，他們正在快速接受無服務器技術。

我認爲，他們能如此快接受這種技術，緣由之一在於不少企業已經開始遷往雲端，既然雲供應商提供了無服務器相關產品，而且這種技術能夠進一步下降成本，他們天然會願意接受。例如 Capital One 的 Srini 介紹說，經過使用雲端無服務器技術，他們大幅節約了成本。目前交易中心每一年運營成本約爲 9.5 萬美圓（考慮到客戶數高達 4500 萬，這樣的成本已經至關低了）。

爲了知足企業的這類需求，不只 AWS，目前全部雲供應商都在無服務器產品方面進行了巨大的投入。其餘雲供應商（Google、微軟，以及 IBM）也介紹了自家的 FaaS 和無服務器編排產品。

無服務器計算造就的現代化敏捷

Mike Roberts 經過一場精彩的演講介紹了應用開發者如何藉助無服務器技術變得更加以客戶爲中心，而無須過分關注技術問題自己。現代化敏捷（塑造更出色的人員，持續不斷地提供價值，讓安全成爲先決條件，更快速地嘗試和學習）在無服務器技術的幫助下變得更易於實現，開發者不再須要從新解決已被其餘開發者解決了無數遍的相同問題（如何進行身份驗證，如何伸縮等），這樣他們就能夠更專一地爲本身的客戶提供價值。藉此，生產發佈不再須要耗費數天甚至數週時間，幾小時就夠了。

考慮到：

「咱們的大部分想法其實都很糟糕」 — Jeff Patton

咱們應當儘量嘗試更多想法。感謝無服務器技術，「試錯」成本得以大幅下降！

無服務器技術在這方面已經有不少成功先例，例如 Marcia Villalba 介紹了 Toons.tv 是如何遷移至無服務器技術的。他們在面向雲環境從新設計架構後，成本大幅下降，而這一切都是由幾名不熟悉無服務器技術的工程師組成的小團隊，在幾個月的時間裏順利完成的。Marcia 認爲他們的成功主要歸功於每週一次的研討會，你們藉此交流討論新技術的學習心得，並經過測試進行概念驗證。

相關工具正在逐漸完善

有一種廣泛共識認爲，相比雲供應商提供的服務，周邊工具的發展有些落後了。Florian Motlik 詳細介紹了 AWS CLI 工具的不足之處。其餘雲供應商也面臨相似狀況，他們每每在無服務器運行時方面投入巨大，但老是會忽視部署、監視和本地測試等過程當中必不可少的工具。

基本上，這也意味着用戶與雲供應商之間的任何交互都必須經過第三方工具進行，例如沒人會經過 AWS CLI 進行無服務器部署，你們更願意經過第三方技術將雲供應商生硬的接口抽象爲簡單易用的應用程序部署框架（例如 Serverless Framework、claudiaJS，以及適合新手的 zappa）。

爲了解決這種問題，AWS 發佈了 Serverless Application Model (SAM)。SAM 是一種 CloudFormation 之上的抽象層，可大幅簡化 Serverless Applications 的建立工做，但 AWS CLI 在這方面依然不夠成熟（我的觀點）。

不少人還認爲，無服務器應用的監視和調試方面也缺少必要的支持，面對基於事件的架構更是如此（「個人函數沒法運行但不知道緣由！」以及「爲何不能對運行中的無服務器函數進行實時調試？？」）。

我這並非在抱怨缺少交互式調試能力，由於交互式調試實際上多是一種反面模式 (Anti-pattern)，但若是你想要這樣作，微軟已經支持經過 Visual Studio 或 Visual Studio Code 對 Azure 雲函數進行實時調試（雖然演示過程看着有點不靠譜）。若是想避免交互式調試，那就寫單元測試吧。

另外，全部雲供應商都開始在監視方面發力。Amazon X-Ray 就是一種很是實用的監視技術，經過與 AWS SDK 集成，可提供有關集成點，即實時架構示意圖的實時圖表 (Live graph) 和分析能力。若是你在本身的服務調用中使用了 AWS SDK，基本上就能夠無償使用該技術。

討論的另外一個重點在於，不少團隊依然在探尋無服務器應用開發的最佳模式。傳統上，咱們很容易理解特定應用所涉及的相關領域，由於全部內容都位於同一個服務器實例中。你能夠啓動一個本地實例，準備好全部依賴項，開發過程當中在本地執行各類探索式測試。然而對於無服務器開發，一般咱們會被緊密綁定至雲供應商（服務越「微型」，綁定的程度越高），爲了測試應用可否端到端運行，一般還須要對應用程序進行實際的部署（可能會涉及多個雲服務組件），甚至要在開發過程當中進行部署。不少因素會要求咱們必須可以在本地進行探索式測試，但如何對測試中的應用進行隔離，目前並無任何行之有效的模式，一般到最後咱們每每會面對一系列同時在本地和雲端運行，「拼湊」出來的測試應用。這方面目前已經有了一些解決方案，例如 Atlassian AWS Local Stack，能夠在用戶的本地計算機上提供一套功能完備的 AWS 棧。然而爲什麼要用它，而不是直接部署到開發環境，這個問題依然存在爭議。

無服務器的編排

無服務器計算還面臨一個大問題：難以經過編排大量 Lambda 函數進而在雲中建立數據管道。事件流是將 Lambda 函數鏈接在一塊兒的一種方法，然而一般咱們還須要更高級的功能，例如等待條件或並行處理能力。

AWS 和 Azure 都曾演示過本身的無服務器編排技術：AWS Step Functions，以及 Azure Logic Apps，這兩種技術看起來都頗有吸引力。

Azure Logic Apps 提供了超過 250 種適用於其餘 Azure 產品，以及第三方產品的鏈接器。雖然華麗的用戶界面讓我以爲它不太靠譜，但該技術以 JSON 形式的腳本 DSL 支撐，演示效果很出彩，他們將實時推文鏈接到了微軟的情緒分析服務，藉此圍繞特定話題實時進行了推文情緒分析……全部操做均在 45 分鐘的演示內完成（固然不少代碼是複製粘貼的）。

我還不太肯定該如何以足夠可靠的方式應用這些工做流編排服務（如何對其進行測試和部署？），不過感受上它們會成爲無服務器技術不可分割的一部分。

我很想親自見證這些工做流服務如何進一步完善成爲功能完備的平臺。若是有更好的語言（例如 JavaScript 或 Swift）能夠編譯爲「AWS 雲計算機語言」，並直接在某種抽象的計算層上運行，又何須使用 JSON DSL 來寫腳本。隨後可由 AWS 管理全部底層服務器及其狀態，用戶無需考慮任何有關最長運行時間或最大內存數的限制，只須要嚴格按照用量來付費。

文章來自微信公衆號：細說雲計算