задний план
Система событий Jingdong — это система, которая может редактировать онлайн, редактировать и обновлять в режиме реального времени и публиковать новые события, а также предоставлять услуги доступа к страницам для внешнего мира. Его высокая своевременность, гибкость и другие характеристики очень популярны, и он превратился в один из нескольких важных порталов трафика на JD.com. В последних нескольких крупных рекламных акциях количество PV, передаваемых системой, достигло сотен миллионов. С быстрым развитием бизнеса JD.com нагрузка на систему событий JD.com будет возрастать. Для поддержки быстрого развития бизнеса срочно необходима более эффективная и стабильная системная архитектура. В этой статье в основном обсуждается производительность активного просмотра страниц.
Трудности в улучшении производительности просмотра активных страниц:
1. Действия сильно различаются от действия к действию, в отличие от страниц продуктов, которые имеют фиксированный шаблон. Общая часть, которую можно извлечь из каждой страницы, ограничена, а повторное использование оставляет желать лучшего.
2. Контент страницы мероприятия разнообразен, а бизнесов много. Опираясь на большое количество внешних бизнес-интерфейсов, сложно замкнуть цикл данных. Производительность и стабильность внешнего интерфейса серьезно ограничивают скорость рендеринга и стабильность активной страницы.
После многих лет разработки и практики в рамках системы была предложена идея «асинхронного рендеринга и просмотра страниц», и на ее основе система была модернизирована и реконструирована. Благодаря эксплуатации в последние месяцы все аспекты производительности были значительно улучшены. Прежде чем поделиться «новой архитектурой», давайте взглянем на текущее состояние архитектуры нашей существующей веб-системы.
1. Развитие и текущее состояние веб-архитектуры
1. Стадия разработки
Взяв в качестве примера эволюцию архитектуры системы деятельности Jingdong, здесь не прорисована конкретная бизнес-логика, а просто описана архитектура:
2. Вторым шагом обычно является добавление кеша в местах, где потребляется производительность.В данном случае добавьте кеш Redis для некоторых операций запросов к базе данных.
3. Полностраничное повторное кэширование страницы: из-за большого объема активного содержимого страницы стоимость однократного рендеринга страницы очень высока. Здесь вы можете рассмотреть возможность кэширования всей страницы отображаемого активного контента.При следующем запросе, если в кеше есть значение, получить кеш и вернуть его напрямую.
Выше приведена эволюция архитектуры сервисного уровня системных приложений, которая является простой иллюстрацией. Чтобы уменьшить нагрузку на сервер приложений, вы можете добавить proxy_caxhe из cdn и nginx перед сервером приложений, чтобы уменьшить скорость возврата.
4. Общая архитектура (старая)
В дополнение к «службе просмотра», упомянутой в первых трех шагах, в старой архитектуре также были сделаны две другие важные оптимизации: «служба интерфейса», статическая служба.
1. Запрос на доступ сначала поступает в службу просмотра и возвращает весь фрейм страницы в браузер (существуют кеши на всех уровнях, таких как cdn, nginx и redis).
2. Для данных в режиме реального времени (таких как seckill) и персонализированных данных (таких как логин, личные координаты) используются вызовы внешнего интерфейса в реальном времени и службы внешнего интерфейса.
3. Статическая служба: статические ресурсы разделены, и все статические js и css имеют доступ к статическим службам.
Ключевые моменты: разделение сервисов просмотра и сервисов интерфейса. Фиксированная часть страницы передается службе просмотра, а изменение и персонализация в реальном времени реализуются службой внешнего интерфейса.
Служба интерфейса: разделена на две категории, непосредственное чтение кэша Redis, вызов внешнего интерфейса. Здесь вы можете использовать nginx+lua для оптимизации интерфейса прямого чтения Redis ( openresty ) без подробных объяснений. Этот обмен в основном фокусируется на архитектуре «службы просмотра».
Во-вторых, сравнение производительности старой и новой архитектуры.
Прежде чем говорить о новой архитектуре, давайте взглянем на сравнение новой энергии в старой и новой архитектуре.
1. Новые возможности сервиса просмотра старой архитектуры:
С учетом кэша cdn и кэша nginx трафик от источника обратно к серверу приложений составляет около 20%-40%.Сравнение производительности здесь только для части от источника обратно к серверу приложений.
2015 Double Eleven, метод просмотра tp99 выглядит следующим образом: (физическая машина)
Tp99 составляет около 1000 мс, а джиттер очень большой, использование памяти почти 70%, а процессора около 45%.
Нет кеша в течении 1000мс, и есть риск блокировки или даже зависания.
2. Новая архитектура и новые функции для просмотра сервисов.
Этот 2016 618 поддерживается новой архитектурой, просмотрите tp99 следующим образом (в действиях на стороне приложения и действиях на стороне ПК):
tp99 активности при просмотре мобильных устройств стабильно составляет 8 мс, а активность при просмотре ПК tp99 стабильно составляет около 15 мс. Почти прямая линия в течение дня без дрожания производительности.
Поддержка новой архитектуры, производительность процессора сервера (докера) выглядит следующим образом
Загрузка ЦП была стабильной на уровне 1%, практически без джиттера.
Результаты сравнения: Новая архитектура tp99 уменьшена с 1000мс до 15мс, потребление процессора снижено с 45% до 1%, качественно улучшена производительность новой архитектуры.
why!!!
Теперь давайте приоткроем завесу новой архитектуры.
3. Исследование новой архитектуры
1. Просмотр страниц, асинхронный рендеринг страниц
Глядя на предыдущую архитектуру службы просмотра, от 20% до 40% запросов страниц будут повторно отображать страницу.Визуализация требует пересчета, запроса и создания объекта, что увеличивает потребление ЦП и памяти и снижает производительность tp99.
Если вы можете обеспечить получение кэша полной страницы Redis для каждого запроса, этих проблем с производительностью не будет.
То есть: просмотр страниц, асинхронный с рендерингом страницы.
2. Проблемы и решения после прямого преобразования:
В идеале, если данные страницы изменяются, рендеринг может запускаться вручную (страница публикует новый контент), а изменение внешних данных может автоматически запускать рендеринг, прослушивая mq.
Однако некоторые внешние интерфейсы не поддерживают mq или не могут использовать mq, например, продукт, размещенный на странице события, меняет название продукта.
Чтобы решить эту проблему, проект представления отправляет запрос на повторный рендеринг в движок каждый заданный момент времени — самый последний контент помещается в редис. Новый контент доступен при следующем поступлении запроса. Так как действий много и невозможно определить, к каким действиям осуществляется доступ, использование таймеров не рекомендуется. Это достигается добавлением ключа кэша, логика обработки следующая:
Преимущество заключается в том, что рендеринг периодически повторно инициируется только для действий, у которых есть доступ.
4. Объяснение новой структуры:
Организуйте структуру (исключая бизнес):
viewИнженерные обязанности:
А. Получить статический HTML-код непосредственно из кеша или жесткого диска и вернуться, если страница с ошибкой не возвращается. (Производительность доступа к файловой системе относительно низкая, превышает уровень 100 мс, который здесь не используется)
б) В зависимости от того, истек ли срок действия кеша key2, определите, следует ли выполнить повторную визуализацию в движке. (Если все внешние интерфейсы вашего проекта поддерживают mq, эта функция не нужна)
обязанности инженера по двигателю: визуализировать активную страницу и поместить результат на жесткий диск, redis.
опубликовать проект, ответственность mq: страница изменяется и повторно отображается в движке. Конкретная логика страницы здесь не будет объясняться.
Задача проекта Engine состоит в том, чтобы повторно отображать страницу при изменении содержимого страницы и помещать содержимое всей страницы в Redis или отправлять его на жесткий диск.
2. просмотреть инженерную архитектуру (версия Redis)
Задача проекта View — получить содержимое страницы из redis по ссылке и вернуть его.
3.viewИнженерная архитектура (жесткий дискВерсия)
Сравнение двух версий
а. Версия Redis
Достоинства: простой доступ, хорошая производительность, особенно в случае большого количества страниц, отсутствие дрожания производительности. Один докер tps достигает 700.
Недостатки: Сильно зависит от сервиса Jingdong Redis, если возникнут проблемы с сервисом Redis, все страницы будут недоступны.
б. Версия жесткого диска
Достоинства: Не зависит ни от каких других внешних сервисов.Пока сервис приложений не завис и сеть в норме, внешний сервис можно стабилизировать.
В случае небольшого количества страниц производительность выше. Один докер tps достигает 2000.
Недостатки: В случае большого количества данных страницы (все активные страницы в системе имеют около xx G) увеличивается потребление дискового io (здесь используется java io, если используется nginx+lua, потребление io должно контролироваться в пределах 10%).
решение:
А. Доступ ко всем страницам и их хранение осуществляется с использованием метода хеширования URL-адресов, и все страницы равномерно распределяются между каждым сервером приложений.
б) Используйте nginx+lua для использования асинхронного ввода-вывода nginx вместо ввода-вывода Java.
4. Openresty+ версия жесткого диска
Теперь использование nginx + lua в качестве службы приложений, его высокая способность одновременной обработки, высокая производительность и высокая стабильность становятся все более и более популярными. Благодаря приведенному выше объяснению проект представления не имеет никакой бизнес-логики. Его можно легко реализовать с помощью lua, получить страницы из Redis или с жесткого диска и добиться более эффективных веб-сервисов. Если вы хотите изучить Java-инженерию, высокую производительность и распределенность, объясните важные вещи простым языком. Друзья микросервисов, Spring, MyBatis и исходный код Netty могут добавить мой расширенный код Java: 694549689, который включает в себя технологию прямых трансляций Али Дэниела и широкомасштабные видеоролики о интернет-технологиях Java, которыми я могу поделиться с вами бесплатно.
1. Можно добавить тех, у кого 1-5 опыт работы, кто не знает с чего начать в условиях нынешних популярных технологий и нужно прорваться через техническое узкое место.
2. Я давно работаю в компании и живу комфортно, но собеседование зашло в тупик, когда я сменил работу. К ним можно добавить тех, кому необходимо в короткие сроки обучиться и сменить место работы для получения высокой зарплаты.
3. Если у вас нет опыта работы, но основа очень прочная, вы можете добавить к java рабочий механизм, общие дизайнерские идеи и общую среду разработки java.
В ходе тестового сравнения проект представления считывает локальный жесткий диск быстрее, чем Redis (та же страница, чтение Redis — 15 мс, жесткий диск — 8 мс). Поэтому я предпочитаю использовать жесткий диск для конечной версии архитектуры, Redis используется для резервного копирования, а Redis считывается, когда чтение с жесткого диска невозможно.
Здесь хэш url front-end машины — это реализованная сама по себе логика.Проект движка можно запушить на жёсткий диск сервера просмотра по тем же правилам.Конкретная логика здесь подробно обсуждаться не будет. Позже будет время сделать отдельный обмен.
Преимущества: он обладает всеми преимуществами версии с жестким диском и в то же время удаляет tomcat и напрямую использует высокие возможности параллелизма nginx и возможности обработки ввода-вывода. Производительность и стабильность оптимизированы.
Недостатки: 1. Сломан жесткий диск, что мешает доступу. 2. Мониторинг методов и печать логов необходимо переписать с помощью lua-скриптов.
Пятое: Резюме
Будь то версия Redis, версия для жесткого диска или версия для жесткого диска openresty+, в основе лежит асинхронный просмотр страниц и рендеринг страниц.
Преимущество:
1. Вся бизнес-логика перенесена в проект движка, а новый проект представления теоретически не нуждается в подключении к сети.
2. Аварийное восстановление диверсифицировано (redis, жесткий диск, файловая система) и проще.При возникновении проблемы с внешним интерфейсом или службой отключите рендеринг проекта движка, и больше не обновляйте redis и жесткий диск .
3. Новый проект представления полностью изолирован от бизнес-логики и не зависит от внешних интерфейсов и сервисов.В период акции, даже если возникнут новые проблемы с питанием на внешнем интерфейсе или зависнут внешние сервисы, это не повлияет на нормальный доступ проекта просмотра вообще.
4. Производительность была улучшена в сотни раз, с 1000 мс до примерно 10 мс. Подробности смотрите на предыдущем скриншоте производительности.
5. Стабильность: Пока сеть сервера просмотра в норме, теоретически его можно использовать без зависаний.
6. Значительная экономия ресурсов сервера.Согласно этой архитектуре, 4+20+30=54 докера достаточно для поддержки 1 миллиарда PV. (4 nginx proxy_cache, 20 представлений, 30 движков)
Шесть: Заключение
Я занимаюсь разработкой почти 10 лет, и как паразит поглощаю ресурсы интернета. Некоторое время назад, по поручению великого бога «Чжан Кайтао», я сделал краткий план новой структуры системы событий и поделился им с вами, надеясь принести вам небольшую помощь. Это первый раз, когда я делюсь в Интернете, и неизбежно, что есть некоторые вещи, которые не рассматриваются всесторонне.В будущем я буду постепенно делиться своим собственным опытом, и все будут расти вместе. Наконец, немного куриного супа для души. . .