共享数据库与消息传递架构 [英] Shared Database vs. Messaging Architecture

问题描述

昨天我和我的一个朋友在酒吧里，我们开始讨论他工作的公司正在使用的架构.谈话基本上围绕着共享数据库架构与分布式独立应用程序架构的优缺点 - 我们无法达成共识，在这种情况下，我想听听人们对这两种方法的优缺点的看法.

基本上，他工作的公司拥有包含许多不同应用程序的大型架构.某些应用程序具有它们之间共享的单个数据库.例如，有 1 个应用程序为用户提供 UI 以更改参考数据.此参考数据由另一个也访问相同数据的应用程序使用.我相信代码实际上是作为共享库编写的(即两个应用程序都将使用为每个应用程序重新部署的公共代码集(一个将其作为依赖项)).

还有其他应用程序的数据库也被其他应用程序通过带有数据访问代码的直接 JDBC 连接使用(这两个应用程序之间不常见 - 重复！！呃！).

我的问题是围绕这种架构与每个应用程序都在孤岛中包含它的主"数据的架构的优缺点.如果应用程序 x 需要来自应用程序 y 的数据，则它们会使用网络服务或某些消息传递技术来接收该数据.

消息传递方法会引入一个问题，即现在必须从其他来源获取在其他应用程序的数据库中使用的参考数据代码"(或外键).在当前架构中，这些的解码"可以随时更改并立即反映在外部应用程序中，而不必在复制数据的地方具有主/从关系 - 或者应用程序 x 必须查询应用程序 y 的替代方案只是为了显示解码值.

我读过企业集成模式，虽然它确实提供了一些消息传递优势的例子 - 我不太相信.

谢谢伊恩

解决方案

的优势共享数据库上的基于消息的集成很难说清楚，但会在这里尝试:

不可避免的争论是，DBA 想要对实体之间的所有关系进行建模，以便数据100% 一致 始终.另一方面，您让开发人员警告 DBA 关于紧耦合源自单体架构，以及无法轻松更改绑定到主表的应用程序.

我认为这两个论点都触及皮毛，无论您如何进行集成，构建一个易于更改的系统都具有挑战性.我想对 SOA 和基于消息的集成提出另一种论点.

归结起来是这样的:

1. 共享数据库集成通常由大系统"世界观驱动.
2. 基于消息的集成通常由小系统"世界观驱动.

您有多少次遇到过拥有数百个用户的大型系统，这些系统执行许多不同的工作，支持多种不同的业务功能?我总是遇到他们.目前看来，它们是企业软件的主要内容.

所有这些系统似乎都有一个共同点，那就是更改它们的成本非常高.原因之一是，正如 Joe R 在 他的回答 中所说的，紧耦合.

然而，耦合是一个很重要的术语，我认为我们需要考虑两种截然不同的耦合类型.

第一个可以被认为是技术耦合，这意味着技术堆栈内部的垂直耦合，通常是 n 层，在一层和另一层之间.

所以我们有应用程序的数据库和数据访问层之间的耦合，数据访问层和业务逻辑层之间的耦合等等.认为这种耦合是好是坏似乎是普遍接受的，但我们应该理性思考不期望，甚至不欢迎，比如 User DTO、UserRepository 类和 User 数据库表之间的高度耦合?

让我们考虑一下耦合在实现级别的实际含义.当属于"一件事的概念泄漏到另一件事时，就会发生耦合.当您有多个层基本上彼此谈论同一个业务实体时，这种泄漏是不可避免的.

第二种耦合，也是我想解决的耦合，可以被认为是业务能力耦合，也称为水平耦合.这就是我们将属于一种业务能力的概念泄漏到另一种业务能力的地方.

我断言这种水平耦合是通过使用数据库作为集成平台而得到鼓励的.

举个例子，想象一个支持电子商务网站系统的典型后端系统.您通常会将库存、订购、定价和 CRM 作为您的核心功能.

如果我们在单个数据库中对这个域进行建模，我们实际上是将不同的功能耦合在一起.每个外键约束都可能增加这些功能之间的耦合程度.事实上，此时的系统已经可以被认为是跨共享数据库集成的几个不同的服务".

这是世界的大系统"图景，它通过使用 500 多个表数据库将企业的不同领域链接在一起而得到支持和鼓励.

