Эволюция декомпозиции: от Linux-серверов до Kubernetes
Что так притягивает разработчиков в микросервисах? За ними нет никакой революционной технологии, преимущества перед монолитом достаточно спорные. Только легкость, с которой современные инструменты разработки и развёртывания позволяют создать системы для запуска на тысячах серверов. Предлагаем проследить путь к настоящему моменту, когда разработка и развёртывание такой распределённой системы возможно силами одного разработчика. О том, как эволюционировали технологии виртуализации, какую роль сыграли Linux-контейнеры, Docker и Kubernetes, рассказывает Александр Трехлебов holonavt, корпоративный архитектор Промсвязьбанка, занимается разработкой ПО больше 15 лет. Начинал с C++, затем перешел на Java. В последнее время разрабатывал банковсковский бэкенд на платформе Spring Cloud.
Если вспомнить первые реализации выполнения скриптов (Java Script, VB Script) в рамках отображения страниц в браузере, то это были однопоточные последовательности инструкций. Тот же JavaScript — он однозадачный. Если в рамках одной веб-страницы выполняется JS, и в одной из исполняемых инструкций произойдет сбой или задержка, то все происходящее на странице, весь код замораживается. И сделать ничего нельзя, только закрыть или перезагрузить страницу, а иногда браузер или всю операционную систему.
Понятно, это было не очень удобно. Особенно если учесть тот факт, что многозадачность/многопоточность была уже повсюду: процессоры, операционные системы, приложения (разве только первые ОС для мобильных устройств были однозадачными), а JS как был, так и остался однопоточным. Что тогда произошло? Начали один за другим появляться различные фреймворки, так или иначе решающие эту проблему. Facebook сделал React, Google выпустил Angular.
Многозадачность штурмует фронтенд и бэкенд
Как вообще из однозадачной системы сделать многозадачную? Взять инструкции и раскидать по разным потокам, плюс, естественно, мониторить эти потоки. Наверняка вы еще помните, как в одной из версий FB вдруг появилась возможность одновременно писать сообщение и следить за изменениями ленты. И если вдруг лента падала, то сообщения продолжали работать. Именно тогда появился первый UI на модульном интерфейсе React. С помощью фреймворка многозадачность стала работать из коробки.
Какое отношение все это имеет к микросервисам? Когда UI интернет-банков стал предоставлять достаточно широкий функционал, заморозка, а тем более падение приложения стало для пользователей, можно сказать, шокирующим событием. Ведь одно дело, когда заглючил Facebook, и другое — когда вы только что сделали ипотечный взнос, а средства на счёте не отобразились, потому что произошёл сбой на форме остатков по счетам.
Возникла простая идея — независимые элементы пользовательского интерфейса, которые позволяют делать Angular и React, прикреплять к столь же независимым элементам бэкенда. Каждый независимый элемент бэкенда — это микросервис, который может масштабироваться, подниматься после сбоя и т.п.
Тут важно грамотно построить пользовательский интерфейс, чтобы он модифицировался в зависимости от доступных бэкенд-компонентов. Если у вас что-то на бэкенде не работает, то на UI вы соответствующую функциональность не показываете, либо показываете каким-то дефолтным способом — можно поменять цвет шрифта на серый или отобразить пустую плашку с надписью «Недоступна информация по остаткам на счёте. Перезвоните завтра». Собственно, такая связка элементов UI с микросервисами помогает повысить общую надежность и масштабируемость банковского приложения.
От «Титаника» до Docker
На мой взгляд, основная причина, почему микросервисы стали так популярны, несмотря на существенный расход памяти и оверхед по вычислительным мощностям — это декомпозиция. В остальном по большому счету, микросервисы не имеют больших преимуществ перед монолитом. Декомпозиция в моем понимании — это когда функционал разделен на некие независимые блоки для запуска и развёртывания. Это означает, что во время работы остальных блоков можно обновить какой-то один, зачастую не останавливая его работу (blue, green — deployment), поднять дополнительный экземпляр.
Все эти технологи появились не вчера и не позавчера. Решения для распределенных вычислений разрабатывались ещё во времена мейнфреймов, потому что нехватка вычислительных ресурсов возникла практически сразу, как только эти ресурсы появились.
Стали придумывать, как это всё рационально распределять, например графические вычисления на станциях Silicon Graphix. Стоило это всё недёшево, и такие решения были доступны только крупным организациям, не говоря уже об отдельных разработчиках. Сами станции и серверное ПО для них были очень дорогими, поэтому соответствующие возможности были разработаны для ядра Linux. Например — обсчёт компьютерной графики для сцен фильма «Титаник», который вышел ещё в 1997 году выполнялся на серверах с процессорами Alpha под управление Linux. Большинство решений, необходимых для работы распределенных систем, уже были в те времена разработаны и обкатаны. Но использовать все эти технологии одному специалисту было пока затруднительно, сборка, доставка и поддержка такой системы требовала серьёзных трудозатрат.
Сначала были просто физические сервера, которые надо как-то маршрутизировать, затем началась эра виртуализации, появились виртуальные машины, работа пошла веселей, но всё равно запуск и остановка виртуальной машины оставались довольно ресурсоемким действием. А хотелось, чтобы это происходило так же быстро, как запуск процесса внутри операционной системы. Большой шаг по выходу технологии «в народ» был связан с появлением Linux-контейнеров.
Linux-контейнер — это почти что системный процесс, но у которого есть свой сетевой интерфейс и много всякого другого, что делало его почти, что виртуальной машиной. Почему почти? Потому что виртуальная машина поднимается в достаточно изолированной среде. Linux-контейнер же использует материнскую операционную систему, внутри каждого контейнера работает своя версия ОС Linux, однако системные вызовы транслируются в ядро материнской ОС.
В этом есть свои плюсы — при создании LXC-контейнера не надо заново поднимать ядро. Однако работа с LXC-контейнерами в их первозданном виде была весьма трудоёмкой и неудобной. Собственно в какой-то момент появился Docker. Это решение взяло на себя все заботы по развертыванию и управлению Linux-контейнерами, выставив более удобный интерфейс.
Появление Docker стало толчком для широкомасштабного распространения микросервисной архитектуры. Да, технологии были придуманы уже давно, но возможность их удобного использования появилась только в этот момент. Сейчас, используя Docker, разработчик буквально парой команд может поднять несколько виртуалок и организовать распределенную вычислительную систему, а после динамически ее обновлять и масштабировать.
Так, возможности декомпозиции позволили широкому кругу разработчик превращать монолит в набор микросервисов внутри контейнеров. Однако, тут возникли новые трудности. Когда контейнеров несколько десятков и они разбросаны по нескольким серверам, нужно как-то управлять ими, сопровождать, выполнять их оркестрацию. Здесь уже появились такие решения, как Docker Swarm и Kubernetes. Индивидуальный разработчик получил новый мощный инструмент.
Микросервисы в банках
Как обстоит дело с микросервисами в банковской отрасли? Сколько их, например, требуется для поддержки онлайн-банкинга? Есть хороший пример: в Великобритании работает полностью цифровой банк — Monzo, у него нет ни бэкофиса, ни отделений, ни сайта, он весь по сути в мобильном приложении. Там всё начиналось с 40 микросервисов, затем их число выросло до 300, сейчас уже больше.
Если посмотреть на внедрения в Промсвязьбанке, то у нас есть системы, где развёрнуто до 40 микросервисов.
Параллельно развиваются и системы разработки, которые позволяют с помощью нескольких строк кода разрабатывать основные компоненты микросервисной системы, которые можно достаточно просто масштабировать и обновлять. Все эти возможности очень востребованы при построении систем с машинным обучением, анализом больших объёмов данных в режиме реального времени (Cloud Streaming и т.п.).
О своём опыте разработки на базе микросервисной архитектуры, Александр Трехлебов расскажет в докладе «Микросервисы — отказоустойчивость на основе сквозной модульности» на Фестивале интернет-деятелей 404, который состоится 6–7 октября 2018 года в Самаре.
