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

问题描述

我是来与我的一个朋友昨天在酒吧，我们开始讨论在他的作品在该公司所使用的架构。谈话基本上围绕着利弊/对分布式独立的应用程序架构的共享数据库架构的缺点 - 我们无法得到在这种情况下，我想听听你对利弊的人的意见达成共识两种方法/缺点

基本上，他为公司工作有许多不同的应用的大型建筑。一些应用程序具有它们在它们之间共享单个的数据库。例如，有1应用程序，它提供了一个用户界面，为用户改变的参考数据。该参考数据由另一个应用程序，也可以访问相同的数据使用。我相信，code实际写入共享库（即这两个应用程序将使用重新部署对每个（人都有它作为一个依赖）共同code组）。

有还与一个数据库，也可用于通过与数据存取code直接JDBC连接的其他应用程序的其他应用程序（在两个应用程序之间的不常见 - 重复!! erghh！）

。

我的问题是解决这个架构与每个应用程序包含在筒仓它的主人的数据架构的优点/缺点。如果应用程序X要求从申请Y数据，他们使用Web服务或一些消息技术来接收数据。

该消息的做法会带来一个问题即它们的其他应用程序的数据库的使用范围内引用数据'codeS（或外键）目前现在必须从其他来源获取。在现有的结构的去codes对这些可以在任何时间改变，并立即在外部应用程序中反映，而不是具有在那里数据被复制的主/从关系 - 或替代，其中应用x具有查询申请Ÿ只显示德code值。

我读了企业集成模式，而虽然它确实给的消息的优点一些例子 - 我不那么信服

谢谢
伊恩

解决方案

消息的优点基于集成在一个<一个href=\"http://www.enterpriseintegrationpatterns.com/patterns/messaging/SharedDataBaseIntegration.html\"相对=nofollow>共享数据库在我看来是很难表达清楚。

有是必然的参数，其中所述的DBA要使得数据是在任何时候都100％一致。在另一方面，你必须警告有关紧密耦合从出现单片架构以及如何绑定到主表的应用程序不能轻易改变。

我觉得这两个论点一种表面文章，并建立一个系统，是很容易改变的是具有挑战性的，不管你怎么做整合。我想提出另一种说法为SOA和基于消息的集成。

什么它归结为是这样的：

1. 共享数据库的集成通常是从世界的一个大系统的观点推动。


2. 基于消息的集成通常是来自世界各地的小系统视图驱动。

有多少次你遇到大型系统与数百个做很多，很多不同的工作，支持多种多样的业务功能的用户呢？我碰到过他们所有的时间。他们是企业软件在它似乎此刻主食。

一件事，所有这些系统似乎有一个共同点，就是他们改变非常昂贵的。与这种情况的原因之一就是，乔中的R 他的回答，紧密耦合。

然而，有两种类型的耦合我们需要考虑。

首先是我喜欢叫的技术耦合的，这意味着技术堆栈，一般的n层内的垂直耦合，一层和另一层之间。

因此​​，我们有一个应用程序的数据库和数据访问层之间的耦合，数据访问层和业务逻辑层等。要对坏这种耦合之间的耦合，似乎该课程被比下去，而是理性思考的，难道我们不应该的期望的高度之间，也就是说，用户的业务对象的耦合，以及UserRepository持久性对象，用户数据库中的表？

让我们来考虑一下耦合实际上意味着在执行层面。当code这属于一件事泄漏到另一件事情发生的耦合。这种泄漏是不可避免的，当你有多个层基本上谈论同样的经营理念。

我想解决，哪些该种耦合通过使用数据库作为集成平台的鼓励，是的的业务能力耦合的。这是我们有code属于一个业务能力泄漏到另一个业务能力。

作为一个例子，假设一个典型的后端系统支持一个电​​子商务网站系统。您通常会有库存，订货，定价和客户关系管理为核心cabilities。

如果我们一个单一的数据库里面这个领域模型，我们实际上是连接不同的功能在一起。每一个外键约束可能增加这些功能之间的耦合度。事实上，系统由这点可以已经被认为是若干不同的服务集成在共享数据库的。

这就是世界的，这是支持并通过连接企业的不同区域使用起来500+庞大的数据库表鼓励的大系统的景象。

与世界的小系统的画面，凡在我们的例子中后端的Web应用程序的库存，订货，定价和客户关系管理是完全独立的应用程序，凭借自身的技术堆栈，自己的项目团队，对比度这个自己自己的发布时间表，和自己的数据库。

