Какие признаки указывают на распределённый монолит?
- Что такое распределённый монолит?
- Почему микросервисы не дали независимости?
Цена распределённой системы уплачена, а независимость не получена: общий релиз, общая база, синхронные цепочки, общая библиотека моделей.
- Сервисы выкатываются только вместе и в определённом порядке
- Одно поле — правки в нескольких репозиториях
- Отказ одного сервиса кладёт все сценарии
А ещё Лечение — пересмотр границ, своя база у сервиса, асинхронное взаимодействие, иногда объединение сервисов обратно
Подробно
Самый частый исход неудачного перехода на микросервисы: система разбита на процессы, но связана так же тесно, как монолит, только теперь через сеть.
Признаки:
- общий релиз — сервисы нельзя выкатить независимо, нужен согласованный порядок;
- общая база — несколько сервисов читают и пишут одни таблицы, схему нельзя менять без согласования;
- синхронные цепочки — пользовательский запрос проходит через пять сервисов, доступности перемножаются, задержки складываются;
- общая библиотека доменных моделей, обновление которой обязательно для всех;
- изменение одной фичи — правки в нескольких репозиториях и командах;
- «болтливые» вызовы — десятки запросов между сервисами на одну операцию.
Признаки здоровой нарезки — наоборот: своя схема данных у сервиса, обратно совместимые контракты, асинхронные события там, где не нужен немедленный ответ, независимые выкатки.
Что делать: найти сценарии с самой сильной связанностью и пересмотреть границы; переносить данные к владельцу; заменять синхронные вызовы событиями и локальными копиями; версионировать контракты; иногда — честно объединить сервисы обратно в один.
Что хотят услышать
- Определение: распределённость без независимости.
- Конкретные признаки: общий релиз, база, синхронные цепочки, общие модели.
- Признаки здоровой нарезки.
- Пути исправления, включая объединение.
Частые ошибки
- Считать проблему решённой, если сервисы просто в разных репозиториях.
- Лечить связанность ещё более частыми синхронными вызовами.
Проверьте себя
Несколько верных вариантов. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✓Сервисы нельзя выкатить по отдельности — релиз идёт «поездом»
- ✗У каждого сервиса своя схема данных и свой контракт, версии которого меняются независимо
- ✓Несколько сервисов ходят в одну базу и знают чужие таблицы
- ✓Один сценарий проходит длинную цепочку синхронных вызовов
Что спросят дальше
- Почему общая база данных особенно вредна?
- Что делать, если сервисы уже нарезаны неудачно?
Разбор темы
- Монолит, микросервисы и границы сервисов
Когда микросервисы оправданы, а когда вредны; bounded context и DDD как способ резать систему; распределённый монолит и его признаки; база на сервис и организационная цена.
Связанные вопросы
- Что в первую очередь покупает переход от монолита к микросервисам? Middle
- По какому принципу правильнее проводить границы между сервисами? Middle
- Почему действует правило «одна база данных на сервис»? Middle
- Пользовательский сценарий последовательно вызывает пять сервисов, доступность каждого 99,9%. Какова примерная доступность сценария и что из этого следует? Middle
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.