Я хочу использовать архитектуру микросервисов для своего следующего проекта на основе ядра ASP.NET.Связь между трубопроводом микросервисов
Я мог бы обменяться между службами через REST, но очень тяжело поддерживать.
Есть ли другой способ для связи между микросервисами, например, по шине событий, например, vertx.
Я мог бы использовать rabbitmq, но не знаю, если это хороший вариант.
Я думаю, что Rabbit MQ будет работать нормально, особенно если у вас много потребителей, т. Е. Требуется балансировка нагрузки и/или если вам нужны сообщения, чтобы они были постоянными, а также, если концептуально, ваши микросервисы в порядке обрабатывают сообщения.
В противном случае, поскольку вы рассматриваете REST, я бы рекомендовал WCF вместо этого.
Просто игнорируйте примеры Microsoft, которые слишком сложны. Вам необходимо создать сборку, содержащую протоколы (в терминологии WCF, контракты на обслуживание) + сообщения, которые они отправляют/получают (в терминологии WCF, контракты данных), которые будут использоваться между вашими службами. Наличие общей сборки позволит вам избавиться от этой ошибки в конфигурации XML в корпоративном стиле. Это также упростит обслуживание, чем REST, потому что компилятор проверяет правильность ваших сетевых вызовов: вы забываете обновлять одну услугу после изменения протокола, и служба прекратит компиляцию.
Here’s my demo, который использует WCF для реализации связи клиент-сервер с нулевой конфигурацией на C#. В настоящее время он настроен на использование именованного связывания каналов, т. Е. Будет работать только локально. Но легко переключаться с NetNamedPipeBinding на NetTcpBinding, что будет прекрасно работать в сети.
P.S. Если вы выберете WCF, не забывайте, что абстракция может и будет течь. Любой сетевой вызов может завершиться неудачей с любым связанным с сетью исключением. Также вам нужно будет снова подключаться (если вы этого не хотите, и у вас не слишком много сообщений в секунду, вы можете использовать протокол без подключения, например NetHttpBinding, но это гораздо менее результативно).
, а что же grpc для .net? –
Наверное, это хорошо для гетерогенных сред. Однако, когда у вас есть .NET на обоих концах сокета, protobuff более хрупкий и более дорогой в обслуживании. Дополнительные пункты отказа: дополнительный язык для протокола (в WCF вы напрямую пишете интерфейсы и классы C#), дополнительный шаг сборки затрудняет изменение протокола (WCF использует отражение во время выполнения). – Soonts
Вручную написанные классы C# легче справиться, вы можете включить в свои сообщения некоторую логику, например, конструкторы/преобразователи/форматирования, с протобаффами вы ограничены простыми структурами данных. Наконец, по моему опыту, .NET framework имеет меньше ошибок и работает лучше, чем сторонние библиотеки, особенно сторонние порты кросс-платформенных приложений. – Soonts
Это довольно широкий и основанный на мнениях, поэтому не очень подходит для stackoverflow, поэтому я просто опубликую его как комментарий: у вас есть два варианта в основном: пойти со всеми Microsoft и использовать Service Fabric и надежные сервисы или использовать стороннюю библиотеку, такую как микрофон (github.com/rogeralsing/Microphone) вместе с распределенным хранилищем ключей/значений (т. е. etcd, consol, redis и т. д.) – Tseng
Поддерживает ли поддержка материнской платы mac os x? –
Насколько я знаю, нет. На данный момент вам также нужна полная .NET Framework, но вы не указали это в своем первоначальном вопросе, поскольку ASP.NET Core работает как на .NET Core, так и на полной .NET Framework. Но он работает либо на месте, либо на Azure – Tseng