В CI всё так жёстко что тестируется даже установка пакетов? Можно ведь кешировать это всё.

Допустим можно валидировать lockfile только если его изменяли в данном pr.

Всем привет. Есть вопрос кто нибудь работал с микросервисами? Меня интересует решение как организовать паттерн shared db (много микросервисов одна база) фреймворк не имеет значение но orm sql alchemy. Может кто видел на github или статью какую как пилят такое

Пока на ум приходит во все микросервисы засунуть одни и те же модели алхемии и дальше логику пилить

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

Извините. Вспомнил диалог просто )

Kirill
Обычные ошибки. Сделать микросервисный монолит и иметь проблемы. Просто тестировать надо, чтобы совсем всё не ломать. А иметь пяток хотфиксов после большого релиза это нормально.

Sergey
надо говорить микросервисы с тесными связями! =)  теперь так говорят

😄посмеялся, но это не дает ответ на мой вопрос

Это какой-то анти-паттерн наверное. Микросервисы ведь делают для того что бы они были минимально связаны друг с другом. Т.е. у каждого сервиса должна быть своя база и он не должен знать про базу других сервисов. А если им надо общаться между собой, то они должны это делать через API, который можно поддерживать в рабочем состоянии независимо от изменений внутри самого сервиса.

Как вариант - можно и базу представить как сервис, но в таком случае надо работать с ней через "API", например в виде сохранённых процедур, а не через прямые SQL запросы. И поддержку этого "API" надо реализовать в виде отдельного проекта микросервиса.

да я тоже так думаю но тут боль будет, сейчас мы думаем с командой

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

короче есть данные которые без данных другой таблицы это не полная информация будет и еще один запрос

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

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

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

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

А так у тебя общая база данных окажется узким местом для масштабирования микросервисов.

вот пользователи у нас вообще хранятся в другом сервисе

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

тут уже легче быть

и есть еще пару сущностей которые имею конечное число

Тогда советую именно строить ERD и смотреть, как модели можно кластеровать по микросервисам. И как дробить какие-нибудь ненужные связи