無服務器架構是當下云計算領域最熱門的趨勢之一。據統計，只有 35% 的技術人員還沒有使用無服務器平臺，越來越多的企業出于降低成本、簡化運維、加快產品上市速度等原因選擇轉向無服務器架構。那么，開發人員該如何轉變自己的開發方式以適應和充分利用無服務器架構？在業務快速變化的情況下如何采用無服務器架構加速應用開發進程？Serverless 架構如何與 AI 等應用場景進行高質量的結合？

亞馬遜云科技 TechTalk 特別版直播活動榮幸的邀請到了亞馬遜云科技首席無服務器專家 Luca Mezzalira，他結合親身經驗為開發者提供了無服務器架構下應用開發的實用建議。

無服務器架構的 核心價值和挑戰

InfoQ：無服務器架構的核心價值是什么？亞馬遜云科技的無服務器架構有哪些優勢？

Luca Mezzalira：“無服務器”這一概念經過多年演變，如今我們稱其是一種策略。用戶采取無服務器策略時可以將同質化的繁重工作交給亞馬遜云科技，自己專注編寫開發新功能，滿足你的客戶需求。

無服務器架構有幾個優勢：首先是業務敏捷性。無服務器架構的優勢在于模塊化，我們能夠在基礎設施層面來將這一概念付諸實踐?；跓o服務器架構，客戶可以享受到亞馬遜云科技內置的各種通用模式。

無服務器的另一大優勢就是我們擁有豐富的基礎設施管理經驗，客戶可以直接享用我們多年來學到的所有最佳實踐，而開發人員或整個企業就可以專注于自己的差異化競爭優勢——也就是他們的軟件或他們正在開發的項目。

InfoQ：您提到了無服務器架構的這么多優勢，但任何事物都有兩面性。那么在您看來，無服務器架構現在面臨著哪些挑戰？我們又該如何應對這些挑戰呢？

Luca Mezzarila：事物確實都有兩面性，特別是對于那些第一次接觸無服務器服務的人來說，想要上手確實得花點功夫。大家要在多個維度上轉變自己的思維，拋棄過去自己熟悉的傳統開發方式，轉而在代碼層面開始習慣模塊化表達，同時試著將更多權力下放給基礎設施。確實我們為了上手要花點時間，但這并不是多難的事情。

InfoQ：在無服務器架構中，冷啟動延遲非常重要，也是一個常見的問題。Amazon Lambda SnapStart 可以將冷啟動時間降低 90%，這絕對是了不起的成就。你能分享一下這背后的故事嗎？

Luca Mezzarila：Amazon Lambda SnapStart 特別關注 Java 的應用場景，因為世界上有很多組織都高度依賴于 Java。將來的 Amazon Lambda SnapStart 也可能適用于其他環境，因為 Amazon Lambda 支持多種由亞馬遜云科技托管的運行時。

很多開發者都很擔心冷啟動問題。但根據我個人在行業內工作了 20 年的經驗，其實并不是所有 API 都必須擁有超低的啟動延遲。大家一直在努力讓自己的軟件達到最好的效果。但我們還是應該先弄清楚瓶頸究竟在哪里。

我們每年推出的版本中總有一些功能會幫助大家改善自己的工作體驗，而且開發者和公司完全不用改變自己的工作習慣。他們一早醒來，會突然發現軟件的延遲有所降低。這是種非常奇妙的體驗。

無服務器架構下 應用開發的實用建議

InfoQ：在開發無服務器應用時，有哪些好的實踐和策略可以提供更好的性能？

Luca Mezzarila：有幾個手段是我們可以重點關注的。我們可以從模式出發，以不同的視角看待問題。比如，當我們的解決方案其中有一部分是同步，而另一部分是異步時，同步的部分需要根據傳入的請求來擴展，方案的其余部分可以保持較低的擴展度，從而降低維護難度。傳統單體架構中，你往往需要優化峰值流量、預先配置基礎設施等，但無服務器架構下這些資源都是開箱即用且可以按需擴展的。

我還特別推薦大家認真觀察并思考自己在做的工作，想想有什么可以優化的地方。比如說有一些 SLA 或功能可以和產品團隊討論，只要一些簡單的調整就可以更加充分地利用它們，讓開發者的工作更輕松，同時給用戶帶來顯著影響。

