19月XNUMX日在莫斯科 第一次主题会议HUG（Highload++ User Group），致力于微服务。 有一个演讲“运营微服务：规模很重要，即使你有 Kubernetes”，其中我们分享了 Flant 在使用微服务架构运营项目方面的丰富经验。 首先，它对于所有正在考虑在当前或未来的项目中使用这种方法的开发人员来说都是有用的。
介绍 （50 分钟，比文章内容丰富得多），以及文本形式的主要摘录。
注意：本文末尾还提供了视频和演示文稿。
介绍
通常一个好的故事都有开头、主要情节和结局。 这份报告更像是一个序幕，而且是一个悲剧。 还需要注意的是，它提供了局外人对微服务的看法。 操作.
我将从这张图开始，其作者（2015 年） 马丁福勒：
它显示了在单体应用程序达到一定值的情况下，生产力如何开始下降。 微服务的不同之处在于，它们的初始生产力较低，但随着复杂性的增加，效率的下降对它们来说并不那么明显。
对于使用 Kubernetes 的情况，我将添加到此图表中：
为什么带有微服务的应用程序更好？ 因为这样的架构对架构提出了严格的要求，而这些要求又被Kubernetes的能力完美覆盖。 另一方面，其中一些功能对于整体应用程序很有用，特别是因为当今典型的整体应用程序并不完全是一个整体应用程序（详细信息将在报告的后面部分介绍）。
正如您所看到的，最终的图表（当单体应用程序和微服务应用程序都位于具有 Kubernetes 的基础设施中时）与原始图表没有太大不同。 接下来我们将讨论使用 Kubernetes 运行的应用程序。
有用和有害的微服务
这是主要思想：
什么是 正常 微服务架构？ 它应该给您带来真正的好处，提高您的工作效率。 如果我们回到图表，它是：
如果你打电话给她 有用，那么在图的另一边将会有 有害 微服务（干扰工作）：
回到“主要思想”：我应该相信我的经验吗？ 从今年年初开始我就一直在看 85个项目。 并非所有这些都是微服务（大约三分之一到一半具有这样的架构），但这仍然是一个很大的数字。 我们（Flant 公司）作为外包商设法看到小型公司（拥有 5 名开发人员）和大型公司（约 500 名开发人员）开发的各种应用程序。 另一个好处是我们看到这些应用程序多年来一直存在并不断发展。
为什么选择微服务？
关于微服务的好处的问题是 来自已经提到的马丁·福勒：
- 模块化的清晰界限；
- 独立部署；
- 选择技术的自由。
我与软件架构师和开发人员进行了很多交谈，并询问他们为什么需要微服务。 我列出了他们的期望。 事情是这样的：
如果我们描述“感觉”中的一些点，那么：
- 模块边界清晰：这里有一个可怕的庞然大物，现在一切都将整齐地排列在Git存储库中，其中一切都“上架”，温暖和柔软不混合；
- 部署独立性：我们将能够独立推出服务，以便开发速度更快（并行发布新功能）；
- 开发独立性：我们可以将此微服务提供给一个团队/开发人员，然后将其提供给另一个团队/开发人员，这样我们就可以更快地开发；
- бо更高的可靠性：如果发生部分降级（20 个微服务中就有一个崩溃），那么只有一个按钮会停止工作，整个系统将继续运行。
典型的（有害的）微服务架构
为了解释为什么现实不是我们所期望的，我将提出 集体 基于许多不同项目的经验的微服务架构的图像。
一个例子是一个抽象的在线商店，它将与亚马逊或至少是 OZON 竞争。 其微服务架构如下所示：
由于多种原因，这些微服务是在不同的平台上编写的：
由于每个微服务必须具有自治权，因此许多微服务需要自己的数据库和缓存。 最终架构如下：
其后果是什么？
福勒也有这个 ——关于使用微服务的“付费”：
我们将看看我们的期望是否得到满足。
清晰的模块边界...
但 我们实际上需要修复多少微服务？推出变革？ 我们甚至可以弄清楚在没有分布式跟踪器的情况下一切是如何工作的（毕竟，任何请求都由一半的微服务处理）？
有一个模式“”，这里原来是一团分散的泥土。 为了证实这一点，下面是请求如何进行的大致说明：
部署独立性...
从技术上来说，已经实现了：我们可以单独推出每个微服务。 但在实践中你需要考虑到它总是会推出 许多微服务，我们需要考虑到 推出的顺序。 以一种好的方式，我们通常需要在单独的电路中测试我们是否以正确的顺序推出版本。
自由选择技术...
她是。 请记住，自由往往与无法无天接壤。 这里非常重要的是不要仅仅为了“玩”而选择技术。
独立发展...
如何为整个应用程序（具有如此多的组件）建立一个测试循环？ 但您仍然需要保持最新状态。 这一切都导致了这样一个事实： 实际测试电路数，我们原则上可以包含， 结果是最小的.
在本地部署所有这些怎么样？事实证明，开发人员通常独立但“随机”地进行工作，因为他被迫等到电路可以自由进行测试。
单独缩放...
可以，但仅限于所使用的 DBMS 领域。 在给定的架构示例中，Cassandra 不会出现问题，但 MySQL 和 PostgreSQL 会出现问题。
Бо更高的可靠性...
现实中，一个微服务的故障往往不仅会破坏整个系统的正常运行，还会带来一个新问题： 让每个微服务都能容错是非常困难的。 因为微服务使用不同的技术（memcache、Redis 等），所以对于每一种技术，你都需要考虑周全并实现它，这当然是可能的，但需要巨大的资源。
负载可测量性...
这真是太好了。
微服务的“轻”...
我们不仅拥有庞大的 网络开销 （对 DNS 的请求成倍增加等），但也是由于我们启动了许多子查询 复制数据 （存储缓存），这导致了大量的存储空间。
这是满足我们期望的结果：
但那还不是全部！
这是因为：
- 我们很可能需要消息总线。
- 如何在正确的时间及时进行一致的备份？ 唯一的 实 选项是为此关闭流量。 但在生产中如何做到这一点呢？
- 如果我们谈论的是支持多个地区，那么在每个地区组织可持续发展是一项非常耗费人力的任务。
- 出现了集中变更的问题。 例如，如果我们需要更新 PHP 版本，我们将需要提交到每个存储库（有数十个）。
- 操作复杂性的增长是指数级的。
这一切该怎么办？
从单体应用程序开始。 福勒的经历 几乎所有成功的微服务应用程序都是从一个整体开始的，后来变得太大，然后就被破坏了。 与此同时，几乎所有从一开始就构建为微服务的系统迟早都会遇到严重的问题。
另一个有价值的想法是，一个微服务架构的项目要想成功，你必须非常了解 和主题领域，以及如何制作微服务。 学习一个学科领域的最好方法就是打造一个整体。
但如果我们已经处于这种情况怎么办？
解决任何问题的第一步是同意它并理解它是一个问题，我们不想再受苦了。
如果，在一个过度增长的整体的情况下（当我们没有机会为其购买额外资源时），我们削减它，那么在这种情况下，结果会是相反的情况：当过多的微服务不再有帮助，而是阻碍时 - 剪掉多余的部分并放大!
例如，对于上面讨论的集体形象......
摆脱最有问题的微服务：
组合负责前端生成的所有微服务：
...到一个微服务中，用一种（现代的和正常的，正如你自己认为的）语言/框架编写：
它将有一个 ORM（一个 DBMS）和几个应用程序：
...但一般来说，您可以在那里传输更多内容，得到以下结果：
此外，在 Kubernetes 中，我们在单独的实例中运行所有这些，这意味着我们仍然可以单独测量负载并扩展它们。
总结
看看更大的图景。 很多时候，所有这些微服务问题的出现都是因为有人接手了他们的任务，但想要“玩转微服务”。
在“微服务”这个词中，“微”部分是多余的。。 它们之所以是“微型”，只是因为它们比一块巨大的巨石还要小。 但不要把它们视为小事。
最后，让我们回到原始图表：
上面写着一张便条 （右上） 归结为这样一个事实 完成项目的团队的技能始终是首要的 — 它们将在您在微服务和整体服务之间进行选择时发挥关键作用。 如果团队没有足够的技能，却开始做微服务，那故事肯定是致命的。
视频和幻灯片
演讲视频（约50分钟；遗憾的是，它并没有传达出参观者的众多情感，这在很大程度上决定了报告的情绪，但事实就是如此）：
报告介绍：
PS
我们博客上的其他报道：
- «» （德米特里·斯托利亚罗夫；28 年 2018 月 XNUMX 日在 RootConf）;
- «» （Dmitry Stolyarov；7 年 2017 月 XNUMX 日，HighLoad++）;
- «» （德米特里·斯托利亚罗夫；6 年 2017 月 XNUMX 日，RootConf）;
- «» （Dmitry Stolyarov；8 年 2016 月 XNUMX 日，HighLoad++）;
- «» （德米特里·斯托利亚罗夫；31 年 2016 月 XNUMX 日在 RootConf）.
您可能还对以下出版物感兴趣：
- «“;
- «“;
- «“。
来源： habr.com