Теперь мы разработали множество сервисов с использованием веб-API asp.net (не ядра .net). нам нужно разработать шлюз, чтобы позволить клиенту подключаться к одной конечной точке, после чего этот шлюз решает, какой API вызывать для обработки входящего запроса и возврата ответа клиенту, поэтому веб-API в качестве шлюза перенаправит запрос и вернуть ответ
клиент <----> API-шлюз <----> соответствующий веб-API
Нам нужно разработать его как можно проще, но с использованием лучших практик с использованием C# и веб-API asp.net.
Любые идеи ??
Ocelot — мощная библиотека, но она используется в .Net Core, что помогает нам создавать отказоустойчивый шлюз, и я не уверен в аналогичных библиотеках Asp.net, которые можно использовать в этом случае. Если вы не можете найти подходящую библиотеку или поставщика (поставщики шлюзов облачного API, такие как azure, AWS) и вам нужно написать собственный API-интерфейс шлюза, вам нужно знать о нескольких вещах.
Лучшие практики для шлюза API.
Шлюз API очень полезен, но в то же время он может быть узким местом. Ваш шлюз должен быть устойчивым и высокодоступным. В зависимости от нагрузки вашего запроса вам может потребоваться реализовать такие шаблоны, как «Автоматический выключатель», «Повторить попытку» и «Наборная головка», и для этого вы можете использовать библиотеку Polly. Вы можете регистрировать свои запросы для отладки и мониторинга производительности. Безопасность — это еще один аспект, но на самом деле он зависит от того, как вы реализуете аутентификацию. Вы можете использовать комбинацию следующих библиотек для достижения своей цели.
https://github.com/App-vNext/Полли
https://github.com/reactiveui/refit
поэтому API-интерфейс шлюза будет отдельным проектом веб-API, который можно развернуть независимо. он будет использовать http и rest для вызова других сервисов. один или несколько контроллеров действительно зависят от вас, например. вызов продуктов проходит через контроллер, вызовы заказов с другого контроллера. но вызывающий механизм должен быть устойчивым. если ваш один из сервисов не работает, вы не можете продолжать накапливать запросы, и поэтому я предложил шаблоны выше. суть в том, что API-шлюз — это единая точка входа, где вы можете дезинфицировать каждый запрос и передавать его своим службам.
Итак, как это сделать? Можете ли вы дать мне простой пример кода? это означает, что если я добавлю новую функцию в службу, я должен добавить эту функцию в контроллер шлюза API?? или есть общий метод? может использовать базу данных для хранения каждой функции с ее URL-адресом API и для поиска, когда шлюз получает запрос? или что ???
Мы не управляем перенаправлением API в базах данных, это накладные расходы. Я делюсь с вами примером, который находится в ядре .net, но идея точно такая же. Веб-приложение в этом случае также работает как шлюз, вы можете создать отдельный API-шлюз, но принцип тот же. В данном примере веб-приложение устойчиво вызывает распределенную службу. github.com/EdwinVW/pitstop/tree/master/src/WebApp
Большое спасибо, Имран, но теперь, если я добавлю какую-либо новую функцию в любую службу, я должен добавить ее и в API-шлюз. Я прав ??? или какие другие сценарии?
Верно . Получение и чтение из самой БД - это накладные расходы.
это хороший вопрос, и я собирался добавить комментарий. Ocelot работает на основе json, поэтому вы можете настроить отображение там.
Спасибо @imran, но в чем основная идея API-шлюза ?? я сделаю один контроллер, который содержит все методы из каждой службы?!! или есть механизм перенаправления запросов API? мне нужны некоторые детали для кодирования шлюза