Web services 面向服务的体系结构和松耦合vs SQL连接

让我们假设我们有一个SOA基础设施，如下图所示 每个服务都可以在不同的主机上运行（这对于两个额外的网络服务“web站点”和“支付系统”尤其有效）

显然，我们有一个数据（持久性）层。假设它是通过EJB+JPA或类似的方式实现的

如果我们想在不同的服务之间连接数据（在用户界面中），我会看到至少两种选择：

• 我们希望在RDBMS级别进行高效连接，因此我们有一个包（即persistence.package），其中包含所有实体和会话外观（CRUD实现），这些实体和会话外观必须以某种方式共享（如何？）或为每个服务部署。这就是说，如果我在order模式中更改了一些内容，我必须重新部署这个包，在几乎所有内容之间引入紧密耦合。此外，数据库必须是唯一的和共享的

• 为了避免此类问题，我们为每个不同的服务保留一个实体包（即order.package），并让服务通过某种协议（soap、rest、esb等）进行通信。因此，我们可以在每个主机中本地保存数据（不共享任何体系结构），并且不需要重新部署实体包。但是这种方法对于数据挖掘来说是可怕的，因为必须在多个服务之间搜索和返回相关数据的查询将非常低效（因为我们不能进行SQL联接）

---

有没有更好的/标准的方法来解决上述问题？

哦，我的朋友，你只是把整个情况复杂化了，但这不是你的错，像微软、甲骨文和其他大型企业级软件供应商这样的公司喜欢让事情变得更简单，他们这样做的原因是：垂直扩展服务意味着更多的许可证

您可以采取另一种方法，暂时忘记所有这些大词，EJB，JPA。。。就像一个聪明人曾经说过的，把大问题分成几个小部分，这样你就不会有大问题，而是有几个小问题，理论上应该更容易处理

因此，您的系统中有两项服务：人员、支付系统、订单、产品、ERP。。。让我们暂时想想，就业务实体而言，这些边界是正确的。假设这些服务是公司的不同物理部门，这意味着它们只关心属于它们的数据，而不关心其他数据

然后，您可以说支付部门有自己的数据库，这同样适用于订单，当然它们仍然需要像所有部门一样相互通信，这可以通过系统生成的公共代理密钥来实现。这意味着每个服务都使用内部键维护其所有内部实体的引用完整性，但如果需要将记录提供给其他服务，您可以使用Guid键，例如：

支付服务需要订单ID和客户ID，但这些实体属于它们自己的服务，因此，不是共享每个记录的私钥（主键），而是每个记录都有一个主键和一个代理外部键，服务将使用它们来共享。问题是，您应该致力于构建松散耦合的服务，每个服务都有自己的“小型”数据库。每个服务还应该有各自的API，不仅前端应该使用这些API，其他服务也应该使用这些API。您应该避免的另一件事是使用DTC或其他事务管理提供商作为服务范围的事务保证人，这是一种可以通过不同的体系结构方法轻松归档的东西

无论如何，请阅读，如果您尚未了解DDD，它将为您提供一个关于如何构建企业级软件的不同概述，顺便说一句EJB，远离它们

更新：

---

您可以使用事件SOA之类的东西，但让我们在这里保持简单。注册客户来到您的站点下订单。负责此操作的服务是订单。产品的外部ID列表将提交给订单服务，然后订单服务将注册订单，此时订单处于“等待付款”状态，此服务将返回公共Guid订单ID。要完成订单，客户需要为货物付款。付款详细信息将提交给付款服务，该服务尝试处理付款，但为此它需要订单详细信息，因为前端发送的唯一内容是订单id，为此它使用订单API中的GetOrderDetails（Guid orderId）。支付完成后，支付服务将调用订单的API PaymentWasCompletedForOrder（Guid orderID）的另一个方法。如果您没有得到任何东西，请告诉我。

SOA的主要动机是可以单独更改的独立组件。正如马可所提到的，第二个动机是将系统简化为更容易解决的小问题。 不同服务的优点是灵活性，缺点是更多的管理和开销——这些开销应该由您得到的回报来证明——例如，请参阅我发布的一个SOA反模式，它讨论了这种平衡

要记住的另一件事是，web服务API并不自动意味着这是服务边界。属于较大服务的多个API仍然可以连接到下面的同一数据库。因此，例如，如果在您的系统中，付款和订单属于一个整体，那么您不应该仅仅因为它们是不同的API而将它们分开（在许多系统中，这些确实是不同的关注点，但这不是自动的）

如果您确实发现将服务分离是合乎逻辑的，那么您应该遵循Marco的建议，确保服务是隔离的，并且不共享数据库。以这种方式隔离服务有助于提高他们的能力