为什么放弃了微服务？

构迁移至微服务。经过一个月的调研和准备之后，我们最终放弃迁移计划，继续使用原先的单体架构。在我们看来，微服务不仅不会帮到我们，反而会对开发流程造成严重影响。

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

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

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

为什么选择放弃?

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

严重依赖第三方

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

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

此外，我们经常要与外部方协同工作，因为一些特性要求双方都做出改动。实际上，外部方成了我们之外的另一个开发团队。如此紧密的合作意味着我

（编辑：淮南站长网）

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