将 JavaEE 应用程序扩展到 1.000.000 个并发用户

Posted 2023-02-23

【中文标题】将 JavaEE 应用程序扩展到 1.000.000 个并发用户

【英文标题】：Scaling a JavaEE application to 1.000.000 concurrent users

【发布时间】：2012-11-29 13:08:00

【问题描述】：

我有一个 JavaEE 应用程序： 1 使用 EJB 和 SOAP 的 EAR；一些使用 Servlet 的 WAR。目前，EAR 部署在 Glassfish 3.1.2（社区版）中，而 WAR 部署在 tomcat 或 Glassfish 服务器上。

该应用程序由 mysql 数据库支持，并且主要执行一些琐碎的数据传入和传出数据库的操作。几乎没有静态内容。在当前架构中，几乎没有任何请求可以由战争本身来回答，并且总是涉及 EAR（可能通过一些重新设计来改变这一点）。

这对于 20 个并发用户来说是开箱即用的，并且通过一些 http 线程池调整可以在一个中型服务器上支持多达 200 个并发用户。

我现在必须扩展应用程序以应对 1.000.000 个用户（这不是一个乐观的猜测，而是对业务的现实要求；大多数“用户”将是部署在现场的设备）。

如何扩展此应用程序以处理 1.000.000 个并发用户？特别是：

我是否应该能够让单个 glassfish 服务器为超过 200-500 个用户提供服务（对于要求不高的 web 应用程序）？如果是，我应该以什么为目标？ glassfish 集群似乎是一种选择，但它的规模有多大？即便如此，运行 1000-2000 台服务器（即使在云中）听起来对我来说也不是很吸引人。 如果 tomcat/glassfish 是错误的答案，有哪些替代方案？ 目前的瓶颈是 webapp，但我认为在某个阶段数据库也可能成为问题。 MySQL 扩展到这样的规模有多好？

【问题讨论】：

问题 1：每天有 1.000.000 个并发用户？问题 2：您的数据多久更改一次？问题3：你有很多交易吗？问这些问题的原因是，是否可以使用缓存（如 ehcache）？数据是否可以使用 Hadoop 或 NoSQL 数据库在分布式服务器上进行分片/传播？等

1) 是的。智能电表和其他传感器等设备意义上的“用户”。 2) 每台设备每 5 到 10 分钟报告一次。有些人可能会更频繁地轮询命令。 3）是的，但微不足道的交易，即必须一起成功的少量写入。第一个问题似乎只是 Glassfish 或 Tomcat 处理了这么多的连接。这个问题是不久前发布的，我们现在可以在长轮询（Servlet 3 Async）上同时进行大约 15.000 个连接，然后才会出现问题。 DB 仍然没有出汗。

【参考方案1】：

希望您能在以下网址中找到一些有用的信息。

http://highscalability.com/blog/category/example

【讨论】：

是的，这个网站真的很棒。