Количество слов для чтения:1501 | 4 минуты чтения
Видеообзор и PPT-адрес гостевых выступлений:t.cn/RnP2eZZ
Резюме
В этом выступлении Сюй Джин, основатель сообщества SpringCloud China, поделился своим опытом исследований и разработок в Spring Cloud Zuul и промежуточном программном обеспечении шлюза.
Введение в шлюз
Шлюз API предоставляет полностью управляемые службы API, богатые функции управления API и помогает предприятиям управлять крупномасштабными API для снижения затрат на управление и рисков безопасности. - Определение от Alibaba Cloud.
Включая адаптацию протокола, переадресацию протокола, политику безопасности (WAF), антибраш, трафик, журналы мониторинга.
Общие функции шлюза
Единый доступ: предоставление унифицированных услуг доступа для различных беспроводных приложений;
Высокая производительность, высокий уровень параллелизма, высокая надежность;
Балансировка нагрузки, аварийное переключение (мультиактивность в разных местах).
Безопасность: сотрудничество с отделом безопасности, черный список IP-адресов, черный список URL-адресов;
Контроль ветра, анти-злонамеренная атака и т.д.
Адаптация протокола: Front-end система (http, http2) back-end бизнес-система (RPC);
Поддержка длинных и коротких ссылок;
Согласно внешнему запросу, он направляется в соответствующий сервис SOA и выполняется, а результат возвращается во внешний интерфейс.
Управление трафиком: Ухудшение качества обслуживания, автоматический выключатель, маршрутизация (приложения в удаленной многозадачности).
На приведенном выше рисунке показано расположение шлюза в удаленной мультиактивности. В удаленном мультиактивном шлюзе может потребоваться разработка фильтра, который в основном используется для маршрутизации пользовательских сегментов. Например, если пользователь помогает другу в Пекине разместить заказ в Шанхае, он должен направить осколок в компьютерный зал в Пекине через шлюз и выполнить все вызовы службы или данные, поступающие в компьютерный зал в Пекине. Следовательно, шлюзы также очень важны в удаленной многозадачности.
Spring Cloud Zuul
SpringCloud Zuul интегрируется с Spring Cloud Eureka, регистрируется на сервере Eureka, интегрируется с Eureka, Ribbon, Hystrix и т. д. и получает информацию об экземплярах всех других микросервисов от Eureka.
Во-первых, после поступления http-запроса он обязательно пройдет через Zuul Servlet или может пройти через Zuul Filter Runner. Runner предназначен для управления порядком всех цепочек фильтров или взаимодействия данных.Filter Runner в основном управляет всем жизненным циклом Zuul.
После поступления пользовательских запросов будет много информации, которая будет передаваться в жизненном цикле Zuul через контекст контекста запроса.
FilterLoader загружает фильтр из локального или из указанного каталога в динамическом фильтре при запуске Zuul.
Как показано на рисунке, Zuul в основном разделен на четыре типа фильтров в дополнение к пользовательским фильтрам. Один из них — «предварительные» фильтры (простой в обращении с фильтром), а другой — «маршрутизирующие» фильтры, то есть фильтр для маршрутизации службы. Существуют также фильтры «пост» и фильтры «ошибка». Если в какой-либо ссылке или настраиваемых фильтрах есть исключение, оно будет переходить непосредственно к фильтрам «ошибок» с контекстной информацией запроса. Если после запуска всех процессов ошибки не будет, обязательно будет вызвана внутренняя служба.
запрос на переадресацию
Тестовая переадресация при аннотации @EnableZuulProxy. Получив доступ к URL-адресу шлюза: http://localhost:8041/api-url/sc/order/1
Обычно вы можете перенаправить запрошенный URL-адрес на http://localhost:8000/sc/order/2.
Правила маршрутизации по умолчанию
Примечание. По умолчанию Zuul будет проксировать все микросервисы, зарегистрированные на сервере Eureka, а правила маршрутизации Zuul следующие:
http://ZUUL_HOST:ZUUL_PORT/serviceId микросервисов на Eureka/**
Он будет перенаправлен в микрослужбу, соответствующую идентификатору службы.
http://localhost:8040/sc-zuul-first-provider/sc/order/2
Балансировка нагрузки шлюза
http://localhost:8040/sc-zuul-first-provider/sc/order/2
Получите доступ к поставщику услуг через шлюз, и балансировка нагрузки напечатает соответствующий журнал.
Зачем нужно разрабатывать собственный шлюз?
1. Конфигурация шлюза вступает в силу в режиме реального времени, настраивайте оттенки серого, откат и т.д.
2. Производительность шлюза, особенно антибраширование, ограничение тока, WAF и т.д.
3. Динамический фильтр, в настоящее время Zuul может реализовать динамический фильтр, доставку конфигурации фильтра, динамический фильтр в реальном времени.
4. Мониторинг, оповещение, распределение трафика и кластеризация шлюзов.
5. Аудит процессов, повышение удобства работы с Dsboard.
Архитектура GW на основе Netty похожа на структуру Zuul, но есть различия в деталях, таких как метод обработки поверхности фильтра, запись высокопроизводительного шлюза на основе Netty и обработка контекста контекста запроса.
Лучший способ внешнего GW — внедрить его в GW-сервер с облегченной клиентской частью. Поскольку управление службами должно обрабатываться путем регистрации и обнаружения некоторых служб в рамках управления службами, клиент в основном выполняет пересылку или некоторую простую функциональную обработку.
Преимущество этого заключается в том, что при обновлении шлюза и структуры управления службами связь между ними довольно низка, и шлюз может быть обновлен сам по себе с итерацией версии. Что касается внутренней службы REST или службы RPC, то на стороне клиента выполняется только тонкая переадресация, что позволяет добиться разделения.
Фильтр должен выполнять только одну обязанность. Как показано на рисунке выше, фильтр имеет абстрактный интерфейс, который будет выполнять некоторую обработку данных при запуске фильтра. Существует также абстрактный фильтр, который в основном выполняет некоторый CRUD данных каждого самого фильтра.
CRUD данных фильтра
Каждый Fliter имеет свои кэшированные данные, и CRUD кэшированных данных обновляется по ключу через режим наблюдателя.
Принципы проектирования шлюза
1. Каждый фильтр основан на цепочке ответственности и выполняет только одну функцию.
2. Каждый фильтр имеет свои независимые данные.
3. Порядок фильтрации потерь производительности размещается позже.
4. Запустите последовательность чтения конфигурации, сначала удаленную, если удаленная не работает, прочитайте локальную.
5. Кластерный шлюз, обратите внимание на различия и оттенки серого данных.
6. Старайтесь не зависеть от структуры управления службами, обеспечить легкий доступ и простоту обновления.
Вот и все на сегодняшнем обмене, спасибо всем!