Выбор API-интерфейса Gateway для реализации архитектуры SOA/микросервисов

Question

Я уверен, что мне нужно использовать шлюз API, но я не могу понять основные различия между различными инструментами в сценарии использования.

В настоящее время у меня есть несколько сервисов (DBs, Mobile App, Web App и некоторые дополнительные системы. Рассмотрим 15 различных сервисов), которые взаимодействуют друг с другом через API REST. Это трудно управлять и тестировать, поэтому я хотел бы изменить архитектуру на нечто большее, чем то, что Netflix делает с Zuul.

В идеале услуги не знают о других услугах. Они отправляют запрос на конкретную конечную точку (шлюз API). Затем API-шлюз взаимодействует с необходимыми службами и отправляет ответ обратно. Вот пример на практике: служба отправляет запрос на пользовательский (конечный) коннектор, выполняется разбор запроса, разбивается на более мелкие запросы, которые отправляются другим службам (которые владеют запрошенным конкретным содержимым), возвращают содержимое в ответе, собрать все ответы, создать окончательный ответ со всем собранным контентом, отправить ответ обратно первому сервису, который отправил запрос.

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

Лучшие решения, которые, я считаю, помогут решить мою проблему: WSO2, Apigee, Zuul и Amazon API Gateway. Я не знаю, что более подходит для моего варианта использования. Я смотрел на других, но я не нашел никаких преимуществ в функциях или стоимости по сравнению с ними. 4.

Благодарим вас за отзывы о преимуществах и недостатках этих технологий! Другие предложения также приветствуются!

Примечания: Не все мои услуги находятся на AWS, но некоторые из них. Система должна обрабатывать пики с десятками тысяч запросов в минуту, которые бывают регулярными, но не всегда.

Answer 1

Поскольку у вас есть ландшафт различных микросервисов, где каждый микросервис имеет свой бизнес-контекст и доступен с помощью REST endponit. В этом случае ваш клиент не должен знать о каждом микросервисе, и, таким образом, API-порт входит в изображение, с помощью которого вы можете иметь одну точку входа во все ландшафты микросервисов.

Существуют различные решения шлюза API, доступные как вы сказали apigee, apiman и т.д. Эти рамки дают некоторую базовую реализацию функций, необходимым в API шлюзах, как запрос дросселирование, monitization из запроса вызовов, аутентификация ручка, централизованная безопасность и т.д.

Zuul Netflix предоставляет фильтры, которые необходимо реализовать самостоятельно. Итак, если вы используете Zuul, вам необходимо реализовать все функции, которые вы хотите поместить в свой шлюз API самостоятельно.

Я надеюсь, что это объяснение поможет !!!

Answer 2

Вы также можете рассмотреть шлюз API Sentry API от Forum Systems (я работаю в Forum Systems).

На основе вашего примера использования, если каждая из служб «меньшего запроса» использует одни и те же протоколы (например, HTTPS), форматы сообщений (например, JSON) и характеристики безопасности (TLS, аутентификация и т. Д.), Тогда решение должен быть относительно прямым.

Если каждый сервис использует разные идентификационные данные или форматы сообщений, скажем, тогда ваше решение API Gateway также должно иметь сильные возможности в отношении идентификации и преобразования сообщений. Например, для одного небольшого запроса может потребоваться, чтобы заголовок BasicAuth аутентифицировался для службы, тогда как для другого небольшого запроса может потребоваться утверждение SAML.