2

精简版：

我们有多个团队，每个团队都在开发多个应用程序。他们需要分享一些数据。我们应该将这些应用程序组合成一个更大的应用程序以简化数据集成，还是应该将它们分开并利用一些数据交换/缓存机制？

更长的版本：

我们有许多团队，每个团队都在处理一组应用程序。其中许多应用程序需要共享数据。一种选择是使用异步消息传递来拥有一个记录系统 - 所有写入都在其中发生 - 并将该数据广播到需要它的任何其他系统。这些系统会将他们需要的数据位存储在只读缓存中（在他们的数据库中）。

这种布局的好处是一个系统可以在不影响其他系统的情况下崩溃。它还使各个团队更容易处理各自的应用程序。它使发布计划更容易，更小的代码库导航等。

另一种选择是确定这些应用程序共享太多数据，并且消息/缓存的开销太高。在这种情况下，您可以决定将这三个应用程序合并为一个更大的应用程序。然后，您将完全消除数据集成问题，因为您将集成移动到应用程序的单个模块的服务/事务层。换句话说，MyGiantApp 仍然可以拆分（罐子、应用程序上下文等）成各种模块，这些模块通过另一个模块的事务服务 API 相互通信。在我们的例子中，我们几乎像使用服务总线一样使用 Spring，使用方法调用而不是 Web 服务或异步消息传递。

虽然第二个选项简化了数据集成，但它使开发复杂化。现在 X 团队必须在相同的代码库上工作。这可以通过使用分支、持续集成和单独的库/上下文等来缓解，但归根结底，它仍然是我们都在构建的一个可悲的工件。此外，现在一个团队的错误可以更容易地传播到整个应用程序；一个应用程序炸毁堆可能会全部关闭。

您将如何决定何时使用解决方案 #1 以及何时使用解决方案 #2？

4

3 回答 3

1

我把它放在一个单独的答案中，因为它的重点与我的第一个完全不同。

听起来您已经深思熟虑，并且很好地掌握了您的问题和解决方案。让我再次破解（我认为是）你的关键问题......

你会怎么决定...

回到基础：从你所知道的真实开始。
与您团队中的相关人员一起举办白板研讨会，在其中您需要：

  • 制定相关约束的列表。
  • 列出您不想要的结果（单个无法管理的大型应用程序等）。
  • 也建议但可能不是必需的：识别风险和潜在影响（作为限制或不良结果的一部分）。
  • 列出您想要的结果（共享数据、轻松部署等）。
  • 优先考虑理想和不理想的结果（非常重要），如果它们在辩论过程中发生变化，不要感到惊讶。

这些信息应该足以开始建立讨论和决策框架。

在本次研讨会之前，您还可以做一些额外的事情（或作为其中的一部分，取决于您所处情况的政治和社会动态）。

  • 确定系统的目标——无论是在“商业”意义上还是“架构”意义上。（提示：两者应该对齐 - 或至少不冲突）。
  • 如果对系统或您的业务有一个明确定义的愿景，这应该会有所帮助（但请记住，这些愿景并不总是存在，好的愿景更罕见）。
  • 请参阅您正在使用的系统的业务/战略计划 - 并考虑市场、趋势等。您认为未来的应用程序可能会发生什么？架构上的超前思考与代码级别的 YAGNI 不同，仔细考虑未来可能会影响你现在做出的决定。
于 2010-10-06T20:40:36.553 回答
1

嗨-不确定我是否涵盖了您想要回答的确切要点-但这是一个开始；如果您愿意，请要求澄清，我会相应地更新我的答案。

在数据管理方面，您可能希望开始考虑主数据管理线。跳到脑海的第一个想法是您不想要不一致的Reference Data；这将建议您使用数据的单个共享实例 - 或者，假设围绕该数据的管理和保管过程非常清晰，您可以拥有多个副本。

在集成方面，重用取决于各种系统的非功能需求。单个共享服务可以轻松管理数据（因为只需担心一个副本），但这意味着它可能会成为瓶颈；此外，“链中最薄弱的环节”规则适用——如果共享服务出现故障，会有什么影响？

可能的解决方案选项

如果没有更多信息，很难知道要推荐什么，但我的想法是：

  • 将您的三个应用程序分开。
  • 对共享数据使用单一共享服务。
  • 可以通过“服务”访问共享数据——这将为您提供最多的控制和选择。
  • 共享服务可能作为单个实例存在 - 或者 - 您可能部署了服务的多个实例（但只有一个数据库实例）。

关键是你应该能够在不影响其他应用程序的情况下抽象出共享服务——特别是，你不应该考虑制作一个超级应用程序。

还有一件事——从商业意义上考虑存在一种“服务”并不排除有多种技术公开和使用它的方式。

于 2010-10-05T21:59:50.200 回答
0

您是否考虑过并发、事务、...

我不知道您的要求，但感觉是时候以正确的方式解决这个问题并使用中央“存储库”来管理您的共享数据了。

于 2010-10-04T14:29:43.330 回答