Лично я сталкивался с тем, как крупные компании разрезают монолит на микросервисы, но потом не используют их повторно.
Они продолжают жить в той же системе.
Здесь мы делаем микросервисы не ради микросервисов, а разрезаем наши монолиты на работоспособные части.
То есть рефакторили кусок, и продакшен с ним работает. На каждого – около 3 месяцев.
Правда, при таком подходе есть риск налететь на ситуацию, когда микросервисы получаются КАК ЕСТЬ, а не в общей идее архитектуры.
В плане поддержки потом их совокупность не лучше монолита.
В общем, расскажу, как на практике распиливают огромные монолиты, контролирующие весь производственный цикл.
А размеры все те же: НЛМК — гигант. Мы производим 20% российской стали и входим в ТОП-20 по объемам производства в мире.
Сейчас идет миграция, мы делаем ее послойно уже чуть больше года.
Быстрее, чем за 5 лет, еще никто не делал, а это считается быстро.
Посмотрим, как у нас дела.
Архитектуру и требования к ней мы продумали сразу.
Правда, никто не обещал, что архитектура по ходу дела не изменится.
Оказалось, что выявить универсальные части инфраструктуры немного сложнее, чем нарисовать архитектуру на бумаге.
Оказалось, что где-то мы выделили функциональные блоки, а где-то сделали послойную миграцию (например, замену фасада).
При этом у нас много проектов на разных стадиях производства, и у каждой команды свой монолит. Мы ожидали, что в итоге получим синергетический эффект от параллельной работы команд, но на самом деле каждая команда делает свой функционал самостоятельно, часто не обращая внимания на то, что мы рассчитываем на общее повторное использование микросервисов.
Ребятам проще сделать компонент внутри своего проекта, который по идее должен быть общим.
Например, есть библиотека справочной информации (нормативная документация), которую проще создать в рамках проекта, чем продумывать универсальную составляющую.
Вот как каждый строит свой велосипед. Боль состоит в том, чтобы затем собрать эти велосипеды в универсальные компоненты.
Наши монолиты
Для управления производством такого масштаба неизбежно необходимы большие информационные системы.Мы подошли к началу цифровой трансформации с большим количеством монолитов, реализованных на уровне базы данных Oracle. В качестве «фронтенда» использовались Oracle Forms с интерфейсом из 90-х.
Надо сказать, что некоторые разделы кодекса являются настоящим антиквариатом.
Ни о каких системах контроля версий или совместной работы, естественно, речи не шло.
Поддержка таких систем требовала самоотверженной работы десятков специалистов, и все знания находились в их головах.
Производственный процесс Группы НЛМК охватывает множество предприятий на разных континентах, и каждый цех имел свою информационную систему со своими особенностями.
Эти системы взаимодействовали, используя как шину данных на базе Kafka, так и обычный DBLink. 
Схема производственного процесса на липецкой площадке НЛМК https://studfile.net/preview/5990480/ На этом этапе основными объектами трансформации являются MES (manufacturing Execution system) – системы управления производством.
Они располагаются между уровнями систем управления процессами (датчики, исполнительные механизмы, контроллеры) и уровнем ERP (такие системы, как SAP и 1С).
В нашем случае это аналитические и учетные системы на уровне цеха.
Структура систем управления производством В качестве новой целевой системы был выбран микросервисный подход на основе стека Java, в частности Spring, как фреймворк, реализующий множество возможных интеграций и позволяющий быстро создавать запускаемые сервисы на Spring Boot. Микросервисы позволяют осуществлять самостоятельную работу над отдельными частями системы и добиваться эффективного масштабирования тех областей, которые испытывают большие нагрузки.
В отличие от многих проектов, где микросервисы делаются ради микросервисов, мы ставим перед собой задачу фактически повторно использовать их на разных системах, чтобы уменьшить объём кода и упростить дальнейшую разработку и поддержку систем.
Как говорится, DRY в лучшем виде.
Но такой подход сопряжен и с трудностями, с которыми мы неизбежно столкнулись.
Врезка в микросервисы
Для запуска сервисов приложений мы развернули «единую цифровую платформу» (UDP) как набор инфраструктурных сервисов от хранения кода и CI/CD в GitLab до запуска в Openshift, сбора логов и мониторинга.
Общая структура единой цифровой платформы (ОДП) НЛМК Использование инструментов EDS для наших сервисов определяется уровнем зрелости разработки.
Начиная от хранения кода в GitLab и заканчивая сбором инфраструктурных и бизнес-метрик на продакшене.
Этапы зрелости разработки сервиса Чтобы получить синергетический эффект от использования одних и тех же микросервисов в разных системах, их необходимо использовать повторно.
Этого легче достичь, когда система разрабатывается с нуля и имеется достаточно времени на проектирование.
Но когда в разных воркшопах параллельно выполняется несколько проектов, и у каждого свои сжатые сроки, может оказаться, что каждый проект разрабатывает собственную реализацию микросервиса.
Большая часть конкретной бизнес-логики находится в уникальных сервисах, но есть и сервисы, которые можно эффективно использовать повторно.
Например, сервисы отчетов, информационных панелей, нормативно-справочной информации (RNI) и т. д. Такие сервисы приходится связывать между несколькими проектами.
Теперь мы пришли к модели, в которой каждый сервис сначала разрабатывается в рамках одного проекта, а затем повторно используется другими.
Возможно, в идеале это будет что-то другое.
Чаще всего первая команда становится техническим владельцем сервиса и отвечает за его развитие.
Задача параллельной разработки на нескольких проектах Другой подход — когда мы используем горизонтальные сервисы, экземпляры которых могут напрямую использоваться несколькими проектами.
И опять же примером является служба справочной информации (RNI), которую могут использовать многие системы.
При таком подходе услуги рождаются внутри проектных команд. Минус в том, что эти команды потом перейдут к другим проектам — у них не будет времени на ранее разработанный сервис.
Мы стремимся к выявлению отдельных сервисных команд, которые бы занимались осознанным проектированием и развитием сервиса с учетом его широкого использования.
Важен уровень критичности сервиса и отдельной системы: сервис не может быть менее критичным, чем любая из систем, которые его используют. В противном случае необходимо вводить дополнительные элементы системы, которые обеспечат ее работу в случае низкой доступности горизонтального сервиса.
Применение горизонтальных сервисов Мы также разработали несколько подходов к переходу на микросервисы.
Один из них — послойная миграция, когда мы сразу создаём новый фронт для всей системы.
Но для этого нужно создать промежуточный слой, содержащий как бэкенд для фронтенда (BFA), так и адаптеры для работы со старой системой на базе старой базы данных.
Преимущество такого подхода в том, что мы можем сразу дать бизнесу новый интерфейс и перевести на него сразу всех пользователей.
Минус в том, что адаптеры для работы со старой системой не будут использоваться в целевой версии и по сути уйдут в мусор.
Послойная миграция Более классический тип миграции — выделение отдельного микросервиса или группы из них для реализации полной функциональности.
Таким образом мы можем сразу делать системы в целевой версии.
Но есть и трудности: не всегда удается выделить достаточно изолированный блок, чтобы он не был связан с остатками нашего монолита.
Приходится создавать дополнительные временные элементы и дублировать информационные потоки.
Часто новые области работают параллельно со старым функционалом, и не так-то просто убедить пользователей использовать новую систему, когда старая еще работает идеально.
Поэтапная миграция функций Миграция на новый стек технологий и архитектуру — всегда сложный процесс, не имеющий четкого решения и иногда даже на очень похожих проектах протекающий по-разному.
В следующих статьях я расскажу подробнее о технических трудностях, с которыми мы столкнулись, и о решениях, которые мы применили.
На данный момент мы активно работаем, и несколько МЧС частично запущены в производство.
В каждом случае существуют различия в бизнес-требованиях и используются разные подходы при переходе к микросервисной архитектуре.
Также, анализируя промежуточные, мы корректируем подходы к разработке и создаем архитектуру горизонтальных сервисов, обслуживающих несколько систем.
Такие проекты не имеют правильного решения с самого начала.
Вам придется пройти путь проб и ошибок.
Сейчас мы пробуем разные подходы, чтобы выбрать из каждого лучшее.
Лично я верю, что мы сделаем все правильно и круто.
Будут новые результаты, будет статья о том, что у нас сработало эффективнее.
А еще коллеги уже пишут посты о конкретных технических и архитектурных кейсах.
Теги: #программирование #Управление разработкой #Микросервисы #Анализ и проектирование систем #монолит
-
Crm-Система: Полный Алгоритм Внедрения
19 Oct, 24 -
Создание Html-Формы С Помощью Веб-Интерфейса
19 Oct, 24
