Микро сервисы, использующие сервисную фабрику, где размещать контроллеры

Question

У меня есть микросервисный проект с несколькими сервисами в .NET Core. Когда дело доходит до размещения контроллеров, есть 2 подхода:

1. Поместите контроллеры в соответствующие микро сервисы, с Startup.cs в каждом микро сервисе.
2. Поместите все контроллеры в отдельный проект и попросите их вызвать отдельные службы.

Я думаю, что первый подход потребует меньше усилий при написании кода, но второй подход отделяет контроллеры от реальных сервисов, использующих интерфейсы и т. Д. Есть ли разница в том, как они создаются и управляются в Fabric с использованием обоих подходов.

Answer 1

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

Перед всеми микросервисами у нас есть API-шлюз, который обрабатывает все проверки подлинности, дросселирования, контроля версий, проверки работоспособности, метрики, ведение журналов и т. Д. У нас есть интерфейсы для каждой микросервисной службы, и мы храним модели запросов и ответов отдельно для каждого контекста. , На этом уровне нет бизнес-логики, и у вас также есть возможность агрегировать ответы, когда необходимо вызвать несколько служб.

Если вы хотите спросить что-нибудь об этой структуре, пожалуйста, не стесняйтесь спрашивать.

Answer 2

Это очень широкая тема, которая может поднять вопросы для обсуждения, поскольку все зависит от предпочтений, опыта и технических стеков. Я добавлю свои два цента, но не считаю это правилом, просто мое мнение для обоих подходов.

Первый подход (API для каждого сервиса, изолированного друг от друга):

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

Второй подход (единый API для переадресации вызовов на нужные сервисы):

• У вас есть одна конечная точка, и обнаружение службы будет происходить в API, вся работа будет выполняться каждой службой.
• API должен масштабироваться для всех, даже если один сервис потребляет гораздо больше ресурсов, чем другие. просто сервис будет масштабироваться независимо.
• При таком подходе для добавления или изменения конечных точек API вы, скорее всего, обновите API и службу, поскольку отключение API повлияет на другие службы.
• Такой подход уменьшает дублирование кода, и вы можете централизовать многие общие аспекты, такие как авторизация, регулирование запросов и т. Д.
• В этом подходе меньше точек сбоев, если один из микросервисов выходит из строя, и от этой службы зависит большое количество вызовов, API будет обрабатывать больше запросов на подключение и ожидающих запросов, что повлияет на другие службы и производительность. Если он выйдет из строя, все службы будут недоступны. По сравнению с первым подходом первый подход приведет к снижению устойчивости к прокси или клиенту.

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