转载

微服务架构选Java还是选Go - 多用户负载测试

Ivan Nikitsenka

微服务架构允许我们再创建新应用时自由选择不同的技术和编程语言。不过究竟哪种语言更适合我们当下的硬件？回答这个问题，需要搞明白Java和Go编写的相同应用程序之间的性能差异。

先决条件

不采用其他性能增强功能
使用默认框架和库设置的最小配置
没有ORM框架
使用纯DB驱动程序和相同的SQL查询
用于Java的Postgres JDBC 4.2驱动程序和用于Go的github.com/lib/pq

怎么做

使用DB（Postgres）数据存储创建简单的Java/Go REST API应用程序
使用JMeter或类似工具创建负载测试
在单独的AWS实例上运行应用程序，加载测试和数据库
收集负载测试结果

被测系统

作为被测系统，这里准备了两个银行应用：bank-java和bank-go。

APIs：

POST / client / new / {balance} - 创建具有初始余额的新客户

POST /交易 - 将资金从一个账户转移到另一个账户

GET / client / {id} / balance - 返回客户端的当前余额

框架和依赖关系

在选择框架和库时，这里使用了最新、最流行和最简单的框架和库来尽快准备好应用程序。

Bank-java：Java 10、Spring Boot 2.0.4、spring-web 5.0.8、PostgreSQL JDBC 4.2.4

Bank-go：Go 1.8，gorilla / mux，github.com / lib / pq。

银行应用源码

Bank-java: https://github.com/nikitsenka/bank-java

Bank-go: https://github.com/nikitsenka/bank-go

测试项目

测试项目Bank-test使用动态变化的用户数（从1,000到10,000）执行对银行API的调用，验证响应并收集统计信息。

测试环境

这里用AWS并创建了两个AWS EC2实例：

Bank-go t2.micro (Variable ECUs, 1 vCPUs, 2.5 GHz, Intel Xeon Family, 1 GiB memory, EBS only)
Bank-java t2.micro (Variable ECUs, 1 vCPUs, 2.5 GHz, Intel Xeon Family, 1 GiB memory, EBS only)
Postgres d2.xlarge (14 ECUs, 4 vCPUs, 2.4 GHz, Intel Xeon E52676v3, 30.5 GiB memory, 3 x 2048 GiB Storage Capacity)
Bank-test t2.2xlarge (Variable ECUs, 8 vCPUs, 2.3 GHz, Intel Broadwell E5-2686v4, 32 GiB memory, EBS only)

结果

完整结果请查看 here

结果小结

两个应用与1,000个并发用户完美配合。2,000个用户时，Go性能显着降低，而Java仍然是完美的。从3,000个用户及以上用户开始，两个应用都显示出不可接受的响应时间，并且错误响应的数量显着增加。

总结

使用相同的硬件，Java REST API应用程序可以提供两倍于具有PostgreSQL数据库的Go应用的并发用户数。

关于Rainbond

> Rainbond （云帮）是"以应用为中心”的开源PaaS，深度整合基于Kubernetes的容器管理、ServiceMesh微服务架构最佳实践、多类型CI/CD应用构建与交付、多数据中心资源管理等技术，为用户提供云原生应用全生命周期解决方案，构建应用与基础设施、应用与应用、基础设施与基础设施之间互联互通的生态体系，满足支撑业务高速发展所需的敏捷开发、高效运维和精益管理需求。