由于许可和单一系统的特性，数据库和内部企业系统的扩展成本会很高。因此，我们希望它们能专注于执行特定的任务。就数据库而言，我们希望它们能够专注于事务而不是产品智能。就后台办公系统(商业智能)而言，我们不希望产品与系统的扩展能力联系在一起。对于业务系统的数据，采用异步传输模式。
我们常常告诉客户，要避免在关系数据库中使用存储过程。他们的第一反应通常是:“你们为什么这么讨厌存储过程呢?”其实我们并不讨厌存储过程，我们在很多情况下也在用它们。但问题在于，存储过程经常在解决方案中被过度使用，而这种过度使用有时会造成系统中的扩展瓶。既然这个原则强调的是数据库方面的问题，那为什么不把这个原则放在数据库那章中呢?事实上我们关注存储过程的真正原因是，我们主张把商业智能和产品智能与事务处理区分开来。一般说来，这个主张可以进一步概括为“把相似的事务放在一起(或者说把不同的事务分开)以获取最大的可用性和可扩展性以及最低的成本”。这样的表述可能不太好理解，因此让我们仍以存储过程和数据库为例，说明为什么需要这种区分。
在你的架构中、数据库可能是最贵的系统或服务之一。即使采用的是开源数据库，这些系统所在的服务器也可能会连接到成本相对较高的存储解决方案(相对于你其他的解决方案而言)，它们具有最快、最大数量的处理器以及最大数量的内存。在成熟的环境中中，这些系统通常都被用于做一件事情、即执行关系操作，并把事务尽可能快地提交给稳定的存储引。这些系统上的每个计算周期的成本都比架构中的其他解决方案或服务(如应用服务器或web服务器)要高。这些系统是某些服务的汇集点、也是泳道的定义点。在极端情况下，如在架构的初期，这些系统所占的比例可能更为巨大的，那么它们显然是影响整个环境的扩展的决定性因素。
出于以上这些原因，把这种昂贵的计算资源用于业务逻辑几乎是毫无意义的。这时每个事务所花的成本会增加，因为处理这些事务的系统的操作成本更为昂贵了。同日时这个系统本身也可能是影响我们扩展的决定性因素，那么为什么我们还要浪费生产力在它上面运行与事务处理不相关的操作呢?因此，我们应该让这些系统只处理与数据库(或相关的存储或 NOSQL)相关的事务，以便让它们做自己最擅长的事情。这样我们不仅提高了可扩展性，还能减少扩展成本。
在数据库这个例子中，我们把不相似的服各区分开可以应用到架构中的其他环节。我们很可能会有后台办公系统，诸如发送和接收电子邮件(与平台无关)的系统、做总账和其他会计事务的系统、市场细分的系统，以及支持客户户的运维系统，等等。我们很可能会把这些系统一股脑地放到我们的平台上。我们可能希望电子商务系统中的一笔交易能立刻显示在我们CFO的ERP系统中，或者我们想让客户支持代表能立刻看到它，以免这笔交易出问题。同样地，如果我们运行的是一个广告平台，那么我们可能想实时分析数据仓库中的数据，以便给出更好的广告建议。有很多原因促使我们想把业务流程与产品平台中的系统混在一起。但是，我们的建议很简单:不要这样做。
理想的情况是，让这些系统都能根据自己的需要独立地进行扩展。如果把这些系统绑定在一起，那么当一个系统需要扩展时，所有系统都要同时扩展。在某些情况下，如用数据库执行业务逻辑，系统的扩展成本会更高。许可证是与CPU相关联的ERP系统就经常会发生这种情况。如果每个事务都同步调用ERP系统，那么扩展成本一定会提高。此外，把系统以串联方式加入平台，也会降低产品的可用性，那么为什么我们还要如此做呢?
就像不应该把产品智能放在数据库中一样，商业智能也不应该绑定到产品事务上。在许多情况下，我们需要让数据驻留在我们的产品中而且此时我们最好让数据驻留在产品中。我们可以从其他系统中选择数据集，在产品中正确地表示出来。通常，最好用一种新的或不同的方式表示这些数据，有时是采用不同的范式。我们经常需要把数据从产品移到后台的业务系统中，如客户支持系统、市场营销系统、数据仓库和ERP系统。在这些情况下，我们也希望能够用不同的方式总结或表示数据。此外，为了提高可用性，我们希望以异步方式在系统间传输这些数据。为此可以采用ETL(提取、转换、加载)系统，甚至还有很多开源工具可以帮助你构建自己的ETL过程。
记住，网站制作模式并不意味着是“旧”数据。没有理由选择过期的数据元素在系统间进行传输。此外，还可以把数据发布到某种消息总线上，以供其他系统使用。成本最低的解决方案是批提取，不过如果时间有限不允许采用这种方法，那么消息总线绝对是个好选择。
本文地址：//www.gogoparty.cc//article/3525.html
