单独部署Web服务还是应该成为Web应用程序的一部分是一种好的做法？例如，我正在开发一个 spring 基于休息的Web服务。该服务的功能是，用于获取用户数据。
查询此Web服务的每个Web应用程序都将其用户数据放在不同的架构中。那么，现在web服务需要知道谁在调用它 - 它是Appilcation A还是Application B？如果它是AppA，那么它应该从Schema A获取数据，如果它是AppB，那么它是另一个模式。请注意，AppA和AppB只是包含在两个不同战争中的相同代码，它们应该查询的模式是从属性文件提供的。
在这种情况下，使用webapp代码打包webservice并将其部署在不同的上下文中是否有意义，因此它成为在不同上下文中运行的duplciate服务。或者，它应该单独部署，并且AppA和AppB应该以某种方式向这个Web服务标识自己？
答案 0 :(得分：5)
我更喜欢以下方法，它用于50K并发用户。
您应该拥有 主网络服务群集＆amp;个人网络服务集群 - App-A＆amp;应用-B
在此方法中，您的 架构可以驻留在不同的数据库 而不是单个数据库
此方法的优点：
每个网络服务都可以水平扩展。如果您想增加规模，只需添加其他VM节点。
如果在不同位置的不同数据库上有不同的模式，则可以避免OLTP查询中的网络性能瓶颈（联机事务处理查询）。
<强>缺点：
答案 1 :(得分：2)
我的意见：
1）为同一代码构建2个不同战争的任何具体原因？是否因为每个数据源都有两个不同的数据源？ 为什么你不能在每个请求中使用一些参数化机制进行单个应用程序部署，以确定从哪个模式获取数据？
2）为什么首先需要网络服务？为什么应用程序不直接挂钩到它需要的数据库。
3）是底层数据库事务DB还是一些历史数据？如何使用某种虚拟视图将两个模式合并为一次性 OR ，这些视图根据输入参数从2个模式中选取数据。
在Jay的输入后编辑的*****：
我的建议是将Web服务与2个Web应用程序分开部署，因为它提供了单一地方来管理代码。我有以下建议：
在SOAP XML Schema中定义您自己的标头，它既可以为您提供appContext（应用程序制作调用），也可以为userContext（用户）提供。在这方面做好充分考虑，保持长远眼光。
保持SOAP请求 - 响应无状态，这将为您提供可伸缩性。不要在服务器端维护任何SOAP请求状态。
我过去曾使用过数据虚拟化解决方案（CISCO Composite）..它提供了哪些好处：如果有两个（或更多）数据源包含相似类型的数据（实体），它可以加入，清理＆安培;虚拟地合并它并将其作为基于REST / SOAP的Web服务公开。尝试评估此选项。 如果将来有其他消费者使用普通的SQL / JDBC调用来访问您的信息，他们将能够做到这一点，它还可以提供帮助...还有数据虚拟化解决方案支持许多其他接口，如Hadoop，OData等消费者。 。这取决于预算和项目的其他限制......我不确定是否有任何有效的开源数据虚拟化解决方案可用？
答案 2 :(得分：2)
我不知道您的业务需求是为用户数据维护不同的模式以及使用webservice。
但是，我建议您在应用程序中配置多个数据源，并根据您的要求切换到数据源，而不是使用相同的代码维护多个战争。
This link may help you to configure multiple DS
如果您允许上述逻辑，则最终可能会出现单个可部署的上下文。
仍然希望坚持多次战争作为webservice，我建议你看看SpringBoot简单，容器不易部署和可扩展。
答案 3 :(得分：2)
这是一个意见问题，两种选择都没问题。您应该考虑服务的使用，扩展问题等。
你可以将Microservices视为一个想法，但从你的角度来看它必须有意义。
关于两个不同的应用：如果差异仅在配置中，请尝试外部化（23. Externalized Configuration）。这样，您可以将一个工件部署两次。
答案 4 :(得分：2)
鉴于这种情况，只有一个Web服务是一种很好的做法，这样就可以提高系统的可维护性，因为您没有两次相同的代码。如果您将来有其他新的类似应用程序，则无需实施新服务。
答案 5 :(得分：2)
方法1： - （优先）
您应该拥有一个Web应用程序，其中包含应用程序UI和Repo /数据交互的完整代码。
根据请求的类型动态切换数据源。您可以查看Spring Dynamic datasource routing here
方法2： -
如果您的UI具有由不同团队管理的完全不同类型的交互，则将单独的UI组件和后端Web服务维护在同一位置是有意义的。
再次根据请求的类型，您可以动态路由数据源。
希望这会有所帮助：）
答案 6 :(得分：2)
就个人而言，根据我的经验，将它们分开会好得多，这通常取决于您的主要项目有多大和多么重要。
但即使一开始你的项目不是那么大，而且只有一个人在做这件事，后来，随着它继续增长，如果你有所有主要的微服务你的主要项目这样做，维护起来会容易得多，而不是让很多人处理同一个代码处理许多版本的独特项目，处理许多小项目不那么容易混淆，错误也更容易找到。
另外，如果某些内容失败，你可以让主服务器在没有中断的情况下运行1次微服务，只会拒绝1项服务，而不是在你修复服务时将所有服务都关闭。
高可用性在生产中非常重要，将它们分开有助于此。
答案 7 :(得分：2)
这实际上取决于你想要达到的目标。
如果要封装数据库/模式/表，那么它应该是每个应用程序的一个服务。这样做的主要优点是，如果当前存在某些问题，您可以稍后交换数据库，它还可以简化缓存和失效等等。
如果数据库/模式/表未被封装，那么单个服务就更容易和更好。每个Web应用程序都必须标识自己，并且每个Web应用程序都将获得他们所需的内容。这可以通过将查询/模式信息放在属性文件中，或创建与客户端同名的数据库视图等来实现。
如果我们采用这种方法，会弹出一个问题。为什么要打扰这个层呢？每个Web应用程序都无法直接查询数据库吗？如果答案是肯定的，那么只需完全删除整个图层。
答案 8 :(得分：2)
根据您的情况，我建议使用一个webapp（一个＆＃34;项目＆＃34;）并提出一些警告，然后考虑两个解决方案中的一个：
1）鉴于你正在使用春天，我会假设（希望）你也在使用maven .. 制定一个不同的编译目标，并使其根据调用的目标产生战争，相关的属性文件是不同的.. 这样你就有了一个webapp，并且基于编译（或者更确切地说基于与特定编译相关的属性文件），你将获得与特定环境和架构相关的战争...你为每个web服务部署一个单独的战争一个干净的分离，虽然根代码是相同的，它只是一个应用程序... [清洁解决方案] 2）这样做是为了让你不仅获得json请求，而且还获得发送者的https证书（因此你可以识别特定的＃34; webapp＆＃34;基于公开的https证书），并且基于证书和请求的来源，您确保来源为＆＃34;合格＆＃34;从模式X而不是模式Y接收数据。您只能部署一个战争，由他自己决定应用逻辑来重新路由您的用户数据获取查询＆＃34;到一个数据库或另一个[我发现这个实践]
当然还有其他方法，但我认为这两种方法最可行..
答案 9 :(得分：1)
我会部署到一个实例。无论。当然，在某些情况下可能需要单独部署。从最好的＆＃34;编码＆＃34;练习时，应该使用一个实例来允许一次使用很多＆＃34;。
则...
答案 10 :(得分：1)
您正在尝试将数据提供程序或DAO实现为服务。 要做到 -
您可以简单地拥有一个Web服务，部署在WebApp之外并驱动配置。配置本身可以存储为属性文件，也可以存储在DB中。应该在webservice请求中传递客户端的标识符。
这实际上是一种非常标准的方法，用于在数据库之外的数据层实现优化，如缓存（再次驱动配置），到期，池化等。
另一个选项，即作为webapp中的共享jar包含，是的，具有代码重用的优势（也可以通过外部部署的服务获得），但是以下缺点超过了选项。
希望它有所帮助。