Как стать автором
Обновить

Комментарии 15

Планируете ли продолжать? Для минимальной полезности нужно масштабирование (а иначе зачем кубер) и желательно HTTPS (куда же без него).

А мне хранилище данных еще интересно. Никак не могу понять что мне дает масштабирование контейнеров, если база данных одна и та же, с фиксированной производительностью и единственной точкой отказа

Хранилище - уже выходит за рамки Kuber.

Кубер это обычно микросервисы, а там у каждого своя база.

У каждого инстанса микросервиса? Или у каждого микросервиса?

а причем тут это? Я имел ввиду, что база данных в микросервисной архитектуре, далеко не узкое место.

Притом, что базу данных разные инстансы микросервисов обычно все же разделяют — а потому она легко становится тем самым узким местом.

Микросервисная архитектура разделяет приложение на несколько самостоятельных частей, узкое место каждой (база данных), не становится узким местом для всей системы.

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

Ну да, поправка принимается. Я, конечно же, говорил про разные инстансы микросервиса.


А вот с тем, что узкое место каждой части не становится узким местом системы, я не согласен. Микросервис делается не просто так, а для решения некоторых задач системы. Если система может справиться с задачей без него — на кой он вообще нужен? Поэтому, когда он не справляется со своей задачей — с этой задачей не справляется и система в целом.

У каждого сервиса своя зона ответственности
Если упала бд сервиса отвечающего за комментарии в системе, то это проблема, но не такая большая как упавшая БД сервиса транзакций

Или сервис комментариев не нужен?

И тем не менее, вопрос остаётся в силе: что вам даёт
масштабирование инстансов сервиса комментариев когда они все лезут в один инстанс базы?


А ничего не даёт, базу тоже надо уметь масштабировать. Даже если это база комментариев, а не транзакций.

У каждого микросервиса.

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

Базу тоже можно размазать репликацией по нескольким серверам. Тогда производительность повышается.

Как минимум - реплицируете одну точку отказа, получите сравнительно простой способ бесшовного обновления кода сервиса, ну и конечно, при желании - можно реплицировать и БД.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории