Эта статья представляет собой отчет г-на Ван Дуна, поделившегося в Интернете «Архитектурной практикой, стоящей за шлюзом продвижения 618, обслуживающим один миллиард вызовов».
Во время акции 618 наши шлюзы пропускают миллиарды трафика и звонков, при этом система шлюзов должна обеспечивать стабильность и высокую доступность всей системы, а также высокую производительность и надежность для поддержки бизнеса. Мы столкнулись с очень сложной проблемой.Основываясь на этой сложной проблеме, как улучшить его производительность и стабильность, а также как интегрировать сложные технологии для обеспечения высокой доступности всего шлюза и находится в центре внимания этой статьи.
1. Технологии, покрываемые шлюзом
1.1 Система шлюза
Существует два основных типа шлюзовых систем:
-
Первый называется клиентским шлюзом, который в основном используется для приема некоторых клиентских запросов, то есть серверной части АРР;
-
Второй называется открытым шлюзом, в основном компании (такие как JD.com) предоставляют интерфейсы для сторонних партнеров.
Методы, используемые этими двумя разными шлюзами, очень похожи.
К трудностям, с которыми сталкиваются шлюзы с относительно большим трафиком, относятся:
Во-первых, система шлюза должна нести миллиарды вызовов трафика.Очень важна бесперебойная работа интерфейса и потеря производительности каждого интерфейса после бэкенд-сервиса. Например, мы использовали кластер Redis, а затем построили два компьютерных зала, в каждом из которых был построен кластер Redis, чтобы гарантировать высокую доступность. Столкнувшись с мгновенным трафиком, мы внедрили некоторую технологию кэширования или более продвинутую технологию Nginx+lua+Redis, чтобы приложения с высоким трафиком можно было отделить от зависимости от JVM. Кроме того, нам нужно перебрать каждый интерфейс и понизить некоторые слабо зависимые интерфейсы через стратегию понижения, чтобы обеспечить доступность основных приложений.
Во-вторых, система шлюза на самом деле представляет собой процесс расширения HTTP-запросов на серверные службы. В нашем шлюзе реализовано более 1000 серверных сервисных интерфейсов. Как в такой ситуации мы можем гарантировать, что сервисы не будут влиять друг на друга? Как уровень архитектуры может предотвратить эффект бабочки и предотвратить сход лавин? То есть, когда проблема возникает на одном интерфейсе, она не повлияет на нормальную работу других интерфейсов. Это звучит просто, но это не так.
Существует более тысячи интерфейсов, и производительность каждого интерфейса непостоянна, и внешние ресурсы и кэши баз данных, от которых зависит каждый интерфейс, разные.Различные проблемы возникают почти каждый день.Как мы можем принять некоторые технологии изоляции, технологии управления, и т.д., чтобы при возникновении проблемы с этими интерфейсами это не повлияло на общую ситуацию?
В-третьих, мы открыли для внешнего мира тысячу сервисных интерфейсов, а за всеми интерфейсами постоянно работают десятки, а то и сотни команд, и каждый день могут запускаться новые требования. Столкнувшись с такой сложной ситуацией, мы не можем модифицировать или подключаться к сети каждый раз, когда изменяется внутренний сервер, поэтому шлюз станет очень хрупким, а стабильность будет крайне низкой.
Мы внедрили технологию динамического доступа, так что внутренний шлюз может быть беспрепятственно подключен через протокол доступа, а затем с помощью некоторых методов динамического прокси внутренний интерфейс, независимо от того, какая модификация или он-лайн сделан, может быть напрямую Через внутреннюю платформу управления он может быть прозрачно опубликован из шлюза, что решает онлайн-проблему нашего шлюза, которая зависит от службы внутреннего интерфейса.
1.2 Технологии, покрываемые шлюзом
Четыре технических направления шлюза:
Во-первых, единый доступ. То есть к трафику внешнего интерфейса (включая APP или другие источники) можно получить доступ на унифицированном сетевом уровне. Проблемы, с которыми сталкивается этот уровень: высокопроизводительная прозрачная передача, высокий одновременный доступ, высокая доступность и то, как перенаправить нагрузку на серверную часть после поступления внешнего трафика.
Во-вторых, управление трафиком в основном относится к части управления трафиком. В условиях большого трафика, как мы можем использовать некоторые технологии защиты от перегрузки, чтобы гарантировать, что шлюз не будет перегружен большим трафиком, и как мы можем использовать некоторые технологии, такие как ограничение тока, понижение версии и слияние, для защиты шлюза в всесторонний способ.
В-третьих, адаптация протокола. Как упоминалось выше, шлюз будет прозрачно передавать тысячи сервисов на серверную часть, и не каждый из этих сервисов должен быть разработан и настроен шлюзом. Через преобразование адаптации протокола мы позволяем открывать различные бэкенд-сервисы из шлюза через указанный нами протокол и через http.Конечно, шлюзом является не только протокол http, но и некоторый TCP. Внутренние протоколы JD.com относительно однородны.Есть протоколы отдыха Http и интерфейсы JSF.JSF – это фреймворк, разработанный JD.com, фреймворк вызовов RPC, похожий на double, а затем фреймворк RPC, обнаруженный на основе регистрации.
В-четвертых, защита безопасности. Эта часть очень важна для сети, потому что шлюз является экспортом всей компании, В этом слое нам нужно сделать некоторые анти-щетки, например, анти-очистку некоторого вредоносного трафика, сделать некоторые черные списки, и когда есть некоторый вредоносный трафик, пропуск Средства ограничения, такие как ограничение IP-адресов, отклоняют его от всего шлюза, предотвращая перегрузку шлюза этим вредоносным трафиком.
2. Архитектура шлюза собственной разработки
2.1 Архитектура шлюза собственной разработки
Наша собственная архитектура шлюза в основном разделена на три уровня.
Первый уровень: уровень доступа. В основном отвечает за доступ к некоторым длинным и коротким ссылкам, ограничение тока, черный и белый списки, маршрутизацию, балансировку нагрузки, переключение аварийного восстановления и т. д. На этом уровне используется технология Nginx+lua.
Второй уровень: уровень распространения (или: бизнес-уровень шлюза). Это скорее асинхронная технология NIO+Serviet3. Этот слой далее делится на несколько частей.
-
Верхний уровень — это проверка данных, на которой будет выполняться некоторая проверка подписи, проверка времени, версии, метода и т. д.
-
Следующий уровень называется уровнем вызова обобщения, который в основном преобразует запрос покоя, выставленный шлюзом, во внутренний протокол Jingdong и выполняет процесс вызова динамической адаптации. В этой части мы больше используем некоторые технологии кэширования, и на этом уровне также реализованы такие технологии, как изоляция потоков и слияние. Поскольку существует большой объем данных и преобразование протоколов, этот уровень использует технологию многоцелевого кеша, Все данные на нашем уровне шлюза не будут напрямую проникать в БД, а будут использовать метод, называемый гетерогенными данными, для прямого использования кеша. .сделано.
В середине уровня обобщения есть две части: одна называется активным уведомлением, а другая — тестированием в песочнице. Активное уведомление легко понять, то есть мы своевременно уведомим клиента через этот нисходящий канал TCP и отправим некоторые купоны или напоминания, такие как учетная запись JD.com; тестирование в песочнице в основном означает, что мы проводим внешнее тестирование.
Как показано на рисунке, крайняя правая часть — это деградация сервиса, логирование и оповещения мониторинга — эти три системы поддержки всего нашего шлюза. Понижение уровня обслуживания означает, что когда у некоторых служб возникают проблемы, их уровень понижается в первый раз; журналы используются для устранения неполадок; оповещения мониторинга будут выделены ниже, поскольку доступность шлюза в значительной степени улучшается благодаря системам мониторинга. ни системы наблюдения, ни сигнализации, как и глаз, нет никакой возможности что-либо узнать.
Третий слой: серверные различные бизнес-API (бизнес-интерфейсы). Эти интерфейсы доступны извне через шлюз.
Весь шлюз примерно разделен на три вышеупомянутых уровня: верхний уровень доступа и средний уровень — это уровень распределения шлюза, а также уровни бизнес-проверки и бизнес-логики, а затем прозрачно передают запросы к серверным службам через шлюз.
В дополнение к этим трем уровням мы смотрим на системы с обеих сторон, которые являются ядром и важной поддержкой всего нашего шлюза.
-
Реестр шлюза. Различные внутренние интерфейсы могут быть выпущены через шлюз в иностранном реестре, система имеет аналогичный интерфейс управления, если внутренние службы в соответствии с API, присущим письменному соглашению, если формат в порядке, то загружается к фону управления, ключ к публикации в Интернете. Конечно, перед локальным интерфейсом будет тест.
-
Центр аутентификации OA. Эта часть в основном используется для аутентификации.Проверки безопасности, такие как проверка многих подписей на уровне проверки данных, унифицированы на этом уровне.
2.2 Стек технологий
Некоторые технологические стеки, задействованные в нашей шлюзовой системе: первый — технология Nginx+lua на уровне доступа, второй — асинхронная технология NIO+Serviet3, третий — технология разделения, четвертый — ограничение тока понижения, пятый — технология предохранителей, шестое — кэширование, где должно кэшироваться, а где можно напрямую читать библиотеку; седьмое — разнородные данные; восьмое — быстрый отказ; последнее — мониторинг статистики, которая является очень важной частью всей системы шлюза высокой доступности .
Ниже приводится подробное обсуждение и анализ сценариев, в которых применимы эти технологии, включая проблемы, для решения которых мы их используем.
3. Основные идеи и точки улучшения процесса
Практика 1 Унифицированный доступ на уровне Nginx
Сначала посмотрите на всю архитектуру онлайн-развертывания шлюза, сначала войдите во весь шлюз Jingdong через LVS с мягкой нагрузкой, первый уровень — это ядро Nginx, после ядра Nginx — это бизнес-Nginx, а затем прозрачно передайте наши запросы через бизнес. Nginx на внутренний сервер.
Ядро Nginx в основном предназначено для распределения внешнего трафика, например, на этом уровне выполняется ограничение тока и защита от кисти. Нижний слой — это бизнес Nginx, и в этом слое реализована основная логика Nginx+lua. Этот уровень также может снизить нагрузку на ядро Nginx и нагрузку на ЦП, а некоторая логика приложения lua, такая как ограничение тока, защита от кисти, аутентификация и переход на более раннюю версию, выполняется на этом уровне.
Зачем добавлять слой Nginx+lua? По сравнению с Tomcat и т. д., Nginx на самом деле является сервером, который может обрабатывать особенно большой одновременный трафик. Основываясь на этой ситуации, у нас были проблемы раньше.Когда такого рода одновременный трафик особенно велик, когда возникает проблема с одной машиной позже, даже если вы понизите этот интерфейс, на самом деле реальный трафик все равно идет на JVM. уровня Tomcat. Когда трафик большой, трудно переварить эту вещь через JVM. Результат: когда у вашего Tomcat есть проблема, вам трудно решить проблему перезапуском, потому что трафик всегда будет есть, этот Tomcat Если что-то пойдет не так, все действия сбрасываются после перезагрузки, но они как вирусы, которые будут передаваться туда-сюда.Вы перезапускаете батч, и этот батч тут же снова заражается. Nginx, естественно, является асинхронным методом NIO, который может очень хорошо поддерживать бизнес-потребности большого параллелизма. Поэтому мы помещаем на этот уровень некоторые основные функции, такие как понижение версии, управление потоком и т. д., и позволяем ему блокировать трафик для нас на внешнем интерфейсе.
Практика 2 Знакомство с NIO и использование Servlet3 для асинхронности
Вторая практика заключается в том, чтобы ввести NIO на уровне Tomcat, использовать конфигурацию JDK7+TOMCAT7+Servlet3, чтобы сделать синхронные запросы асинхронными, а затем использовать технологию обработки мультиплексирования NIO, чтобы позволить нам одновременно обрабатывать большее количество параллелизма.
Использование асинхронного Servlet3 может улучшить пропускную способность, но время ответа на один запрос будет немного больше, но эта потеря допустима, поскольку она приведет к увеличению пропускной способности и гибкости всего приложения. Тем не менее очень стоит использовать.
Конкретная стратегия такова: бизнес-метод открывает асинхронный контекст AsynContext; освобождает текущий поток обработки tomcat; поток tomcat освобождается, а затем используется для обработки следующего запроса для повышения его пропускной способности; для завершения обработки бизнес-метод в среде AsynContext, вызовите его полный метод, который записывает ответ обратно в поток ответов. Это может улучшить возможности бизнес-логики tomcat, позволяя нам обрабатывать больше запросов с очень небольшим количеством потоков на этом уровне, не перегружаясь при очень большом трафике.
Практика 3 Искусство разделения
В этом разделе мы выберем два наиболее важных метода разделения.
Разделение парсинга запросов и бизнес-обработки
Во-первых, отделить поток разбора запроса от бизнес-потока, обрабатываемого позже, с помощью NIO.
Запросы обрабатываются одним потоком tomcat, в режиме NIO очень небольшое количество потоков может использоваться для обработки большого количества ситуаций связи. Обработка бизнес-логики и генерация ответов выполняются другим пулом потоков tomcat, изолированным от потока запроса. Пулы бизнес-потоков здесь могут быть дополнительно изолированы, и разные пулы потоков настраиваются для разных предприятий.
Разделение пула бизнес-потоков
Второй — это разделение пулов бизнес-потоков, которое заключается в изоляции различных интерфейсов или разных типов интерфейсов с помощью технологии изоляции потоков. Например, интерфейсы, связанные с заказами, обрабатываются 20 отдельными потоками, интерфейсы, связанные с товарами, обрабатываются 10 отдельными потоками, поэтому разные интерфейсы могут быть независимы друг от друга. потоков других интерфейсов.
Конкретная изоляция потоков может указывать количество групп потоков в соответствии с бизнесом. Эти потоки подготовлены для фиксированного интерфейса. Когда возникает проблема с этим интерфейсом, он будет использовать свое количество потоков и не будет занимать другие интерфейсы.Thread, который играет роль изоляции потока, так что при сбое одного API это не повлияет на другие.
Практика 4
Понижение в основном означает, что при возникновении проблемы с интерфейсом мы можем напрямую понизить интерфейс и позволить вызову вернуться напрямую, без использования других приложений. Кроме того, если есть проблема с более слабой бизнес-логикой, мы напрямую понижаем эту логику, чтобы не затрагивать другие золотые логики.
Как понизить?
Прежде всего, переключением на более раннюю версию следует управлять централизованно, например, отправлять его в различные службы приложений через zookeeper. Таким образом, соответствующий переключатель может быть найден для обработки перехода на более раннюю версию, как только возникнет проблема.
Унифицированная конфигурация, основанная на самой разработке и даунгрейде, система должна быть высокодоступной и поддерживать многомерное кэширование.Например, если мы используем zookeeper для реализации, сначала у zookeeper будет хранилище базы данных, а затем будет локальный кеш. Затем у нас будет снимок.Если zookeeper не может прочитать кеш, он загрузит некоторые базовые данные через снимок, чтобы гарантировать, что после запуска разработки он сможет ответить как можно скорее. И наш коммутатор не будет проблемой для других систем, это очень слабый, очень тонкий слой.
Точное управление потоком
После разговора о переключении, управлении трафиком и даунгрейде, давайте рассмотрим многомерную стратегию управления трафиком и даунгрейда, такую как управление по единому API или API + регион, оператор и другие измерения. Как только возникает проблема, мы снижаем рейтинг различных комбинаций, а также можем контролировать трафик в соответствии с различными измерениями, такими как секунды/минуты, чтобы добиться более точного управления трафиком.
изящная деградация
Когда дело доходит до понижения версии, то, что я сказал выше, больше относится к техническому уровню, а на бизнес-уровне мы также должны обратить внимание на плавный переход на более раннюю версию. Мы не можем сказать, что после того, как эта логика установлена, она напрямую возвращается к внешнему интерфейсу 502, что определенно недружественно. Мы обязательно свяжемся с внешним интерфейсом, например, после перехода на более раннюю версию, сообщим интерфейсному интерфейсу соответствующий код ошибки или предоставим пользователю подсказку и другие инструкции по эксплуатации, которые могут улучшить работу пользователя.
Практика 5. Дросселирование
Вредоносные запросы, вредоносные атаки, трафик вредоносных запросов могут получить доступ только к кешу, а вредоносные IP-адреса могут быть заблокированы с помощью запрета на уровне nginx;
Чтобы процесс не превышал пропускную способность системы, хоть он и будет расчетным, всегда есть сюрпризы.Если нет ограничения по току, то при превышении пиковой нагрузки системы вся система рухнет.
Практика 6 фюзинга
Когда возникает проблема с нашим внутренним механизмом и достигается определенный порог, система может автоматически отключаться и переходить на более раннюю версию — это общая идея предохранителя. У нас будет более гибкая конфигурация: например, когда интерфейс обращается три раза подряд и тайм-аут или возвращает ошибку, он автоматически фьюзится; также его можно настроить с некоторыми тайм-аутами, например, если производительность трех последовательных вызовы этого метода превышают 50 миллисекунд, он будет автоматически сгорать.После предохранителя это эквивалентно понижению версии.Если он будет вызван снова, он вернет отказ, то есть он напрямую откажется возвращаться.
Также может быть настройка после предохранителя: например, он выйдет в полуоткрытом состоянии через 5 секунд или минуту.Проснувшись снова, он проверит, в порядке ли сервис в этот день.Если нет проблема, он пойдет к вам Ранее продутый бизнес API снова открыт, и услуги могут нормально предоставляться внешнему миру. Сейчас есть некоторые практики с открытым исходным кодом, благодаря которым можно сделать хороший предохранитель.Конечно, по идеям здесь, можно и самому реализовать, это не особо сложное дело.
Практика 7. Быстро терпите неудачу — тайм-ауты в ссылке
Fail fast — очень важная практика не только для шлюзовых систем, но и для других систем, особенно с большим количеством вызовов, например, обращать внимание на настройки таймаута во всей цепочке. Это одна из вещей, на которой нам нужно сосредоточиться, когда мы готовимся к Double 11 и 618 каждый год, в том числе, когда мы обычно разрабатываем, и каждый раз, когда новый модуль выходит в онлайн, мы должны сосредоточиться на мониторинге этого. Разберемся со всеми внешними зависимостями системы, например, шлюз зависит от каких-то наших собственных бизнес-кэшей и баз данных, а еще от тысяч различных сервисов на бэкенде.
Когда дело доходит до сети, мы должны установить тайм-аут, потому что система с большим количеством вызовов, таких как шлюз, если тайм-аут не установлен, время по умолчанию может быть несколько минут.Проблема в том, что весь шлюз система может рухнуть в одно мгновение, и любой интерфейс нельзя будет использовать извне, из-за огромного количества данных вас может смыть раньше, чем вы сможете понизить версию.
Практика 8 Мониторинг статистики — прикладной уровень
Статистика мониторинга является очень важной частью системы шлюза. Только с помощью мониторинга и сигналов тревоги мы можем знать обо всех операциях и каждом вызове API в режиме реального времени.
контролировать цель
Во-первых: Гарантия 7*24 часов системы охраны;
Во-вторых: он может отслеживать состояние работы системы в режиме реального времени, например, какой API слишком долго вызывается? Какой API не работает? и т.д;
Третье: статистические данные, показатели анализа. Например, по прошествии суток есть ли тайм-аут для каждого вызова API? Есть ли ухудшение производительности доступа и т.д.;
Четвертое: будильник в реальном времени. Поскольку мониторинг является частью этого, возможность уведомить нас, как только проблема будет обнаружена, чтобы мы могли немедленно ее решить, также является аспектом улучшения работоспособности системы.
Диапазон мониторинга
измерения мониторинга
-
Первый уровень: аппаратный мониторинг. Например, системная память ЦП, сетевая карта и так далее.
-
Второй слой: пользовательский мониторинг. Например, позвонить в полицию напрямую.
-
Третий уровень: мониторинг производительности. Например, индикаторы TP каждого интерфейса, TP999, TP99, TP90, TP50, четыре индикатора производительности используются в качестве справочных стандартов для SLA, доступности и т. д., что очень важно для шлюзов.
-
Четвертый уровень: мониторинг сердцебиения. На системной линии шлюза много машин. Какова текущая ситуация с каждой машиной? Есть ли запас и т.
-
Пятый уровень: мониторинг бизнес-уровня. Например, у нас будет некоторый мониторинг JVM, мониторинг количества подключений Nginx и т. д.
На JD.com есть очень полная система мониторинга, называемая системой UMP, которая может помочь нам контролировать все уровни. В основном он предоставляет нам некоторые файлы, похожие на конфигурацию.После того, как мы настроим его, мы можем контролировать систему.Когда мы это делаем, мы будем отслеживать все методы через некоторых агентов АОП. Поскольку мы являемся шлюзом, нам нужно много внутренней прозрачной передачи.Поскольку шлюз динамически генерирует эти интерфейсы, он вообще не знает, какие интерфейсы существуют, поэтому, когда интерфейс создается динамически, АОП автоматически внедряет его с мониторингом. один за другим Интерфейс может иметь один монитор.
Когда дело доходит до мониторинга, я должен упомянуть, что мы делаем систему шлюза для прозрачной передачи.За этим стоят различные интерфейсы и бизнес-логика.Производительность каждой бизнес-логики и интерфейса необходимо отслеживать, а затем информировать другую сторону, чтобы пусть другая сторона Чтобы исправить, поэтому после того, как мы добавили эти наблюдения, мы должны иметь возможность уведомить соответствующее ответственное лицо, включая себя, если есть проблема. Поэтому мы будем рассылать электронные письма в виде отчетов каждый день и каждую неделю, чтобы все системные руководители могли узнать о ситуации в соответствующей организации, например, есть ли проблема с производительностью, нужно ли ее исправить и т. д.
Данная статья защищена оригиналом, перепечатка без разрешения автора запрещена. linkedkeeper.com (Текст/Ванг Дун)