Java RESTful架構的性能比較

在微服務流行的今天，我們會從縱向和橫向分解代碼的邏輯，将一些獨立的無狀态的代碼單元實作為微服務，可以将它們釋出到一些分布式計算單元或者Docker中，并在性能需要的時候及時地建立更多的服務單元。

微服務是一個概念，并沒有規定服務的格式，但是很多廠商和架構都不約而同的采用RESTful的架構,盡管也有一些其它的性能很好的RPC架構。

如何在Java生态圈選擇一個輕量級的RESTful架構？可以參考一些其他人的經驗， 比如我翻譯的: 最好的8個 Java RESTful 架構。

就我個人而言，我選擇架構的理由很簡單：

• 簡單，輕量級
• 性能好
• 穩定，可靠
• 易于開發和維護

我會首選遵循Java規範(JSR339)的架構，輕量級，便于釋出到Docker容器中。 是以我不會選擇Spring boot, Spring MVC, CXF等比較重的架構,也不會選擇純netty這樣的太過底層，還得實作路由等基本功能架構。

因為追求輕量級，便于釋出到docker容器中，我也不會考察JBOSS, Tomcat這樣的JEE容器， 而是選用jetty, undertow這樣的嵌入式容器。

是以，這裡我挑選了幾個候選者：

1. Jersey + Grizzly
2. Jersey + Jetty
3. Dropwizard
4. RESTEasy + Netty
5. RESTEasy + Undertow

[Updated on 2015/11/18]

我增加了更多的 RESTful 架構,有些不是Jax-RS的實作，但是也有很活躍的社群。

1. Jersey + Jetty4
2. Spring Boot
3. 純Netty

4. Vert.x

   你會發現一些有趣的測試結果。

Jersey 是Jax-RS的官方參考實作，可以很好的和其它JEE容器內建。RESTEasy是JBoss出品的架構，也很容易的和其它容器內建。Dropwizard實際上內建了Jersey, Jetty以及其它的第三方庫比如它的Metrics，提供了一站式的開發，略微有些厚重。

測試相關的代碼已經放在了GITHUB上： 代碼

編譯代碼

測試代碼是一個多子產品的Maven項目， 你直接運作

maven clean package

就可以生成各個jar,而且這些jar包含了所依賴的類，執行起來相當簡單。

你也可以在每個子產品下運作

mvn exec:java

啟動服務，然後在浏覽器中通路 http://localhost:8080/rest/hello (對于Jersey + Jetty,位址是http://localhost:8080/hello)

測試環境

伺服器

AWS C3.2xlarge

• 8 cores (E5-2666 v3 @ 2.90GHz)
• memory: 16G (服務隻配置設定了4G記憶體)

Java

1.8.0_51

測試工具

wrk

測試指令如: 

wrk -t16 -c1000 -d30s http://127.0.0.1:8080/rest/hello

.

針對每個case, 我使用16個線程，以及100/200/500/1000并發進行測試。

服務啟動指令

1 2 3 4 5 6 7 8 9

java -Xmx4g -Xms4g -jar jersey-grizzly2- 1. 0-SNAPSHOT.jar java -Xmx4g -Xms4g -jar jersey-jetty- 1. 0-SNAPSHOT.jar java -Xmx4g -Xms4g -jar dropwizard- 1. 0-SNAPSHOT.jar hello.yml java -Xmx4g -Xms4g -jar resteasy-netty- 1. 0-SNAPSHOT.jar java -Xmx4g -Xms4g -jar resteasy-undertow- 1. 0-SNAPSHOT.jar java -Xmx4g -Xms4g -jar springboot- 1. 0-SNAPSHOT.jar java -Xmx4g -Xms4g -jar resteasy-netty4- 1. 0-SNAPSHOT.jar java -Xmx4g -Xms4g -jar nativenetty- 1. 0-SNAPSHOT.jar java -Xmx4g -Xms4g -jar vertx- 1. 0-SNAPSHOT.jar

測試結果

測試結果資料可以檢視這裡： 測試資料,

延遲基本在幾毫秒到10幾毫秒之間。

圖形化測試結果(y軸為Requests/sec, x軸為并發量)：

結論

從結果看，

• RESTEasy的性能要好于 Jersey,無論哪種嵌入式JEE容器。
• Jersey+Grizzly2和Jersey+Jetty, dropwizard性能差别不大
• dropwizard底層實際是Jersey+Jetty,性能結果也和Jersey+Jetty一樣
• RESTEasy+netty (netty3)的結果并沒有優于RESTEasy+undertow.這出乎我的意料，可能CPU和Memory占用上會好一些
• RESTEasy+netty4的性能遠遠低于RESTEasy+netty3，這出乎我的意料。或許因為Netty線程池的改變。
• 純netty的性能遠遠高于其它架構，一方面是由于沒有http router的邏輯，另一方面也顯示了Netty架構的優秀。如果不是實作很複雜的路由和很多的Service,不妨使用純Netty實作高性能。
• Spring Boot太厚重了，使用Spring MVC的文法，性能隻有Jersey的一半。
• Vert.x底層使用Netty,可以使用Java 8 Lambda文法，也提供了其它語言的支援，但是性能看起來不是太好，而且随着并發量增大吞吐率也随之下降。

當然測試也有一點遺憾，就是沒有記錄測試時的CPU占用率和Memory占用率，以我個人的經驗，這方面Netty會占一些優勢。

轉自： http://h2ex.com/371?utm_source=tuicool&utm_medium=referral