0

我有一个客户端服务器应用程序,它是基于 Java 的服务器,带有 Spring。

现在我必须用 Web 客户端替换 Java 客户端。

我有三个不同的架构概念来实现网络服务器并将其链接到应用程序服务器。但我不确定我应该使用哪个。我对网络应用程序不是很坚定,但我认为这不是网络客户端的纯粹决定。有人可以给我一些不同概念的优缺点,或者请告诉我我的概念是否有错误。

这些是概念:

  1. 在我的应用程序服务器中使用嵌入式 Web 服务器。 Pro:我不能在 Web 服务器和应用程序服务器之间实现任何会话处理。网络服务器可以使用应用服务器的数据存储来处理请求。缺点:客户必须决定是否允许应用服务器启动他们自己的 Web 服务器。而且我不确定将 web ui 逻辑与应用程序服务器的业务逻辑混合是否是一种好风格

  2. 将业务逻辑嵌入到 web ui 中,以争取独立的 web 服务器。 优点:基本的安全内容,如 https 处理将由 Web 服务器完成。对于客户来说,部署可能更容易接受。我不能在 Web 服务器和应用程序服务器之间实现任何会话处理。网络服务器可以使用应用服务器的数据存储来处理请求。 缺点:应用程序服务器有大量内存和 cpu 使用率。这可能是Web服务器的问题。

  3. 将 web ui 嵌入 web 服务器并通过套接字连接将其链接到应用程序服务器。 优点:严格分离用户界面和业务逻辑。应用服务器一定不能改变,因为web服务器和应用服务器之间的socket连接可以使用胖客户端已有的socket连接。缺点:用户会话的处理必须处理两次。首先是 Web 会话,其次是到应用程序服务器的会话。此外,Web 服务器必须为数据设置自己的存储,并且必须使它们与应用服务器中的存储保持同步。

我的第一个想法是采用第一个概念,因为我在一个应用程序中拥有所有东西。但是我的第二个想法是使用第三个概念,因为严格的分离和真实 Web 服务器的好处。但这里我的问题是为每个用户处理两个会话。还是有更好的概念?

谢谢你给我意见!

4

1 回答 1

0

你的第三种方法更好。保持应用程序服务器分开将更好地服务于不同的客户端,如 Java 客户端、Web 客户端等。它将分离 2 个不同的关注点。如果有 UI 相关的问题,那么您可以关闭 UI 服务器并修复它。但是您的其他 Java 客户端可以正常工作。此外,从发展的角度来看,它也会更好。

于 2018-05-10T16:45:40.683 回答