無服務器技術的高性能和穩定性往往是由細節決定的?，F在你不用再操心在哪里使用 circuit breaker，在哪里存儲內存信息，而是直接借用成熟方案，而且不用自己去維護它們，這樣你就可以專注于那些真正重要的任務。

InfoQ：您說易于使用和易于維護是非常重要的，那么您能和我們分享一下如何將應用程序劃分為小型、獨立的功能模塊，并利用無服務器架構構建和部署這些模塊嗎？

Luca Mezzarila：當我們談到分布式系統時，主要的挑戰在于建模部分。有些公司先是針對細碎的服務做出一些非常小的模塊，然后再嘗試耦合；還有些公司則是先構建一些小體量或模塊式的單體架構，然后當他們對新技術有更深刻的理解時再進一步拆分它。我認為第二種模式效果最好，尤其是當你不太確定你是否想采用微服務時。

有一些實踐可以幫助你理解如何拆分應用。首先我推薦大家了解一些領域驅動設計的知識。研究這種技術的社區提供了很多極具啟發性的方案和一些能夠幫助你拆分應用的工具。例如事件風暴就是一個很好的起點。首先，業務部門和技術部門通過事件風暴會議攜手合作，并且只關注用戶的整個使用流程。大家在白板上羅列出用戶為了完成某一項或多項任務所必須經歷的所有事件，這樣就可以直觀展示使用應用或特定功能的整個流程，看到促成流程推進的關鍵事件。它們代表著不同任務之間的邊界，接下來我們就可以順利地將各部分工作分配給各個團隊。

這時團隊已經可以從業務的角度出發，對自己想要表達的內容有了比較清晰的認知，并且可以將其付諸代碼。然后團隊就可以輕松地把一個個環節映射到無服務器服務上。而如果沒有事件風暴這一環節，直接不管不顧開始寫代碼的話，你很可能會在代碼的構建、重構和刪除上浪費大量時間。

第二點，我們不應該過早開始預先設計，你不需要在開始寫代碼前幾個月就開始構思準備。你應該采用一個非常精簡的方法，在有限的時間內收集盡可能多的信息，然后根據掌握的信息做出決定。有時你很有可能要改變原本的設計方向，而無服務器是在基礎設施級別實現模塊化的，所以我們就可以直接刪除或丟棄一些代碼，然后沿著更適合我們軟件的新方向前進。

此外，事件風暴的另一大亮點是你可以看到各個團隊在與哪些人交流，以及服務中的各個部分在與哪些服務溝通。這樣架構師就可以輕松調整架構，改善團隊溝通機制，對整個系統的認識也會更加清晰。

無服務器 VS 微服務：無服務器架構 是微服務的一種表現形式

InfoQ：我們談了這么多關于無服務架構的內容，但我們知道在這個領域另一項非常重要的技術叫做微服務。那么您對這兩種架構之間的關系有何看法？您認為一項技術會取代另一項嗎？

Luca Mezzarila：微服務只是一個術語，表示一個特定的實體或工作單元，而且它是完全獨立的，可以由單一團隊管理。微服務要有一個強大的封裝。而這個強大的封裝可以是由各種方式設計的，可能是代碼，可能是某種基礎設施。我認為無服務器應該算是微服務的一種表現形式。現實應用中并不存在它們之間的硬性分割，大家完全可以用容器、虛擬機或者無服務技術等各種方式來實現微服務。

真正重要的是我們到底想用模塊化微服務表達什么。很多 API 其實根本沒有那么高的要求，也許我們只想用它獲取數據和查詢數據庫，這時候無服務器也是個好選擇。但無服務器可能并不適合每一個負載，所以大家不必盯著一套方案到處使用，這反而會限制你做架構優化的能力。

在設計系統時，我們需要考慮太多因素，包括成本、性能、可擴展性和可靠性等等。真正有意義的是先想清楚要不要用微服務，再思考要用哪種方法來實現，而無服務器只是實現方法之一。

InfoQ：哪些企業適合使用無服務架構，哪些又適合微服務架構？

Luca Mezzarila：首先，利用無服務器構建解決方案能幫初創企業快速部署生產環境。而大企業顯然面臨著更大的挑戰，因為他們有大量的舊代碼和舊邏輯需要處理，而當初編寫這些代碼、設計這些邏輯的人可能已經離職。因此他們需要先審視整個業務體系，然后思考該如何拆分這些代碼和邏輯，從而讓它們更容易被新人理解，下一步才是思考具體該使用哪種服務。所以有時候，采用混合架構也不錯，畢竟系統中的某些部分可能跟容器匹配得更好，而某些部分更適合無服務器架構。

