Может ли кто-нибудь привести меня к чему-то, что объяснит, когда я должен создать приложение Azure Service Fabric и приложение Azure App Service? У меня есть приложение, которое я хочу создать, но не могу определить, следует ли его создавать с использованием Azure Service Fabric или Azure App Service.Azure App Service vs Azure Service Fabric
Microsoft создала document со сравнением для Azure App Service, виртуальных машин, сервисной и облачной служб.
К сожалению, нет никаких официальных указаний о том, когда им пользоваться. Это две отдельные платформы, следуя различным парадигмам развития.
Служба App предоставит вам функциональность, которую Service Fabric не предоставляет из коробки. Такие вещи, как автомасштабирование, аутентификация, ограничение скорости, интеграция с приложениями SaaS и т. Д. Некоторые или все это может постепенно появляться в Service Fabric, но я бы сказал, что в этот момент они нацелены на разные аудитории - менее опытной команде может быть проще работать с App Service.
Сервисная ткань, с другой стороны, упрощает составление деталей. Например, в «традиционном» подходе, если у вас есть API, который говорит с хранилищем данных и кешем, чтобы не забивать хранилище данных, вам придется обрабатывать различные сценарии отказоустойчивости. С помощью Service Fabric ваш кеш может работать в рамках процесса API в надежной коллекции, и вам не придется иметь дело с наличием внешнего компонента кэша. Данные размещаются вместе со службой (быстрее получать/редактировать!) И являются надежными, поскольку они распределены по всем узлам, в которых развертывается служба. Аналогичная ситуация с очередями. Если вы думаете о системе типа рабочего процесса, где есть API, служба заданий и очередь, которая находится между ними и позволяет им общаться, вам нужно будет управлять тремя различными компонентами и между ними. С Service Fabric очередь входит в приложение. И это всего лишь половина из этого: вы также получаете возможность использовать модель актера для распределенных вычислений без обычных головных болей. Наконец, с помощью Service Fabric вы получаете преимущество в создании более полной среды разработки в своем локальном поле - вам не нужно заниматься созданием очередей и т. Д. В учетной записи Azure dev или что-то в этом роде.
Также стоит отметить, что вам нечего останавливать на использовании обеих парадигм - представьте себе два приложения, в которых, по крайней мере, одно из них является приложением для сервисов, которое выставляет API и логическое приложение, которое находится поверх них.
Ваше решение должно основываться на том, что вы пытаетесь создать, сколько времени, когда вы хотите выпустить (в настоящее время сервисная ткань находится только в приватном превью, так что это будет некоторое время, пока они не доберутся до GA) и какая у вас команда. Я полагаю, что с App Service будет легко ударить по земле, даже если у вас нет опытной команды, но Service Fabric даст вам больше силы, гибкости и контроля.
Спасибо, Чариск, это определенно помогает. Я думаю, что гибридная модель привлекательна. Я хотел бы использовать простоту и добавленные функции службы приложений для своих веб-приложений и приложений API, но я хотел бы создать задний конец системы, используя структуру сервиса. Я углубится в понимание того, как это сделать больше. Надеюсь, есть способ получить лучшее из обоих миров. :) – StewartArmbrecht
Служба приложений - это более управляемое обслуживание, SF - это больше, чем вы сами управляете, и вы можете работать в своих собственных помещениях. SF имеет лучшую поддержку для не-MS стека dev, например, родных приложений и т. Д.
Как указано в этом документе «Сервисная ткань - хороший выбор, если вы создаете новое приложение или переписываете существующее приложение для использования архитектуры микросервиса . »
Если у вас есть несколько приложений, вы не должны смотреть на SF, с другой стороны, если вы развертываете более 10 сервисов, чем это станет лучшим решением.
Также примечание SF имеет механизм хранения данных, который входит в состав услуг.Это хорошо на 3 вещи 1) Массивные кластеры данных 2) Простые данные, часто в службах служб Micros, становятся тяжелым бременем, так как каждая служба должна иметь свои собственные данные, а такие вещи, как SQL, немного переборщиваются, когда у вас есть только 1-3 столы. 3) Государственное хранилище для модели программирования Актера.
Я думаю, что SF и веб-приложения в будущем будут использовать пользовательскую базу «Cloud Service».
Я не думаю, что там есть исчерпывающий путеводитель - это зависит от того, что вы пытаетесь построить, и какой у вас есть команды. Может быть, вы можете поделиться некоторой информацией? – charisk
Это специальное приложение для управления проектами для предприятий, которое может быть расширено в систему управления контентом и многое другое. Его можно легко создать с использованием стандартных API и веб-приложений, но я не уверен, что бы я отказался. Мне нравится масштабируемость Service Fabric, как с точки зрения производительности, так и с точки зрения развития. Тем не менее, я не знаю, что бы я отказался, если я подхожу к подходу App Service. То, что я надеялся, было чем-то, что могло бы обозначить плюсы и минусы каждого подхода. Как вы решаете между ними? – StewartArmbrecht
Вы можете найти эту статью, сравнивая Azure App Service, виртуальные машины, сервисные и облачные сервисы - https://docs.microsoft.com/en-us/azure/app-service-web/choose-web-site- cloud-service-vm – mvark