是什么吸引了开发人员这么多的微服务？ 它们背后没有革命性的技术；相对于整体而言，其优势颇具争议。 只有借助现代开发和部署工具的简便性，您才能创建可在数千台服务器上运行的系统。 我们建议当一个开发人员有可能开发和部署这种分布式系统时，追溯到现在的道路。 Promsvyazbank的企业架构师Alexander Trekhlebov holonavt说，关于Linux容器，Docker和Kubernetes的发展方式，Linux容器，Docker和Kubernetes所扮演的角色，已经开发软件超过15年了。 从C ++开始，然后切换到Java。 最近，他在Spring Cloud平台上开发了银行后端。
如果我们在浏览器中显示页面时回顾脚本执行的第一个实现（Java Script，VB Script），则这些是单线程指令序列。 相同的JavaScript-它是单任务处理。 如果在一个网页的框架内执行JS，并且其中一个可执行指令失败或延迟，则页面上发生的所有事情都将被冻结。 而且您什么也做不了，只是关闭或重新加载页面，有时甚至是浏览器或整个操作系统。
显然，这不是很方便。 特别是当您考虑到多任务/多线程已经无处不在的事实时：处理器，操作系统，应用程序（除非用于移动设备的第一个OS是单任务的），而JS仍然是单线程的。 那怎么了 解决这个问题的各种框架开始陆续出现。 Facebook制造了React，谷歌发布了Angular。
多任务风暴前端和后端
如何从单任务系统进行多任务处理？ 听取指示并分散在不同的流中，当然，还要监视这些流。 当然，您仍然记得在其中一个FB版本中突然出现了同时写入消息和监视磁带中的更改的功能。 如果磁带突然掉下来，则消息继续起作用。 那时，第一个UI出现在React模块化界面上。 在该框架的帮助下，多任务开箱即用。
这一切与微服务有什么关系？ 当互联网银行的用户界面开始提供相当广泛的功能时，冻结，甚至更糟糕的是，应用程序的崩溃对于用户来说都是一个令人震惊的事件。 毕竟，当Facebook陷入困境时，这是一回事，而当您刚进行抵押付款时，您的帐户中的资金却没有出现，这是一回事，因为帐户余额形式出现了问题。
一个简单的想法出现了-独立的用户界面元素，该元素允许将Angular和React附加到同样独立的后端元素。 每个独立的后端元素都是微服务，可以在发生故障后进行扩展，提升等。
正确构建用户界面非常重要，以便可以根据可用的后端组件对其进行修改。 如果后端无法正常工作，则您不会在用户界面上显示相应的功能，或者以某种默认方式显示它-您可以将字体颜色更改为灰色或显示带有“帐户信息不可用”字样的空盘子。 明天回电 “实际上，UI元素与微服务的这种组合有助于提高银行业务应用程序的整体可靠性和可伸缩性。
从泰坦尼克号到Docker
我认为，尽管显着消耗了内存并增加了计算能力，但微服务如此流行的主要原因是分解。 其余的微服务总体上没有整体优势。 以我的理解，分解是指将功能划分为某些独立的模块以进行启动和部署。 这意味着，当其余的块正常工作时，可以在不停止其工作的情况下对其进行更新（蓝色，绿色-部署），并引发另一个实例。
所有这些技术人员都不是昨天，也不是前天。 分布式计算解决方案是在大型机时代开发的，因为一旦这些资源出现，计算资源的短缺就会立即出现。
他们开始研究如何合理地分配所有这些信息，例如Silicon Graphix工作站的图形计算。 这一切都是昂贵的，而且此类解决方案仅适用于大型组织，更不用说单个开发人员了。 工作站本身和用于它们的服务器软件非常昂贵，因此针对Linux内核开发了相应的功能。 例如，1997年发行的电影《泰坦尼克号》的场景的计算机图形计算是在装有运行Linux的Alpha处理器的服务器上执行的。 当时，已经开发并测试了分布式系统操作所需的大多数解决方案。 但是，一个专家仍然很难使用所有这些技术，这种系统的组装，交付和支持需要大量的人工成本。
最初，只有物理服务器需要以某种方式进行路由，然后虚拟化时代开始了，虚拟机出现了，工作变得更加有趣，但是启动和停止虚拟机仍然是一项非常耗费资源的操作。 我希望它能够像在操作系统内部启动进程一样快。 Linux容器的出现与向人们“释放”技术迈出了一大步。
Linux容器几乎是一个系统进程，但是它具有自己的网络接口，其功能使其几乎像虚拟机一样。 为什么差不多？ 因为虚拟机在相当隔离的环境中运行。 Linux容器使用父操作系统，每个容器都有其自己的Linux OS版本，但是系统调用会广播到父OS的内核。
这有其优点-创建LXC容器时，您无需重新提升内核。 但是，使用原始形式的LXC容器非常耗时且不便。 实际上在某个时候出现了Docker。 这个决定花了部署和管理Linux容器的所有工作，并公开了更方便的界面。
Docker的出现是微服务架构广泛传播的动力。 是的，这项技术发明了很长时间，但是仅在此刻才出现方便使用的可能性。 现在，使用Docker，开发人员可以将几个虚拟机与几个命令配对，并组织一个分布式计算系统，然后动态地更新和扩展它。
因此，分解功能允许大量开发人员将整体组件转换为容器内的一组微服务。 但是，这里出现了新的困难。 当有几十个容器并且它们分散在多个服务器上时，您需要以某种方式管理它们，陪伴它们，执行它们的编排。 诸如Docker Swarm和Kubernetes之类的解决方案已经出现在这里。 单个开发人员收到了一个新的强大工具。
银行中的微服务
银行业的微服务情况如何？ 例如，需要多少支持在线银行业务？ 有一个很好的例子：在英国，有一家完全数字化的银行-Monzo，它没有后台，没有分支机构，没有网站，基本上所有的东西都在移动应用程序中。 一切始于40种微服务，然后它们的数量增加到300种，现在更多。
如果您看一下Promsvyazbank中的实现，那么我们将部署多达40个微服务的系统。
同时，正在开发一些开发系统，这些开发系统允许使用几行代码来开发微服务系统的主要组件，这些组件可以非常简单地进行缩放和更新。 所有这些功能在构建机器学习系统，实时分析大量数据（云流等）中非常流行。
亚历山大·特列赫列波夫（Alexander Trekhlebov）将在2018年10月6日至7日在萨马拉举行的404 Internet Workers Festival上的报告“微服务-基于端到端模块化的容错能力”中讲述基于微服务架构的开发经验。