9月19日，
第一个主题metap HUG（高负载++用户组）在莫斯科
举行 ，专门针对微服务。 这份报告“微服务的运营：即使您拥有Kubernetes，规模也很重要”，在这份报告中，我们分享了Flant在使用微服务架构运营项目方面的丰富经验。 首先，它将对所有正在考虑在当前或将来的项目中采用这种方法的开发人员有用。
我们将
视频与报告一起呈现（50分钟，比文章多得多），并以文本形式提供其主要摘录。
注意：视频和演示文稿也可以在本出版物的末尾获得。 引言
通常，一个好故事有一个情节，一个主要情节和一个结局。 这份报告更像是一个阴谋，而且是悲惨的。 同样重要的是要注意它提供了微服务的
运行情况 。
我将从这样一个时间表开始，该时间表的作者（在2015年）
是 Martin Fowler：
它显示了在单片应用程序已达到一定值的情况下，工作效率如何开始下降。 微服务的不同之处在于，微服务的初始生产率较低，但是，随着复杂性的提高，它们的效率下降并不是那么明显。
对于使用Kubernetes的情况，我将对此图进行补充：
为什么微服务应用程序会变得更好？ 因为这样的架构提出了严重的架构要求，而Kubernetes功能又可以完美地覆盖这些要求。 另一方面，此功能的一部分对整体结构也很有用，特别是因为当今的典型整体结构并非完全是整体结构（详细信息将在报告中进一步介绍）。
如您所见，最终时间表（当使用Kubernetes的基础架构中的单片和微服务应用程序时）与原始时间表没有太大差异。 接下来，我们将讨论使用Kubernetes运行的应用程序。
有用和有害的微服务
这里的主要思想是：
什么是
正常的微服务架构？ 它应该为您带来真正的好处，提高工作效率。 如果您返回图表，则为：
如果您认为它
有用 ，那么在图的另一侧，将会有
有害的微服务（干扰工作）：
回到“主要思想”：完全值得信赖我的经验吗？ 从今年年初开始，我研究了
85个项目 。 并非所有人都是微服务（大约三分之一到一半拥有这种架构），但这仍然是一个很大的数目。 作为外包商，我们（弗兰特公司）设法看到在小型公司（有5个开发人员）和大型公司（约500个开发人员）中开发了各种各样的应用程序。 另外一个好处是，我们可以看到这些应用程序多年来如何生存和发展。
为什么选择微服务？
对于有关微服务的好处的问题，已经提到的Martin Fowler有一个
非常具体的答案 ：
- 明确的模块化界限；
- 独立部署；
- 选择技术的自由。
我与架构师和软件开发人员进行了很多交谈，并询问为什么他们需要微服务。 并整理了他的期望清单。 这是发生了什么：
如果您“有些激动”地描述了一些观点，那么：
- 明确的模块边界：这里我们有一个可怕的整体，现在所有内容都将被整齐地放置在Git存储库中，其中所有内容都“摆在架子上”，而不是温暖和柔软的混合；
- 部署独立性：我们将能够独立推出服务，从而加快开发速度（并行发布新功能）；
- 开发独立性：我们可以将此微服务提供给该团队/开发人员，以及另一个，以便我们可以更快地进行开发；
- 更高的可靠性：如果发生部分降级（20个故障中有1个微服务），那么只有一个按钮将停止工作，整个系统将继续运行。
典型的（有害的）微服务架构
为了解释为什么实际上一切都不如我们期望的那样，我将基于许多不同项目的经验，提供微服务体系结构的
总体形象。
一个例子是将要与亚马逊或至少与OZON竞争的抽象在线商店。 其微服务架构如下所示：
由于多种原因，这些微服务是在不同的平台上编写的：
由于每个微服务都应具有自治权，因此许多微服务需要自己的数据库和缓存。 最终的体系结构如下：
其后果是什么？
Fowler对此主题
发表了一篇文章 -关于使用微服务的“回报”：
我们将看看是否满足我们的期望。
明确的模块边界...
但是
，我们真的需要修复多少微服务才能推出更改？ 我们是否可以弄清楚没有分布式跟踪器的情况下所有东西如何工作（毕竟，任何请求都由一半的微服务处理）？
有一个“
大块的泥 ”模式，但是这里我们得到了一个分散的泥块。 为此，下面是查询如何进行的示例说明：
部署独立性...
从技术上讲，它已经实现：我们可以分别滚动每个微服务。 但是实际上，您需要考虑到总是会推出
许多微服务 ，并且我们需要考虑
其推出的
顺序 。 以一种很好的方式，我们通常需要在单独的电路中测试是否按正确的顺序推出了发行版。
自由选择技术...
她在那里。 唯一值得记住的是，自由常常与无法无天联系在一起。 在这里非常重要的是不要选择仅与它们“玩”的技术。
发展独立性...
如何为整个应用（由那么多的组件）制作测试电路？ 但是您仍然需要保持最新状态。 所有这些导致一个事实，即我们原则上可以包含
的测试循环的
实际数量 是最小的 。
但是要在本地部署所有这些吗？..事实证明，开发人员通常是独立但随机地完成工作，因为他必须等到测试电路发布后才能进行。
单独缩放...
是的，但是它在使用的DBMS领域中受到限制。 在给定的体系结构示例中，Cassandra不会有问题，但是MySQL和PostgreSQL会有问题。
更高的可靠性...
不仅如此，事实上，一个微服务的故障通常会破坏整个系统的正常运行，还有一个新问题：
使每个微服务容错非常困难 。 因为微服务使用不同的技术（内存缓存，Redis等），所以每个人都需要考虑并实现所有事情，这当然是可能的，但是需要大量的资源。
负载的可测量性...
一切真的很好。
微服务的轻便性...
我们不仅有巨大的
网络开销 （DNS查询等），而且由于子查询很多，我们开始
复制数据 （存储缓存），从而导致大量的存储。
这是满足我们期望的结果：
但这还不是全部！
因为：
- 我们很可能需要消息总线。
- 如何在正确的时间进行一致的备份？ 唯一的实际选择是为此关闭流量。 但是如何在生产中做到这一点？
- 如果我们要谈论支持多个地区，那么在每个地区组织可持续性是一项非常耗时的任务。
- 存在进行集中更改的问题。 例如，如果需要更新PHP的版本，则需要提交到每个存储库（其中有数十个）。
- 一方面，操作复杂性的增加是指数级的。
这一切怎么办？
从整体应用开始 。 Fowler的经验
表明 ，几乎所有成功的微服务应用程序都是从整体开始的，而整体变得太大，之后就被破坏了。 同时，几乎所有从一开始就构建为微服务的系统迟早都会遇到严重问题。
另一个有价值的想法是，要使具有微服务架构的项目成功，您应该非常了解
主题领域和如何制作微服务 。 知道主题区域的最佳方法是制作一个整体。
但是，如果我们已经处于这种情况下该怎么办？
解决任何问题的第一步是同意它，并理解这是一个我们不再希望遭受的问题。
如果在整体堆满的情况下（当我们没有足够的机会为其购买资源时）将其削减，那么在这种情况下，我们得到了相反的结论：当过多的微服务不再有用，而是造成干扰时，请
砍掉多余的并扩大规模 ！
例如，对于上面讨论的集体图像...
摆脱最可疑的微服务：
组合所有负责生成前端的微服务：
...在一种微服务中，以一种（您自己认为是现代的和普通的）语言/框架编写的：
它将有一个ORM（一个DBMS）和第一个应用程序：
...一般而言，可以得到更多的结果，结果如下：
此外，在Kubernetes中，我们在单独的实例中运行所有这些，这意味着我们仍然可以测量负载并分别缩放它们。
总结
宽看图片。 通常，微服务的所有这些问题都是由于有人执行任务但想“玩微服务”而引起的。
在“微服务”一词中，“微”部分是多余的 。 它们之所以“微”，仅仅是因为它们比巨大的整体小。 但是不要认为它们太小。
最后的想法是回到原来的时间表：
写给他的注释
（右上）可以归结为这样一个事实，即使
您的项目成为团队的
技能始终是首要的 -它们将在您选择微服务和整体服务之间发挥关键作用。 如果团队没有足够的技能，但是开始提供微服务，那么这个故事肯定是致命的。
影片和幻灯片
演讲视频（〜50分钟；不幸的是，它并没有传达出访客的众多情绪，很大程度上决定了报告的气氛，但实际上）：
报告介绍：
聚苯乙烯
我们博客上的其他报告：
您可能也对以下出版物感兴趣：