随着科技公司认识到单片架构的局限性，向微服务的转变在 2010 年代初开始获得发展势头。然而，亚马逊 (Prime Video)、Invision、Istio 和 Segment等许多公司正在回归单片架构。本文将探讨许多组织在过渡到微服务架构时失败的原因。
什么是整体式架构？
单片架构很简单：用户请求数据，所有业务逻辑和数据都位于单个服务中。然而，单片系统面临着诸多挑战，例如可扩展性有限、部署更新困难以及容易出现单点故障。
构建 Agentic AI 的基础设施
为了解决这一问题，许多组织尝试过渡到基于微服务的架构，以利用抽象和封装、更快的部署、更容易的维护以及每个服务与团队所有权更紧密结合等优势。
为何采用微服务？
在理想的微服务架构中，每个业务领域都作为独立的服务运行，并拥有自己的数据库。这种设置具有更好的可扩展性、灵活性和弹性等优势。请考虑下图。
现实
然而，最近的趋势表明，许多公司正在远离这种模式，并坚持使用单片架构。这是因为在现实世界中很难实现这种程度的和谐。现实往往如下图所示。
众所周知，迁移到微服务架构会导致服务之间复杂的交互、循环调用、数据完整性问题，而且说实话，几乎不可能完全摆脱单体架构。让我们讨论一下为什么迁移到微服务架构后会出现这些问题。
域边界不正确
在理想情况下，单个服务应封装一个或多个完整的业务域，以便每个域在服务内独立存在。域不应分散到多个服务中，因为这会导致服务之间相互依赖。下图显示了单个服务如何包含一个或多个完整的域以保持清晰的边界。
在复杂的现实系统中，定义领域边界可能具有挑战性，尤其是当数据传统上以特定方式概念化时。下图显示了当边界未提前定义或工程师在不考虑领域边界的情况下添加新服务时，现实系统在微服务架构中通常的样子。
如果域定义不明确，对其他服务的依赖就会增加，从而导致多个问题：
- 循环依赖或过度调用：当服务相互依赖时，它们需要频繁的数据交换。
- 数据完整性问题：跨服务的单个域分裂导致深度耦合的数据分裂到多个服务。
- 团队所有权不模糊：多个团队可能需要在重叠的领域进行协作，从而导致效率低下和混乱。
数据和功能深度耦合
在单片架构中，客户端通常会跳过指定的接口并直接访问数据库，因为在单一代码库中实施封装很困难。这可能会导致开发人员走捷径，尤其是在接口不明确或看起来很复杂的情况下。随着时间的推移，这会创建一个与特定数据库表和业务逻辑紧密相连的客户端网络。
在迁移到微服务架构时，每个客户端都需要更新才能使用新的服务 API。但是，由于客户端与单体式架构的业务逻辑紧密相关，因此需要在迁移过程中重构其逻辑。
在不破坏现有功能的情况下解开这些依赖关系需要时间。由于工作复杂，一些客户端更新经常被延迟，导致一些客户端在迁移后仍在使用整体式数据库。为了避免这种情况，工程师可能会在新服务中创建新的数据模型，但将现有模型保留在整体式数据库中。当模型深度链接时，这会导致数据和功能在服务之间分裂，从而导致多次服务间调用和数据完整性问题。
数据迁移
数据迁移是迁移到微服务过程中最复杂、风险最高的要素之一。准确、完整地将所有相关数据传输到新的微服务至关重要。由于复杂性，许多迁移在此阶段停止，但成功的数据迁移是实现微服务优势的关键。常见挑战包括：
- 数据完整性和一致性：迁移期间的错误可能导致数据丢失或不一致。
- 数据量：传输大量数据会耗费大量资源并且耗费时间。
- 停机时间和业务连续性：数据迁移可能需要停机，这可能会中断业务运营。平稳过渡并将对用户的影响降至最低至关重要。
- 测试和验证：需要进行严格的测试以确保迁移的数据准确、完整且在新服务中表现良好。
结论
微服务架构可能看起来很有吸引力，但从单体架构过渡却充满挑战。许多公司发现自己陷入了中间状态，这增加了系统复杂性，导致数据完整性问题、循环依赖和团队所有权不明确。无法在现实世界中充分利用微服务的优势是许多公司回归单体架构的原因。
原创文章，作者：王 浩然，如若转载，请注明出处：https://www.dian8dian.com/wei-shen-me-wei-fu-wu-ke-neng-hui-sui-zhe-dan-ti-ying-yong
