为什么我们应该放弃转向微服务？

最近，我们的开发团队的开发计划出现了一个小暂停。技术部门认为，现在是将应用程序从单体架构迁移到微服务的最佳时机。 图片来自Pexels 经过一个月的准备和调查，我们取消了迁移并保持整体模式。对于我们来说，微服务不但没有帮助，反而会影响开发计划。 大约一年前，我们了解了微服务，但惊讶地发现它不太适合我们。这篇文章写的是我们的经历，或许对大家有参考作用。 尽早发现问题并做出妥协 我们严重依赖第三方 我们的应用程序集成了外部现有产品和业务规则，以呈现用户友好的 UI。客户端是一个UWP App，后台有相应的服务来与第三方域和我们交换数据。 对第三方的依赖严重影响了我们对微服务的选择。例如，应用程序通常必须在域之间转换功能，使第三方域看起来像一个完全不同的域，如果我们之间只有单一服务，这还不错。 然而，当整个域交换被分解为多个微服务时，看起来很奇怪。 是不是我们的微服务的分解方式和第三方的不同？我们是否重复所有服务的前端和后端需求？还是我们分解了自己的微服务，仍然需要一个微服务来从第三方获取信息？所有这些问题似乎都与微服务准则相悖。 我们与第三方密切合作，经常合作发布。微服务的好处是每个团队可以独立发布服务而不受影响，而跨公司协作就失去了这个好处。 微服务的另一个好处是每个团队只需要充分设计自己的业务问题。对于我们来说，作为一个完全独立于第三方的公司团队，这种重组似乎并不可行。 我们无法有效分离微服务 我们实在不知道该从哪一个应用程序开始。因此，我们在域模型之间进行连接来决定要创建哪些微服务。 然而，一旦开始这样做，你就会发现很多共享的业务逻辑影响了微服务域的划分。如果微服务被分成更小的部分，只会带来更多的耦合关系，需要到处都有消息总线，可能会出现消息大爆炸。 原因是我们的整体应用程序服务于业务逻辑。为了方便用户，我们创建了许多跨域和组的工作流程，本质上，UI 在过去四年中一直在将各种内容整合在一起。 此外，我们误解了微服务是如何隔离的，并低估了在服务之间选择正确边界的重要性。 唯一能做的就是实现一个标准功能，这需要所有相关的微服务同时升级，这就要求每个微服务不能归一个团队所有。 共享微服务 我们有大约 12 名开发人员，分布在两个功能团队和一个支持团队中。这项工作波动性很大，没有专门的团队负责。所有团队同时接触相同的代码是正常的。您不能将一项微服务分配给一个团队。 在考虑架构时，一定要记住康威定律，这意味着软件架构将在模仿组织和团队架构中成长。 当不同的团队负责不同的业务逻辑时，微服务架构会更有效。不过，共享代码功能的工作模型最好采用单体架构。 平台尚未准备好 各种问题意味着至少六个月内，微服务和单体应用需要在 IIS 中并行运行。 我们无法使用与微服务相关的工具，例如容器、Kubernetes、服务总线、API网络管理等，这意味着与其他微服务的通信存在很大障碍。 因此，我们决定每个微服务都应该复制与存储层转换相关的读服务的共享逻辑。由于服务无法正常拆分，意味着必须承担大量的复制工作量。 例如，某个复杂且基础的业务逻辑，至少需要复制、粘贴和维护4个规划的微服务。 没有清晰的未来图景 开发团队在六个月内只有一个大概的想法，而业务变更频繁（业务变更需求也屡见不鲜），这让微服务变得更加不确定，因为即使在短期内也无法预测会出现哪些环节。 微服务之间的复杂度会增加吗？需要几个月才能分离的服务会回到过去吗？虽然我们今年早些时候做了一些PoC，但由于业务需求的变化，我们不得不放弃它。 架构上紧密耦合 我们只有很短的时间将单体应用程序分解为列出的微服务，并且没有针对可能的更改或 B 计划的冗余，我们陷入了困境。 因为我们在规划阶段就发现了很多问题和挑战，更不用说实施阶段了，开发团队压力很大。 缺乏经验 由于风险和时间压力，架构师和实施专家都没有任何特殊经验，而且没有可用的标准工具，所以我们不得不自己实施，这加剧了这种情况。 在与其他微服务专家沟通后，他们也发出了很多警告，并给出了很多以前没有的架构建议，指出了我们在领域模型之间划线的顺序。 到目前为止，由于时间紧迫、工作量大，我们的计划包含了许多与标准微服务不同的妥协。 由于缺乏专家，这看起来更像是一条不归路，开发团队越来越着急。 再次质疑我们的目标 痛点解决了吗？ 一旦前方的道路充满障碍，我们就会失去目标，我们会停下来，意识到我们不明白为什么要做我们正在做的事情。 我们没有列出痛点，也不清楚这样做是否能解决这些问题。更重要的是，微服务可能会给我们带来新的问题。我们开始思考，我们能从中得到什么好处？它能解决什么问题？我们召开了多次会议进行讨论，但一直没有明确的答案。 最后我们发现我们在讨论微服务的过程中忽略了一个非常重要的痛点，并且没有足够的时间来解决这个问题，那就是我们无法考虑微服务或者其他的东西。 潜在的好处是什么？ 这个时候我们开始反思一般意义上的微服务会带来哪些好处？ 自治 微服务允许团队控制整个堆栈来提供功能。这种分离会减少不同团队之间的协作次数，并且不会影响彼此的工作。 让团队更加专注 在单体应用程序中，团队可以专注于所有任务。采用微服务后，您就成为某个业务流程的专家。 他们会了解自己领域的业务规则和需求，知道如何构建软件堆栈，并且在发生变化时会非常自信。 易于扩展 通过微服务，可以根据性能需求来扩展服务。在单体应用中，虽然服务可以水平扩展，但是单体应用的模块却无法独立扩展。 微服务粒度可以增加或减少服务能力。也许当发现性能问题时，你可以参与其他工作，或者喘口气。 易于回滚 每个功能只需要修改单个微服务，并且可以回滚而不影响其他团队的工作。此外，微服务还可以减少单个错误对整个系统的影响。 易于迭代 如果您有一个扩展系统，其中每个版本都耗时且有风险，那么将需要大量工作来处理每个版本的问题。 微服务可以减少沟通时间和成本，团队可以单独确定合适的时间。 使用最好的技术 依赖微服务的团队可以选择最佳的技术解决方案。另一方面，单体很难升级。 易于升级 升级大型应用程序并不是一件容易的事。尤其是在多个团队之间进行协作时。隔离的微服务一次只能升级一项服务，更容易控制风险。 风险保障 微服务可以将经常变化的服务和很少变化的服务分开，降低意外发生的风险。 粒径减小 小型化服务更容易理解并保持设计的一致性。相反，由于不同团队的意见不一致，单体应用程序可能会导致不一致。 优点总结 微服务有很多优点。但我们能从中得到什么？ 最终，只有无法改变或妥协的架构才能放弃这些优势。我们失去了微服务带来的隔离。与第三方的合作减少了服务无关性带来的好处。 权衡 用大炮灭蚊子 微服务并不全是优点，还有很多问题需要考虑。例如，日志记录、监控、异常处理、容错、回滚、通信、消息格式、容器、服务发现、备份、遥测、警报、跟踪、工具、共享、文档、扩展、时区、阶段、API 版本、网络延迟、健康检查、负载平衡、CDC 测试等。 如果没有微服务平台，我们将不得不面对上面列出的所有问题。因为痛点，我们不得不转向微服务，但我们不但不能从中受益，还要面对转向微服务带来的很多问题。我们为什么要烦恼？ 微服务只是一个名字 下图展示了我们现在的单体应用和微服务的对比。从架构的角度来看，新架构非常像一个整体，每个组件仍然紧密耦合。也许我们只是使用微服务的标签。 ​ 一体机就一定不好吗？ 看来“单体”意味着落后，“微服务”意味着先进。但从开发团队的角度来看，我们的单体应用运行良好，基本没有问题。 我们拥有出色的 CI/CD 设置，易于配置和回滚。分支和测试策略可确保问题得到尽早解决。 似曾相识 这个时候，似乎有一些熟悉的感觉。我在之前的工作经历中也有过类似的经历，但从来没有被称为微服务。虽然它并不完全符合微服务的规则，但它确实解决了问题并带来了类似的好处。 一个 5 人的小团队领导着 200 名开发人员。这是一个巨大的 C# 应用程序，大约 5% 的工作通过整体共享，其余工作在两个节点服务之间​​共享。 我们也不喜欢单一的方法，因为它的运行速度非常慢。编译、测试、架构的变化非常快，我们经常看到不同的同事出现。 有时整个项目会被推迟，因为我从未听说过的同事辞职，技术更新需要几个月的时间，因为需要与整个公司同步，而 Pull 申请需要整个系统的批准，需要几周的时间。 同时，有两个服务规模较小，我们可以很好地控制、部署和架构它们。一旦出现性能问题，实例数量就会受到怀疑，直到解决了底层问题，其他团队很少会受到困扰。 我们的团队主导了前端和后端开发语言的选择。简而言之，我们专注于非常狭窄的业务逻辑，每个人都成为专家。 超越技术 我们对微服务了解得越多，就越发现它们不适合我们。我们是否为了技术而过于技术化？ 还有很多问题没有考虑到： 有专门负责业务逻辑的团队吗？ 领域和微服务能否清晰划分？ 所有团队的工作是否平衡？ 团队负载是否平衡？ 单一的困难是否会被分解到其他工作中？ 审查 迁移到微服务是一次大爆炸。每个人都停止功能并开始思考如何分解单个引用，即使先决条件尚不可用。 后来事实证明，这不是一个好办法，甚至可能是一种倒退。先创建所有微服务，然后搭建架构，忽略团队架构。如果我们一开始就考虑团队和业务逻辑的结合，等待架构成熟，等待微服务自然出现，那就更好了。并且当出现新的业务需求时，可以直接放入新的服务中。 强制使用微服务还意味着选择每个微服务的大小。一些文章建议每个微服务的设计都需要至少一个团队的支持。其他人则认为越小越好，这样如果需要改变，可以在很短的时间内完成。 领导层决定工作领域的划分，并在必要时进一步细分。该决定导致了上述问题。后来在回顾的时候，我发现如果我们等待微服务自然出现的话，它们的大小其实是最合适的。 取消 随着预定时间的临近，我们的团队不断发现越来越多的问题。上线四天后，仍然看不到预期效果。召开了一次会议，微服务计划最终被取消。 取代行动 微服务的流行度已经消散，这意味着我们还没有做必要的研究。放弃微服务之后，我们还有精力去研究其他解决方案。 最终，我们决定将单个应用划分为不同的项目，以更好地划分架构和耦合关系。 另外，这种架构让领域模型更加清晰，以后更容易考虑微服务。 综上所述 领导层在没有考虑挑战和现状的情况下仓促做出了有关微服务的决定。经过评估，我们发现微服务不适合我们，需要更多的妥协。 这些权衡抵消了微服务的好处。微服务没有考虑团队结构和工作量等非技术因素。 经过几个月的研究，我们放弃了微服务尝试，决定对现有的单体应用程序进行一些更合适的微调。