作者： Will James

譯者： 大愚若智

我想通過本文簡單談談自己對奧斯丁 Serverlessconf 大會上所涉及主要議題的看法。這次活動讓我受益匪淺，還見到了不少行業牛人，萬分感謝 A Cloud Guru 舉辦的這次活動。此外我還領到了很多新 T 恤，吃了美味的甜甜圈，拜訪了住在奧斯丁的親友們。

總的感想如下。

什麼是“無伺服器”？

Serverlessconf 的所有與會者依然還在忙著給“無伺服器”下定義，並達成了一些共識：

• 無伺服器不僅僅是函式即服務 (FaaS, Functions As A Service)，還包含諸如資料庫、身份驗證、API 閘道器、編排，甚至具體到某一領域的其他服務，例如視訊轉碼即服務或認知服務。總的來說，所有與這些服務有關的基礎架構都不需要我們自行管理。
• 無伺服器意味著（近似於）100% 的利用率。如果和 PaaS 相比的話，PaaS 應用程式要麼以特定的規模執行，要麼以非常慢的速度進行伸縮，但會因為伸縮操作本身造成一定的開銷（例如有未使用的例項處於閒置狀態，等待接受請求）。作為對比，如果無伺服器服務暫不使用，此時不會產生任何成本，但如果有必要可以（幾乎）瞬時伸縮至數百萬使用者，服務的成本直接取決於使用量。

事件驅動，而非資料驅動

會上的另一個重要議題是：無伺服器應用促成了一種圍繞事件本身，而非圍繞資料來設計的架構。將應用程式訂閱到某個事件佇列，這是管理服務通訊的一種好方法，藉此我們可以輕鬆地為現有佇列新增新服務，或修改 / 新增功能，而不需要將資料流直接繫結給應用，進而產生強耦合。

Rob Gruhl 介紹了 Nordstrom 公司正在從事的一個有趣專案：他們正在通過一個集中且統一的事件日誌管理零售系統內部的資料流動。應用程式可以通過流生成和使用事件，任何需要對當前狀態獲得高效能檢視的應用程式均可訂閱至事件流，藉此構建自己的狀態資料庫（一種資料庫檢視）。隨後即可根據需求為請求提供服務。同時這些應用還可生成供其它服務使用的事件。這樣的方式徹底避免了為實現某些狀態的中心化儲存而使用核心資料庫系統的做法，可在改善伸縮性的同時實現微服務之間的解耦。

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

詳情可參閱 GitHub 上的 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 管理所有底層伺服器及其狀態，使用者無需考慮任何有關最長執行時間或最大記憶體數的限制，只需要嚴格按照用量來付費。

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