将单体服务拆分为多个服务答案

【问题标题】：Splitting monolithic service to multiple services将单体服务拆分为多个服务
【发布时间】：2021-02-26 01:14:34
【问题描述】：

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

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

从所有 3 次调用中命中 DB，但这会增加最终服务输出的延迟并增加硬件成本。
仅从第一个服务访问数据库并将该数据传递给第二个和第三个服务这里的问题是大量数据需要传递给不同的服务，这使得服务更加依赖第一个服务。

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

【问题讨论】：

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

标签： architecture microservices real-time soa software-design

【解决方案1】：

我不认为有灵丹妙药，但我建议在切割单体时要考虑一些事情。

首先，谨防“单体应用拆分为微服务”。单体和微服务是两种不同的野兽，每一种都需要自己的方法。微服务可以帮助您扩展团队并降低维护成本。但我们还要记住，单体架构使您无需考虑模块之间的延迟或在它们之间发送的对象的大小。架构的变化需要伴随着使用模式的变化，例如：

使用消息而不是直接调用，使用更少的同步操作，更多的并行异步任务。查看您的数据流。
批处理，批处理，批处理。如果您一次处理一个条目，跨服务延迟将导致您的应用程序崩溃。
甚至更少的耦合。在单体应用中，工程师倾向于留下比需要更多的耦合，这意味着服务之间的调用更多（昂贵）。这些服务真的需要相互了解吗？
最终一致性。在单体架构中，工程师倾向于使所有数据和对象状态保持一致。一旦你进入微服务世界，一致性几乎是不可能的——总会有一点延迟。追求一致性并不适合性能。但是如果你把延迟作为一个核心原则呢？您可能会突然减少服务之间的依赖关系。这是对最终一致性意味着什么的简单解释 - Eventual consistency in plain English
缓存。此处无需添加太多内容 - 使用缓存 :)

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

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

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

话虽如此，在每个服务中直接从源获取数据似乎更简单——从数据库或调用服务来提供数据。更简单的设计可能会以更低的维护成本得到回报：)

【讨论】：