我正在制作多人游戏。现在我正在尝试选择将Android设备连接到服务器的技术。客户端在Android上运行，游戏是MMORPG。我想用java编写服务器。 现在我只有3个想法：
1）使用普通的java和套接字创建多线程环境。以这种方式，在游戏客户端和服务器之间执行全双工连接将更容易。但我有以下问题：
1.1）游戏是带有大量对象的MMORPG，如果有5000个人同时玩，我不确定这些解决方案是如何缩放的。我可以在Java机器上运行多少个线程？我怎样才能大致计算出来？如果1个线程正在为每个套接字读取并且1个线程正在写入套接字（因此1个玩家有2个线程）。
1.2）当玩家数量增加时，我如何能够扩展我自己编写的jar-archive以分布在多个服务器上？也许有一些特殊的技巧可以做到这一点？
1.3）许多编程开销 - 套接字API都是相当低级的。
2）创建用于提供HTTP请求的Servlet接口。
2.1）只要每个玩家都有他/她自己的会话，就可以轻松控制会话（和授权）。
2.2）可以连接到Java EE EJB或其他任何东西 - 系统级编程的许多复杂性被带走。所以我可以集中精力编写业务逻辑。
2.3）可以使用HTTP - 移动设备+浏览器为所有类型的客户端提供服务。
2.4）高速 - 即使是1个servlet容器也可以每秒提供几千个请求，因此速度非常快。
2.4）但这种方法无法提供全双工通信。我将每隔1秒发送一次请求以检查更新。 1秒的延迟并没有给游戏带来太大的影响，因为它是基于回合的，但它仍会产生大量的流量。有很多球员在比赛时可行吗？我听说过一些COMET技术，但似乎服务器必须连续推送许多消息，我仍然必须每次都发送请求+这项技术尚未建立。
3）创建套接字并通过JMS将它们连接到java EE服务器。
3.1）酷因为允许客户端和服务器之间的全双工通信+提供了Java EE的所有酷炫功能。以后可以通过servlet接口扩展到浏览器。
3.2）这似乎是某种过度工程。人们真的会这样做吗？我的意思是它甚至是正确的方式吗？任何理智的开发人员会这样做吗？我希望你能帮我解决这个问题。我做这样的工作没有多少经验。并希望坚持最佳做法。
答案 0 :(得分：2)
我认为Idea 3不会过度工程化，而且我会走上这条路。
构建@MessageDriven Bean“适配器”处理onMessage方法中的传入套接字连接很容易开发，从那里你就可以进入规模较大的EE世界。
根据您的情况，您甚至可能希望依赖UDP。请参阅以下示例： http://www.apprigger.com/2011/06/javaee-udp-resource-adapter-example/
但从我的观点来看，还有其他重要原因可以采用这种方式。一些指示：
1。）正如你已经提到过的那样。构建一个自己的Socket Server处理线程和请求是很多工作，最后你可以构建自己的小“应用程序服务器”。
2。）不要害怕使用应用程序服务器。当然，人们倾向于称这种平台为“开销”。虽然当我测量调用其他服务或退潮的时间时，使用本地接口确实花费了不到10微秒的呼叫。拥有自己的线程池＆amp;工人和自己处理它们可能会更快，但也不会接近0微秒; - ）
3。）拥有AS，您可以非常轻松地配置实例边界。更重要的是，您可以比自制软件更轻松地扩展应用程序。想象一下，在2+台服务器上运行集群（如果您的MMO成功，您将会这样做）。网络负载均衡器适用于所有类型的体系结构，但是有可能共享会话信息（可能不是为了游戏玩家连接，但为什么不是用于登录的用户会话）或者群集节点上的实体管理器在EE包中是“免费”的。
所有这些EE工具＆amp;模式让你有时间开发游戏而不是框架; - ）