单独部署 Web 服务是一种好习惯，还是应该将它们作为 Web 应用程序的一部分？例如，我正在开发一个基于 spring 休息的网络服务。该服务的功能是获取用户数据。
查询此 Web 服务的每个 Web 应用程序都有不同模式的用户数据。所以，现在网络服务需要知道是谁在调用它——是应用程序 A 还是应用程序 B？如果是 AppA，那么它应该从 Schema A 获取数据，如果是 AppB，那么它应该是另一个模式。请注意，AppA 和 AppB 只是打包到两个不同 war 中的相同代码，并且它们应该查询的模式是从属性文件提供的。
在这种情况下，将 webservice 与 webapp 代码打包并将其部署在不同的上下文中是否有意义，因此它成为在不同上下文中运行的重复服务。或者，是否应该单独部署，并且 AppA 和 AppB 应该以某种方式向该 Web 服务标识自己？
最佳答案
我更喜欢下面的方法，它用于 50K 并发用户。
- 通过执行所需的业务用例，确保每个 Web 服务都独立封装 UI 和 Schema。每个 Web 服务都将具有所有三层 - 用于该业务服务的模型、 View 和 Controller 。这意味着您的 App-A 是一种 Web 服务，而 App-B 是另一种 Web 服务。
- 所有网络服务都将注册和注销主网络服务。主 Web 服务负责将用户请求重定向到适当的 Web 服务，如 App-A 或 App-B。
您应该有主 Web 服务集群和单个 Web 服务集群 - App-A 和 App-B
在这种方法中，您的 架构可以驻留在不同的数据库中，而不是单个数据库
这种方法的优点:
每个网络服务都可以水平扩展。如果您想扩大规模，只需添加额外的 VM 节点即可。
如果您在不同位置的不同数据库上有不同的架构，则可以避免 OLTP 查询(在线事务处理查询)中的网络性能瓶颈。
缺点:
- 我只看到一个缺点，因为 Master Web Service 的作用类似于 Facade，它应该了解各个 Web Service 的内部结构。但是，如果您考虑权衡，这并不是它所提供的优势的缺点。
关于java - 部署 Web 服务的好习惯是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32184751/