Pull to refresh

Comments 6

Это должно работать для микросервисов. Интересно, можно ли применить подобный подход, когда речь идет о компоненте, который может менять схему данных? На первый взгляд — нет.
Если нужен 99.99% uptime все равно не получится вносить ломающие обратную совместимость изменения в схему. Скорее всего нужно делать обратно совместимые изменения схемы, что бы и старый и новый сервис могли с ней работать одновременно. Потом в следующем релизе удалять не нужное.
Так можно. Но тут ломаетя сама идея проверки изменений на небольшом количестве пользователей. Если ошибка как-раз в изменении схемы, то от нее пострадают все.
Тогда нужно делать шардирование базы и канаречный деплой схемы в один из шардов
Ага. И озаботиться, чтобы именно с этим шардом всегда работал один и только один инстанс application server… Сложности, сложности :)
Хм.
~2002 год (ещё те времена, когда международных интернет-каналов в Украине было мало и они были сильно дороже внутренних). Я админ в ISP.
Стоит HTTP прокси.
Делаю тесты на новом прокси: с утра поворачиваю DNS на него (TTL полчаса), вечером — обратно. Ставлю его или внутренним (ближе к юзерам), или внешним (ближе к серверам) в пару к основному, смотря что тестирую.
На второй день звонит некто (вообще не наш пользователь) и начинает рассказывать, что мы «не обеспечиваем качество сервиса». При выяснении оказывается, что он для контроля доступа к своей системе по IP вписал адреса наших прокси в белый список… а тут я своими экспериментами мешаю доступу. Что характерно, сами наши пользователи молчат.
Неожиданный результат.

Вывод: что-то обязательно пойдёт не так и там, где вы и предположить не могли.
Sign up to leave a comment.