Служебная структура Stateful service - масштабирование без разбиения?

Question

Я планирую перенести существующую облачную монолитную службу Restful Web API в Service Fabric в три этапа. Кэш памяти (в процессе) интенсивно использовался в моем облачном сервисе.

Шаг 1) Миграция облачного сервиса на сервис SF Stateful с 1 репликой и одним разделом. Код кеша как есть. Не использовать надежную коллекцию.

Шаг 2) Горизонтальное масштабирование SF монолитной службы с сохранением состояния до 5 реплик и одного раздела. Код кэша изменен для использования надежной коллекции.

Шаг 3) Разбейте монолитный сервис SF на микро сервисы (без сохранения состояния / с сохранением состояния)

Является ли вышеуказанный подход чище? Любая рекомендация. Любой недостаток?

Подробнее на шаге 2) Горизонтальное масштабирование службы SF Stateful

• Я не планирую использовать стратегию секционирования SF, так как я не мог придумать равномерного распределения данных в моей заявке.
• Добавляя больше реплик и не разделяя их с сервисом SF Stateful, я просто делаю свой сервис более надежным (доступность) . Правильно ли мое понимание?
• Я изменю код кеша, чтобы использовать Надежную коллекцию - Словарь. Одинаковые данные о состоянии будут доступны во всех репликах.
• Я понимаю, что GET может выполняться на любой реплике, но обновление / запись нужно выполнять на первичной реплике?
• Как я могу масштабировать свою службу SF с сохранением состояния без разделения?

• Могут ли все реплики, включая secondory, прослушивать мой клиентский запрос и отвечать одинаково? GET должен быть в состоянии выполнить, как работает вызов PUT & POST?

• Должен ли я предпочесть использование внешнего хранилища кэша (Redis) над надежным сбором на этом этапе? Использовать сервис без сохранения состояния?

Answer 1

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

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

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

Чтобы ответить на некоторые другие ваши вопросы:

• Да, добавление дополнительных реплик увеличивает доступность / надежность, а не масштаб. Фактически это может оказать негативное влияние на производительность (для записи), поскольку изменения должны быть записаны в большее количество реплик.
• Данные о состоянии не гарантируются одинаковыми во всех репликах, только в большинстве из них. Некоторые второстепенные могут быть даже впереди, поэтому чтение из вторичных не рекомендуется.
• Итак, к вашему следующему вопросу рекомендуется, чтобы все операции чтения и записи всегда выполнялись с первичными данными, чтобы вы могли видеть согласованные данные, принятые кворумом.