Particle1Particle2Particle3Particle4Particle5
HWdTech / Блог /

Улучшение скорости

отклика страниц

в 10+ раз

Микросервисная архитектура значительно ускорила работу городского портала.

26 Мая 2021
# микросервисная_архитектура #cases #HWdTech # microservice_architecture #web_application #новостной_портал

Reading time: 5 min

КЛИЕНТ

Популярный городской портал

Ежедневно более 50 тысяч уникальных посетителей заходят на сайт, чтобы почитать новости, подать или найти объявления.

ИСХОДНАЯ СИТУАЦИЯ

Медленное отображение страниц

Среднее время отклика страниц сайта составляет 4,5 с. По этому показателю портал - самый медленный сайт среди своих ближайших конкурентов. Пользователи массово жалуются в службу поддержки на медленную работу сайта.

О клиенте в цифрах

  • 1+ млн просмотров страниц в день;

  • 50+ тыс уникальных посетителей в день;

  • 4,5 сек - среднее время отклика страницы.

ПОСТАНОВКА ЗАДАЧИ

Сделать сайт самым быстрым среди конкурентов

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

С чего начать?

Для погружения в суть задачи мы начали с code review сайта, затем поговорили с программистами, менеджерами по работе с клиентами, службой поддержки.
Находка №1
Анализ показал, что большая часть времени при формировании страницы уходит на ожидание ответа от базы данных либо из-за большого количества запросов, либо из-за длительного времени выполнения запроса. Причиной такого поведения является слишком сложная и запутанная структура базы данных, содержащая более 200 таблиц. От программиста требуется аккуратность и хорошая квалификация, чтобы писать оптимизированные запросы к базе данных.
Находка №2
На каждой странице присутствует информация, которая берется из внешних источников, например, курсы валют, прогноз погоды, комментарии из ВКонтакте. В текущей реализации страница не отображалась до тех пор, пока, не будут получены ответы от всех внешних сервисов, причем, если хотя бы один из них не ответит, то страница не будет отображена вообще. Этот фактор сильно влияет на скорость загрузки и стабильность работы всего ресурса.
Находка №3
Проект использует 6 серверов баз данных: мастер - все данные записываются на него, и 5 подчиненных, которые являются репликами мастера. Поскольку все сервера содержат одни и те же данные, то добавление нового сервера базы данных никак не улучшит время выполнения отдельного запроса, а лишь замедлит время репликации. Почти каждую неделю происходит сбой в механизме репликации из-за взаимных блокировок, что приводит к нестабильной работе всей системы.
РЕШЕНИЕ

Микросервисная архитектура

Разбиваем все приложение на набор небольших независимых сервисов, каждый из которых решает одну небольшую задачу:
  1. Отказались от реляционной структуры базы данных. Теперь каждый сервис работал со своей изолированной коллекцией документов. Наш заказчик отказался использовать NoSQL базу, поэтому для текущей базы была написана NoSQL обертка, позволяющая работать с неструктурированными данными. Удалось описать всю работу с базой с помощью пяти (!) запросов.

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

  3. Сам сайт был переписан в виде одностраничного веб-приложения, который обращается к микро-сервисам только за необходимыми для отображения данными и грузит их асинхронно. Это существенно позволило снизить объем трафика, передаваемого на клиент и положительно сказалось на скорости отображения контента.

Анализ результатов

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

  2. Предсказуемость запросов к базе данных. Среднее время запроса к базе составило 200 мс и теперь не зависело от квалификации программиста. Стало легче прогнозировать время выполнения выполнения операции — надо, грубо говоря, разложить операцию на набор запросов к БД и умножить на 200 мс.

  3. Сокращение парка серверов в 5 раз. Удалось уменьшить количество серверов с 15 до 3 экземпляров.

Подводим итоги

Сравним вложения компании и результат, который был получен.

Затраты

Затраты на разработку составили 1,5 млн. рублей (в ценах 2013 года).

Эффект

Время открытия страницы оказалось лучше требуемого в 2,5 раза.
Читайте также

Наши статьи!

Спросите нас

Мы ответим в течение суток

* - обязательное поле

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