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

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

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

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

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

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

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

微服务的好处是什么?

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

自治

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

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

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

伸缩性

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

更容易回滚

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

更高的发布频率

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

使用最合适的技术

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

升级更简单

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

缩小变更影响范围

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

易于重构

（编辑：西安站长网）

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