Web服务 – 面向服务的体系结构和松散耦合与SQL JOINS

概述假设我们有一个类似于下面绘制的SOA基础架构 每个服务都可以在不同的主机上运行(这对于两个额外的网络服务“网站”和“支付系统”尤其有效). 显然,我们有一个数据(持久性)层.假设它是通过EJB JPA或类似的东西实现的. 如果我们想要在不同的服务之间加入数据(在用户UI中),我至少看到了几个选择： >我们希望在RDBMS级别上进行高效的JOIN,因此我们有一个包(即.persistence.pac 假设我们有一个类似于下面绘制的SOA基础架构
每个服务都可以在不同的主机上运行(这对于两个额外的网络服务“网站”和“支付系统”尤其有效).

显然,我们有一个数据(持久性)层.假设它是通过EJB JPA或类似的东西实现的.

如果我们想要在不同的服务之间加入数据(在用户UI中),我至少看到了几个选择：

>我们希望在RDBMS级别上进行高效的JOIN,因此我们有一个包(即.persistence.package),它包含所有实体和会话外观(CRUD实现),这些实体和会话外观在某种程度上必须共享(如何？)或部署到每个服务.也就是说,如果我在订单模式中更改某些内容,我必须重新部署这些包,引入几乎所有内容之间的紧密耦合.此外,数据库必须是唯一的和共享的.
>为了避免这些问题,我们为每个不同的服务(即order.package)保留一个实体包,让服务通过一些协议(soap,rest,esb等)进行通信.所以我们可以在每个主机中本地保存数据(不共享任何架构),我们不需要重新部署实体包.但是这种方法对于数据挖掘来说非常糟糕,因为必须在多个服务之间搜索和返回相关数据的查询效率非常低(因为我们无法进行sql连接)

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

解决方法 SOA的主要动机是可以单独更改的独立组件.正如marco提到的那样,次要动机是将系统简化为更容易解决的小问题.
不同服务的优点是灵活性,缺点是更多的管理和开销 – 这种开销应该通过你得到的东西来证明 – 例如,我看到我发布的一个名为 Nanoservices的SOA反模式,它讨论了这种平衡

另外要记住的是,Web服务API并不自动意味着这是一个服务边界.属于较大服务的多个API仍然可以连接到下面的同一个数据库.因此,例如,如果您的系统中的付款和订单属于一起,您不应仅仅因为它们是不同的API而将它们分开(在许多系统中,这些确实是不同的关注点,但同样,这不是自动的)

当您确实发现服务逻辑分离时,您应遵循marco的建议,并确保服务是隔离的,不要共享数据库.以这种方式隔离服务有助于他们改变的能力.然后,您可以使用composite front end将它们集成到UI中.您应该注意,这适用于应用程序的 *** 作方面,因为您只需要每个服务中的一些项目.对于报告,您需要类似于aggregated reporting的内容,即将不可变数据副本导出到为报告优化的中央数据库(例如,非规范化星型模式等)

总结

以上是内存溢出为你收集整理的Web服务 – 面向服务的体系结构和松散耦合与SQL JOINS全部内容，希望文章能够帮你解决Web服务 – 面向服务的体系结构和松散耦合与SQL JOINS所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。