Это действительно брокер сообщений, но особенности amq протокола позволяют организовать весьма причудливые сценарии взаимодействия, в т.ч. обработку очереди несколькими сервисами для распараллеливания обработки.
А насчет кросс-платформенности — я имел в виду взаимодействие с приложениями на java, php и т.д. Хотя Вы правы, лучше использовать чистый .Net Core, если нет каких-то экстраординарных кейсов.
Нет, это я не пробовал. Для балансировки нагрузки и масштабирования я имею опыт использования ApacheMq. В общем-то те же фичи что описаны Вами для Microsoft Orleans, но плюс еще кросс-платформенность
оказывается MS уже в 2000 году придумала фреймворк для микросервисов — .NET Remoting в то время позиционировался как средство междоменного взаимодействия, но по сути это то же самое. Но собственно идея генерировать прокси по интерфейсу не так уж плоха, я бы даже сказал весьма продуктивна. Главное — чтобы это было просто и гибко. Согласитесь, это гораздо менее трудоемко, чем расписать структуру в yml, сгенерировать по ней заготовку сервиса и клиента, наполнить сервис функционалом и т.д.
«OpenApi упомянут» — не нашёл. Да, видимо ошибся в именовании, уже исправил.
И насчет сваггера — я не говорю что он плох. Но давайте рассмотрим процесс разработки чего-то (назовем Service) с использованием OpenApi:
1. Описать структуру сервиса и моделей данных.
2. Сгенерировать ServiceApi, реализовать в нем нужную функциональность (лучше конечно функциональность вынести в отдельный сервис и внедрить его в ServiceApi как зависимость)
3. Сгенерировать ServiceApiClient.
4. Сконфигурировать использование ServiceApiClient во всех нужных местах приложения.
5. Если планируем обращаться к ServiceApi из UI, то нужно либо как-то передать в UI конфигурации конечных точек, либо организовать редиректы, сконфигурировать CORS и т.д.
Хотя признаю, бесплатное, из коробки, документирование, валидация и другие плюшки это приятно :-)
Теперь с использованием описанного в статье подхода:
1. Разработать интерфейс IService
2. В микросервисе разработать реализацию этого сервиса и опубликовать как конечную точку (пара строк в Setup)
3. Зарегистрировать IService как зависимость во всех нужных местах и использовать ее привычным образом (в общем-то для ServiceApiClient нужно сделать ровно то же самое, но в отличие от OpenApi мы можем все интерфейсы собрать в одну сборку)
4. Ну с собственно редиректы на микросервисы из главного приложения (если нужно).
Наше приложение Microcommerce с использованием OpenApi получается несколько более громоздким, не так ли?
Эта статья — дополнение к книге Хорсдала, упомянутой во введении. Рассмотрен единственный вопрос — упрощение разработки микросервисов. В книге описывается использование Nancy, я предлагаю альтернативный подход, позволяющий оставить вопросы предоставления конечных точек, генерирования web-клиентов, переадресации «под капотом».
Опыта использования NATS у меня нет. Я немного почитал доки по Вашей ссылке, насколько я понял это message oriented система. Собственно, MQ-сервисы тоже из этой линейки, и да, я абсолютно согласен что такое решение хорошо решает проблему балансировки нагрузки.
Для такой системы взаимодействие через WebApi плохо подходит. В такой архитектуре нужно заботиться о предоставлении конфигураций каждому микросервису, плюс к тому же нужно как-то решать вопрос балансировки нагрузки.
Мне кажется в вашем случае нужна звездообразная архитектура. Как вариант — использование какого-либо MQ-сервера, RabbitMq или ApachMq. Я разрабатывал подобные системы взаимодействия приложений, и даже есть Nuget-пакет для этого, хоть меня и критикуют за велосипеды :-). Если Вам интересно — пишите в личку, я поделюсь наработками.
Очевидно, Вы невнимательно прочитали статью. Я ни в коем случае не игнорирую общепринятые фреймворки, по крайней мере OpenApi упомянут, и я с ним немало работал. Мне очень нравится swagger, но не нравится идея генерировать «болванку» для сервиса на основе yml и клиента как отдельную сборку. Предлагаемое в статье решение — просто альтернатива, и разумеется не панацея. Хорошо подходит для web-приложений, где нужно предоставлять большое количество разнородных и часто меняющих структуру данных.
И насчет логирования (пишется с одним «г» :-). Я прекрасно знаю как логируются данные и что такое ELK (не ELC). Сервис ActivityLogger — не более чем пример опроса событий. Если Вы знакомы с упоминаемой книгой Хорсдала, Вы поймете, почему я привел именно этот пример.
А насчет кросс-платформенности — я имел в виду взаимодействие с приложениями на java, php и т.д. Хотя Вы правы, лучше использовать чистый .Net Core, если нет каких-то экстраординарных кейсов.
Ну на самом деле не все так печально с типизацией на стороне клиента
habr.com/ru/post/266899
И насчет сваггера — я не говорю что он плох. Но давайте рассмотрим процесс разработки чего-то (назовем Service) с использованием OpenApi:
1. Описать структуру сервиса и моделей данных.
2. Сгенерировать ServiceApi, реализовать в нем нужную функциональность (лучше конечно функциональность вынести в отдельный сервис и внедрить его в ServiceApi как зависимость)
3. Сгенерировать ServiceApiClient.
4. Сконфигурировать использование ServiceApiClient во всех нужных местах приложения.
5. Если планируем обращаться к ServiceApi из UI, то нужно либо как-то передать в UI конфигурации конечных точек, либо организовать редиректы, сконфигурировать CORS и т.д.
Хотя признаю, бесплатное, из коробки, документирование, валидация и другие плюшки это приятно :-)
Теперь с использованием описанного в статье подхода:
1. Разработать интерфейс IService
2. В микросервисе разработать реализацию этого сервиса и опубликовать как конечную точку (пара строк в Setup)
3. Зарегистрировать IService как зависимость во всех нужных местах и использовать ее привычным образом (в общем-то для ServiceApiClient нужно сделать ровно то же самое, но в отличие от OpenApi мы можем все интерфейсы собрать в одну сборку)
4. Ну с собственно редиректы на микросервисы из главного приложения (если нужно).
Наше приложение Microcommerce с использованием OpenApi получается несколько более громоздким, не так ли?
Мне кажется в вашем случае нужна звездообразная архитектура. Как вариант — использование какого-либо MQ-сервера, RabbitMq или ApachMq. Я разрабатывал подобные системы взаимодействия приложений, и даже есть Nuget-пакет для этого, хоть меня и критикуют за велосипеды :-). Если Вам интересно — пишите в личку, я поделюсь наработками.
И насчет логирования (пишется с одним «г» :-). Я прекрасно знаю как логируются данные и что такое ELK (не ELC). Сервис ActivityLogger — не более чем пример опроса событий. Если Вы знакомы с упоминаемой книгой Хорсдала, Вы поймете, почему я привел именно этот пример.