Comments 9
При разделении монолитного приложения мы прошли несколько этапов. Изначально все Entity базы данных хранились в одном модуле Maven, и была настроена политика обновления схемы на основе изменений Entity классов hibernate.hbm2ddl.auto: update. Когда мы выделили первый микросервис, то сразу столкнулись с проблемой двойного апдейта базы, так как было два приложения, которые на старте пытались инициализировать новую схему БД. Авто-апдейт схемы выключили и перешли на написание скриптов и их запуск при деплое на окружении. Изначально это делалось руками, потом внедрили Liquibase.
Постепенно мы разносили Entity классы по микросервисам, которым они «принадлежат». В текущий момент мы все ещё имеем одну БД, но таблицы в этой БД принадлежат разным микросервисам.
Для записи в БД мы так же используем Hazelcast, то есть мы не пишем в БД напрямую, а бросаем Event на событие, и каждый микросервис (в том числе и тот, который бросил Event) записывает в БД. Это сделано не для всех случаев, но это необходимо, чтобы между микросервисами не было интеграции через БД.
Мы выбрали Hazelcast по нескольким причинам:
- Действительно, был опыт работы с ним. Redis использовали только как кэш или для хранения сессий, но не было опыта работы как с event-bus. С Hazelcast, напротив, был опыт подобной работы, хоть и не большой.
- Наличие необходимого функционала из коробки (ex. reliable topic).
все же микросервисы должны иметь свою изолированную базу.
Вы правы, все микросервисы должны иметь изолированную базу, и мы идем к этому. До сих пор не перешли, поскольку есть более приоритетные задачи. А также осложнения:
- база данных используется как источник для других служб,
- есть резервное копирование и восстановление данных, которое работает на основе базы, которая была на монолите.
По поводу “может случайно (или намеренно) создать сайдэффекты” – такого с БД не было. В этой плоскости у нас нет проблем.
И ещё хотели добавить вот что. Наличие одной БД для нескольких микросервисов, которые используют liquibase, приводит к конкуренции за таблицы liquibase при старте приложения и может привести как к замедлению, так и к незапуску. Это в копилку знаний, почему нужно делать отдельные БД :)
Спасибо! Не можем сказать, что готовы расстаться с какой-то технологией. Но с каждой были сложности, которые мы осознали не сразу.
Например, Hazelcast довольно сложен, если вам нужно разобраться, почему он вдруг начинает работать медленно или почему он делает неожиданные вещи. Последнее, что мы пытались настроить в Hazelcast, но не очень успешно — это логирование медленных операций. И мы так и не добились от него вменяемой информации по этому вопросу.
По части Eureka: мы используем не самую актуальную версию, и в UI у Eureka есть проблемы, но мы с этим живем.
Gitlab CI только на первый взгляд имеет очевидный язык настройки Job’ов.
И если бы начинали сейчас, то сразу подумали бы о правильном тестировании микросервисов.
Во-первых, Job’ы сложно тестировать, нет готового инструмента для того, чтобы протестировать ваш Job, кроме проверки синтаксиса файла .gitlab-ci.yml.
Во-вторых, не совсем очевидно работают секции only & except. При написании первого пайплайна ожидали, что условия в only будут “И”, а они оказались “ИЛИ”. Чтобы выйти из положения, нужно в except писать все исключения, например:
чтобы запускать сборку по расписанию в ветке develop нужно
only:
-web
-schedules
except:
-master
-/^feature/.$/
-/^bug/.$/
-/^bugfix/.$/
-/^cherry-pick-.$/
В-третьих, до недавнего времени не было возможности разделить конфигурацию на несколько файлов, и наш текущий файл .gitlab-ci.yml уже слишком большой.
Остальные сложности были связаны скорее с тем, что не понимали формат и учились в процессе.
Сейчас используем почти весь функционал Gitlab-CI кроме environment, если у вас есть какие-то вопросы, то можно поговорить более предметно.
Как перейти на микросервисы и не разломать production