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這樣的嵌入式容器。
所以，這里我挑選了幾個候選者：
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 -t16 -c1000 -d30s http://127.0.0.1:8080/rest/hello.
針對每個case, 我使用16個線程，以及100/200/500/1000并發進行測試。
服務啟動命令
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
測試結果
測試結果數據可以查看這里：測試數據,
延遲基本在幾毫秒到10幾毫秒之間。
圖形化測試結果(y軸為Requests/sec, x軸為并發量)：
結論
從結果看，
- RESTEasy的性能要好于 Jersey,無論哪種嵌入式JEE容器。
- Jersey+Grizzly2和Jersey+Jetty, dropwizard性能差別不大
- dropwizard底層實際是Jersey+Jetty,性能結果也和Jersey+Jetty一樣
- RESTEasy+netty的結果并沒有優于RESTEasy+undertow.這出乎我的意料，可能CPU和Memory占用上會好一些
當然測試也有一點遺憾，就是沒有記錄測試時的CPU占用率和Memory占用率，以我個人的經驗，這方面Netty會占一些優勢。