一切工作的本質都在于整合，而無服務器架構恰好是實現整合的出色方案。無服務器架構能用隊列輕松消化掉流量，也可以用事件或使用 Amazon Lambda 函數來與其他系統同步。所以每當大家談到邊緣架構時，我想到的首選都肯定是無服務器架構。

另外我還發現，其實 API 并沒有大家想象中那么脆弱。我們完全可以用 CDN 將流量轉出源站，無服務器在這方面也有巨大優勢，因為大家只需按實際用量付費。所以如果絕大多數流量都流經 CDN，那我們根本不用為所在區域的源站支付多少成本。

總之，想清楚自己的軟件要表達什么是很重要的，這會為日后省下很多不必要的麻煩。

InfoQ：如果沒有無服務器架構，編程工作會變得更復雜嗎？

Luca Mezzarila：通常情況下，對于公司所掌握的每項服務、每段代碼，我們天然希望它能對應一套連貫且統一的代碼庫。所以團隊就得一同定義設計路徑、確定所要使用的工具等等。但遺憾的是，這樣的一致性總會隨著時間的推移發生變化。對于開發人員來說，這就像是在戴著鐐銬跳舞。所以，我認為基礎設施的模塊化表達可以在這里派上用場，我們只需根據業務稍做調整，而不必每次都重新做一遍配置。另外，從應用程序的整體性出發，我們會看到相似的情況總比特殊情況要多，而無服務器架構可以將這些相似的工作集成在架構中，減輕開發者的負擔。

亞馬遜云科技 Serverless 化 全面改造的最新進展

InfoQ：亞馬遜云科技在推動向無服務器的全面轉型方面做了哪些努力？

Luca Mezzarila：我們在亞馬遜云科技建立了多個項目。我們面向的不只是開發者群體，同時也嘗試改變企業高管層的思維方式，讓他們了解包括無服務器在內，整個現代開發思維所帶來的好處。除此之外，我們也有面向架構師和開發人員的項目，與他們一起走向現代化，也幫助他們了解如何構建事件驅動架構和微服務架構。我們也會與擁有無服務器經驗的合作伙伴通力合作，甚至可以為客戶推薦能幫其達成目標的合作伙伴。

我們為客戶準備了很多充滿潛力的選項。客戶只需說明自己想達成怎樣的目標，亞馬遜云科技就能夠提供相應的協助方案，而且大部分服務都是免費的。只要我們能在建模階段把工作做到位，并在網站上發布豐富的說明文檔、博文素材、應用實例，開發人員就能切實掌握值得借鑒的最佳實踐。并且我們的努力涵蓋各個領域，能幫助任何企業在云端取得成功。

InfoQ：亞馬遜云科技自己的無服務器實踐目前走到哪一步了？

Luca Mezzarila：無服務器技術在亞馬遜云科技的內、外部工具中正在迅速普及。Amazon Lambda 函數的調用總量已達到 1 萬億。通過無服務器技術，我們部署了大量開箱即用的最佳實踐，就連可用性保障都已經在函數部署過程中被默認內置，客戶用不著為這些麻煩事分心。我們也在亞馬遜云科技內部使用它支持客戶、支撐自己的服務。

當 Severless 遇上生成式 AI

InfoQ：無服務架構在機器學習領域的前景如何？

Luca Mezzarila：現在已經出現了不少使用無服務器架構的示例，特別是在粘合各種系統的場景下。在我看來，最重要的就是用無服務器架構充當粘合劑，實現這些信息的跨系統傳輸，讓開發者可以專注于真正重要的事情。

關于生成式 AI，我們在亞馬遜云科技中已經成功落地。在開發層面，我們推出了 Amazon CodeWhisperer 插件，可以根據提示生成代碼編寫建議。另一項生成式 AI 服務是 Amazon Bedrock。它允許用戶選擇自己想要使用的大語言模型。我們還開發了自己的大語言模型，也就是 Amazon Titan。隨著這些服務的推出，我堅信這種幫助客戶靈活選擇、定制大語言模型的方案一定能夠大放異彩。

InfoQ：您對 AI 和無服務器之間的關系有何看法？二者有什么聯系嗎？

