Сервисная ткань и WCF

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

Коммуникационный стек
Все наши сервисы находятся в WCF с использованием net.tcp, поэтому теоретически мы можем повторно использовать коммуникационный стек WCF, но я не уверен, что это лучший способ. Каковы различия между стандартными коммуникационный стек и WCF?

Расширяемость
У нас много реализаций, использующих точки расширения WCF. Если мы выберем коммуникационный стек WCF, сможем ли мы его использовать? В основном мы используем IServiceBehavior, IOperationInvoker, OperationContext и ServiceSecurityContext для этого:

<сильный>1. Безопасность ServiceSecurityContext/OperationContext для получения IP-адреса, и если вызов находится в интрасети, учетная запись домена, которая выполняет вызов, я проверил в StatelessServiceContext, но не смог найти ни одного свойства, где я мог бы получить эту информацию.

<сильный>2. Параметры и время IOperationInvoker для регистрации параметров метода и того, сколько времени потребовалось для завершения операции, чтение this кажется, что если реализовать методы Start/Stop, продолжительность времени выполняется автоматически, в чем я не уверен, так это в том, что это будет работать в контексте атрибута и с IErrorHandler при возникновении ошибки.

<сильный>3. Уведомления IErrorHandler, чтобы зарегистрировать исключение, а затем отправить электронное письмо команде разработчиков. В настоящее время мы делаем это с помощью SMTP-сервера. Есть ли лучший способ отправки уведомлений в Azure?

Спасибо за ваше время


person Juan Zamudio    schedule 09.08.2016    source источник


Ответы (1)


Отвечая на это:

Коммуникационный стек Никогда не сравнивали производительность прослушивателя по умолчанию и WcfCommunicationListener, но мы выбрали WCF для повторного использования всех наших компонентов и в качестве первой версии, чтобы понять, как работает сервисная структура.

Расширяемость

  1. Безопасность Весь код работал одинаково, нам нужно было внести некоторые изменения в то, как работает контекст, но вся необходимая информация была там (плюс некоторые данные об узле, на котором он работал).

  2. Параметры и время. Мы использовали Azure Service Profiler с собственной реализацией Microsoft.Diagnostics.Tracing.EventSource, собирая данные с помощью IOperationInvoker, потрясающе.

  3. Уведомления IErrorHandler продолжал работать, но мы использовали sendgrid для электронных писем.

person Juan Zamudio    schedule 04.07.2017