微服务的炒作高峰期似乎已经过去了。 我们不再每周阅读几次帖子“我如何将我的庞然大物转移到 150 个服务”。 现在我听到了更多常识性的想法：“我不讨厌单体，我只是关心效率。” 我们甚至观察到了几次迁徙 。 从一个大型应用程序迁移到多个较小的服务时，您将必须解决几个新问题。 让我们尽可能简短地列出它们。
背景：从基础化学到量子力学
使用后台进程设置基本数据库和应用程序是一个相当简单的过程。 我在 Github 上发布自述文件 - 通常在一小时后，最多几个小时，一切正常，然后我开始一个新项目。 添加和运行代码（至少对于初始环境而言）是在第一天完成的。 但如果我们冒险进入微服务，初始启动时间就会急剧增加。 是的，现在我们有了带有编排功能的 Docker 和 K8 机器集群，但对于新手程序员来说，这一切要复杂得多。 对于很多后辈来说，这是一种负担，确实是一种不必要的复杂化。
系统不太容易理解
让我们暂时关注一下我们的初级学生。 对于单体应用程序，如果发生错误，很容易找到它并立即进行调试。 现在，我们有一个服务正在与另一个服务进行通信，而另一个服务正在消息总线上排队处理另一个服务，然后发生错误。 我们必须将所有这些部分放在一起，最终发现服务 A 正在运行版本 11，而服务 E 已经在等待版本 12。这与我的标准综合日志有很大不同：必须使用交互式终端/调试器来行走一步一步地完成这个过程。 调试和理解本质上变得更加困难。
如果无法调试，也许我们会测试它们
持续集成和持续开发现在变得司空见惯。 我看到的大多数新应用程序都会在每个新版本中自动创建和运行测试，并要求在注册之前进行和审查测试。 这些都是不应被放弃的伟大流程，并且对许多公司来说是一个重大转变。 但现在，要真正测试该服务，我必须启动应用程序的完整工作版本。 还记得那个拥有 8 个服务的 K150 集群的新工程师吗？ 好吧，现在我们将教我们的 CI 系统如何启动所有这些系统来验证一切是否真正有效。 这可能需要花费太多精力，因此我们将单独测试每个部分：我相信我们的规范足够好，API 很干净，并且服务故障是隔离的，不会影响其他部分。
所有的妥协都有充分的理由。 正确的？
迁移到微服务的原因有很多。 我看到这样做是为了更大的灵活性、扩展团队、提高绩效、提供更好的可持续性。 但实际上，我们已经在工具和实践上投入了数十年的时间来开发不断发展的单体。 我与不同技术领域的专业人士一起工作。 我们通常谈论扩展，因为它们遇到了单个 Postgres 数据库节点的限制。 大多数对话都是关于 .
但我一直有兴趣了解他们的架构。 他们正处于向微服务过渡的哪个阶段？ 有趣的是看到更多的工程师表示他们对他们的整体应用程序感到满意。 许多人将从微服务中受益，而且其好处将超过迁移路径中的障碍。 但就我个人而言，请给我我的整体应用程序，在海滩上的一个地方 - 我非常高兴。
来源： habr.com