Here's the latest graph of memory versus billing for Spring Cloud Function on AWS Lambda. It shows the billing metric GBsec as a function of memory allocation in Lambda for two custom runtimes, one in plain Java and one using a GraalVM native image, as described recently in this blog by Andy Clement (這是 AWS Lambda 上 Spring Cloud Function 的最新記憶體與計費圖。它顯示了計費指標 GBsec 作為 Lambda 中記憶體分配的函式，用於兩個自定義執行時，一個使用純 Java，一個使用 GraalVM 原生映象，正如 Andy Clement 最近在這篇部落格中描述的那樣)

In both cases the functionality is identical (a simple POJO-POJO function), and they both show only the results for cold start. Warm starts, where the function was already active when the request came in, were much faster and cheaper (except for the smallest memory setting they all cost the same because there is a minimum charge for all functions in AWS). You can see that the native images start up very fast and that they are more than two times cheaper to run than the regular JVM. The fastest startup was in the 1000MB container - it only took 19ms to start the app, but it took AWS 700ms to prepare the container, so it was billed at 800ms. In fact, all of the cold starts were billed at 800ms for the native image. For the regular JVM the fastest startup was also in the 1000MB container at 300ms, but it was billed at 2200ms. (在這兩種情況下，功能都是相同的（一個簡單的 POJO-POJO 函式），並且它們都只顯示冷啟動的結果。熱啟動，即函式在請求到來時已經啟用，速度更快，成本更低（除了最小的記憶體設定，它們的成本都相同，因為 AWS 中所有函式都有最低費用）。您可以看到原生映象啟動速度非常快，並且執行成本比普通 JVM 便宜兩倍以上。最快的啟動是在 1000MB 容器中 - 只需 19 毫秒即可啟動應用程式，但 AWS 花費了 700 毫秒來準備容器，因此計費為 800 毫秒。事實上，所有冷啟動的原生映象都以 800 毫秒計費。對於普通 JVM，最快的啟動也是在 1000MB 容器中，耗時 300 毫秒，但計費為 2200 毫秒。)

For comparison, here's the a similar graph that I published over a year ago when Spring Cloud Function reached its 2.0 release. It showed significant improvements over the 1.x version, and also featured the custom runtime which I am using again here (so the orange bars are the equivalent of the red bars in the graph above) (為了比較，這是我一年多以前釋出的類似圖表，當時 Spring Cloud Function 達到了 2.0 版本。它顯示了比 1.x 版本的顯著改進，並且還具有我在此再次使用的自定義執行時（因此橙色條與上圖中的紅色條等效）)

The custom runtime in the regular JVM is roughly the same in version 3.x, but you can use it at lower memory settings because of Spring Boot optimizations that have been released since then. (普通 JVM 中的自定義執行時在 3.x 版本中大致相同，但由於此後釋出的 Spring Boot 最佳化，您可以在較低的記憶體設定下使用它。)

Building the Sample (構建示例)

The sample app was taken from the Spring Graal Native Feature, but modified to be a function of POJO to POJO, forcing Spring to do some extra work. So compared to the sample in Github I modified the function (該示例應用程式取自 Spring Graal Native Feature，但修改為 POJO 到 POJO 的函式，強制 Spring 進行一些額外的工作。因此，與 Github 中的示例相比，我修改了該函式)

class Foobar implements Function<Foo, Foo> {

	@Override
	public Foo apply(Foo input) {
		System.err.println("HI: " + input.getName());
		return new Foo("hi " + input.getName() + "!");
	}
}

where the Foo is defined like this (其中 Foo 定義如下)

class Foo {
	private String name;

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}

	public Foo(String name) {
		this.name = name;
	}

	Foo() {
	}
}

and the function is registered in the main application (該函式在主應用程式中註冊)

	@Override
	public void initialize(GenericApplicationContext context) {
		context.registerBean("foobar", FunctionRegistration.class,
				() -> new FunctionRegistration<>(new Foobar())
						.type(FunctionType.from(Foo.class).to(Foo.class)));
	}

Note that I am using the functional bean registration style, although it doesn't make much difference for such a simple application. (請注意，我正在使用 函式式 bean 註冊樣式，儘管對於如此簡單的應用程式來說，它沒有太大區別。)

I also had to modify the tests to make sure they work with the new POJO signature. You could just delete the tests and the verify.sh to avoid having to do that, if you just want something quick to work. If you want to see what I did look at the foo branch in my fork. (我還必須修改測試以確保它們適用於新的 POJO 簽名。如果您只是想要快速工作的東西，您可以刪除測試和 verify.sh 以避免這樣做。如果您想檢視我所做的事情，請檢視我的 fork 中的 foo branch。)

Then I built the application in the same way as the other samples. This creates the native image and dumps it in the target directory (然後我以與其他示例相同的方式構建了應用程式。這將建立原生映象並將其轉儲到 target 目錄中)

$ ./build.sh

It also creates a .zip file to upload to AWS. This one is the regular JVM version (它還會建立一個 .zip 檔案以上傳到 AWS。這是普通 JVM 版本)

$ ls -l target/*.zip
-rw-rw-r-- 1 dsyer dsyer 32577121 Apr 21 09:37 target/function-aws-0.0.1-SNAPSHOT-java-zip.zip

and then this creates a .zip file for the native image (然後，這將為原生映象建立一個 .zip 檔案)

$ ./mvnw package -P native
$ ls -l target/*.zip
-rw-rw-r-- 1 dsyer dsyer 32577121 Apr 21 09:37 target/function-aws-0.0.1-SNAPSHOT-java-zip.zip
-rw-rw-r-- 1 dsyer dsyer 26284838 Apr 21 09:28 target/function-aws-0.0.1-SNAPSHOT-native-zip.zip

Conclusion (結論)

Using Spring Cloud Function is a very convenient way to develop functions that run on AWS and other platforms. If you also use the experimental Spring Graal Native Feature project to compile the result to a native binary executable they can run faster than the same application on a regular JVM. Note that there is another sample in the Spring Graal Native Feature project that makes a function into a standalone web application (there is also a functional bean registration version of the same sample). You can run that on a lot of platforms that allow you to "bring your own container". (使用 Spring Cloud Function 是一種非常方便的方式來開發在 AWS 和其他平臺上執行的函式。如果您還使用實驗性的 Spring Graal Native Feature 專案將結果編譯為原生二進位制可執行檔案，它們可以比普通 JVM 上的相同應用程式執行得更快。請注意，Spring Graal Native Feature 專案中還有另一個示例，它將函式轉換為獨立的 Web 應用程式（還有相同示例的函式式 bean 註冊版本）。您可以在許多允許您“自帶容器”的平臺上執行它。)