use*_*382 19 architecture messaging shared-data
我昨天和我的一个朋友一起去了酒吧,我们开始讨论他在他工作的公司使用的架构.这个对话基本上围绕着共享数据库架构与分布式独立应用程序架构的优缺点 - 我们无法达成共识,在这种情况下,我想听听人们对这两种方法的优缺点的看法.
基本上,他所工作的公司拥有一个拥有许多不同应用程序的大型架构.某些应用程序具有单个数据库,它们在它们之间共享.例如,有一个应用程序为用户提供UI以更改参考数据.该参考数据由另一个也访问相同数据的应用程序使用.我相信代码实际上是作为共享库编写的(即两个应用程序都将使用为每个代码集重新部署的公共代码集(一个将其作为依赖项)).
还有其他应用程序与数据库,其他应用程序也使用直接JDBC连接与数据访问代码(两个应用程序之间不常见 - 重复!!呃!).
我的问题是围绕这个架构的优缺点而不是一个架构,其中每个应用程序都包含它在筒仓中的"主"数据.如果应用程序x需要来自应用程序的数据,则他们使用Web服务或某些消息传递技术来接收该数据.
消息传递方法将引入一个问题,即当前现在必须从另一个源获取在其他应用程序的数据库中使用的参考数据"代码"(或外键).在当前的体系结构中,这些体系的"解码"可以随时更改并立即反映在外部应用程序中,而不必具有复制数据的主/从关系 - 或者应用程序x必须查询应用程序的替代方案y只是为了显示解码值.
我曾阅读过企业集成模式,虽然它确实提供了一些消息传递优势的例子 - 但我并不那么信服.
谢谢伊恩
tom*_*ern 27
DBA希望模拟实体之间的所有关系,以便数据始终100%一致,这是不可避免的争论.另一方面,开发人员会向开发人员发出关于紧密耦合的警告,这些紧密耦合来自单一体系结构,以及如何轻松更改绑定到主表的应用程序.
我认为,无论你如何进行整合,这两个论点都有点难以理解,构建易于改变的系统具有挑战性.我想为SOA和基于消息的集成提出另一种论点.
它归结为:
您有多少次遇到拥有数百名用户的大型系统,这些用户可以完成许多不同的工作,支持多种不同的业务功能？我总是遇到他们.它们似乎是企业软件的主要内容.
所有这些系统似乎都有一个共同点,那就是改变它们非常昂贵.其中一个原因是,正如Joe R在他的回答中所说,紧密耦合.
但是,我们需要考虑两种类型的耦合.
第一种称为技术耦合,这意味着技术堆栈内部的垂直耦合,通常是在一层和另一层之间的n层.
因此,我们在应用程序的数据库和数据访问层之间进行耦合,在数据访问层和业务逻辑层之间进行耦合等.将这种耦合看作是错误或错误似乎被普遍接受,但理性思考我们不应该期待,或者甚至欢迎用户DTO,UserRepository类和User数据库表之间的高度耦合？
让我们考虑一下耦合在实现层面的实际意义.当"属于"一件事物的概念泄漏到另一件事物中时,会发生耦合.当您有多个层基本上相互讨论同一个业务实体时,这种泄漏是不可避免的.
第二种耦合,也就是我想要解决的问题,是业务能力耦合,也称为水平耦合.这就是我们将属于一个业务功能的概念泄漏到另一个业务功能中的地方.
我断言,使用数据库作为集成平台可以促进这种水平耦合.
例如,想象一下支持电子商务网站系统的典型后端系统.您通常会将库存,订购,定价和CRM作为核心功能.
如果我们在单个数据库中对此域进行建模,我们实际上将不同的功能耦合在一起.每个外键约束都可能增加这些功能之间的耦合程度.事实上,到目前为止,系统已经可以被认为是在共享数据库中集成的几种不同的"服务".
这是世界的"大系统"图片,通过使用500多个表数据库将企业的不同区域连接在一起,支持和鼓励这一点.
与此对比世界的"小系统"图片,在我们的示例中,后端Web应用程序库存,订购,定价和CRM是完全独立的应用程序,具有自己的技术堆栈,他们自己的项目团队,他们自己的发布计划,以及他们自己的数据库.
每个应用程序或服务都将对给定实体的内容有自己的理解,并根据其支持的业务能力来适应该实体的定义.
一个例子是"用户".CRM对用户的定义与订购或履行有着截然不同的定义.订购仅关注用户购买的用户.CRM关注其他内容,例如客户购买模式,以及关于名称,地址等的履行关注.使用共享数据库中的单个User表不容易实现.
这张图片对我来说比共享数据库路由更可取,主要原因是生成的系统将更好地模拟它应该支持的实际业务流程.DDD的主要原则之一是系统应该尽可能地拥有拥有它的企业.
在典型的业务中,这些各种功能不是由一个大型业务团队实现的,而是由小团队实现,通常彼此完全分离,他们之间通过发送请求和指令进行通信,或者让另一个团队知道某些过程或任务已经开始/完成等.
好的,但是没有共享数据库,网站现在依赖于来自所有这些不同服务的数据.它仍然需要在同一屏幕上一起显示这些东西.网站"演示"层如何组合所有这些并将其呈现给UI？
更重要的是,如果CRM想知道客户何时订购了什么呢？如果订购想知道产品价格何时发生变化,或者产品库存缺货,该怎么办？如果这些服务完全分开,那么他们如何交换数据呢？
首先解决UI问题,这可以通过复合UI完成.这方面有很多技巧,但足以说它是一个相对知名的景观,而不是我们的重点.
这些服务如何通信的第二个问题是,它们交换消息.什么样的消息？活动.事件由一个系统发布,以便由对该事件感兴趣的任何其他系统使用.
在我们的电子商务示例中,各种事件可能是:
这些事件具有商业意义.这意味着我们可以通过小型系统方法获得额外的好处,即集成介质本身具有商业意义,并且可以用业务语言表达,这非常适合Scrum和敏捷方法.
所以我认为从技术角度来看,数据库与消息集成方法之间存在很大差异.但我确实认为它们背后的驱动力存在巨大差异,而在我看来,采用更多小系统思维模式的逻辑结果总体上提供了更好的商业价值.
希望这有帮助,而不是太漫无边际.
小智 6
我正在使这个案例在工作中发挥作用。我相信有非常明确的理由使用其中一个（以及一些尚未提出的观点）。
数据库集成
优点
缺点
不能很好地扩展。您最终会得到一个运行各种工作负载（例如事务和报告）的单个数据库，或者您最终会使用数据库复制来分配生产负载。
广域分布是困难的。多站点架构更是如此。
消息系统
优点
缺点
| 归档时间： |
|
| 查看次数： |
8626 次 |
| 最近记录： |