Безболезненный переход на микросервисы для ИТ-компании

В данной статье мы рассмотрим вариант безболезненного перехода на более продуктивные микросервисы, который не нарушит текущую работу продукта и сам процесс его сопровождения. Стоит отметить, что мы берем в расчет ПО, которое поддерживает до 120 тыс. соединений в сутки.

Каждый программный продукт разрабатывается с учетом текущих требований для удовлетворения потенциальных клиентов. Но с течением времени, команда разработчиков должна быть готова к внедрению новых элементов или к оптимизации разработки ПО.

Большая часть ПО обладает следующей архитектурой:

Изначально, разработчики предусматривают несколько вариантов управления разработкой программного обеспечения, учитывая пользовательские сценарии. Но далеко не все из них соответствуют текущим реалиям, делая дальнейший процесс глубокой оптимизации крайне трудным.

С момента продакшна, многие сталкиваются с необходимостью решить следующие проблемы:

• Нужен способ для быстрого обновления продукта;
• Большой поток отзывов и замечаний требует оперативного отклика. В результате, появляется проблема, связанная с проведением тестов для новых наработок и исправлений;
• Не корректная работа Tomcat: session management, из-за которой случаются сбои во время соединения с приложением и восстановлением сессии;
• Нехватка физических ресурсов, в частности, сказывается на стабильности работы ПО.

Все проблемы нужно решать поэтапно, не пытаясь найти решение для всего сразу. Мы подойдем к делу, внедряя DevOps.

Внедрение первого микросервиса

Первый микросервис поможет решить проблему с изменяющимися требованиями к ПО. Попытаемся вынести определенную часть бизнес-логики, за счет отдельного war-файла, расположенного в Tomcat. Для этой цели пригодится Spring Boot.

Таким образом, мы получаем эффективный инструмент для беспрерывной работы приложения, который может обновлять указанную его часть без перезагрузки всего ПО.

В конечном итоге, разработчики смогут не беспокоиться о временной потере пользовательской активности, накатывая даже масштабные обновления для всей системы. При необходимости, они смогут создать новый микросервис для разделения оптимизируемых зон.

Проблемы с типизацией

Чем больше микросервисов, тем медленнее происходит перезагрузка Tomcat, что усложняет работу.
Это результат длительного игнорирования возникающих ошибок во время тестирования. С течением времени, их количество будет увеличиваться, а помочь в решении сможет Spring Cloud Feign, который не требует много ресурсов, самостоятельно генерирует клиента и обладает единым интерфейсом как для сервера, так и для клиента.

Решение проблемы с простоями и работоспособностью

С увеличением количества микросервисов, возникновение малейшего простоя в системе недопустимо. Поэтому, нужно оптимизировать разработку ПО.

Зачастую, все сталкиваются с простоями из-за выкатывания обновлений, перезагрузки Tomcat и во время процесса освобождения ресурсов. Выход один – изменить архитектуру и внедрить DevOps методы:

• Горизонтальное разделение приложений, за счет нескольких data-центров;
• Внедрение Filebeat;
• Установка дополнительного сервера для ELK;
• Расширение имеющихся серверов для лучшей производительности.

Эффективные инструменты:

За счет этого, приложение может продолжать работу даже в случае сбоя одного из серверов. Появились бэкапы и ускорялась сама работа во время перезагрузки. Простои отсутствуют, благодаря чему пользователь не замечает сам процесс обновления.

Консистентность данных

После изменения архитектуры, возникла проблема с консистентностью данных, из-за чего некоторые функции мониторинга отваливались, а пользователи были вынуждены ждать переключения на другой сервер.

Решение достаточно простое – разделение сервисов и хранение на отдельных серверах. Связь между ними организовывается с помощью ряда портов, указанных для модулей. С этим поможет Zuul или Eureka.

Процесс добавления идентичных сервисов на разные сервера оптимизируется за счет stateless-архитектуры, то есть, горизонтального масштабирования проекта. Такой подход позволяет уменьшить время простоя во время обновления, а также ускорить перезагрузку всех микросервисов.

Оптимизация процесса управлением информацией

Большое количество микросервисов усложняет процесс управления информацией, потому что к работе подключается все больше серверов. Для отправки одного запроса, нужно охватывать несколько систем, а это не удобно.

Решение: микросервис Hazelcast, который помогает отправлять запросы, а при продвинутой настройке, может выступить прослойкой между сервисами и БД.

Проблема с consistency решена, а любая информация может записываться одновременно на всех серверах. Hazelcast самостоятельно определяет, что и куда сохранять. Сама сессия также хранится в Hazelcast, что оптимизирует процесс авторизации и делает переход пользователя с одного сервера на другой незаметным.

Ускорение поставки сервисов

Любое обновление занимает время. И его нужно сократить. Поэтому, назревает необходимость во внедрении GitFlow. CI поможет проанализировать отдельные процессы, за счет различных способов тестирования.

Будет не лишним развернуть ряд GitLab-раннеров, работающих по команде разработчиков. Это поможет вам четко разделить имеющиеся сервера на категории:

• Develop
• QA
• Release-candidate
• Production

Таким образом, разработка делится на этапы и каждый человек в команде контролирует процесс поставки сервисов. В самом конце цепи, проводится тестирование, а затем и релиз обновления.

В случае возникновения проблем на любом из этапов, команда сможет оперативно их решить, не перенося релиз на длительный срок.

Как только разработчики будут выкладывать новые jer-ки на продакшн, команда столкнется с большими временными затратами, связанными с перезагрузкой. Лучшим решением будет полная автоматизация управления разработкой программного обеспечения.

Для этого необходимо окончательно довести все оставшиеся детали в архитектуре до stateless-модели. Это уменьшит затраты по времени на отправку запросов.

Оптимизировать и автоматизировать разработку ПО в вашей копании, а также мягко внедрить микросервисы для облегчения поддержки программного продукта поможет профессиональный DevOps инженер с опытом более 10 лет. Обращайтесь [email protected]