В данной статье мы рассмотрим вариант безболезненного перехода на более продуктивные микросервисы, который не нарушит текущую работу продукта и сам процесс его сопровождения. Стоит отметить, что мы берем в расчет ПО, которое поддерживает до 120 тыс. соединений в сутки.nnКаждый программный продукт разрабатывается с учетом текущих требований для удовлетворения потенциальных клиентов. Но с течением времени, команда разработчиков должна быть готова к внедрению новых элементов или к оптимизации разработки ПО.nnБольшая часть ПО обладает следующей архитектурой:
nn
nnИзначально, разработчики предусматривают несколько вариантов управления разработкой программного обеспечения, учитывая пользовательские сценарии. Но далеко не все из них соответствуют текущим реалиям, делая дальнейший процесс глубокой оптимизации крайне трудным.nnС момента продакшна, многие сталкиваются с необходимостью решить следующие проблемы:n
- Нужен способ для быстрого обновления продукта;
- Большой поток отзывов и замечаний требует оперативного отклика. В результате, появляется проблема, связанная с проведением тестов для новых наработок и исправлений;
- Не корректная работа Tomcat: session management, из-за которой случаются сбои во время соединения с приложением и восстановлением сессии;
- Нехватка физических ресурсов, в частности, сказывается на стабильности работы ПО.
Все проблемы нужно решать поэтапно, не пытаясь найти решение для всего сразу. Мы подойдем к делу, внедряя DevOps.n
Внедрение первого микросервиса
Первый микросервис поможет решить проблему с изменяющимися требованиями к ПО. Попытаемся вынести определенную часть бизнес-логики, за счет отдельного war-файла, расположенного в Tomcat. Для этой цели пригодится Spring Boot.nn
nnТаким образом, мы получаем эффективный инструмент для беспрерывной работы приложения, который может обновлять указанную его часть без перезагрузки всего ПО.nnВ конечном итоге, разработчики смогут не беспокоиться о временной потере пользовательской активности, накатывая даже масштабные обновления для всей системы. При необходимости, они смогут создать новый микросервис для разделения оптимизируемых зон.n
Проблемы с типизацией
Чем больше микросервисов, тем медленнее происходит перезагрузка Tomcat, что усложняет работу.nЭто результат длительного игнорирования возникающих ошибок во время тестирования. С течением времени, их количество будет увеличиваться, а помочь в решении сможет Spring Cloud Feign, который не требует много ресурсов, самостоятельно генерирует клиента и обладает единым интерфейсом как для сервера, так и для клиента.n
Решение проблемы с простоями и работоспособностью
С увеличением количества микросервисов, возникновение малейшего простоя в системе недопустимо. Поэтому, нужно оптимизировать разработку ПО.nn
nnЗачастую, все сталкиваются с простоями из-за выкатывания обновлений, перезагрузки Tomcat и во время процесса освобождения ресурсов. Выход один – изменить архитектуру и внедрить DevOps методы:n
- Горизонтальное разделение приложений, за счет нескольких data-центров;
- Внедрение Filebeat;
- Установка дополнительного сервера для ELK;
- Расширение имеющихся серверов для лучшей производительности.
Эффективные инструменты:
nnЗа счет этого, приложение может продолжать работу даже в случае сбоя одного из серверов. Появились бэкапы и ускорялась сама работа во время перезагрузки. Простои отсутствуют, благодаря чему пользователь не замечает сам процесс обновления.n
Консистентность данных
После изменения архитектуры, возникла проблема с консистентностью данных, из-за чего некоторые функции мониторинга отваливались, а пользователи были вынуждены ждать переключения на другой сервер.nnРешение достаточно простое – разделение сервисов и хранение на отдельных серверах. Связь между ними организовывается с помощью ряда портов, указанных для модулей. С этим поможет Zuul или Eureka.nnПроцесс добавления идентичных сервисов на разные сервера оптимизируется за счет stateless-архитектуры, то есть, горизонтального масштабирования проекта. Такой подход позволяет уменьшить время простоя во время обновления, а также ускорить перезагрузку всех микросервисов.n
Оптимизация процесса управлением информацией
Большое количество микросервисов усложняет процесс управления информацией, потому что к работе подключается все больше серверов. Для отправки одного запроса, нужно охватывать несколько систем, а это не удобно.nnРешение: микросервис Hazelcast, который помогает отправлять запросы, а при продвинутой настройке, может выступить прослойкой между сервисами и БД.nn
nnПроблема с consistency решена, а любая информация может записываться одновременно на всех серверах. Hazelcast самостоятельно определяет, что и куда сохранять. Сама сессия также хранится в Hazelcast, что оптимизирует процесс авторизации и делает переход пользователя с одного сервера на другой незаметным.n
Ускорение поставки сервисов
Любое обновление занимает время. И его нужно сократить. Поэтому, назревает необходимость во внедрении GitFlow. CI поможет проанализировать отдельные процессы, за счет различных способов тестирования.nn
nnБудет не лишним развернуть ряд GitLab-раннеров, работающих по команде разработчиков. Это поможет вам четко разделить имеющиеся сервера на категории:n
- Develop
- QA
- Release-candidate
- Production
Таким образом, разработка делится на этапы и каждый человек в команде контролирует процесс поставки сервисов. В самом конце цепи, проводится тестирование, а затем и релиз обновления.nn
nnВ случае возникновения проблем на любом из этапов, команда сможет оперативно их решить, не перенося релиз на длительный срок.nnКак только разработчики будут выкладывать новые jer-ки на продакшн, команда столкнется с большими временными затратами, связанными с перезагрузкой. Лучшим решением будет полная автоматизация управления разработкой программного обеспечения.nnДля этого необходимо окончательно довести все оставшиеся детали в архитектуре до stateless-модели. Это уменьшит затраты по времени на отправку запросов.n
Оптимизировать и автоматизировать разработку ПО в вашей копании, а также мягко внедрить микросервисы для облегчения поддержки программного продукта поможет профессиональный DevOps инженер с опытом более 10 лет. Обращайтесь [email protected]