Разработка микросервисов

Мы обеспечим успешный переход вашей системы или монолитных приложений на микросервисы при минимальном простое системы.

Ukrsibbank
Kisel
Realogy
rbs
aig
Kovsh, Alexey

Алексей Ковш

Архитектор
программных решений

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

Микросервисы. Подход к разработке

Если на выходе вы хотите получить эффективную микросервисную архитектуру, проект по разделению монолита на микросервисы должен предполагать следующие основные шаги.

  1. Анализ состояний — мы исследуем текущую архитектуру монолита и определяем первых кандидатов в микросервисы. Уточняется и согласовывается новая микросервисная архитектура.

  2. Построение инфраструктуры — команда подготавливает инфраструктуру виртуализации, систему оркестровки контейнеров, CI/CD-инструменты и внутренний репозиторий артефактов.

  3. Этап разработки — мы внедряем различные микросервисы с использованием определенной дорожной карты и помещаем их в новую инфраструктуру.

  4. Развертывание — наши DevOps-инженеры развертывают новую систему с микросервисами на предпроизводственном и производственном этапах.

  5. Сопровождение и поддержка микросервисной инфраструктуры.

При переходе на микросервисы используются разные модели развертывания. Выбор зависит от специфики проекта.

Однократная миграция (SADT)

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

Такая работа с микросервисами позволяет лучше проанализировать будущий проект и снизить на него затраты (за счет оптимизации ресурсов команды). Кроме того, на начальном этапе в данном случае требуется меньшее число разработчиков, а на этапе внедрения — более низкая квалификация инженеров (затраты).

Поэтапная миграция

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

Данный подход к разбиению монолитной структуры рассчитан на краткосрочный результат. Мы не тратим много времени на детальный анализ монолита и предварительную разработку архитектурного стиля. Вместо этого мы беремся за 1–2 слабо связанных друг с другом сервиса и перемещаем их в микросервисную архитектуру, создавая для этого необходимую инфраструктуру. Процесс разделения выглядит как постепенный переход на микросервисы.

Этот вариант характерен для монолитного ПО, в которое внедряют новые функции (большинство проектов продуктовой разработки).

Мы будем рады ответить на все ваши вопросы по реализации вашего видения микросервисной архитектуры.

С чего начать процесс разбиения
на микросервисы

Service Team (Micro-team) – group of engineers who already worked together and know how to do certain task/project.Service Team (Micro-team) – group of engineers who already worked together and know how to do certain task/project.

Ky-ky, я дропдаун

Ky-ky, я дропдаун

Ky-ky, я дропдаун

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

Выявление компонентов
без сохранения состояния

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

Функциональное
разбиение сервисов

- Сервисы, работающие с внешними системами (шлюзы, модули платежей)
- Сервер аутентификации
- Модуль уведомлений

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

Логическая схема архитектуры

Промежуточное состояние (после разбиения 1–2 сервисов)

Та же микросервисная архитектура с коммуникационным слоем

Если имеющийся код подходит для создания микросервисов, мы используем его повторно по максимуму. Это определенно позволит вам сократить расходы на разработку и тестирование.

Наши команды

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

Командная работа — управление задачами, качество, результаты и т. д.

Service Team (Micro-team) – group of engineers who already worked together and know how to do certain task/project.Service Team (Micro-team) – group of engineers who already worked together and know how to do certain task/project.

Члены команды работали вместе минимум над
2 проектами

Ky-ky, я дропдаун

Специализация команды на конкретных типах задач

Ky-ky, я дропдаун

Наличие бизнес-экспертизы в определенных сферах

Ky-ky, я дропдаун

Структура проектной команды

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

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

Мы можем выслать вам несколько профилей наших команд в течение 3 рабочих часов с момента вашего запроса.

Техническая экспертиза

Монолит сложно разделить без запуска проекта по созданию инфраструктуры. Для нормального функционирования микросервисам необходима особая среда, которая позволит реализовать все плюсы архитектуры при раздельном развертывании микросервисов. Рекомендуем продумать следующие компоненты:

