Значение по умолчанию Miroservices для резервных сценариев

Значения по умолчанию часто рекомендуются как часть механизма аварийного переключения для микросервисов. На высоком уровне для любых сервисов (например, микросервисов здесь) характер операции можно широко классифицировать как «Чтение или запись».

  1. Наличие значений по умолчанию для операций записи не является надежным.
  2. Возвращаемые значения для операций чтения с точки зрения размера данных могут (?) классифицироваться следующим образом:

    • Чтение возвращаемых данных малого /среднего размера
    • Прочитать возврат Огромный объем данных

Предположим, что источником данных является высокодоступный кэш [используемый для производительности, избежания взаимного отказа и т. д. и имеет собственный цикл обновления].

Теперь, когда кэш не работает, план отказа может быть:

  • Когда размер данных мал - Возвращаясь к фактической системе для извлечения данных (при условии, что время, затраченное на диапазон миллисекунд), в режиме реального времени, кажется, что это нормально.
  • Когда размер данных огромен, а вызов в режиме реального времени занимает несколько минут, делая это по синхронному вызову, кажется, не является правильным.

Решения, о которых я могу думать, следующие:

  1. Храните фактические данные в постоянном хранилище, которое поддерживается высокой доступностью и использует его как резерв. Таким образом, доступность данных теперь будет контролироваться политикой HA постоянного хранилища.
  2. Используйте кеширование для запроса . Кэш может иметь фиксированный верхний предел по размеру и может использоваться для хранения только последнего запроса. Кэш можно периодически обновлять (с той же частотой обновления кэша HA) после проверки работоспособности кэша HA. Если доступен HA Cache, кэш запросов можно сбросить, иначе он может сохранить последнее состояние. Это существенно повышает надежность доступности данных для платформы, на которой размещены микросервис (ы)

Было бы действительно полезно узнать из сообщества, которое из вышеперечисленного лучше подходит OR, есть ли другой лучший способ справиться с проблемой, описанной в (2)?

3 голоса | спросил Divs 28 ThuEurope/Moscow2017-12-28T09:37:33+03:00Europe/Moscow12bEurope/MoscowThu, 28 Dec 2017 09:37:33 +0300 2017, 09:37:33

1 ответ


3

Ты переусердствуешь.

Цель распределенного кеша - оптимизировать производительность, не более того. Если вы ожидаете, что данные будут храниться в always , ваш дизайн будет испорчен. У вас могут не быть данных по нескольким причинам (и гораздо более актуальным), чем недоступность службы кеша:

  • Данные еще не кэшированы,
  • Данные стали устаревшими и должны быть восстановлены,
  • Служба кеша была низкой в ​​памяти и удалила элемент из кеша.

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

Единственная дополнительная проблема, с которой вы сталкиваетесь с потенциально недоступной службой кэширования, - это не слишком долгие запросы, но многие короткие. Если вы ожидаете сделать несколько сотен запросов (по 1 мс каждый) в секунду в кеш, и кеш перестает отвечать на запросы, что означает, что каждый запрос теперь занимает 500 мс. (timeout), вы, возможно, исчерпаете пул HTTP-соединений, не считая последствий для вашего пользователя. Чтобы защитить себя от этого сценария, используйте шаблон автоматического выключателя микросервисов.


Следуя вашему комментарию, кажется, что нам необходимы дополнительные объяснения. Я думаю, что проблема с вашим вопросом заключается в том, что вы говорите о огромных объемах данных , считая, что для получения этих данных из кеша потребуется секунд или миллисекунд, но за несколько минут до получите его без кеша. Если это вопрос только размера данных, для получения данных из кеша все равно потребуется minutes .

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

В этом случае служба может ответить HTTP-Accept Accepted , указав, что она начала генерировать ответ, ответ будет доступен позже. Это фактически означает, что клиенту придется обрабатывать два случая: тот, в котором ответ готов (HTTP 200), и тот, где ответ должен быть регенерирован (HTTP 202) и действовать соответственно.

Работает ли постоянное хранилище как резервный механизм? Конечно. Лично я предпочел бы не использовать его, поскольку он делает всю систему довольно сложной. Как только вы храните данные в двух разных системах (основной кеш и резервное хранилище), обслуживание становится слишком дорогостоящим, и вам придется иметь дело с недействительностью должным образом (например, что произойдет, если первичный кеш недействителен, но когда пытаясь аннулировать данные в постоянном хранилище, это не удается?) Более того, как далеко вы могли бы с этим справиться? Вам не нужно обрабатывать случай, когда и кеш, и постоянное хранилище пусты?

По моему мнению, цель должна заключаться в следующем:

  • Убедитесь, что служба кеширования надежна. Если он падает один раз в день в течение часа, у вас есть более важные дела, чем думать о резервных стратегиях.

  • Убедитесь, что в случае, когда служба кеша отключена (или пустой), выполняется, то есть пользователь видит что-то другое, кроме «Ошибка сервера». В зависимости от конкретного случая это может быть так же просто, как явное и полезное сообщение об ошибке, объясняющее, что произошло, и что пользователь может сделать дальше. Или это может быть механизм, при котором пользователю придется ждать несколько минут, чтобы восстановить контент. Или это может быть очень сложный резервный механизм, который обеспечивает надежность 99,99999%. Это зависит от вас, чтобы определить, стоит ли это усилий.

ответил Arseni Mourzenko 28 ThuEurope/Moscow2017-12-28T12:18:29+03:00Europe/Moscow12bEurope/MoscowThu, 28 Dec 2017 12:18:29 +0300 2017, 12:18:29

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132