Удаленное обслуживание в Azure Service Fabric против вызовов RestFul - PullRequest
0 голосов
/ 01 ноября 2018

Я пытаюсь понять конкретные случаи использования использования удаленного взаимодействия в Azure Service Fabric против успокоительных вызовов. Любое понимание производительности, безопасности и любых соответствующих аспектов приветствуется.

Ответы [ 2 ]

0 голосов
/ 02 ноября 2018

Вы не упомянули цель общения, поэтому ответы могут быть очень широкими:

Технически

REST

REST-связь универсальна, может использоваться любым клиентом на любой платформе, это лучший способ представить ваши сервисы клиентам за пределами кластера SF с использованием протокола HTTP.

Сервис может развиваться без нарушения совместимости с существующими клиентами, между Клиентом и Сервисом нет жесткого контракта.

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

SF Remoting

SF Remoting является реализацией .Net Remoting, компонента .Net, обеспечивающего двоичную связь по TCP. Это намного быстрее, потому что не нужно сериализовать данные в JSON и проверить все правила json для сериализации.

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

Недостатки,

Первая проблема с удаленным взаимодействием заключается в том, что Клиент и Сервис должны разговаривать на одном языке, в данном случае .Net (PS: вы могли бы использовать и другие языки, но это не совсем понятно), а также говорить о одна и та же тема, поэтому обоим нужен доступ к контракту (интерфейсу), который расскажет, как они должны общаться друг с другом. Это связывает клиента с сервисом, и обновление может произойти с обеих сторон одновременно.

Во-вторых, из-за первого вы ограничены .Net, а также Service Fabric, вы не можете запускать SF Remoting вне кластера, он тесно связан с SF Runtime.

Remoting работает на уровне ниже протокола HTTP, риск выставить его в интернет выше, чем на сервере HTTP. Это не означает, что он небезопасен, но он не получает обновления так часто, как WebServers.

В итоге

Используйте Remoting, если вам нужна производительность и простое взаимодействие между сервисами.

Использовать REST Если вы не хотите, чтобы клиент был подключен к сервисам и гибкость использовалась любым клиентом \ платформой.

Или, может быть, вы можете использовать другие протоколы. Эта SO имеет некоторую информацию, которая может быть полезна: Azure ServiceBus против ServiceRemoting, HTTP и WCF

0 голосов
/ 01 ноября 2018

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

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

Но трудно дать окончательную рекомендацию, потому что это будет зависеть от вида услуги и ее цели. Иногда, например, вам нужно прямое общение с использованием удаленного взаимодействия, а иногда вам нужна шина сообщений между двумя службами.

Самым важным было бы использование https для связи с кластером, а также для общедоступных SF-сервисов.

Дополнительные справочные материалы:

Подключение и связь со службами в Service Fabric

Защищенный сервис удаленного взаимодействия

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...