Оркестрация
(Kub8s, Docker и т. д.)

Процессы
DevOps и CI/CD

API
Gateway

Контроль
работоспособности

Коммуникация
между микросервисами

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

Разделение системы цифрового банкинга на микросервисы

Разделение системы цифрового банкинга на микросервисы

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

Технологический стек

У нас обширный опыт применения новейших инструментов и технологий, которыми мы владеем на профессиональном уровне.

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

Облачные технологии

MS Azure, AWS (Amazon Web Services), GCP (Google Cloud Platform)

API Gateway

Ocelot, Tyk, Nginx; облачные технологии: AWS API Gateway, Azure API Management, GCP API Gateway

DevOps-инструменты

Ansible, Helm

CI/CD-инструменты

Jenkins, Thoughtworks GoCD, TeamCity; облачные технологии: Azure DevOps

Контроль работоспособности, логирование

Prometheus/Grafana, Elastic Stack (Elasticsearch + Kibana), Zabbix, Logstash

Контейнеры (оркестрация)

Kubernetes, Docker Swarm, MS Service Fabric; облачные аналоги: Azure AKS, Azure Service Fabric, AWS EKS, Google GKE и т. д.

Обмен сообщениями

Apache Kafka, Rabbit MQ, Active MQ, MS SQL SSBS; облачные аналоги: AWS SQS, Azure Service Bus, GCP Pub/Sub и т. д.

Эталонная микросервисная архитектура

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

Структура отдельных микросервисов

Типичный микросервис имеет следующую архитектуру высокого уровня.

Нам это нужно для оценки вашего проекта

Архитектура текущей системы и описание технического проекта

Технические документы, описывающие архитектуру программного обеспечения, включая логику и развертывание, список технологий, UML/DFD/сетевые диаграммы (при наличии)

Функциональные модули
и требования

Спецификации требований к программному обеспечению (SRS) или то или иное высокоуровневое иерархическое представление функциональных модулей и функций

Нефункциональные требования к текущей и планируемой системам

Технические требования как к текущим, так и к новым системам, такие как Соглашение об уровне обслуживания (SLA), производительность, доступность, надежность, масштабируемость (горизонтальная, вертикальная), целостность данных и т. д.

Доступ к исходному коду
(опционально)

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

Если у вас нет указанной выше информации — не беспокойтесь. Наши архитекторы найдут выход.

Еще немного про микросервисы

Сокращение времени выхода
на рынок

Разделение монолитной архитектуры означает, что каждый из микросервисов становится проще тестировать и использовать. Это обеспечивает быструю разработку и частое независимое развертывание с использованием CI/CD-процесса.

Параллельная реализация микросервисов

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

Упрощение регрессионного тестирования

Вам не нужно проводить комплексное регрессионное тестирование всей системы, когда в код вносятся какие-либо изменения: для проверки нужен только измененный сервис (если API согласован).

Эффективная локализация неисправностей

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

Мы не исключаем, что работа над микросервисами может сопровождаться определенными трудностями. Свяжитесь с нами, и мы проконсультируем вас по техническим аспектам реализации микросервисов.

Контакты

 Я даю свое согласие на сбор и обработку моих личных данных в соответствии с Политикой конфиденциальности Qulix Systems.*

 Я согласен(-а) на получение новостей от Qulix Systems.

Спасибо, !

Спасибо, что выбрали нас!
Наш специалист скоро с вами свяжется.

На главную

Просто заполните контактную форму, и мы свяжемся с Вами как можно скорее.

Телефон: +7 495 646 03 34
E-mail: request@qulix.com

Спасибо!

Спасибо, что выбрали нас!
Наш специалист скоро с вами свяжется.

На главную

Заполните эту контактную форму, и мы свяжемся с вами как можно скорее.

Телефон: +7 495 646 03 34
E-mail: request@qulix.com