部署 Web 服务的良好做法是什么？[已关闭]

java architecture web-services spring

2022-09-04 08:12:57

单独部署 Web 服务是一种很好的做法，还是应该将它们作为 Web 应用程序的一部分？例如，我正在开发一个基于弹簧休息的Web服务。比方说，此服务的功能是获取用户数据。

查询此 Web 服务的每个 Web 应用程序都有不同架构中的用户数据。因此，现在Web服务将需要知道谁在调用它 - 它是Appilcation A还是应用程序B？如果它是 AppA，那么它应该从架构 A 获取数据，如果它是 AppB，那么它就是另一个架构。请注意，AppA 和 AppB 只是打包成两场不同战争的相同代码，它们应该查询的架构是从属性文件中提供的。

在这种情况下，将 Web 服务与 webapp 代码打包在一起并将其部署在不同的上下文中是否有意义，因此它将成为在不同上下文中运行的双重服务。或者，它应该单独部署，并且 AppA 和 AppB 应该以某种方式向此 Web 服务标识自己？

答案 1

我更喜欢以下方法，该方法用于50K并发用户。

通过执行所需的业务用例，确保每个 Web 服务独立封装 UI 和架构。每个 Web 服务将具有该业务服务的所有三个层 - 模型、视图和控制器。这意味着您的 App-A 是一个 Web 服务，App-B 是另一个 Web 服务。
所有 Web 服务都将向主 Web 服务注册和取消注册。主 Web 服务负责将用户请求重定向到适当的 Web 服务，如 App-A 或 App-B。
你应该有 Master Web Service 的集群和单个 Web 服务的集群 - App-A 和 App-B
在此方法中，架构可以驻留在不同的数据库上，而不是单个数据库上

这种方法的优点：

每个 Web 服务都可以水平扩展。如果要增加规模，只需添加其他 VM 节点即可。
如果在不同位置的不同数据库上具有不同的架构，则可以避免 OLTP 查询（联机事务处理查询）中的网络性能瓶颈。

弊：

我只看到一个缺点，因为主Web服务就像一个门面，它应该知道单个Web服务的内部。但是，如果您考虑权衡利弊，那么它所提供的优势并不是一个缺点。

答案 2

我不知道您的业务需求，即为用户数据维护不同的架构并使用Web服务。

但是，我建议您不要使用相同的代码维护多个战争，而是在应用程序中配置多个数据源，并根据您的要求切换到数据源。

此链接可以帮助您配置多个 DS

如果您放弃了上述逻辑，则最终可能会得到单个可部署的上下文。

仍然想坚持将多次战争作为Web服务，我建议您看看SpringBoot简单，容器不可部署性和可扩展性。