Комментарии 7
Спасибо за пост. Вопрос про мониторинг istio. У istio метрики с наибольшим количеством серий это: istio_request_bytes_bucket, istio_request_duration_milliseconds_bucket, istio_response_bytes_bucket. Уменьшали ли вы их кардинальность? Если да, то как?
Но если базы, кэши и очереди не разделены, то получается все эти фичаветки используют общие базы, кэши и очереди? А как быть с миграциями, изменениями контрактов в очередях и всем таким?
Согласен. Тоже не понимаю как это может работать с единой базой.
С очередями пока самое сложное. Явного какого-то способа не нашли. Есть возможность поднять отдельную кафку и натравить на неё микрик.
С базами пока решили что если схема меняется, то происходит полное копирование данных в этой же базе, но в другую схему, там делаются правки и потом миграцией заливаются в основную. Это с SQL. С многой не много проще получается потому что коллекции можно создать автоматом.
Если нужен отдельный кеш, то он разводится по имени мапы.
Но, к сожалению, эти все действия нужно совершать в ручную.
>Есть некоторые api, над которыми работают несколько команд. Каждая работает над своей фичей локально и пишет тесты, а вот при деплое на стэнд получается столпотворение потому, что нужно изменения слить в одну ветку аля develop и её закинуть на тест.
Наверное проще чтобы каждая команда делала свои фичи в отдельном проекте на отдельных роутах. А уже кто-то выше вызывал те что нужны.
Проще убрать пересечение чем разруливать его.
Безопасная параллельная разработка. Istio