Анализ того, как спроектировать шлюз миллиардного уровня

задняя часть открытый источник HTTP Dubbo

1. Предпосылки

1.1 Что такое шлюз API

Система Gateway API можно увидеть со внешним мировым входом Unicom, мы можем иметь дело с какой-то нефтовой логикой логики в воротах, таких как подтверждение разрешения, мониторинг, кэширование, маршрутизация запроса и так далее.

1.2 Зачем вам нужен шлюз API

  • Протокол RPC преобразуется в HTTP.

При внутренней разработке мы все используем протокол RPC (thrift или dubbo) для разработки и предоставления доступа к внутренним службам.Когда внешним службам необходимо использовать этот интерфейс, часто необходимо преобразовать протокол RPC в протокол HTTP.

  • маршрутизация запросов

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

  • Единая аутентификация

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

  • Единый мониторинг

Так как шлюз — это вход внешних сервисов, мы можем здесь отслеживать нужные нам данные, такие как входные и выходные параметры, время соединения.

  • Управление потоком, понижение предохранителя

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

Есть много компаний, которые сами внедряют уровень шлюза для доступа к своим собственным сервисам, но этого недостаточно для всей компании.

1.3 Единый шлюз API

Unified API Gateway не только обладает всеми функциями API Gateway, но и имеет следующие преимущества:

  • Модернизация унифицированных технических компонентов

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

  • Единый доступ к услугам

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

  • экономить ресурсы

Если разные отделы разных предприятий следуют нашему подходу, описанному выше, они должны сами построить уровень шлюза для этого.Можно предположить, что если в компании 100 таких предприятий и каждое предприятие оснащено 4 машинами, то потребуется 400 машин. . И для развития RD каждого бизнеса необходимо развивать этот уровень шлюза, поддерживать его в любое время и увеличивать штат сотрудников. Если есть унифицированный уровень шлюза, то для уровня шлюза этих 100 сервисов можно использовать только 50 машин, и бизнес-RD не нужно в любое время обращать внимание на этапы разработки и онлайн.

2. Дизайн единого шлюза

2.1 Асинхронные запросы

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

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

  • Tomcat/Jetty+NIO+servlet3

Эта стратегия широко используется. JD.com, Youzan и Zuul выбирают эту стратегию. Эта стратегия больше подходит для HTTP. Асинхронность может быть включена в Servlet3.

  • Netty+NIO

Netty рождается для высокой параллелизма.В настоящее время шлюз Vipshop использует эту стратегию.В технической статье Vipshop при тех же условиях у Netty пропускная способность 30w+ в секунду, а у Tomcat 13w+.Видно, что там Есть определенный пробел, но Netty должна сама обрабатывать протокол HTTP, что более проблематично.

Для шлюза ворота можно использовать для запроса сервлета, в конце концов, имеет более зрелый HTTP-протокол. Если больше обратите больше внимания пропускной способности, можно использовать Netty.

2.1.1 Полноканальный асинхронный

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

В контейнере Open Web Servlet, Asynchronous, а затем в пул резьбы до сервисного шлюза для бизнес-процесса, а затем RPC и регистрация асинхронного вызова требует обслуживания обратного вызова, перезвоните последним процессом в пуле обратного вызова.

2.2 Цепная обработка

В шаблоне проектирования есть шаблон, называемый шаблоном цепочки ответственности, Его функция состоит в том, чтобы избежать связи между отправителем запроса и получателем, чтобы несколько объектов могли получать запросы, соединять эти объекты в цепочку и следовать этой цепочке. запрос, пока не появится объект для его обработки. Этот шаблон отделяет отправителя запроса от обработчика запроса. Этот шаблон реализован в каждом из наших фреймворков, таких как filter в сервлете и Interceptor в springmvc.

Этот шаблон также применяется в Netflix Zuul, как показано ниже:

Этот шаблон в дизайне шлюза мы можем научиться разработать свои собственные шлюзы:

  • preFilters: Предварительные фильтры используются для обработки некоторых общих служб, таких как унифицированная аутентификация, унифицированное ограничение тока, понижение версии предохранителя, обработка кэша и т. д., а также обеспечивают расширение на стороне бизнеса.

  • routingFilters: используется для обработки некоторых обобщающих вызовов, в основном для преобразования протоколов и маршрутизации запросов.

  • postFilters: Пост-фильтры, в основном используемые для обработки результатов, управления журналом, записи времени и т. д.

  • errorFilters: фильтры ошибок, используемые для обработки исключений вызовов.

Этот дизайн также имеет приложения, такие как шлюзы.

2.3 Изоляция бизнеса

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

2.3.1 Изоляция семафоров

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

2.3.2 Изоляция пула потоков

Самое простое — изолировать разные сервисы через разные пулы потоков, даже если будет проблема с бизнес-интерфейсом, потому что пул потоков изолирован, это не повлияет на другие сервисы. В реализации шлюза JD.com принята изоляция пула потоков, и более важные бизнес-процессы, такие как товары или заказы, обрабатываются отдельно через пул потоков. Однако, поскольку это унифицированная шлюзовая платформа, при наличии множества бизнес-направлений каждый считает, что его бизнес важнее и требует отдельной изоляции пула потоков.Если вы используете разработку на языке Java, то в Java потоки являются относительно тяжелыми ресурсами и относительно ограничены и не очень подходят, если имеется слишком много пулов потоков, которые необходимо изолировать. Если вы используете некоторые другие языки, такие как Golang, для разработки шлюза, потоки являются относительно легкими ресурсами, поэтому лучше использовать изоляцию пула потоков.

2.3.3 Изоляция кластера

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

2.4 Запросить предел тока

