部署Web服务的好习惯是什么？

Question

单独部署Web服务或者它们是Web应用程序的一部分是一种好的做法吗？例如,我正在开发基于Spring rest的Web服务.该服务的功能是,用于获取用户数据.

查询此Web服务的每个Web应用程序都将其用户数据放在不同的模式中.那么,现在web服务需要知道谁在调用它 - 它是Appilcation A还是Application B？如果它是AppA,那么它应该从Schema A获取数据,如果它是AppB,那么它是另一个模式.请注意,AppA和AppB只是包含在两个不同战争中的相同代码,它们应该查询的模式是从属性文件提供的.

在这种情况下,使用webapp代码打包webservice并在不同的上下文中部署它是否有意义,因此它成为在不同上下文中运行的duplciate服务.或者,它是否应该单独部署,并且应该以某种方式将AppA和AppB标识为此Web服务？

Answer 1

我更喜欢以下方法,它用于50K并发用户.

1. 通过执行所需的业务用例,确保每个Web服务独立地封装UI和Schema.每个Web服务都将具有所有三个层 - 该业务服务的模型,视图和控制器.这意味着您的App-A是一个Web服务,App-B是其他Web服务.
2. 所有Web服务都将注册并取消注册Master Web服务.主Web服务负责将用户请求重定向到适当的Web服务,如App-A或App-B.

3. 您应该拥有Master Web服务集群和各个Web服务集群 - App-A和App-B

4. 在此方法中,您的架构可以驻留在不同的数据库而不是单个数据库

这种方法的优点:

1. 每个Web服务都可以水平扩展.如果要增加比例,只需添加其他VM节点即可.

2. 如果在不同位置的不同数据库上有不同的模式,则可以避免OLTP查询中的网络性能瓶颈(联机事务处理查询).

缺点:

1. 我认为只有一个缺点,因为Master Web Service就像Facade一样,它应该知道单个Web服务的内部.但如果考虑权衡取舍,它所提供的优势并不是一个缺点.

Answer 2

您正在尝试将数据提供者或 DAO 实现为服务。为了做到这一点——

1. 简单的
2. 可扩展
3. 维护友好，
4. 适应性强

您可以简单地拥有一个 Web 服务，部署在 Web 应用程序外部并驱动配置。配置本身可以存储为属性文件或来自数据库。客户端的标识符应在 Web 服务请求中传递。

这实际上是一种非常标准的方法，用于在数据库之外的数据层进行优化，例如缓存（再次由配置驱动）、过期、池化等。

另一个选项，即作为共享 jar 包含在 web 应用程序中，是的，具有代码重用的优点（您也可以通过外部部署的服务获得），但以下缺点超过了该选项。

• 耦合
• 采用优化很困难
• 发布管理（这也取决于您的代码的组织方式）
• 版本控制。

希望能帮助到你。