Azure App Service против Azure Service Fabric

Ответ 1

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

Ответ 2

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

Служба App предоставит вам функциональность, которую Service Fabric не предоставляет из коробки. Такие вещи, как автомасштабирование, аутентификация, ограничение скорости, интеграция с приложениями SaaS и т.д. Некоторые или все это может постепенно появляться в Service Fabric, но я бы сказал, что в этот момент они нацелены на разные аудитории - менее опытной команде может быть проще работать с App Service.

Сервисная ткань, с другой стороны, упрощает компоновку деталей. Например, в "традиционном" подходе, если у вас есть API, который говорит с хранилищем данных и кешем, чтобы не забивать хранилище данных, вам придется обрабатывать различные сценарии отказоустойчивости. С помощью Service Fabric ваш кеш может работать в рамках процесса API в надежной коллекции, и вам не придется иметь дело с наличием внешнего компонента кэша. Данные расположены совместно с сервисом (быстрее получить/отредактировать!) И надежны, поскольку он распределен по всем узлам, в которых развертывается служба. Аналогичная ситуация с очередями. Если вы думаете о системе типа рабочего процесса, где есть API, служба заданий и очередь, которая находится между ними и позволяет им общаться, вам нужно будет управлять тремя различными компонентами и между ними. С Service Fabric очередь входит в приложение. И это всего лишь половина из этого :) вы также получаете возможность использовать модель актера для распределенных вычислений без обычных головных болей. Наконец, с помощью Service Fabric вы получаете преимущество в создании более полной среды разработки в своем локальном поле - вам не нужно заниматься созданием очередей и т.д. В учетной записи Azure dev или что-то в этом роде.

Также стоит отметить, что вам ничего не мешает использовать обе парадигмы - представьте себе два приложения, в которых, по крайней мере, одно из них представляет собой приложение для сервисов, которые выставляют API и логическое приложение, которое находится поверх них.

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

Ответ 3

Служба приложений - это более управляемый сервис, SF - это больше, чем вы сами управляете, и вы можете работать в своих собственных помещениях. SF имеет лучшую поддержку для не-MS-стека, например, собственных приложений и т.д.

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

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

Также обратите внимание, что SF имеет механизм хранения данных, который входит в состав служб. Это хорошо на 3 вещи 1) Массивные кластеры данных 2) Простые данные, часто в службах служб Micros, становятся тяжелым бременем, так как каждая служба должна иметь свои собственные данные, а такие вещи, как SQL, немного перегружены, когда у вас только 1-3 таблицы. 3) Государственное хранилище для модели программирования Актера.

Я думаю, что SF и веб-приложения в будущем будут использовать пользовательскую базу "Cloud Service".

Ответ 4

Используйте Service Fabric, когда вам нужен больший контроль или прямой доступ к базовой инфраструктуре.

Используйте сервис приложений, когда вам нужна полностью управляемая хостинговая платформа для ваших веб-приложений.

-as за документацию

Ответ 5

Если (в будущем может потребоваться увеличить масштаб приложения ||, чтобы создать приложение с микросервисной архитектурой), выберите Azure Service Fabric.

еще служба приложений Azure в порядке