為什麼JVM平臺對於無伺服器FaaS來說是個壞主意？ - frankel

JVM平臺是一個很好的技術產品。特別是，抽象層允許 JVM 將位元組碼編譯為適合工作負載的本機程式碼。這就是為什麼即使 C/C++ 編譯的應用程式更接近裸機，JVM 也能夠在效能方面與它們競爭 - 甚至獲勝的原因。

然而，這種優化是有代價的：JVM 需要時間來預熱，例如，將類載入到記憶體中。這就是為什麼在 JVM 上的效能測試需要幾輪熱身。出於這個原因，JVM 非常適合長時間執行的程式，與整個生命週期程式相比，啟動時間可以忽略不計。應用伺服器是此類用例的典型代表：一旦啟動，就應該執行很長時間，比如幾天，這是非常保守的。在這方面，一分鐘的啟動時間毫無意義。

現在FaaS來了 。

在做任何事情之前，我們應該首先解決 FaaS 和 Serverless 的定義。

檢視維基百科上的人都同意的內容：

無伺服器計算是一種雲端計算執行模型，其中雲提供商執行伺服器，並動態管理機器資源的分配。定價基於應用程式消耗的實際資源量，而不是預先購買的容量單位。

函式即服務 (FaaS) 是一種雲端計算服務，它提供了一個平臺，允許客戶開發、執行和管理應用程式函式，而無需構建和維護通常與開發和啟動應用程式相關的基礎設施的複雜性。

從上面的定義來看：

無伺服器是關於資源的管理

您需要動態處理它，屬性是彈性

FaaS 是關於程式碼的大小

規模的演變從成熟的應用程式到微服務再到函式。

因此，FaaS 意味著無伺服器。

在 JVM 上下文中，FaaS 意味著 JVM 啟動、函式執行、然後一切都被丟棄。在這種情況下，啟動時間對整體執行時間有重大影響。此外，JVM 沒有時間將位元組碼編譯為本機程式碼：它還處於“冷態”。

一些人建議在 JVM 執行之後一直保持它，這樣避免支付啟動時間的成本。實現這一點非常簡單：只需比 FaaS底層銷燬JVM速度更快地速度向函式傳送請求（一直保持請求活躍，類似快取擊中率）。然而，它違背了無伺服器的目的，因為彈性屬性現在已經消失了。

這一分析適用於 Kotlin、Java、Scala、Groovy、Clojure 以及在 JVM 之上執行的所有其他語言。即使我喜歡 Kotlin，這也是行不通的：除非沒有人需要 FaaS 方法提供的彈性。

兩全其美的方法有嗎？

然而，並沒有失去所有希望。有很多方法可以使用 Kotlin 並且仍然能夠從 FaaS 中受益。既然FaaS的問題是JVM，那為什麼不去掉呢？有兩種簡單的方法可以實現：

• 使用 Graal 的原生映象

GraalVM 是一組不同的技術。其中包括SubstrateVM：它允許將 JAR（或類）轉換為本地可執行檔案。然後，您可以將生成的應用程式包裝到 Docker 容器中，該容器必須與您選擇的 FaaS 框架相容。這是這種方法的一個示例。

• 轉換為 JavaScript

另一種選擇是將 Kotlin 轉換為 JavaScript。JavaScript 不需要執行 JVM 平臺。然後，可以將程式碼包裝到上述容器中或直接打包到 ZIP 存檔中。後一個選項可以在專有基礎設施上執行，例如 AWS Functions。

這兩種方法都需要一個可靠的構建管道，以從 Kotlin 開始並以 Docker 容器（或 ZIP）結束。與原始設計一樣，他們既需要單元測試來測試程式碼是否正確，也需要整合測試來測試最終工件是否按預期工作。

結論

人們需要了解大多數技術的背景上下文，您（可能）不需要微服務、FaaS 或任何目前流行的炒作技術。但是，通過了解它們的利弊，您將能夠在適當的時候利用它們。

就目前而言，將 JVM 與 FaaS 結合使用是不明智的。這並不意味著您根本不能使用 Kotlin。