为什么放弃了微服务？是哪些原因导致的？

微服务被认为是一种理想的架构模式，因此，Steven Lemon 所在公司的领导层决定从单体架构向微服务架构迁移，这让整个开发团队在随后的的日子里苦不堪言，七大现实问题摆在面前无法解决，微服务架构的好处也没有享受到，并发现这不单单是一个技术问题。最终，整个团队决定放弃。

领导决定：迁移微服务

最近，我所在的开发团队在紧张的交付周期结束后，有了短暂的休息机会。领导层认为可以利用这段时间将单体架构迁移至微服务。经过一个月的调研和准备之后，我们最终放弃迁移计划，继续使用原先的单体架构。在我们看来，微服务不仅不会帮到我们，反而会对开发流程造成严重影响。

微服务被认为是一种理想的架构模式，但并不适合我们。我们公司的情况是这样的：一共有 200 多名开发人员，不过我们团队只有 5 个人，大概有 5% 的后端开发工作涉及公司层面的单体系统，这是一个巨大的 C#应用程序。剩下的时间，我们开发了自己的两个 Node 服务。

我们团队负责的这两个服务都很小巧，完全可以控制开发、架构和部署整个流程。遇到性能问题时，我们会把生产环境中的实例数量增加一倍，直到把底层问题解决。我们几乎不与其他团队合作，因为这些服务是用 TypeScript 开发的，所以我们团队 (主要是前端开发人员) 能够在前端和后端使用相同的编程语言。最重要的是，我们可以在客户端及后端的验证和报告服务中包含复杂的规则计算引擎。总而言之，我们整个团队专注于特定业务。

首先需要声明：我们不喜欢开发单体系统，因为增加新功能、编译和运行测试都很慢，而且架构经常发生变化，在构建过程中总会出现难以预料的东西。所以，当领导提出迁移至微服务架构时，我们也同意了。

为什么选择放弃?

然而， 在整个调研过程中，我们发现了如下七大难以解决的问题，这些问题让我们最终选择放弃。

严重依赖第三方

我们的整体应用程序是一个建立在外部产品之上的自定义 UI 层，集成了自定义业务规则，并提供了用于交互的界面。客户端是一个 UWP 应用程序，还有一些后端服务，用于在我们和第三方域之间进行转换。

因为大量依赖第三方，我们在进行微服务划分时遇到了一些问题，例如，为了让第三方的某个域起作用，应用程序必须在域之间做一些转换工作，让第三方域看起来像是我们的域的一部分。如果前端和第三方之间只有一个服务，那么这种转换还是可行的。当我们试图将域划分成多个独立的微服务时，域之间的转换工作带来了很多麻烦。比如，微服务划分是否要跟第三方保持一致，并在两边服务之间重复实现前端需求?或者根据自己的原则来划分微服务，并通过一个微服务从第三方的多个域获取数据?这两种方法都违反了微服务原则，并且会导致额外的耦合。

此外，我们经常要与外部方协同工作，因为一些特性要求双方都做出改动。实际上，外部方成了我们之外的另一个开发团队。如此紧密的合作意味着我们的发布流程必须与他们保持同步。 微服务的一个好处是每个团队都可以独立发布自己的服务，不需要与其他团队进行协调 ， 但跨团队甚至是跨公司的协调发布流程导致我们无法享受到这些好处。

微服务的核心思想之一是打破“不同层由不同团队负责开发”的模式。在微服务架构中，每个团队需要处理与其业务相关的整个技术栈。对于我们来说，因为外部方是一家完全独立的公司，所以进行这种重构是不现实的。

无法有效拆分微服务

我们无法在单体系统中找到可以被明显拆分成微服务的部分。于是，我们随意挑了几个领域模型，得到了一个需要创建的微服务清单，但在着手调研时，我们发现这些微服务之间存在很多共享的业务逻辑和隐式耦合。我们又进一步尝试将这些微服务再细分为更小的服务，但这样却带来了 更多耦合、无处不在的消息总线，以及潜在的通信大爆炸——一个服务需要与十个甚至更多的微服务通信。

这些微服务之所以耦合得很厉害而且难以拆分，主要是因为我们原先的单体架构只为一个业务提供服务。UI 应用程序的主要设计目标是将第三方基础应用程序的数据聚合在一起。为了方便用户，我们创建了跨领域的工作流，将分散的功能聚合在一起。

在整个过程，我们并没有正确理解应该怎样拆分微服务，而且低估了正确选择微服务边界的重要性。如果按照我们的方式来拆分，那么实现一个标准的功能需要同时修改多个微服务。每个功能都需要不同的微服务团队参与开发，这就导致单个微服务无法只由某个团队负责。

不同团队共享微服务

我们大约有 12 名开发人员在做这件事情，分布在两个功能团队和一个支持团队。但我们负责的工作是波动的，一个团队不会只负责开发应用程序的某个部分，两个团队同时修改同一处代码的情况并不少见，所以不能将某个微服务的所有权赋予某个团队。

康威定律指出，软件架构将以一种与组织和团队结构类似的方式增长。如果有很多独立的团队，这些团队可以负责不同的业务关注点，那么可以考虑采用微服务架构。但是，如果只有很少的团队，并且开发的是同样的功能，那么还是不要这么做。

平台还没做好准备

因为有各种各样的问题，至少在 6 个月内，我们必须同时部署旧的单体应用和新开发的微服务，无法使用与微服务相关的工具，例如容器、Kubernetes、服务总线、API 网关等。没有这些工具，微服务之间的通信变得更加困难。

因此，我们在每个微服务中都包含了共享逻辑。因为未能正确拆分，所以出现了很多重复工作。例如，有一个特别复杂但很重要的业务逻辑，我们不得不在四个微服务中复制、粘贴和维护。

前路渺茫

开发团队只对接下来 6 个月做什么有粗略想法，除此之外就没有其他东西了。业务经常发生变化，需求突然发生变化的情况并不少见。这种不确定性使微服务的开发变得更加困难，因为无法预测会出现什么新状况。例如，微服务之间的关系和耦合会一直增长吗?几个月后，我们需不需要花时间把它们重新连接在一起?

今年早些时候，我们已经试着进行微服务概念验证，但随着业务需求的变化，这被否决了。

时间太紧

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!