Luca Mezzarila：就目前來講，我覺得只能算是有松散的聯系。我們還需要進一步探索，畢竟大語言模型對內存容量有著極高的要求。盡管無服務器技術擁有自己的優勢，但正如我之前提到的，它最大的優勢應該是把不同的系統粘合起來，確保技術人員能專注于真正重要的工作。比如在 AI 語境下，你就可以專注于思考如何訓練你的模型等等。同時，我很確定會有一些通過無服務器技術實現的有趣應用。社區那邊就發布過不少方法，以新穎的生成式 AI 方法嘗試簡化開發者的工作體驗。我有種感覺，其實很多工作正在幕后悄悄推進，只是我們還沒看到。

面向未來，無服務器架構 將為開發者帶來怎樣的機遇？

InfoQ：您如何看待無服務器架構的未來發展趨勢？

Luca Mezzarila：我覺得最重要的還是研究客戶用例。過去幾年間出現了大量關于無服務器的需求。亞馬遜云科技推出的絕大多數功能都是應客戶的要求而生。未來幾年的重點應該是為無服務器重新找準定位，因為現在我們將其視作一種策略，而不只是簡單的 Lambda 函數。

我們有些客戶一直立足前沿，正在做一些我們從未預料的瘋狂嘗試。但同時也有很多客戶要么對服務不完全信任，要么持明確的懷疑態度，還有一些客戶并不太了解這項技術。所以我一直在努力為大家答疑解惑。我們建立了一套心智模型來幫助客戶方的開發人員、架構師和平臺團隊把自己的軟件以科學的方式映射到無服務器架構。這樣，無服務器的負載就能快速增長，因為我們以往的觀察已經證明無服務器架構具有諸多優勢，令許多客戶從中受益。

InfoQ：對于開發者來說，無服務器架構未來有哪些潛在的機會？

Luca Mezzarila：開發人員面前的機會有很多。他們可以編寫出免維護的代碼、建立更快的反饋循環，并開始研究如何幫助業務和產品所有者一同重塑業務。還有一個挑戰是思維方式的轉變。企業中仍然流行一種非常集中制的思維模式，單純由組織頂層人員、或者說技術領導層來決定一切，而開發人員只是螺絲釘。他們沒有機會與產品團隊溝通，共同塑造成功的軟件。產品和技術團隊永遠在彼此指責和爭吵，我覺得必須要避免這種爭執，讓雙方更好地合作，這才能給軟件帶來益處，進而惠及整個組織。

InfoQ：時代車輪滾滾向前，過去開發者可能更關注學習哪種語言、哪種新技術，但現在，特別是在疫情過去之后，企業開始更多關注利潤。他們苦苦掙扎，要在糟糕的經濟環境下生存下去。在這樣的背景下，開發人員應該掌握哪些軟技能呢？如何面對這樣的大環境變化？

Luca Mezzarila：在組織中，“軟技能”已經成為了核心技能。如果我們沒有能力開展有效溝通、做出權衡，并代表企業的利益發言，即使你可以成為世界上最了不起的開發者，你也沒法把握成功的脈搏。因為當今的現實是，我們寫的每一行代碼都不是為了娛樂自己而寫，而是為我們的客戶創造價值。

另外，開發人員現在需要身兼數職，他們工作中的開發占比越來越低，而需要對事物的發展變化具備更敏銳的感知。我建議大家不要局限于特定的框架或語言，而是著眼于更廣泛的問題，包括架構、安全性、平臺、基礎設施等。這些會讓我們成為更全面的開發者、更優秀的人才。還有一點要著重強調，當你以開發者身份做出一個超出自己能力的決定時，必須意識到這不只是一項技術決策，它也一定會在架構和組織層面產生相應的影響。

我發現很多開發者對分布式系統特別興奮，或者每一種新語言都想去試試。但每一個框架都有自己的哲學、思維方式和合作生態。我覺得我們永遠都要保持開放思維。你掌握了一種編程語言或框架，這當然是好事。但與此同時你需要看看你的周圍，通過團隊內不同成員的協同，我們才能構建真正有效的功能單元，在特定場景下大放光彩。我們要做 T 型人才，涉獵廣泛的領域，并在特定的領域精通鉆研下去，同時也有具備相應的軟技能，從而在職業生涯中不斷成長前進。