В предыдущем посте мы рассказали, как облачные сервисы превратились в негласный стандарт предоставления ИТ-услуг. Нетрудно догадаться, что компании, которые желают по-прежнему зарабатывать на пользовательских приложениях, должны адаптировать и создавать новые продукты с учетом Cloud-Native подхода. Впрочем, для разработчиков это однозначно позитивная новость, поскольку использование облачных технологий открывает для них огромные новые возможности. Главное уметь ими правильно распорядиться.
Когда приложение заказывает окружение
Если вы уже читали гид по облачным технологиям, то наверняка помните, что одним из «источников магии» облаков является технология виртуализации. Благодаря этому разработчику практически не нужно задумываться о параметрах серверов, на которых будет работать его приложение. Зачем тратить на это время, если правильно настроенный гипервизор или контейнер могут сконфигурировать машину с практически любыми характеристиками, которые нужны приложению для работы?
Развитием этой идеи является подход Infrastructure as code (IAC). Его суть в том, чтобы дать возможность разработчикам или службам эксплуатации применять для обслуживания инфраструктуры такие же подходы, которые используются на этапе разработки. Он позволяет готовить общие программные блоки управления заранее и легко осуществлять интеграцию таких компонентов в новых проектах.
Возможности современных ЦОДов уже позволяют переходить к декларативному языку управления инфраструктурой. В идеале, приложение должно само администрировать занимаемый им пул ресурсов в дата-центре. Это позволит разработчику не быть запертым в ограничениях, связанных с процессом работы с инфраструктурой, когда надо заказывать и проектировать наперед или если одни и те же компоненты инфраструктуры повторяются в разных проектах.
Фактически разработчик или инженер делает Pull Request, в котором находится конфигурация виртуальной машины (ядра, память, сеть, шаблон и т.д.), далее менеджер виртуального окружения самостоятельно создает машину или создает новый инстанс базы данных или стартует предустановленный сервис, согласно настройкам в файле. Такой подход — настоящее спасение при работе с большими данными и нейронными сетями. Приложения, связанные с этими технологиями, в некоторых случаях нуждаются в динамически изменяемых объемах памяти и процессорных мощностей.
Например, для обучения сети необходимо «прогнать» через нее сотни гигабайт информации, и облака позволяют получить необходимые для этого мощности по запросу. После того, как обучение будет завершено, ресурсы возвращаются в пул провайдера, а разработчику не нужно думать, чем их занять или как по-другому сконфигурировать приложение, чтобы оно продолжало работу на меньшем объеме мощности.
Монолит vs. упорядоченный хаос
Благодаря тому, что облака умеют эластично подстраиваться под потребности разработчика, это, теоретически, упрощает еще одну задачу – проблему масштабирования приложений. Почему теоретически?
К сожалению, задача по масштабированию приложений не является линейной. Чтобы приложение справлялось с огромными нагрузками в периоды пиковой посещаемости (или вычислений), недостаточно просто давать ему дополнительную память и процессорные мощности. Абсолютно у каждого традиционного приложения есть порог, после которого оно уже не в состоянии «переварить» новые ресурсы и продемонстрировать рост производительности. Проблема в данном случае состоит не в ресурсах, а в самой архитектуре большинства программ.
Особенно остро эта проблема стоит для приложений с монолитной архитектурой, которые, фактически, представляют собой единые бинарные файлы. Достоинства такого подхода очевидны: монолитные приложения достаточно просты и линейны. Все сценарии поведения пользователя можно предсказать, отследить и при необходимости произвести отладку бага.
Однако у такой простоты есть цена. Во-первых, это уже упомянутые выше проблемы с масштабированием. В какой-то момент даже самое продуманное монолитное приложение перестает работать эффективнее от апгрейда конфигурации сервера на котором оно исполняется.
Во-вторых, монолитное приложение не так-то просто перенести на новые сервера и для этого может потребоваться полная перекомпиляция программы.
В-третьих, такое приложение сложно поддерживать и развивать. Любое обновление превращается требует полной сборки всей программы, и ошибка в одном из блоков кода может обернуться падением всей системы.
В поисках идей, как решить эти проблемы была разработана другая концепция – service-oriented architecture (SOA). Она подразумевает, что приложение разделено на несколько модулей, каждый из которых предоставляет другим какую-то функциональность. Между собой модули взаимодействуют через набор веб-служб, и независимо друг от друга могут обращаться к единой или к собственным базам данных.
Такой подход действительно упрощает поддержку программы и не превращает ее обновление «в работу сапера», в которой нет права на ошибку; но и у него есть свои недостатки. Ключевой из них – проблемы с масштабированием разработки таких приложений. По мере роста программы, новые функции становится все сложнее «запихивать» в изначально утвержденные архитектором 5-10 пакетов. Их число становится все больше, что оборачивается проблемами с поддержкой.
Микросервис как элемент эволюции приложения
Результатом эволюции SOA стала идея микросервисной архитектуры, которая и используется при конструировании облачных приложений. Концептуально идеи обоих подходов крайне схожи, и некоторые архитекторы даже не выделяют микросервисную архитектуру в отдельную парадигму, считая ее частным случаем SOA.
Микросервисная архитектура подразумевает, что приложение состоит не из какого-то небольшого количества крупных модулей, а из множества независимых друг от друга частей. В отличие от монолита, в микросервисном приложении можно использовать различные способы взаимодействия компонентов между собой. У системы нет единого, заранее определенного состояния. Вместо этого каждый компонент работает «по ситуации»: как только ему поступает событие он начинает работу. Это позволяет делать очень гибкую и независимую архитектуру.
При этом число сервисов в микросервисном приложении постоянно меняется – какие-то добавляются, какие-то удаляются. В новом подходе можно любой микросервис заменить и вместо него встроить цепочку микросервисов. Другие сервисы продолжают стабильно работать, потому что не связаны напрямую между собой. Такова естественная эволюция программы. Благодаря этому у разработчиков и архитекторов появляется возможность быстро что-то менять, чтобы реагировать на изменения бизнес-требований и опережать конкурентов.
Помимо повышения скорости выпуска обновлений использование микросервисной архитектуры позволяет добиться децентрализации управления. Команда, которая отвечает за разработку того или иного сервиса, сама вправе определять его внутреннюю архитектуру и его особенности. Такой подход, кстати, сейчас в Блоке Технологии внедряет Архитектурный совет Сбербанка.
При этом садясь за разработку своего облачного приложения не следует спешить со скорейшим дроблением его на составные элементы. Главный противник подобного бездумного подхода — Мартин Фаулер; он же – один из авторов идеи микросервисной архитектуры. Проще изначально использовать монолитный подход, и потом стимулировать эволюцию приложения «естественным образом», ориентируясь на расшивку узких мест и добавление дополнительных функций.
В результате можно сформулировать следующее правило: задача программиста при работе с микросервисной архитектурой – не просто разбить приложение на максимальное количество составных частей, а разумным образом разграничить их ответственность за получение и обработку данных.
Четыре детали
Помимо множества очевидных достоинств, у микросервисной архитекутуры есть свои особенности, которые необходимости учитывать при разработке своего облачного приложения. В частности, для поддержки работы такого приложения необходимо постоянно поддерживать повышенные требования к качеству управления внутренними API.
Когда один из компонентов меняет свой интерфейс, он должен поддерживать обратную совместимость, чтобы поддерживать прошлую версию собственного API. Если это правило соблюдается, можно динамично переключаться со старой версии на новую без сбоев работе. Если же поддержка прежней версии API не проработана, то это грозит в лучшем случае, потерей части функциональности приложения, а в худшем – постоянными сбоями в его работе.
Вторая важная особенность микросервисных приложений заключается в сложностях поиска в них багов. Если «падает» приложение, написанное в монолитной логике или SOA, найти источник проблемы не составит труда. В приложении, состоящем из множества сервисов, поиск причины бага может сильно затянуться из-за того, что данные от пользователя нередко проходят обработку через несколько микросервисов, и сложно определить, в каком именно из них происходит сбой. При этом процесс поиска бага нужно вести очень аккуратно: любой неудачный рефакторинг может привести к поломке работающего модуля, и в дополнение к первоначальной проблеме разработчик получит вторую.
Третья важная деталь, которую необходимо учитывать, разрабатывая облачное приложение – способ взаимодействия его составных частей между собой. Как и в SOA, для обмена данными сервисы используют веб-службы, но в микросервисной архитектуре появились паттерны взаимодействия, например, как streaming, CQRS, Event sourcing. Обычно разработчики рассчитывают, что время отклика между запросом и ответом в приложении достаточно небольшое. В распределенной системе нельзя полагаться даже на то, что ответ вообще придет.
Так же в архитектуре облачных приложений микросервисы используют различные базы данных, наиболее оптимально подходящие для решения их конкретных задач. Например, гриды могут быстро читать, но с трудом справляются с большим количеством операций по изменениям данных. Такая база хорошо подойдет для ведения счетов вкладов – они редко изменяются. Другой тип операций – процессинг; в нем ежедневно по каждой карте могут быть десятки изменений, а чтений данных наоборот мало.
Наконец, четвертый факт, о котором нужно помнить при разработке облачного приложения – микросервисная архитектура ориентирована в первую очередь на использование сервисов без поддержки состояний. При этом не стоит впадать в крайности. Некоторые сервисы, при необходимости, все же могут осуществлять поддержку состояния, если того требует бизнес-логика, и они должны быть спроектированы особенно тщательно.
Например: если пользователь делает запрос на получение кредита, то получившая заявку система должна это состояние сохранить, чтобы передать его другим сервисам. А вот сервис, отвечающий за поиск информации во внутренней картотеке кредитных историй, может не сохранять состояние и забыть о том, данные на какого именного пользователя он искал пару минут назад – все равно уже через мгновенье ему придет новый запрос (хотя и в этом процессе может быть различное поведение сервиса).
Все описанные выше примеры и практики уже активно используются лидерами мировой ИТ-отрасли. Например, пионером в развитии микросервисной архитектуры является Netflix. Компания выпустила множество open-source приложений, библиотек и фреймворк для мониторинга, балансировки и логирования запущенных микросервисных приложений.
Автор: Sberbank
