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

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

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

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

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

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

权衡利弊

大材小用

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

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

名义上的微服务

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

单体架构很糟糕吗?

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

微服务更多与技术无关

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

（编辑：西安站长网）

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