将此与世界的小系统"图进行对比，在我们的示例中，后端 Web 应用程序库存、订购、定价和 CRM 是完全独立的应用程序，具有自己的技术堆栈、自己的项目团队、自己的发布时间表和自己的数据库.

每个应用程序或服务，对给定的实体是什么都有自己的理解，这将根据它支持的业务能力适合该实体的定义.

用户"就是一个例子.CRM 将对用户的定义与订购或履行的定义截然不同.订购只在用户购买什么方面关心用户.CRM 关心其他内容，例如客户购买模式，而履行则关心姓名、地址等.使用共享数据库中的单个用户表并不容易实现这一点.

这张图片对我来说比共享数据库路线更可取，主要原因是生成的系统将更好地模拟它应该支持的实际业务流程.DDD 的主要原则之一是系统应尽可能类似于拥有它的企业.

在典型的企业中，这些不同的功能不是在跨企业的大型团队的各个层级实现的，而是由小型垂直团队实现的，这些团队通常是完全自主的，他们之间以及与其他垂直团队经常通过发送请求进行通信，指令，或者让其他团队知道某个流程或任务已经开始/完成等.

好的，但是没有共享数据库，网站现在依赖于来自所有这些不同服务的数据来制作它的用户界面.它仍然需要在同一个屏幕上一起显示这些东西.网站表示"层如何组合所有这些并将其呈现给用户界面?

更重要的是，如果 CRM 想知道客户何时订购某样东西怎么办?如果下单想知道产品价格何时发生变化，或者库存中产品何时缺货怎么办?如果这些服务是完全独立的，那么它们如何交换数据?

首先解决 UI 问题，这可以通过 复合 UI.有很多技术可以做到这一点，但可以说这是一个相对知名的景观，并不是我们真正关注的焦点.

关于这些服务如何通信的第二个问题是，它们交换消息.什么样的消息?事件.事件由一个系统发布，以便它们被对该事件感兴趣的任何其他系统使用.

在我们的电子商务示例中，事件类型可以是:

1. 已下订单
2. CustomerUpgradedToGold
3. 产品折扣
4. 库存耗尽

这些事件具有商业意义.这意味着我们可以通过小型系统方法获得额外的好处，即集成媒介本身具有业务意义，并且可以用业务语言表达，这非常适合 Scrum 和敏捷方法论.

因此，为了最终回答 OP 的问题，我认为从技术角度来看，共享数据库与消息传递集成方法之间没有太大区别.这两种方法都需要相同类型的抽象和语义.但我确实认为它们背后的驱动力存在巨大差异，采用更多小型系统思维方式的结果提供了更好的整体业务价值.

I was down the pub with a friend of mine yesterday and we started discussing the architecture in use at the company he works at. The conversation basically surrounded the pros/cons of a shared database architecture against a distributed independent application architecture - we couldn't get to a consensus in which case I'd like to hear people's opinions on the pros/cons of both approaches.

Basically, the company that he works for has a large architecture with many different applications. Some applications have a single database that they share between them. For example, there is 1 application which provides a UI for users to alter reference data. This reference data is used by another application which also accesses the same data. I believe the code is actually written as shared libraries (i.e. both applications will use a common code set that is redeployed for each (one has it as a dependency)).

There are also other applications with a database that is also used by other applications by direct JDBC connection with data access code (not common between the two apps - duplicated!! erghh!).

My question is around the pros/cons of this architecture vs. an architecture where each application contains it's "master" data in silo. If an application x requires data from application y they use web services or some messaging technology to receive that data.

The messaging approach would introduce a problem whereby reference data 'codes' (or foreign keys) which are used within the db's of other applications currently now have to be fetched from another source. In the current architecture the 'decodes' for these can change at any time and be reflected in the external application immediately, rather than having to have a master/slave relationship where data is copied - or an alternative where application x has to query application y just to display the decode values.

I had read Enterprise Integration Patterns and whilst it does give some examples of the advantages of messaging - i'm not so convinced.

Thanks Iain

解决方案

The advantages of message-based integration over a shared database are difficult to articulate, but will here be attempted:

There is the inevitable argument where the DBAs want to model all the relationships between the entities so that the data is 100% consistent at all times. On the other hand, you have the developers warning the DBAs about tight-coupling that emerges from monolithic architecture and how applications bound to master tables cannot be changed easily.

