2

我目前正在为大约 90 KLOC 的保险经纪人开发一个数据库繁重的业务线 Rails 应用程序——其中大部分是通过业务交易进行数据操作，以及汇总所有数据的多个报告。

我们是一个非常小的团队，代码库的大小和复杂性开始超出我们管理它的能力。正因为如此，我们正在研究驯服它的方法，其中之一是将其转换为面向服务的架构——即将其拆分为几个较小的应用程序。

这种方法的问题在于报告方面：我们的报告通常涉及最多 7 个连接的表，过滤器在此过程中作用于多个表。如果我们放弃服务共享表的可能性（多篇文章都指出这是一种反模式），是否有可能以一种不会对性能造成太大影响的方式连接所有这些数据？

那么，SOA 是针对这类问题推荐的方法吗？还是它带来的问题多于解决的问题？

虽然我们的专长主要在于 Ruby（Rails 和 Sinatra）和 Python（Plone 和 Grok），但我也想知道其他技术（.NET、Java）周围的社区通常如何处理这个问题。

提前致谢！

4

3 回答 3

1

我来自数据仓库背景，对 ruby​​/rails 保持一些兴趣。阅读您的帖子，我感觉您的报告架构可能需要重新设计，并且需要脱离基础系统。

通过重新设计该部分，您的原始系统可能不会那么大/复杂。

简而言之，一个经过 7 级联接的报告要求让我感到“尴尬”，看起来您正在尝试使用您的事务系统进行报告？

我建议您使用预先计算的聚合转移到不同的模式/数据库（当然，杠杆将取决于您的业务案例）。这应该有助于降低基础系统的复杂性，并允许您更快和相对简单的报告环境。您可能会产生一些存储成本（对于 aggs env 的单独数据库/模式），但这应该是为了简单/设计而付出的小代价。

hth

于 2012-10-07T21:15:04.000 回答
1

SOA 确实会帮助您保持受人尊敬的服务的代码库更小并更好地分离。它还将简化您的操作数据库，因为每个服务的数据库将分开。当然，不利的一面是它不适用于报告。

另一方面，正如 learn4living 所指出的，无论如何，您最好使用单独的模式进行报告，因为操作数据库不方便报告，并且非规范化数据更易于使用。

我把这种聚合报告的模式称为这种模式，你可以阅读我几年前写的一篇关于弥合 BI 和 SOA 之间差距的文章

于 2012-10-08T07:52:34.713 回答
1

SOA、批处理和缓存的结合将在很大程度上解决您的问题。您需要确定哪些流程

  1. 应该用于高可用性（Webservices/Messaging）
  2. 您的用户能否负担得起等待结果（批处理）
  3. 可以容忍陈旧数据的显示/消耗（缓存）

为了长期利益，投资一些非规范化可能也是值得的。

于 2012-10-08T13:42:33.327 回答