Architecture 将单一服务拆分为多个服务

我有一个实时（10毫秒的延迟）单片服务，它在一次执行中完成多项任务。由于单片体系结构，特别是扩展团队和维护复杂的代码库，我面临着很多问题。我已经确定了3种不同的功能服务，并计划将单一服务拆分为3种不同的服务。但所有这些服务都依赖于相同的数据

由于目前只有1次代码执行，我们只需要在调用中点击DB（目前是它的Redis）一次。拆分后有两个选项

从所有3个调用中点击DB，但这将增加最终服务输出的延迟，并增加硬件成本

只从第一个服务点击DB并将数据传递到第二个和第三个服务这里的问题是大量数据需要传递到不同的服务，使服务更加依赖于第一个服务

---

请分享您的经验，了解哪种方法更好，或者是否有更好的解决方案。

我认为没有什么灵丹妙药，但我建议您在切割一块巨石时要考虑一些事情

首先，要小心“将巨石分割成微服务”。巨石和微服务是两种不同的野兽，每一种都需要自己的方法。微服务可以帮助您扩大团队规模并降低维护成本。但我们也要记住，monolith体系结构使您不必考虑模块之间的延迟或在模块之间发送的对象的大小。架构的变化需要伴随着使用模式的变化，例如：

• 使用消息而不是直接调用，使用更少的同步操作，更多的并行异步任务。查看您的数据流
• 配料，配料，配料。如果您一次处理一个条目，跨服务延迟将杀死您的应用程序
• 甚至更少的耦合。在一个整体中，工程师往往会留下比需要更多的耦合，这意味着服务之间的调用会更多（更昂贵）。这些服务真的需要相互了解吗
• 最终的一致性。在一个整体中，工程师倾向于保持所有数据和对象状态的一致性。一旦你们进入了微服务的世界，一致性几乎是不可能的——总会有一点延迟。为一致性而繁荣与性能不匹配。但是如果你把延迟作为一个核心原则呢？服务之间的依赖性可能会突然减少很多。以下是对最终一致性含义的简单解释-
• 缓存。这里没有太多要添加的内容-使用缓存：）

另一个陷阱是“逻辑分裂”。业务逻辑通常提供了一种很好且易于理解的分割代码的方法。但这并不总是最好的延迟。因此，我建议在决定确切的切割线之前，仔细考虑您的数据流。您对数据流的最低要求是什么？尝试绘制某种依赖关系图，并在进行实际拆分之前将其最小化。就个人而言，我更喜欢一种迭代方法，首先花几个月（取决于项目大小）准备代码——删除依赖项并在可能的微服务中重新组织代码。大约每月审查一次拆分。如果3-4个月后裂口看起来仍然很好，他们可能会认为你做对了（足够了）

可能还有一些事情需要考虑，但我想你明白我的意思了——确保你有正确的架构和适当的模式。但您可能仍然会遇到最初的问题（在服务之间传递数据与多次获取数据）。如果是这样，我仍然不认为有一个通用的答案，因为有太多的变量：

• 您是否只关心性能，还是同时关心（基础设施）成本
• 你需要一致性吗？传递数据可能会导致过时数据（例如，在其他服务处理数据之前更新数据）
• 所有服务都需要所有数据吗？或者每个服务都需要一小块（不同的）数据，以便更快地获取数据
• 有一个只读的DB副本可用吗
• 你付交通费吗？流量是否受到限制（例如，如果发送大量数据，流量是否会变慢）

---

尽管如此，直接从每个服务中的源获取数据（从DB或调用服务来提供数据）的设计似乎更简单。简单的设计可能会带来更低的维护成本：）

很久以前，除了编写“最快的代码”的所有代码技巧和最佳实践之外，人们可以给出的最佳建议是，您应该在特定的案例/应用程序中进行基准测试。我认为这仍然是今天最好的建议。TinstaTFC：在你的例子中，没有“最快的代码”这样的东西，这是关于可靠性的，但同样的事情。我会同时实现和基准测试（并保持基准测试框架不变，以便在情况发生变化时可以多次重新测试）