Предложение для компаний по внедрению компонентов шлюза

Всем привет,давно я не вел блог.Старею,и очень старею.Иногда мне вдруг хочется что-то написать,но чувствую,что делать нечего,поэтому я снова сдаюсь. На этот раз я собирался написать этот блог на внутрикорпоративном форуме компании. (Предложение), подумав об этом позже, это также мое собственное осадок о шлюзе, поэтому я просто разместил его на внешнем сеть, ладно, не много чепухи, позвольте мне сначала рассказать о предыстории, наша компания провела сравнение в прошлом году Основное преобразование, разделение единого проекта на различные подсистемы и использование Dubbo, едва ли является микросервисной архитектурой. микросервисная архитектура действительно надуманная. 15 лет назад автор впервые сделал микросервисную архитектуру, и 4 года прошло, не зная об этом. Теперь, когда мы говорим о микросервисах, это просто жареный рис. Сами по себе микросервисы действительно не очень техничны. Сегодняшние слова в основном не о микросервисах, а хочу поделиться с вами компонентом, который хочу внедрить в компанию — шлюзом! Про роль шлюза говорить не буду.Каждый сам гуглит.На самом деле для архитектора слепо гнаться за ветром и слепо следовать техническим терминам-это табу. Изучение технологий заключается не в изучении существительных, а в изучении философии архитектуры. Ну, не брезгуйте, перейдем непосредственно к структуре статьи:

Текущая структура компании
Проблемы с существующей архитектурой
Роль шлюза
Несколько основных фракций существующих шлюзов
Kong

1. Существующая структура компании

Кратко расскажу о бизнес-фоне компании. Наша компания является интернет-компанией первой линии в Шэньчжэне (простите меня за позорное слово «первой линии»), специализирующейся на онлайн-торговле закупок электронных компонентов. Веб-сайт, в соответствии с характеристиками бизнеса, интерфейсный веб-сайт разделен на несколько подсистем, таких как домашняя страница, страница сведений, страница списка, страница поиска и т. д., которые все называют микросервисами. Затем вкратце поговорим о входной структуре трафика. Из-за проблем конфиденциальности компании, которые могут быть здесь затронуты, некоторые компоненты используюткомпонентзаменять:

Введение: на самом деле все очень просто.После того, как трафик будет разрешен через DNS, он будет перетекать в некоторые компоненты безопасности и компоненты SLB, а затем пойдет на три Nginx.Nginx направляет трафик на уровень Tomcat.Фокус. Компания разделена на множество подпроектов, как упоминалось выше, система заказов, система корзины покупок, структура каждой системы одинакова, конечно, некоторые Nginx являются общими. То есть могут быть системы A, B, C, D, E5.Трафик системы AB идет на три общих Nginx, а остальные являются отдельными кластерами Nginx.Основной бизнес, как правило, три отдельных кластера, которые Не очень важно, что предприятия могут совместно использовать Nginx.Это также обычная практика для большинства компаний.

Вроде все идеально....

2. Проблемы с существующей архитектурой

Я полагаю, что у большинства мелких партнеров возникает похожее чувство, увидев вышеприведенную архитектуру, потому что большинство микросервисных архитектур в отрасли именно такие. Разберите проект, используйте RPC для связи между системами, используйте платформу управления сервисами, а затем уже микросервисы. На самом деле, лично я не думаю, что это микросервис. Сначала я использовал компанию в Пекине, у которой был аналогичный набор архитектуры. Все знакомы с Dubbo для связи RPC. Позже другая компания использовала Spring Cloud. , лично я пока немного разбираюсь в микросервисах. Но здесь мы не запутываемся с проблемой микросервисов, а возвращаемся к проблеме самой архитектуры. Здесь я кратко расскажу о некоторых проблемах, существующих в этом наборе трафик-порталов:

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

Как мы все знаем, между узлами Nginx и узлами нет связи, и все они не имеют состояния. Другими словами, если есть три узла Nginx, A, B и C, которые маршрутизируются к трем Tomcats с номерами 1, 2 и 3 и теперь хотят временно добавить Tomcat с номером 4, эксплуатация и обслуживание оцениваются быть хитом импульс. Поскольку нам нужно перейти к трем узлам, чтобы изменить конфигурацию, а затем «nginx -s reload», подумайте об этом, каждый проект имеет такую структуру, количество nginx также является очень большой проблемой, проблема развертывания, изменение конфигурации проблема.

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

2.2 nginx изначально не поддерживает dlb

Как было сказано выше, в Nginx нет функции динамической балансировки нагрузки, после изменения конфигурации необходимо перезапустить nginx, что неприемлемо для компаний с очень высокой плотностью трафика. (Конечно, есть много хороших решений для поддержки динамического lb Nginx, вы можете сами погуглить, например, комбинирование с Consul и т. д.)

2.3 Невозможно динамически сократить вес трафика (выпуск canary, выпуск AB и т. д.)

На самом деле вполне понятно. Например, три ноды Tomcat сейчас висят за Nginx.Одна из нод хочет сделать AB upgrade.При переходе на новую версию нужно временно отрезать трафик.Nginx не может поддерживать динамическое изменение веса трафика. Вам необходимо перезагрузить после изменения файла конфигурации.

2.4 Нет доступа к API для системы мониторинга и персонала по эксплуатации и техническому обслуживанию.

Хороший компонент должен отображать множество внутренних индикаторов, но для Nginx он не может показать, сколько восходящих потоков существует в настоящее время, какие восходящие службы (например, Tomcat) в настоящее время проблематичны, текущую конкретную конфигурацию и т. д. Это эквивалентно к использованию черного ящика. Это очень раздражает. Не говоря уже о раскрытии API для динамического изменения конфигурации, изменения информации о маршрутизации...

2.5 Нет функции обнаружения сервисов

Я пока не буду об этом говорить.

2.6 Динамическая масштабируемость

Честно говоря, у Nginx все еще есть масштабируемость в виде модулей, но он не поддерживает динамическое подключение и отключение, что также является головной болью. Например, я написал плагин для ограничения тока и хочу динамически регулировать силу ограничения тока. Не могу этого сделать.

Глядя на вышеизложенное, можно сказать, что если узлов слишком много, то еще несколько операций и обслуживание будет в порядке, мне не нужны эти функции динамического развертывания, я могу перезапускать его каждый раз, когда пишу скрипт. Честно говоря, это действительно так, именно поэтому большинству малых и средних компаний шлюзы не нужны, ведь они не просто так нужны. Большинство компаний могут подключать весь трафик проекта к нескольким Nginx и перенаправлять его на бизнес Tomcat через Nginx.Не проблема для малых и средних компаний! Но если вы хотите быть платформой управления уровнем доступа или платформой шлюза. Просто использовать Nginx недостаточно. Давайте нарисуем для вас картинку, чтобы вы увидели, как выглядит идеальная платформа шлюза: (На рисунке ниже опущены некоторые несущественные компоненты, что не означает, что реальная архитектура такая, просто уловите ключевые моменты)

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

На самом деле, говоря прямо, я хочу настроить платформу для решения многих из вышеперечисленных проблем. Теперь, чтобы ответить один за другим:

2.1 [Конфигурация разбросана, связь между узлами невозможна, эксплуатация и обслуживание затруднены. 】

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

проект	нижестоящий узел	Веса	URL пульса	статус узла	действовать
система заказов	192.168.157.123:8888	50	/	выживать	-
система заказов	192.168.157.124:8888	100	/test	умри	-
система заказов	192.168.157.125:8888	100	/test1	выживать	-

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

2.2 [nginx изначально не поддерживает dlb]

Не говоря уже об этом, наша платформа GateWay должна поддерживать динамическую функцию lb, то есть, как только она будет настроена на платформе, она вступит в силу немедленно, без перезапуска компонентов!

2.3 [Невозможно динамически сократить вес трафика (выпуск canary, выпуск AB и т. д.)]

Точно так же, если вы хотите переключить какой-то трафик, вам нужно только работать с весом. Он также динамичен.

2.4 [Нет API, доступных для системы мониторинга и персонала по эксплуатации и техническому обслуживанию]

Наша платформа управления шлюзом управляет шлюзом в соответствии с API, предоставляемым кластером шлюза. Конечно, существуют связанные API-интерфейсы мониторинга и API-интерфейсы операций.

2.5 [Нет функции обнаружения службы]

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

2.6 [Динамическая масштабируемость]

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

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

3. Роль шлюза

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

Существуют некоторые общие функции, такие как: управление и контроль сервисной группы, публикация в оттенках серого, мониторинг автоматических выключателей, контейнерная миграция, унифицированное управление входом и выходом, адаптация протокола, переадресация протокола, политика безопасности (WAF), анти-щетка, контроль трафика, журнал мониторинг, который может гибко и динамично контролировать трафик, а шлюз API также играет роль защиты безопасности, предоставляя черный список IP и черный список URL Я не буду перечислять их все здесь, на самом деле, если честно, я хочу внедрить шлюз в компанию не из-за его многочисленных функций, а для решения некоторых из упомянутых выше проблем, что касается последних функций, у меня есть подключаться медленно. , начинать с нуля очень важно!

Стабильность шлюза очень важна.

4. Несколько основных фракций существующих шлюзов

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

4.1 zuul 1.0 & zuul 2.0

Возможно, вы знакомы с zuul1.С поддержкой Spring Cloud zuul1, все используют его один за другим.Я не буду рисовать здесь картинку, а сразу нарисую ключевые моменты:

zuul1 в настоящее время используется в сочетании с Spring Cloud spree и имеет функцию обнаружения служб.Благодаря интеграции Eureka автоматическое удаление узлов из списка очень хорошо поддерживается!
Zuul1 относится к модели пула потоков и не может поддерживать высокую пропускную способность.При возникновении проблем с серверной службой требуется прерыватель цепи.
Наши требования: Функция обнаружения сервисов не обязательна, но она должна быть доступна для автоматического исключения из списка и исключения из списка узлов. Если вы используете собственный zuul1, вы действительно можете добиться маршрутизации узлов, но вам нужно сделать свой собственный прерыватель цепи. Правильное использование автоматического выключателя поддерживается только в сочетании с Spring Cloud.

зуул2:

Модель NIO, высокая производительность (официальных данных нет, результаты отраслевых испытаний не идеальны)
Трудности с доступом к системе мониторинга APM
высокая стоимость обучения

4.2 Spring Cloud GateWay

Spring Cloud GateWay :

Модель NIO с использованием WebFlux в сочетании с Spring Cloud для автоматического обнаружения сервисов.
Результаты отраслевых испытаний не идеальны
новые компоненты

4.3 Nginx

Есть много шлюзов фракции Nginx, Orange, Kong и некоторые, разработанные на основе openresty, не перечислены один за другим, фракция Nginx — это та, которую я рекомендую.

5. Kong

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

Суммировать

Ладно, дописал, но на самом деле очень коряво.Я в основном говорил о причинах желания ввести шлюз.Немного собственного мнения написал для сравнения компонентов сзади.Мое предложение здесь заключается в том, что если вы используете экосистему Spring Cloud, то лучше использовать zuul1 и Spring Cloud GateWay. Поскольку наша компания не является системой с микросервисной архитектурой, я все же выбираю относительно чистый API-шлюз Kong, официальная информация о Kong очень подробная и очень проста в использовании. Это компонент, который мне очень нравится, если вам интересно, вы можете изучить его самостоятельно.

TODO :

Динамический даунгрейд (требуется доступ к платформе мониторинга), даунгрейд вручную.
Правила динамического ограничения тока
и т.д... Все, что можно сделать в шлюзе, можно превратить в конфигурацию на основе платформы. Конечно, некоторые высокочастотные функции работают. Низкочастотный пересмотр.