Эта статья была включена в мойгитхаб-адрес, добро пожаловать в службу поддержки ^_^
Думаю, все слышали о таком классическом вопросе на собеседовании: «Пожалуйста, расскажите мне весь процесс от ввода ключевого слова на Taobao до конечной отображаемой страницы, чем подробнее, тем лучше».
Эта проблема на самом деле очень сложная. Она включает в себя ряд связанных концепций и рабочих механизмов, таких как HTTP, TCP, шлюз и LVS. Если вы сможете освоить каждый из этих пунктов знаний, это значительно осветит ваше дерево навыков. четкое понимание того, как работает сеть. Даже если вы не можете полностью понять это, знание потоков трафика будет очень полезно для вас при устранении неполадок и поиске проблем. Я использовал эти знания для обнаружения многих проблем раньше. понять весь процесс, я проверил много информации и проконсультировался со многими людьми. Я считаю, что должен быть в состоянии ясно объяснить эту проблему. Однако я обнаружил, что длина письма была слишком длинной, поэтому я разделил его на две части. части, чтобы представить их по отдельности.В этой статье сначала представлен трафик в общей диаграмме архитектуры серверной части, в следующей статье будут проанализированы детали, такие как рабочие детали LVS, которые будут включать рабочий механизм коммутаторов и маршрутизаторов, и т.п.
Li Daniu начал свой бизнес.Поскольку трафика на ранней стадии не было, он только развернул сервер tomcat, чтобы клиент мог напрямую делать запросы к этому серверу.
В начале не было проблем с этим развертыванием, потому что объем бизнеса был не очень большим, и для его переноса было достаточно одной машины.Однако бизнес Ли Даниу шел по ветру и бизнес развивался быстро, поэтому производительность Одна машина постепенно столкнулась с узким местом, и поскольку была развернута только одна машина. Машина, эта машина упадет до нуля, если бизнес зависнет. Это неприемлемо. Поэтому, чтобы избежать узкого места производительности одной машины и решить скрытой опасности единой точки отказа, Ли Даниэль решил развернуть еще несколько машин (предположительно три), чтобы можно было позволить клиенту случайным образом поразить одну из машин, чтобы даже если одна из машин зависла , другие машины все еще живы, и пусть клиент поразит другие машины, которые не отключены.
Теперь вопрос, какую из этих трех машин должен вызвать клиент?Определенно не подходит для выбора клиентом, потому что если клиент выбирает конкретный сервер, он должен знать, какие серверы есть, а затем использовать опрос и другие методы случайного подключения к одной из машин, но если один из серверов не работает, клиент не может это воспринять заранее, то очень вероятно, что клиент подключится к вышедшему из строя серверу, так что выбирайте какой из них работу по подключению машины лучше всего разместить на сервере.Как это сделать?Существует классический консенсус в архитектурном дизайне: нет ничего, что нельзя было бы решить добавлением слоя.Если есть,добавьте еще один слой,так мы на сервере. Добавьте еще один слой в конец и назовите его LB (Load Balance).LB получает запрос клиента единообразно, а затем решает, с каким сервером взаимодействовать.Как правило, Nginx обычно используется в качестве LB в отрасли.
Этот дизайн архитектуры, наконец, поддержал быстрый рост бизнеса, но вскоре Ли Даниу обнаружил, что в этой архитектуре есть проблема: весь трафик может достигать сервера, что, очевидно, проблематично и не очень безопасно.Прежде чем попасть на сервер, сделайте еще один слой аутентификации.После прохождения аутентификации мы даем ей попасть на сервер.Мы называем этот слой шлюзом (чтобы избежать единой точки отказа,шлюз также должен существовать в виде кластера)
В этом случае весь трафик перед попаданием на сервер должен пройти через уровень шлюза.После прохождения аутентификации трафик будет перенаправлен на сервер.В противном случае клиенту будет возвращено сообщение об ошибке.Помимо аутентификации, Шлюз также играет роль в контроле рисков (предотвращение нежелательной вечеринки), преобразовании протоколов (например, преобразовании HTTP в Dubbo), управлении потоком и других функциях, обеспечивающих максимальную безопасность и управляемость трафика, направляемого на сервер.
Такой дизайн просуществовал долгое время, но позже Ли Даниу обнаружил, что проблема с этим дизайном все еще существует, будь то запрос динамического или статического ресурса (например, файла js, css), который попадает в tomcat, поэтому когда трафик большой Это заставляет tomcat нести большую нагрузку.На самом деле, tomcat не так хорош, как Nginx в обработке статических ресурсов.Tomcat должен каждый раз загружать файлы с диска, что влияет на производительность.Nginx имеет такие функции, как прокси-кеш, что может значительно улучшить способность обработки статических ресурсов.
Голос за кадром: Так называемый прокси-кеш означает, что после того, как nginx получит ресурсы от сервера статических ресурсов, они будут закэшированы в локальной памяти + на диске, и если следующий запрос попадет в кеш, он будет возвращен непосредственно из локального сервера Nginx. Кэш.
Поэтому Ли Даниу сделал следующие оптимизации: если это динамический запрос, он будет отправлен на tomcat через шлюз, а если это статический запрос, он будет отправлен на сервер статических ресурсов.
Это то, что мы называемДинамическое и статическое разделение, отделяет статические запросы от динамических запросов, так что tomcat может сосредоточиться на обработке динамических запросов, в которых он хорош, а статические ресурсы используют преимущества прокси-кэша Nginx и других функций, а возможности обработки бэкэнда достигли нового уровня.
Кроме того, следует отметить, что не все динамические запросы должны проходить через шлюз, например, бэкэнд нашего операционного центра используется внутренними сотрудниками, поэтому его аутентификация не совпадает с аутентификацией API шлюза, поэтому мы напрямую развернули два Сервера операционного центра напрямую позволяет Nginx отправлять запрос операционного центра на эти два сервера, минуя шлюз.
Конечно, чтобы избежать единой точки отказа, Nginx также необходимо развернуть как минимум две машины, поэтому наша архитектура становится следующей: Nginx развертывает две машины, которые существуют в виде основной и резервной, а резервный Nginx будет использовать механизм поддержки активности (отправлять пакеты пульса) для своевременного обнаружения выживаемости основного Nginx и обнаружения времени простоя, чтобы действовать как основной Nginx.
Кажется, что эта архитектура действительно хороша, но следует отметить, что Nginx — это семиуровневый (т.е. прикладной) балансировщик нагрузки, а это значит, что если он хочет перенаправить трафик, он должен сначала установить TCP-соединение с клиентом, и при пересылке он также должен взаимодействовать с клиентом.Переадресованный восходящий сервер устанавливает TCP-соединение, и мы знаем, что для установления TCP-соединения на самом деле требуется память (сокет TCP, буферы приема/отправки и т. д. должны занимать память), и и клиент, и вышестоящий сервер должны сначала отправить данные, сохранить их в Nginx, а затем передать другой стороне через TCP-соединение на другом конце.
Таким образом, нагрузочная способность Nginx ограничена рядом конфигураций, таких как машинный ввод-вывод, память ЦП и т. д. Как только будет много подключений (например, миллионы), сопротивление нагрузки Nginx резко упадет.
После анализа видно, что плохая нагрузочная способность Nginx в основном связана с тем, что балансировщик нагрузки уровня 7 должен установить два TCP в восходящем и нисходящем потоках, поэтому можно ли спроектировать маршрутизатор, который только загружает и пересылает пакеты но не требует установления соединения.Что касается балансировщика нагрузки, так как ему не нужно устанавливать соединение, он отвечает только за пересылку пакетов, и ему не нужно поддерживать дополнительные TCP-соединения, его грузоподъемность неизбежно будет сильно улучшен, поэтому родился четырехуровневый балансировщик нагрузки LVS, просто сравните эти два отличия.
Видно, что LVS просто пересылает пакеты и не требует установления соединения с восходящим и нисходящим потоком для пересылки пакетов.представлениеВысокий, может достигать 60% аппаратного обеспечения F5; низкое потребление памяти и ресурсов процессора
Так как же работает балансировщик нагрузки уровня 4?
Когда устройство балансировки нагрузки получает первый запрос SYN от клиента, оно выбирает оптимальный сервер с помощью алгоритма балансировки нагрузки, изменяет целевой IP-адрес в пакете (изменяется на IP-адрес внутреннего сервера) и перенаправляет его непосредственно на сервер. . Установление TCP-соединения, то есть трехстороннее рукопожатие, устанавливается непосредственно между клиентом и сервером, а устройство балансировки нагрузки действует только как действие пересылки, подобное маршрутизатору. В некоторых сценариях развертывания, чтобы гарантировать, что возвращаемые сервером пакеты могут быть правильно возвращены на устройство балансировки нагрузки, исходный адрес источника пакета может быть изменен при пересылке пакета.
Подводя итог, мы добавили уровень LVS поверх Nginx, чтобы он мог принимать весь наш трафик.Конечно, чтобы обеспечить доступность LVS, мы также развертываем LVS в активном и резервном режимах. , если Nginx примет эту архитектуру. Если емкости недостаточно, мы можем легко расширяться по горизонтали, поэтому наша архитектура улучшена следующим образом:
Конечно, если есть только один LVS, его невозможно найти при большом трафике.Что делать?Добавить еще несколько и использовать балансировку нагрузки DNS, чтобы случайным образом попасть в один из них при разборе доменного имени.
Таким образом поток трафика можно наконец стабилизировать.Есть момент, что у некоторых друзей могут возникнуть вопросы.Давайте посмотрим.
Поскольку LVS может развертывать несколько модулей, чтобы избежать единой точки отказа, то же самое может сделать и Nginx, а Nginx также начал поддерживать его после версии 1.9.четырехъярусная нагрузкаСбалансированный, значит, LVS не нужен?
Если вы не используете LVS, схема архитектуры выглядит так
Действительно возможно развернуть несколько Nginx, когда трафик не такой большой, но LVS является модулем ядра Linux и работает в режиме ядра, в то время как Nginx работает в пользовательском режиме и является относительно тяжелым, поэтому с точки зрения производительности и стабильности Nginx не так хорош, как LVS, поэтому мы используем метод развертывания LVS + Nginx.
Кроме того, я думаю, вы также заметили, что если трафик большой, статические ресурсы должны быть развернуты на CDN, и CDN автоматически выберет ближайший к пользователю узел и вернет его пользователю, поэтому наше последнее улучшение архитектуры следующим образом
Суммировать
Архитектура должна быть разработана в соответствии с реальной ситуацией в бизнесе.На самом деле говорить об архитектуре без бизнеса - хулиганство.Видно, что вывод каждой из вышеперечисленных архитектур тесно связан с развитием нашего бизнеса.Как балансировки нагрузки достаточно, после быстрого роста трафика рассмотрите возможность использования lvs+nginx.Конечно, для огромного трафика, такого как Meituan (трафик в десятки Гбит/с, десятки миллионов одновременных подключений), lvs не работает (хотя реальное измерение использует lvs, но потери пакетов все равно много) поэтому они разработали собственный набор четырехуровневого балансировщика нагрузки MGW
Кроме того, прочитав эту статью, я считаю, что каждый должен иметь более полное представление о концепции многоуровневости.Нет ничего, что не может быть решено многослойностью.Если есть, то добавьте еще один слой.Расслоение выполнять свои обязанности и функции. Развязка и легкое расширение. Знакомый TCP/IP является хорошим примером. Каждый уровень отвечает только за свои дела. Что касается того, что реализует нижний уровень, то верхний уровень не заботится.
Выше приведено все содержание этой статьи, надеюсь, вы что-то почерпнете из ее прочтения ^^, в следующей статье мы продолжим углубляться в круговорот запроса, и глубоко разберем принципы работы LVS, коммутаторов, роутеров и т.д., так что следите за обновлениями ^^
приветствую всех добро пожаловатьПубличный аккаунт "Код Море", общий прогресс