Обнаружение служб и балансировщики нагрузки с частой проверкой работоспособности
Кажется, существует неправильное представление как об обнаружении сервисов, так и о балансировке нагрузки. Сравнение «против» невозможно, потому что обнаружение сервисов и балансировка нагрузки — независимые, но дополняющие друг друга понятия.
Балансировка нагрузки службы позволяет отделить клиентов от масштабируемости этих других служб. Все клиенты имеют один URL-адрес для взаимодействия. В облачных средах есть автоматизированные инструменты, которые могут добавлять и удалять узлы за балансировщиком нагрузки. Это помогает обеспечить масштабируемость, обещанную микросервисами. Обнаружение службы не имеет ничего общего с этим аспектом. Буквально, поэтому вы должны поставить балансировщик нагрузки перед кластером узлов для масштабирования микросервиса.
Если балансировка нагрузки отделяет клиентов от масштабируемости службы, то обнаружение служб отделяет клиентов от знания того, какие URL-адреса можно использовать для связи с другими службами. Думайте об обнаружении сервисов как об индексе всех микросервисов в вашей экосистеме. Метаданные о каждой службе должны возвращать URL-адрес балансировщика нагрузки перед службой.
Балансировщики нагрузки позволяют добавлять и удалять узлы для одной службы, не затрагивая клиентов. Обнаружение служб позволяет добавлять и удалять целые службы без внесения изменений в конфигурацию всей экосистемы. Клиенты могут самостоятельно обнаруживать новые конечные точки.
Итак, не выбирайте одно над другим. Выберите оба. Они хорошо работают вместе, потому что служат разным целям.
Обратите внимание, что отказоустойчивость микросервисов не полностью достигается на уровне балансировщика нагрузки. Такие концепции, как конечная согласованность и использование простых очередей сообщений, помогают сделать всю систему отказоустойчивой. Система должна быть устойчивой с точки зрения целых сервисов, а не отдельных узлов. Это то, что Мартин Фаулер называет «тупыми каналами (брокерами сообщений) и интеллектуальными конечными точками (служба, считывающая сообщения из очереди сообщений)». Чем проще компонент, тем меньше вероятность его отказа.
Очереди сообщений должны быть довольно простыми, чтобы они не терпели частых сбоев. Услуга сложная и более подвержена сбоям. Если служба выходит из строя, сообщения накапливаются в очереди. Когда служба возвращается в оперативный режим, она начинает обрабатывать накопившиеся сообщения. Это основа отказоустойчивости микросервисов.
Рекомендую посмотреть эти видео для лучшего погружения в вопрос: