Микросервисы и концепция «единой точки отказа»

Question

Одна концепция, которую я не совсем понимаю, это единственная точка отказа.Мне кажется, что всякий раз, когда у вас есть несколько служб, скажем, A, B и C, задействованных во всей системе, то, если какой-либо из них не работает, система в целом не может сделать что-либо полезное (Если система может быть полезна без B, то зачем вообще нужно B?).

Например, допустим, у нас есть конвейер, в котором A публикует событие, котороеиспользуется B, а затем B публикует сообщение, которое используется C, и этот поток данных показывает, как вся система выполняет свое предназначение.

A ===> B ===> C

Может быть C - это служба, которая обрабатывает информацию о кредитных картах: бизнес на самом деле не работает, если не поступают деньги!

Поскольку это система обмена сообщениями, этиуслуги являются «независимыми» в том смысле, что если один из них выходит из строя, он не приводит к отказу другого.Хорошо, но если B выйдет из строя, то C не получит никаких новых сообщений, и вся система не будет выполнять свои задачи.Итак, в чем разница с наличием отдельных служб A, B и C, а не одной службы ABC?

Answer 1

Я думаю, что ваш вопрос риторический.Очевидно, что если система зависит от всех служб, то любая служба является единственной точкой отказа.Если один сервис отключается, система не будет "служить своей цели".Использование Microservices не освободит вас автоматически от проблемы единой точки отказа.

Большинство сторонников Microservices скажут вам, что вы должны проектировать свою систему таким образом, чтобы вся система не зависела ни от кого.оказание услуг.Но такая система звучит для меня как единорог.Это то же самое, что сказать: «если вы удалите часть своего кода, приложение должно продолжать работать»

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

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

Создание иногда подключенных клиентов может быть еще одним способом избежать единой точки отказа.Git - хороший пример.Если GitHub не работает, у вас нет людей, сидящих без дела и говорящих: «О, похоже, мне не нужно будет сегодня ничего делать».

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

Answer 2

Сервисная композиция - одна из самых сложных частей микросервисов.Не читая несколько книг по этому вопросу, вот несколько рекомендаций.Если вы ищете некоторые из перечисленных ниже преимуществ, возможно, имеет смысл использовать независимую службу:

1. Повторное использование логики.В вашем примере, если служба C также вызывается другими службами: D -> E -> C. Если вы подозреваете, что ваша логика может или должна использоваться другими службами, создание службы C в качестве независимой означает, что вы можете обслуживать клиентов этой логики дажекогда A и B. упали.
2. Разъединить команды.Если вы небольшая команда, вам, вероятно, не нужны сотни услуг.Но напишите свою логику, чтобы вы могли отделить ее позже.Хорошо иметь «микросервисное» мышление, даже если вначале вы не разбиваете свою логику на независимые работающие службы.Легко обмануть, когда ваш код находится в монолите.Если вам действительно нужно заставить себя или свою команду думать о двух вещах как о «отдельных», чтобы вы могли использовать их повторно, это может сделать другая служба.
3. Оптимизация для шаблонов выполнения.Если ваша система должна реагировать синхронно, выполнять асинхронную работу, иметь дело с огромными скачками входящего потока работы (от 0 до 10000 об / мин в минуту), вы можете выделить службы.Облегченный сервис, который принимает только вызов REST API и ставит его в очередь для реальной работы, может быть именно тем, что вам нужно для обработки входящих потоков работы, когда вы можете позволить себе обрабатывать или отвечать асинхронно.Облегченный сервис может ускоряться за миллисекунды, обеспечивая быстрое реагирование на неустойчивый спрос.Если у вас есть 12-гигабайтный Java-зверь, его масштабирование может занять некоторое время.

Я бы также порекомендовал вам правильно выбрать хранилище данных.Можно потратить много времени на оптимизацию надежности закодированных сервисов и сопутствующей инфраструктуры, но вы все равно можете иметь единую точку отказа в вашей архитектуре базы данных (или сети, или балансировщика нагрузки, или DNS, или ...)

Answer 3

Различные части сервиса имеют разные потребности в онлайн-емкости.Анализ режима сбоев очень важен для того, чтобы по-настоящему понять, где необходимо разделить службы и сделать их более устойчивымиНапример, возможно, C бесполезно разделять, если он не является обязательным для рабочего процесса для упорядочения, но, поскольку это очень важно, он должен получить собственную дополнительную устойчивость (несколько отказоустойчивых рабочих на нескольких хостах).

Если бы, с другой стороны, C был системой исполнения (отправлял пикап на склад), ему не требовался бы такой уровень устойчивости, и он мог бы позволить себе упасть.Речь идет о том, чтобы решить, где находятся точки сбоя, и сколько стоит предотвращать эти сбои.

В дополнение к режимам сбоев, существуют проблемы с пропускной способностью.Обработка кредитных карт может иметь совершенно иные потребности в масштабировании, чем служба инвентаризации.Возможно, клиенты запрашивают цены ОЧЕНЬ часто, и поэтому вам может потребоваться поддерживать гораздо большую емкость, чем для обслуживания обработки кредитных карт.В связи с этим вам необходимо увеличить пропускную способность для этой части вашего сервиса.Кроме того, сбой в этом сервисе может быть более приемлемым, чем сбой в реальном сервисе обработки заказов (выручка скорее всего против спекулятивного).В любом случае вам необходимо понимать ценность каждой из этих услуг и находить способы их разделения, которые позволят вам независимо масштабировать их емкость и отказоустойчивость.

Answer 4

Немного измените систему и добавьте избыточность.

[(A) (A) (A)] ===> [(B) (B) (B)] ===> [(C)) (C) (C)]

Теперь, даже если один из реплицированных сервисов скажет (B) отключится, пользовательская история будет завершена из-за доступности узлов-клонов (B).

Эта система (в этой области) не имеет единой точки отказа.

Следует отметить, что в вашем проекте использовались сообщения или, по сути, "слабосвязанная", было очень легко изменить систему и удалить точки отказа.,

Существуют и другие аспекты микроуслуг, которые требуют подробного обсуждения. перспектива , которая помогла мне понять концепции в привязке к микросервисам, - это модель Scale cube .

Answer 5

Думайте о сервисе ('B') как о наборе параллельных дорог или каналов обработки.Как только эти дороги построены по проекту (коду), они будут там работать.Дизайн не меняется, поэтому обработка не меняется, и это происходит, как вы говорите.Однако рассмотрим, что на дороге развивается незапроектная ошибка - аппаратный сбой.Поверхность дороги физически не проходима.Движение не может течь, но, к счастью, у нас есть много параллельных дорог, которые могут поглотить это движение!Если бы у нас была только 1 (широкая) дорога, вся дорога была бы закрыта для повторной шлифовки, поэтому движение не могло проходить.

Вы можете пойти дальше.Представьте, что движение на ваших параллельных дорогах увеличивается, а дороги заполнены.Легко построить еще одну однополосную дорогу.Это не так много, но как только он будет построен, вы сможете позволить ему работать с максимальной производительностью.Но аренда земли стоит денег!Поэтому, когда движение транспорта сокращается, мы можем легко вывести из эксплуатации небольшую дорогу и не платить за нее арендную плату.

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