Дизайн приложения в Azure Service Fabric

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

Сегодня у нас есть приложение, построенное на облачных службах Azure. Приложение построено на основе DDD, и у нас есть отдельные ограниченные контексты для разных частей подсистемы приложения. Ограниченные контексты сегодня размещаются в одной рабочей роли, которая предоставляет эти подсистемы с помощью одного WebAPI.

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

Мы стремимся перейти к архитектуре микросервисов. Первое, что я планировал сделать, это извлечь весь ограниченный контекст в их собственные API-хосты. Это приведет к появлению 5-10 новых сервисов WebAPI, поддерживающих наши подсистемы.

На мой вопрос, должны ли все эти подсистемы / ограниченный контекст / узлы API быть их собственным приложением Service Fabric или службой в одном приложении Service Fabric?

Я прочитал приведенную здесь документацию Модель приложения Service Fabric , снова и снова, и я не могу понять, где мои услуги.

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

Пожалуйста, может ли кто-нибудь подсказать мне, что подходит моим потребностям.


azure architecture azure-service-fabric asp.net-web-api2
person honk    schedule 01.06.2016    source источник
comment
Если вы хотите обновлять части независимо, каждая из них должна быть приложениями. Что касается архитектуры ваших приложений, это действительно зависит от ваших индивидуальных потребностей. Убедитесь, что вы настроили схемы разбиения с учетом будущего роста. С SF вы размещаете все свои разделы на небольшом количестве машин, а затем распределяете их по мере вашего роста, а не добавляете больше разделов в будущем.   -  person Dan Harms    schedule 01.06.2016

Ответы (1)


arrow_upward
11
arrow_downward

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

С логической точки зрения, думайте о приложении как о связном наборе функций. Сервисы, которые в совокупности образуют этот целостный набор функций, должны быть сгруппированы как приложение. Для каждой службы вы можете спросить себя: «Имеет ли смысл развертывать эту службу отдельно без этих других служб?» Если ответ отрицательный, то их, вероятно, следует сгруппировать в одном приложении.

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

С оперативной точки зрения приложение представляет собой границу процесса, группу обновления и группу управления версиями:

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

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

person Vaclav Turecek    schedule 01.06.2016
comment
Спасибо за развернутый ответ! Мне очень помогли :-) - person honk; 02.06.2016
comment
Если мы используем отдельные приложения, но каждая служба должна взаимодействовать со службами в других приложениях, какой способ лучше (Контекст: разработка и тестирование)? Kuberenetes предоставляет вариант Azure Dev Space с AKS, чтобы реализовать этот сценарий разработки микросервисов с итерацией внутреннего цикла. Любые рекомендации по служебной структуре были бы очень полезны, - person Sowmyan Soman; 09.11.2018