I think both of these arguments are kind of scratching the surface and building a system which is easy to change is challenging, regardless of how you do the integration. I want to put forward another kind of argument for SOA and message-based integration.

What it comes down to is this:

1. Shared database integration is generally driven by a "big system" view of the world.
2. Message-based integration is generally driven by a "small system" view of the world.

How many times have you come across large systems with hundreds of users which do many, many different jobs supporting multiple and diverse business functions? I come across them all the time. They are the staple of enterprise software at the moment it seems.

One thing all these systems seem to have in common is that they are very expensive to change. And one of the reasons for this is, as Joe R says in his answer, tight coupling.

However, coupling is something of a loaded term and I think there are two very different types of coupling we need to consider.

The first can be thought of as technological coupling and this means vertical coupling inside the technology stack, usually n-tiered, between one tier and another tier.

So we have coupling between the database and data access layer of an application, coupling between the data access layer and business logic layer, etc. To regard such coupling as bad or wrong seems to be generally accepted, but thinking rationally should we not expect, or even welcome, a high degree of coupling between, say, the User DTO, the UserRepository class, and the User database table?

Let's consider what coupling actually means at the implementation level. Coupling happens when concepts which "belong" to one thing leak into another thing. This leakage is inevitable when you have multiple layers basically talking to each other about the same business entity.

The second kind of coupling, and the one I'd like to address, can be thought of as business capability coupling, also known as horizontal coupling. This is where we have concepts belonging to one business capability leaking into another business capability.

It is my assertion that this horizontal coupling is encouraged by the use of databases as an integration platform.

As an example, imagine a typical back-end system supporting an e-commerce website system. You would generally have inventory, ordering, pricing, and CRM as your core capabilities.

If we model this domain inside a single database, we are in effect coupling different capabilities together. Every foreign key constraint potentially increases the degree of coupling between these capabilities. In fact, the system by this point can already be thought of as several different "services" integrated across a shared database.

This is the "big system" picture of the world, which is supported and encouraged by linking different areas of your enterprise together using huge 500+ table databases.

Contrast this with the "small system" picture of the world, where in our example back-end web application inventory, ordering, pricing, and CRM are completely separate applications, with their own technology stacks, their own project teams, their own release schedules, and their own databases.

Each application, or service, will have its own understanding of what a given entity is, and that will fit the definition of that entity according to the business capability it is supporting.

An example of this is the "User". CRM are going to have a very different definition of User than ordering or fulfilment. Ordering only cares about the user in terms of what the user is buying. CRM cares about other stuff like customer buying patterns, and fulfilment cares about name, address, etc. This is not easily achieved with a single User table in a shared database.

This picture to me is preferable to the shared database route and the main reason is that the resulting system will better model the actual business processes it is supposed to be supporting. One of the main tenets of DDD is that a system should resemble as much as possible the business who owns it.

In a typical business, these various capabilities are not implemented across the layers of big, enterprise-spanning teams, but instead by small vertical teams, often completely autonomous, who communicate among themselves and with other vertical teams often by sending requests, directives, or by letting other teams know that a certain process or task has been started/completed etc.

OK, but without the shared database, the website now relies on data from all of these different services for it's UI. It still needs to display this stuff together on the same screen. How can the website "presentation" layer assemble all this and render it to the UI?

More importantly, what if CRM wants to know when a customer orders something? What if ordering wants to know when the prices of products change, or when products are out of stock in the inventory? If these services are completely separate then how can they exchange data?

Addressing the UI question first, this can be done with composite UIs. There are many techniques for this, but suffice to say it's a relatively well-known landscape and not really our focus here.

The second question of how do these services communicate is, well, they exchange messages. What kind of messages? Events. Events are published by one system in order that they are consumed by any other system which is interested in that event.

In our e-commerce example, kinds of events could be:

1. OrderPlaced
2. CustomerUpgradedToGold
3. ProductDiscounted
4. StockExhausted

These events have business meaning. That means we can get an additional benefit with the small system approach which is that the integration medium itself has business meaning, and can be expressed in business language, which lends itself well to scrum and agile methodologies.

So, to finally answer the OP's question, I don't think that from a technological perspective there is much difference between Shared Database vs Messaging integration approaches. Both approaches require the same kind of abstractions and semantics. But I do think there is a huge difference in the driving forces behind them, and the outcomes of adopting more of a small systems mindset provide better business value overall.

这篇关于共享数据库与消息传递架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！