Многие реализации с открытым исходным кодом могут использоваться для управления трафиком, такие как Sentinel с открытым исходным кодом, недавно выпущенный Ali, и относительно зрелый Hystrix.

Как правило, ограничение тока делится на ограничение тока кластера и ограничение тока в автономном режиме:

  • Чтобы использовать унифицированное хранилище для экономии текущего трафика, обычно можно использовать Redis, который обычно имеет некоторую потерю производительности.
  • Ограничение тока для одной машины: Ограничено каждой машиной, которую мы можем делать напрямую с бочонками токенов Guava, потому что нет потребления производительности удаленных вызовов.

2.5 Переход на более раннюю версию

Эта часть также может относиться к реализации открытого источника Sentinel и Hystrix, которая не является ключевой точкой здесь.

2.6 Обобщенные вызовы

Обобщенные вызовы относятся к преобразованию некоторых протоколов связи, например преобразованию HTTP в Thrift. В некоторых шлюзах с открытым исходным кодом, таких как Zuul, это не реализовано, потому что внутренние протоколы связи службы каждой компании различны. Например, Vipshop поддерживает HTTP1, HTTP2 и бинарные протоколы, а затем конвертирует их во внутренние протоколы, Taobao поддерживает HTTPS, HTTP1, HTTP2 и т. д. Эти протоколы можно конвертировать в HTTP, HSF, Dubbo и другие протоколы.

2.6.1 Обобщенный вызов

Как реализовать вызов обобщения? Поскольку протокол сложно преобразовать автоматически, фактически интерфейс, соответствующий каждому протоколу, должен обеспечивать сопоставление. Проще говоря, оба протокола могут быть преобразованы в общий язык и, таким образом, преобразованы друг в друга.

Вообще говоря, есть три способа указать общий язык:

  • json: формат данных json относительно прост, скорость синтаксического анализа высокая, и он легче. В экосистеме Dubbo есть проект HTTP to Dubbo, который использует JsonRpc для преобразования HTTP в JsonRpc, а затем в Dubbo.

Например, вы можетеwww.baidu.com/id= 1 Get можно сопоставить с JSON:

кодовый блок

{
  “method”: "getBaidu"
  "param" : {
    "id" : 1
  }
}
  • xml: XML-данные тяжелые и их сложно анализировать, поэтому я не буду обсуждать их здесь.

  • Пользовательский язык описания: как правило, стоимость относительно высока, необходимо определить язык для описания и анализа, но его масштабируемость, индивидуальная индивидуальность являются самым высоким сопротивлением. Пример: spring установите свой собственный язык выражений SPEL

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

2.7 Платформа управления

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

  • Ограничение
  • предохранитель
  • тайник
  • бревно
  • пользовательский фильтр
  • Обобщенный вызов

3. Резюме

Последний разумный стандартный шлюз должен быть реализован следующим образом:

--- Jingdong. Випшоп Понравилось Али Zuul
Ключ к достижению servlet3.0 netty servlet3.0 servlet3.0 servlet3.0
Асинхронный случай Сервлет асинхронный, неясно, является ли RPC асинхронный Полная асинхронная ссылка Полная связь асинхронной Полная асинхронная ссылка Zuul1 синхронно блокирует, Zuul2 асинхронно и неблокирует
Ограничение --- --- Плавное ограничение тока. Первоначально это был кодис, а позже он был переключен на ведро токенов каждой отдельной машины, чтобы ограничить ток. 1. Базовое управление потоком: QPS на основе API для ограничения тока. 2. Оперативное управление потоком: Поддержка пакета потока APP, управление потоком APP+API+USER 33. Большое управление потоком продвижения: управление потоком веса API доступа к APP. Али с открытым исходным кодом: Sentinel Предоставленный пакет JAR: Spring-Cloud-Zuul-RateLimit. 1. Текущее ограничение на запрашиваемый целевой URL-адрес (например, URL-адресу разрешено только звонить сколько раз в минуту). 2. Текущее ограничение на IP-адрес доступа клиента (например, сколько раз разрешено разрешать запросы в минуту) 3. Ограничение потоковой передачи для некоторых конкретных пользователей или групп пользователей (например: ограничение для не-VIP пользователей только в минуту) Supreme API и т. д.) 4. Многомерное ограничение смешанного тока. В настоящее время вам необходимо реализовать некоторые механизмы прокрутки некоторых текущих правил потока. Выровнять с или, не- Поддержка четырех методов хранения: ConcurrentHashmap, Consul, Redis, базы данных.
Слияние понижения --- --- Hystrix --- Поддерживается только автоматический выключатель уровня обслуживания, а не уровень URL.
изолировать изоляция пула потоков --- Изоляция семафора --- Изоляция пула потоков, изоляция семафора
тайник redis --- Вторичный кеш, локальный кеш + CODIS HDCC Местный кеш, удаленный кеш, база данных Нужно разработать самостоятельно
Обобщенный вызов --- http, https, http1, http2, двоичный dubbo,http,nova hsf,dubbo,http,https,http2,http1 Поддерживает только http

4. Ссылка

Последняя статья была включена в JGrowing-CaseStudy, всеобъемлющий и отличный маршрут изучения Java, совместно созданный сообществом. Если вы хотите участвовать в обслуживании проектов с открытым исходным кодом, вы можете создать его вместе. Адрес github:GitHub.com/Java растет…Пожалуйста, дайте мне маленькую звезду.

Если вы считаете, что в этой статье есть статьи для вас, вы можете подписаться на мой технический общедоступный аккаунт или присоединиться к моей группе технического обмена для большего количества технических обменов. Ваше внимание и пересылка - самая большая поддержка для меня, O(∩_∩)O.