Эта статья была впервые опубликована в личном паблике WeChat: coder Xiaohei
Боль службы раскололась
После разделения сервиса ссоры между front-end и back-end студентами по поводу детализации API становятся все более частыми:
«Студенты фронтенда запрашивают два интерфейса, почему бы просто не агрегировать данные?» Студенты бэкенда хотят предоставить только базовые сервисные возможности API в сфере бизнеса, и ожидается, что обработка сборки данных будет завершена фронтендом. кончают студенты.
«Агрегация серверной части, интерфейсная часть может иметь на один запрос меньше и отвечает только за отрисовку страницы!» Студенты клиентской части надеются нести ответственность только за отрисовку страницы и ту же логику агрегации для H5, APP и апплета. может появиться на трех концах, а агрегация серверной части должна быть только один раз.
Сервис агрегации интерфейсов — одно из наших решений.
Что такое служба агрегации интерфейсов?
Служба агрегации интерфейсов — это средство переноса, которое только помогает студентам переднего плана агрегировать возвращаемые данные нескольких интерфейсов и возвращает результат соответствующего запроса клиенту сразу после агрегации.. Мы надеемся, что с помощью службы агрегации интерфейсов, среднего уровня, клиентская часть сможет напрямую получать данные, в то время как серверная часть сможет по-прежнему сосредоточиться на предоставлении основных возможностей службы API бизнес-домена.
Анализ сценария
- Сценарий 1: серийный сбор данных. Несколько запросов связаны.
- Например: получить информацию о комментарии по идентификатору продукта, получить информацию о пользователе по идентификатору пользователя в комментарии.
- Сценарий 2. Параллельный сбор данных. Несколько запросов, не связанных между собой.
- Например: получить информацию о продукте через идентификатор продукта, получить информацию о активности продукта и получить приобретенную текущую информацию пользователя
Программа исследований
| Сценарий А | Вариант Б | |
|---|---|---|
| абонент | клиент | клиент |
| API-Server | Самостоятельное изучение | GraphQL |
| Payload | соглашение | GraphQL |
| Response | соглашение | GraphQL |
| Отказоустойчивость | соглашение | соглашение |
| Динамически выбирать поля | да | да |
В конце концов, мы выбрали решение А, чтобы решить эту проблему, разработав простой промежуточный уровень агрегации интерфейсов.
Поэтому есть сервис агрегации интерфейсов: api-aggregator. Фреймворк имеет следующие особенности:
-
Код ядра составляет около тысячи строк,Легкая реализация.
-
Не навязчивый к существующему коду, нет необходимости модифицировать и адаптировать существующие сервисы и коды, а существующие интерфейсы можно использовать напрямую.
-
Предоставляет точки расширения ApiAggregatePostProcessor для вмешательства на различных этапах агрегации интерфейса,Сильная масштабируемость.
-
Интерфейс дружественный, учащиеся внешнего интерфейса могут настраивать возвращаемую структуру данных и поддерживать динамический выбор полей.
-
Логика агрегации интерфейса взаимодействует напрямую с API-агрегатором через файлы конфигурации,Добавить интерфейс агрегации, публиковать не нужно.
API-агрегатор: сервис агрегации интерфейсов
API-агрегатор считает, что агрегированный интерфейс должен быть агрегирован из результатов нескольких интерфейсов, поэтому при проектировании мы делим его на две части: метаинформация интерфейса и логика агрегации между интерфейсами.
ApiDefinition: метаданные интерфейса
ApiDefinition не только определяет метаинформацию интерфейса, но также описывает источник параметров, требуемых интерфейсом.
API-агрегатор считает, что при агрегации интерфейса параметры интерфейса метаинформации могут иметь следующие источники:
- Он передается напрямую клиентом, то есть параметры получаются напрямую из HttpRequest.
- Получается из возвращаемого значения предыдущего интерфейса. Например: получить информацию о комментарии по идентификатору продукта, получить информацию о пользователе по идентификатору пользователя в комментарии. На этом этапе параметр uid должен быть получен из возвращаемого значения предыдущего интерфейса.
ResponseDefinition: логика агрегации между интерфейсами.
ResponseDefinition описывает логику агрегации между интерфейсами.Благодаря ResponseDefinition учащиеся могут настраивать структуру данных, возвращаемую интерфейсом, или динамически выбирать необходимые поля.
Если ResponseDefinition отсутствует, API-агрегатор может просто агрегировать данные двух интерфейсов вместе (как показано на левом рисунке выше). Теперь вы можете определить структуру возврата с помощью ResponseDefinition, предоставляя учащимся переднего плана лучший опыт разработки (как показано на правом рисунке выше).
простой дизайн чата
Предварительная загрузка файла конфигурации
Информация о конфигурации объединения интерфейсов настраивается разработчиками внешнего интерфейса в фоновом режиме управления.
После того, как фронтенд-студенты отправят файл конфигурации, API-агрегатор проведет некоторый статический анализ файла конфигурации: проанализирует зависимость интерфейса и наличие проблем, таких как циклические зависимости.
Чтобы повысить производительность, после того, как API-агрегатор проанализирует соответствующую информацию о конфигурации, она будет напрямую кэширована в памяти, чтобы уменьшить повторный анализ одного и того же файла конфигурации.
Упрощенная модель http-запроса
API-агрегатор абстрагирует HttpMethodInvoker для инициирования HTTP-запросов. Возвращаемый результат получается через Поставщика, который скрывает различия API между разными Http-клиентами.
Помните сцену, упомянутую ранее?
Сценарий 1: серийный сбор данных. Несколько запросов связаны.
Сценарий 2. Параллельный сбор данных. Несколько запросов, не связанных между собой.
В API-агрегаторе эти два сценария упрощаются в один.
Прежде всего, когда API-агрегатор разбирает файл конфигурации и анализирует зависимости интерфейса, он выдает процесс HTTP-запроса, который API-агрегатор считает лучшим в соответствии с интерфейсными зависимостями, вместо последовательного запроса в соответствии с порядком интерфейса, определенным файл конфигурации.
Например:
Предполагая, что при агрегации интерфейсов необходимо запрашивать интерфейсы A, B и C, а данные интерфейса B зависят от интерфейса A, параметры запроса интерфейса A и интерфейса C могут напрямую получать параметры из HttpRequest.
Затем, в фактическом процессе агрегации интерфейсов, API-агрегатор сначала запросит интерфейс A и интерфейс C, затем заблокирует, чтобы получить возвращаемый результат интерфейса A, и, наконец, запросит интерфейс B.
предоставить точки расширения
API-агрегатор предоставляет ApiAggregatePostProcessor для облегчения последующего расширения.
Через ApiAggregatePostProcessor API-агрегатор может вмешиваться во весь процесс агрегации интерфейса, например: кэширование информации об интерфейсе, добавление журналов мониторинга и т. д.
Хотя ApiAggregatePostProcessor можно использовать для вмешательства в процесс агрегации интерфейса, вам все равно необходимо перезапустить API-агрегатор, когда вы хотите добавить новый процессор. Как точка агрегации интерфейсов API-агрегатор аналогичен шлюзу, а также является централизованной точкой трафика.В последующих версиях Groovy-скрипты могут рассматриваться как поддерживающие динамическую активацию и деактивацию процессоров.
Наконец, приглашаем всех оставить сообщение и обсудить в области комментариев, спасибо за чтение~~
Приглашаем обратить внимание на личный публичный номер: