Categories
程式開發

微服務和Serverless的天作之合


2015 年,第一個使用 AWS Lambda 和 API 網關的教程出現了,它主要關注的是如何復制微服務。但是,隨著時間推移,那些大規模使用 AWS Lambda 的人越來越清晰地意識到,使用 AWS Lambda 的微服務存在嚴重的局限性。

我們先來聊聊為什麼會有微服務

微服務之所以會出現,主要是因為單體應用程序存在不足。簡單地說,單體就是把所有邏輯都塞進同一個邏輯代碼庫的應用程序。

在單服務器環境時代,多服務器價格十分昂貴。默認情況下,應用程序是按照單服務器的方式進行構建的。部署一個單體就是把應用程序的一部分或者整體部署到一台服務器上。

在部署單體時,必須確保不出任何問題。通常,一個很小的改動都會導致整個應用程序和服務器宕機。

在雲服務出現之後,通過簡單的操作就可以在幾分鐘而不是幾天或者幾週之內分配好服務器實例,這就為關注點分離提供了條件。

於是,拆分單體就成了一件勢在必行的事情,微服務也就孕育而生。

你不再需要把所有邏輯都部署在同一個實例或服務器上,你可以把不同的部分放在不同的實例上,然後使用輕量級的通信協議(比如 HTTP API)把它們連接起來。

於是,應用程序架構就從單體轉向了微服務。

微服務的價值在於,在做出修改時,你修改的不是整個代碼庫,而是其中的一個微服務,它只是整個應用程序的一部分。也就是說,改動不會造成整個應用程序宕機。

但這畢竟也只是一個美好的理論,一個比單體更好的理論,在現實中,它並不完美。

服務接口(通常是 HTTP 接口)是微服務的關鍵所在。這本沒有什麼問題,但是,當存在大量的服務時,要協調好它們就成了一個大問題。

向 Serverless 架構轉變

AWS 上的第一個 Serverless 應用就是一個微服務:一個 API 網關接口,網關背後是 Lambda 函數和路由器。

每一個 API 網關都是一個服務接口,看起來似乎是合乎邏輯的。

你可以構建一系列的服務,每個服務都可以獨立伸縮,某種程度上說,這樣做非常合理。

但問題是,AWS Lambda 和 FaaS 不應該被當作實例或服務器看待。

因為底層使用了服務器(互聯網上的很多東西都運行在服務器之上,但就是沒有人指出“S3 也是有服務器的”、“BigTable 也是有服務器的”或者“Azure Active Directory 也是有服務器的”),所以我們假設你應該簡單地把FaaS 函數看成是服務,也就是有些人所謂的“minilith”。

但問題是,Serverless 的關鍵點是事件,而這一點往往被忽略掉。

Serverless、事件和触發器

Serverless 系統本質上就是事件驅動的系統,採用了事件驅動的架構。這種架構改變了 Serverless 系統的開發和管理方式。

微服務架構的主要目標是提供高度響應的 API,這也是服務間主要的交互機制。

Serverless 架構的主要目標是對發生的事件做出響應,API 是生成事件的唯一機制。

在 AWS 生態系統(最為成熟的 Serverless 生態系統)中,API 並不是主要的接口,事件變得更為重要。

這也就是為什麼會有將近 50 個事件來觸發一個 Lambda 函數。

如果可以不通過 API 網關來觸發 Lambda 函數,就會更快、更高效,特別是在從其他 AWS 接口觸發事件的時候。

這裡有一些 Serverless 最佳實踐

其中最重要的是函數的單向性。大多數微服務採用的是請求 / 響應式的架構,這也是大多數 Web 應用程序的運行模式。 Serverless 應用程序裡的函數通常是單向的,並使用隊列充當迴路斷路器,所以請求 / 響應式的架構就變得不那麼常見了。

數據層的管理方式也不太一樣。最好是可以使用多個函數,而不是使用一個帶有切換開關的代理函數。

相比微服務架構,多函數還有另外一個好處。例如,如果一個函數出錯,因為它是無狀態的(或至少應該是),所以只會影響該函數本身,不會影響到應用程序的其餘部分。

如果只是簡單地從微服務轉向 Serverless 架構,雖然確實會給你帶來一些好處,但也會錯失很大一部分 Serverless 應用程序的真正價值。

從很多方面來看,微服務與 Serverless 應用程序是相背離的,雖然我們可以基於 Serverless 後端來構建微服務,但在微服務和 Serverless 之間並不存在直接的路徑。

從微服務到 Serverless

那麼,從微服務到 Serverless 需要經過怎樣的路徑?微服務已經相當普及了,那麼是否存在一條簡單的路徑,可以直接從一方過渡到另一方?

我想,這也正是 Serverless 世界正在解決的問題。最近,Twitter 上有很多與這個話題相關的推文。這裡引用其中的一條,看看社區都是怎麼討論這個話題的。

微服務和Serverless的天作之合 1

現在有很多工具聲稱它們會讓 Serverless 應用程序的構建變得更容易,但實際上最終都是要去到它們的平台上。我不認為它們會帶來額外的價值或者會讓人們更好地理解什麼是 Serverless 架構。

我們非常清楚地意識到,我們正在討論的是Serverless 架構的未來,但並沒有說這會讓從舊架構風格過渡到Serverless 會變得更容易,或者斷定Serverless 是不是一個正確的選擇(在某些情況下可能不是)。

這是有原因的。人的思維是不容易改變的。構建一個 Lambda 函數很容易,但構建一個真正的 Serverless 應用程序並不容易,它需要在思維上做出一系列改變,而這樣做相對沒有那麼容易。

另外,我也經常說,我們不要只是簡單地把人們帶入到“hello world”,然後就撒手不管,有很多技術人認為這樣做就夠了。

我寫了一個有關 Serverless 的最佳實踐,是想幫助人們認識到他們不應該基於當前的知識框架去構建 Serverless 應用程序。

我們現在用來構建 Serverless 解決方案的工具就是我們用來構建雲 1.0 應用程序的工具,它們並不完全符合我們的目標。

這些工具還不完美,我們會努力去改進它們。

英文原文

Serverless and Microservices: a match made in heaven?