微服务的炒作高峰似乎已经落后。 我们不再每周几次阅读“我如何将我的巨石转移到150个服务”的帖子。 现在，我经常听到合理的想法：“我不讨厌整体，我只关心效率。” 我们甚至观察到了从微服务向整体迁移的几次迁移。 从一个大型应用程序迁移到几个较小的服务时，您将不得不解决几个新问题。 我们将它们尽可能简短地列出。

安装：从基础化学到量子力学

使用后台进程设置基本数据库和应用程序是一个非常清晰的过程。 我在Github上发布了一个自述文件-通常一个小时后，最多几个小时，一切正常，然后开始一个新项目。 至少在初始环境中，添加和运行代码是在第一天完成的。 但是，如果我们冒险进入微服务，那么最初的启动时间将飞向天堂。 是的，现在我们有一个经过精心设计的Docker和一组K8机器，但是对于新手程序员而言，这一切都复杂了一个数量级。 对于许多初级用户来说，这是一个负担，实际上是不必要的复杂性。

该系统不容易理解。

让我们在我们的大三学生上停留片刻。 对于单片应用程序，如果出现错误，很容易对其进行跟踪并立即进行调试。 现在，我们有一个与另一个服务对话的服务，该服务在处理另一个服务的消息总线上排队一些东西，然后发生错误。 我们必须将所有这些部分放在一起才能最终确定服务A在版本11中运行，服务E已经在等待版本12。这与我的标准合并日记非常不同：您必须使用交互式终端/调试器来完成该过程一步一步 本质上，调试和理解变得更加困难。

如果您无法调试，也许我们会对其进行测试

持续集成和持续发展现在变得司空见惯。 我在每个新发行版中看到的大多数新应用程序都会自动创建并运行测试，并要求测试通过并在注册之前进行检查。 这些是无法放弃的出色流程；对于许多公司而言，它们已经成为一个重大转变。 但是现在，要真正测试服务，我必须提高应用程序的完整工作版本。 还记得拥有150个服务K8集群的新工程师吗？ 好了，现在我们将教我们的CI系统如何提升所有这些系统，以验证一切是否确实有效。 这可能是太多的工作，因此我们将单独测试每个部分：我确定我们的规格足够好，API干净，服务失败是孤立的，不会影响其他部分。

所有妥协都有充分的理由。 对不对

升级到微服务的原因很多。 我看到他们这样做是为了更大的灵活性，缩放命令，提高性能，提供更好的稳定性。 但是实际上，我们已经在开发整体式工具的工具和实践上投入了数十年的时间，而且这种方法还在不断发展。 我与不同技术的专业人员合作。 我们通常谈论扩展，因为它们面临着单个Postgres数据库节点的限制。 大部分讨论都是关于扩展数据库 。

但是我总是很想了解他们的架构。 它们是在向微服务过渡的哪个阶段。 有趣的是，越来越多的工程师表示对整体应用感到满意。 许多微服务将受益，而收益将超过迁移路径上的障碍。 但就我个人而言，请给我我的整体应用程序，在海滩上一个地方-我完全满意。