Комментарии 4
Для реализации Circuit breaker вы используете свое решение или готовый пакет? Если готовый, то какой?
В контексте программного обеспечения паттерн предполагает разделение ресурсов сервиса на несколько независимых блоков, например, создание двух пулов подключений к базе данных: один для критических задач, второй для остальных.
Не совсем понятен контекст данного примера. Два пула на одну БД или это две разные БД? Почему не разделить задачи на два разных сервиса?
Для разных БД и так будут разные пулы соединений, их просто не получится объединить в один. Речь конечно же о варианте с двумя пулами для одной БД.
Например, есть у вас сервис по обработке заказов. У него есть методы для создания заказа и изменения его состояния (подтвержден, завершен, отменён), а также методы для получения информации о заказе (подробности заказа, история). Первые являются бизнес-критичными, а вторыми можно пожертвовать в случае отказа, компания не потеряет деньги.
Разделив соединения к БД заказов на два пула мы можем выделять ресурсы (соединения) независимо, и если внезапно возрастёт нагрузка на методы получения данных о заказах, это не приведёт к замедлению или остановке обработки заказов.
Теоретически можно выделить отдельный слейв БД только для чтения, а обработку заказов делать на мастере, но в реальности возникают ситуации, когда необходимо сразу после обновления считывать свежие данные, а лаг репликации препятствует этому. Также в БД могут храниться другие данные, необходимые для обработки заказа (например инфо о клиенте), которые будут читаться со слейва, и эти операции тоже должны быть защищены от повышенной нагрузки на некритичных методах. Тем самым выделение read-only слейва уже не спасёт, и потребуется применять паттерн Bulkhead.
Повышение устойчивости микросервисов к отказам