他们是独立的，以便可以释放更多或更少频繁取决于它们支持业务capbility的volitility。每个服务将具有它自己的给定实体是什么理解，这将根据业务能力是支持符合该实体的定义。

这方面的一个例子是用户。 CRM将有用户的一个非常不同的定义比订货。订购只关心什么，用户在购买方面的用户。 CRM在乎其他的东西，如姓名，地址等，这是不是与单个用户表中共享数据库轻松实现。

此画面对我来说是更prefereable到共享数据库路线，主要的原因是，所产生的系统将更好的模型实际业务处理它应该是支持的。一个 DDD 的主要原则是系统应该像尽可能业务谁拥有它。

在一个典型的业务这些不同的功能，不是由一个大的业务团队来实现，而是通过小团队，常常是完全相互独立的，谁经常通过发送请求和指令本身之间进行通信来实现，或者通过让其他球队知道某个流程或任务已开工/竣工等。

OK，但没有共享数据库，该网站现在依靠数据所有这些不同的服务，它的UI。它仍然需要在同一屏幕上同时显示这个东西。该网站presentation层如何组装了这一切，它呈现到用户界面？

此外，如果想要CRM时，知道客户订单的东西吗？如果订购想知道当一个产品的价格变化，或者产品缺货的库存？如果这些服务是完全分开的，然后他们怎么能交换数据？

首先解决UI问题，这可以用<一做href=\"https://www.google.co.uk/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=composite%20ui%20pattern\"相对=nofollow>复合用户界面。这有许多技术，但我只想说这是一个比较知名的景观，而不是真正我们的重点在这里。

中如何做这些服务进行通信的第二个问题是，好了，他们交换消息。什么样的信息？ 活动的。事件是由一个系统，以便公布，它们通过任何其他系统，这是感兴趣的是事件消耗。

在我们的电子商务为例，种类的事件可能是：

1. OrderPlacedByCustomer


2. CustomerStatusUpdatedFromSilverToGold


3. PriceOfProductChanged


4. ProductStockExhausted

这些事件有业务含义。这意味着我们可以得到与小系统的做法，是整合媒体本身具有商业含义一个额外的好处，并且可以在商业语言，这很适合Scrum和敏捷方法pssed前$ P $。

所以，我不认为从技术角度来看，是VS Messaging集成方法数据库太大的区别。但我认为在他们身后的驱动力的巨大差异，而在我看来，采取更小的系统整体思维提供了更好的商业价值的必然结果。

希望这有助于和是不是太散漫。

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 is in my opinion very difficult to articulate.

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 from a "big system" view of the world.
2. Message based integration is generally driven from 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, there are two types of coupling we need to consider.

The first is what I like to call 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 a application, coupling between the data-access layer and business logic layer, etc. To regarding such coupling as bad seems to be par for the course, but thinking rationally, should we not expect a high degree of coupling between, say, the User business object, and the UserRepository persistence object, and the User database table?

Let's consider what coupling actually means at the implementation level. Coupling happens when code which "belongs" to one thing leaks into another thing. This leakage is inevitable when you have multiple layers basically talking about the same business concept.

The kind of coupling I'd like to address, and which is encouraged by the use of databases as an integration platform, is business capability coupling. This is where we have code belonging to one business capability leaking into another business capability.

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

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.

They are separate so can be released more or less frequently depending on the volitility of the business capbility they are supporting. Each service will have it's 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. Ordering only cared about the user in terms of what the user is buying. CRM cares about other stuff like name, address, etc. This is not easily achieved with a single User table in a shared database.

This picture to me is more prefereable 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 by one big business team, but instead are implemented by small teams, often completely separate from each other, who communicate between themselves often by sending requests and directives, or by letting another team 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?

Additionally, what if CRM wants to know when a customer orders something? What if ordering want to know when the price of a product changes, or the product is 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 ecommerce example, kinds of events could be:

1. OrderPlacedByCustomer
2. CustomerStatusUpdatedFromSilverToGold
3. PriceOfProductChanged
4. ProductStockExhausted

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 I don't think that from a technological perspective there is much difference between Database vs Messaging integration approaches. But I do think there is a huge difference in the driving forces behind them, and to my mind, the logical outcome of adopting more of a small systems mindset provides better business value overall.

Hope this helps and is not too rambling.

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