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

除了面临风险和时间压力外，负责设计和实现微服务的人之前没有相关经验。由于没有足够的标准工具可用，导致情况更加恶化，我们不得不自己实现基础设施平台。在与一些有微服务经验但没有参与我们项目的人交流之后，引发了更大的恐慌。他们建议的基础设施我们没有，他们还指出了我们在领域模型之间划分界限可能带来的后果。

到目前为止，我们的计划中包含了很多不得已的妥协，多少都偏离了标准的微服务模式。时间紧迫，没有专家指导，犯错成了家常便饭，我们以极高的代价换来血的教训。

反思：微服务解决痛点了吗?

当这些事情变得越来越困难，清晰的前行之路开始变得模糊。我们才意识到当初都不知道为什么要做这些事情，我们没有列出痛点是什么，也不知道做这些事情是否可以解决问题。更糟糕的是，微服务可能会带来新的问题。

我们开始分析这些问题：应该从重构中得到什么好处?要解决什么问题?我们试图通过无休止的会议搞清楚这些问题。在每一次休息时间，开发人员之间的每一次对话都在讨论和质疑微服务，但仍然无法得到答案。

事实证明，相比于微服务，我们确实有其他更紧迫的痛点需要解决，只是这些痛点在我们考虑迁移到微服务的过程中被忽视了，但我们没有足够的时间来解决这些痛点，所以我们最后既没有得到微服务的好处，也没能解决其他痛点。

微服务的好处是什么?

在意识到并不清楚采用微服务的目的之后，我们开始研究微服务能够带来哪些好处。

自治

在采用微服务架构时，开发团队拥有交付特性所需的整个技术栈的控制权，好处是可以减少与其他团队之间的协调工作，互不影响。

开发团队可以专注某些领域

在采用单体架构时，开发任务的分配是不固定的，任何人都有可能分配到任意的任务。但如果每个团队可以拥有自己的服务，就可以在特定业务领域积累专业知识，理解特定领域的业务规则和需求。他们对自己的技术栈十分了解，在做出变更时更有信心。

伸缩性

在采用微服务时，开发者可以根据每个服务的性能需求进行伸缩。而在采用单体架构时，虽然也可通过添加更多服务器进行水平伸缩，但却不能让单体的每个组件进行独立伸缩。此外，细粒度的微服务可以更容易根据需要进行垂直伸缩。例如，有时可能希望多处理一些负载，而在处理性能问题时又需要一些额外的机会。

更容易回滚

如果回滚某个功能，只需要修改单个微服务就可以直接回滚，不会影响其他团队的工作。此外，微服务架构有助于降低因单个微服务故障导致整个系统宕机的风险。

更高的发布频率

如果是一个大型系统，每次版本发布都很耗时，且伴随着风险。回归测试需要覆盖很多东西，从而限制发布节奏。开发人员可能需要经过很多人准许，并在所有参与版本发布的团队之间进行协调。微服务缩小了变更范围，减少了团队之间的协调工作量。开发团队可以根据自己的时间表发布版本，而不是被一个整体的节奏所束缚。

使用最合适的技术

微服务的各个团队可以为要解决的问题选择最合适的技术，可以使用较新的技术，而单体系统则很难升级，只能停留在过时的技术平台上。

升级更简单

给大型应用程序升级框架从来都不是件有趣的事情，而且通常都伴有风险。当需要在多个团队间协调相互关联的变更时，一切都变得更加困难。而在采用微服务架构时，可以只升级必要服务，每次只让一个团队升级一个服务。

缩小变更影响范围

应用程序的不同部分以不同的速度发生变化，大部分组件可能几个月甚至几年都不需要改动，将很少发生变化的代码与频繁发生变化的代码分开可以降低意外回归带来的风险。

易于重构

较小的服务更容易理解。一个服务只由一个团队负责开发，服务的设计风格就能够保持一致。小巧的微服务更容易进行重构。相比之下，单体架构可能会出现不一致，因为随着时间的推移，不同的团队会向单体系统中加入不一样的设计想法。

这些好处跟我们有什么关系?

采用微服务有很多潜在的好处，但我们能捞到这些好处吗?

最终，单体架构中无法变更的部分和我们不得不做出的妥协导致无法获得这些好处。开发团队需要在不同的微服务之间协调，一些功能分散在多个共享的微服务中，这说明我们并没有获得微服务的隔离性好处：减少协调和专门化。

微服务之间的差异变成了缺点，而不是优点。开发每一个新功能都需要了解新的微服务以及需要其他团队做出哪些改动。我们对第三方的依赖严重阻碍了开发进程，让我们无法获得微服务伸缩性的优势。

权衡利弊

大材小用

采用微服务架构并不是没有代价，需要解决很多问题，而大部分在单体系统中已经解决过了，例如：日志、监控、异常处理、容错、回退服务间通信、消息格式、容器化、服务发现、备份、遥测、警报、跟踪、构建管道、发布管道、工具、共享基础设施代码、文档、伸缩、时区支持、API 版本控制、网络延迟、健康检查、负载均衡、CDC 测试、容错、在本地开发环境调试和开发多个微服务等。

更糟糕的是，因为没有现成的微服务平台，我们不得不自己完成上面这些事情。要转向微服务，我们确实存在痛点和困难，也确信无法从微服务架构获得任何好处，如果要支持微服务，还需要做一长串额外工作。

名义上的微服务

下图分别是我们当前的单体架构、计划中的架构和微服务架构。从结构上看，新的架构跟当前的单体架构很像，所有东西仍然紧密耦合在一起。

单体架构很糟糕吗?

自从微服务架构大火之后，“单体”成了一个不太好的名词，好像“单体”就是糟糕的东西，而“微服务”就是好东西。但回望过去，我们的开发团队在开发单体系统时并没有遇到什么问题。开发和扩展都非常简单，已经有一个非常好的 CI/CD 管道，部署和回滚都非常容易。我们的分支管理和测试策略确保了很少会有问题进入到生产环境。

微服务更多与技术无关

我们对微服务研究得越多，就越觉得它与技术无关，更多的是与团队的结构和工作模式有关。我们把微服务视为纯粹的技术问题，或许是我们错了?

（编辑：新余站长网）

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