Архитектура И Платформа Проекта «Одноклассники»

Архитектура и платформа проекта «Одноклассники» В этом посте мы поговорим о накопленном за 5 лет опыте сопровождения высоконагруженного проекта.

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

Основная статистика

Архитектура

• Состав страниц состоит из независимых блоков (обычно портлетов), что позволяет обновлять информацию на экране по частям с помощью AJAX-запросов.

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

Без javascript страница полностью функциональна, за исключением функционала, написанного на GWT — при переходе по ссылкам она просто полностью перерисовывается.

• Функциональные компоненты, такие как сообщения, обсуждения и оповещения, а также все динамические части (ярлыки меню, теги фотографий, сортировка фотографий, ротация подарков) написаны с использованием платформы Google Web Toolkit. Отбор, обработка и кэширование данных: Код написан на Java. Есть исключения — некоторые модули кэширования данных написаны на C и C++.

Java, потому что это удобный язык для разработки, на Java очень много разработок в различных областях, библиотек, проектов с открытым исходным кодом.

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

Каждую секунду между этими модулями происходит около 3 000 000 удаленных запросов.

Для кэширования данных используется самописный модуль odnoklassniki-cache. Он предоставляет возможность хранить данные в памяти с помощью Java Unsafe. Мы кэшируем все данные, к которым часто обращаются.

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

ЦП загружен до 7%, максимальная загрузка в среднем за 5 минут 1,2. Количество вершин графа > 85 миллионов, связей 2500 миллионов (два с половиной миллиарда).

График занимает в памяти 30 ГБ.

Распределение нагрузки и балансировка: • взвешенный циклический анализ внутри системы; • вертикальное и горизонтальное секционирование данных как в базах данных, так и на уровне кэширования; • серверы на уровне бизнес-логики разделены на группы.

Каждая группа обрабатывает разные события.

Имеется механизм маршрутизации событий, т.е.

любое событие (или группу событий) можно выбрать и отправить на обработку определенной группе серверов.

Управление услугами осуществляется через централизованную систему конфигурации.

Система написана самостоятельно.

Через WEB-интерфейс можно изменить расположение портлетов, конфигурации кластера, изменить логику работы некоторых сервисов и т.д. Измененная конфигурация сохраняется в базе данных.

Каждый из серверов периодически проверяет наличие обновлений для запущенных на нем приложений.

Если они есть, примените их.

Данные, серверы баз данных, резервные копии: Общий объем данных без резервного копирования составляет 160 ТБ.

Для хранения и обслуживания данных используются два решения — MS SQL и BerkeleyDB. Данные хранятся как минимум в двух копиях.

В зависимости от типов данных их может быть от двух до четырех копий.

Существует ежедневное резервное копирование всех данных.

Резервные копии накопленных данных создаются каждые 15 минут. Эта стратегия резервного копирования приводит к максимально возможной потере данных в течение 15 минут. Оборудование, дата-центры, сеть: Используются двухпроцессорные, 4-ядерные серверы.

Объем памяти от 4 до 48 ГБ, в зависимости от функционала.

В зависимости от типов и использования данных они хранятся либо в памяти сервера, на дисках сервера, либо на внешних системах хранения.

Все оборудование расположено в 3 дата-центрах.

Всего насчитывается около 2400 серверов и систем хранения данных.

Дата-центры объединены в оптическое кольцо.

На данный момент пропускная способность на каждом маршруте составляет 30 Гбит/с.

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

Эти пары объединяются в общий «канал» на корневых маршрутизаторах.

Сеть делится на внутреннюю и внешнюю.

Сети физически разделены.

Разные серверные интерфейсы подключены к разным коммутаторам и работают в разных сетях.

Через внешний сетевой веб-сервер они общаются с миром.

Все серверы общаются друг с другом через внутреннюю сеть.

Топология внутренней сети — звезда.

Серверы подключены к коммутаторам L2 (коммутаторам доступа).

Эти коммутаторы подключены как минимум двумя гигабитными каналами к стеку агрегации маршрутизаторов.

Каждое соединение идет к отдельному коммутатору в стеке.

Чтобы эта архитектура работала, мы используем протокол РСТП .

При необходимости подключения коммутаторов доступа к стеку агрегации производятся более чем по двум каналам.

Затем используется агрегирование портов.

Коммутаторы агрегации подключены 10-гигабитными каналами к корневым маршрутизаторам, которые обеспечивают как связь между дата-центрами, так и связь с внешним миром.

Используются коммутаторы и маршрутизаторы Cisco. Для связи с внешним миром мы имеем прямые связи с несколькими крупными операторами связи.

Сетевой трафик в часы пик – 32 Гбит/с.

Система статистики: Есть библиотека, отвечающая за логирование событий.

Библиотека используется во всех модулях.

Он позволяет агрегировать статистику и сохранять ее во временной базе данных.

Само сохранение происходит с помощью библиотеки log4j. Обычно мы храним количество вызовов, максимальное, минимальное и среднее время выполнения, а также количество ошибок, возникших во время выполнения.

Вся статистика по времени хранится в DWH. Каждую минуту серверы СХД обращаются к временным базам данных в производстве и собирают данные.

Временные базы данных периодически очищаются от данных.

Пример кода, сохраняющего статистику об отправленных сообщениях:

   

 public void sendMessage(String message) {
    long startTime = LoggerUtil.getMeasureStartTime();
    try {
        /**
         * business logic - send message
         */
         LoggerUtil.operationSuccess(LogFactory.getLog({log's appender name}), startTime, "messageService", "sendMessage");
     } catch (Exception e) {
         LoggerUtil.operationFailure(LogFactory.getLog({log's appender name}), startTime, "messageService", "sendMessage");
     }
 }
 

   

Система основана на решениях Microsoft. Серверы баз данных – MS SQL 2008, система формирования отчетов – Службы отчетов.

На данный момент СХД состоит из 13 серверов, расположенных в среде, отдельной от производства.

Некоторые из этих серверов предоставляют оперативную статистику (т.е.

онлайн-статистику).

Некоторые отвечают за хранение и предоставление доступа к исторической статистике.

Общий объем статистических данных составляет 13 ТБ.

Планируется внедрить многомерный статистический анализ на основе OLAP.

Мониторинг

У нас есть собственная система мониторинга, основанная на оперативных данных в СХД.

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

В случае мониторинга ресурсов мы отслеживаем как «здоровье» оборудования (температуру, производительность компонентов: CPU, RAM, дисков и т.д.), так и показатели ресурсов сервера (загруженность CPU, RAM, загрузку дисковой подсистемы и т.д.).

).

Для контроля «здоровья» оборудования мы используем Zabbix, а статистику использования серверных и сетевых ресурсов накапливаем в Cacti. Оповещения о наиболее критичных аномалиях рассылаются по SMS, остальные оповещения отправляются по электронной почте.

Технологии: • Операционные системы: MS Windows, openSUSE. • Java, C, C+.

Весь основной код написан на Java. Модули кэширования данных написаны на языках C и C+.

• Мы используем GWT для добавления динамики в WEB-интерфейс.

Такие модули, как «Сообщения», «Обсуждения» и «Оповещения», были написаны с использованием GWT. • ВЕБ-серверы – Апач Томкэт • Серверы бизнес-логики работают под управлением ДжейБосс 4 • Балансировщики нагрузки на веб-уровне – ЛВС .

Мы используем IPVS для балансировки на уровне 4. • Apache Lucene для индексации и поиска текстовой информации.

• База данных: MS SQL 2005 стандартная версия.

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

Серверы с MS SQL объединены в отказоустойчивый кластер.

При выходе из строя одного из рабочих узлов его функции берет на себя резервный узел.

BerkeleyDB – для работы с BDB используется собственная внутренняя библиотека.

Мы используем BDB, реализацию C, версию 4.5. Двухузловой кластер «главный-подчиненный».

Между главным и подчиненным устройствами существует собственная репликация BDB. Запись происходит только в мастере, чтение происходит с обоих узлов.

Данные хранятся в tmpfs, журналы транзакций хранятся на дисках.

Мы делаем резервные копии логов каждые 15 минут. Серверы в одном кластере располагаются на разных линиях электропередачи, чтобы не потерять обе копии данных сразу.

Новое решение для хранения находится в разработке.

Нам нужен еще более быстрый и надежный доступ к данным.

• Когда серверы взаимодействуют друг с другом, мы используем собственное решение, основанное на Удаленное взаимодействие JBoss • Связь с базами данных SQL осуществляется через драйверы JDBC.

Люди:

Из них 40 разработчиков, 20 системных администраторов и инженеров, 8 тестировщиков.

Все разработчики разделены на небольшие команды (1-3 человека).

Каждая из команд работает автономно и разрабатывает либо какой-то новый сервис, либо работает над улучшением существующих.

В каждой команде есть технический руководитель или архитектор.

Он отвечает за архитектуру сервиса, выбор технологий и подходов.

На разных этапах разработки к команде могут присоединиться дизайнеры, тестировщики и системные администраторы.

Например, для сервиса «Группы» есть отдельная команда.

Или команда, разрабатывающая коммуникационные службы для сайта (например, системы сообщений, обсуждения, каналы активности).

Есть команда платформы, которая тестирует, пилотирует и внедряет новые технологии, а также оптимизирует существующие решения.

В настоящее время одной из задач этой команды является разработка и внедрение высокоскоростного и надежного решения для хранения данных.

Основные принципы и подходы в разработке

Примером жизненного цикла разработки является трехнедельный цикл: Неделя 0 — Определение архитектуры 1 неделя - разработка, тестирование на компьютерах разработчиков Неделя 2 — тестирование в предпроизводственной среде, выпуск в производственной среде.

Почти весь новый функционал сделан «отключенным».

Типичный запуск новой функции выглядит так: 1. функционал разработан и включен в производственную версию 2. Благодаря централизованной системе настройки функционал доступен небольшой части пользователей.

Анализируется статистика активности пользователей и загруженность инфраструктуры.

3. если предыдущий этап прошел успешно, функционал постепенно включается для все более широкой аудитории.

Если в процессе запуска нам не нравится собранная статистика, или нагрузка на инфраструктуру возрастает недопустимо, то функционал отключается, анализируются причины, исправляются ошибки, происходит оптимизация и все повторяется с 1-го шага.

Рекомендации, рекомендации и советы

разные группы таблиц располагаются на разных серверах (вертикальное секционирование), а данные из больших таблиц дополнительно распределяются между серверами (горизонтальное секционирование).

Встроенный в СУБД аппарат секционирования не используется — вся логика расположена на уровне бизнес-сервисов.

• Распределенные транзакции не используются – все транзакции происходят только в пределах одного сервера.

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

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

Вместо этого используется денормализация данных или происходит JOIN на уровне бизнес-сервиса.

При этом JOIN происходит как с данными из базы данных, так и с данными из кэша.

• При проектировании структуры данных не используются внешние ключи, хранимые процедуры и триггеры.

Опять же, чтобы снизить нагрузку на ЦП серверов баз данных.

• Операторы SQL DELETE также используются с осторожностью — это самая тяжелая операция DML. Стараемся не удалять данные повторно или использовать удаление маркера — запись сначала помечается как удаленная, а затем удаляется из таблицы фоновым процессом.

• Индексы широко используются.

Как обычные, так и кластерные.

Последние предназначены для оптимизации наиболее частых запросов к таблице.

Кэширование: • Мы используем кэш-серверы собственной разработки, реализованные на Java. Некоторые наборы данных, такие как профили пользователей, социальный график и т. д., полностью хранятся в кеше.

• Данные распределяются по кластеру кэш-серверов.

Репликация разделов используется для обеспечения надежности.

• Иногда требования к производительности настолько велики, что используются локальные кратковременные кэши данных, полученные от кэш-серверов, расположенные непосредственно в памяти серверов бизнес-логики.

• Кэш-серверы, помимо обычных операций «ключ-значение», могут выполнять запросы к данным, хранящимся в памяти, тем самым сводя к минимуму передачу ненужных данных по сети.

Использует Map-Reduce для выполнения запросов и операций в кластере.

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

• Для хранения больших объемов данных в памяти используется внекучная память Java для снятия ненужной нагрузки с Java GC. • Кэши могут использовать локальный диск для хранения данных, что делает их высокопроизводительным сервером базы данных.

Оптимизация скорости и производительности загрузки страниц • Мы кэшируем все внешние ресурсы (заголовки Expires и Cache-Control).

Файлы CSS и JavaScript минимизируются и сжимаются (gzip).

• Чтобы уменьшить количество HTTP-запросов от браузера, все файлы JavaScript и CSS объединены в один.

Маленькие графические изображения объединяются в спрайты.

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

• Нет универсальных селекторов CSS. Мы стараемся не использовать стандартные селекторы (по имени тега).

• Если нужны CSS-выражения, то пишите «одноразово».

По возможности избегайте фильтров.

• Мы кэшируем вызовы дерева DOM, а также свойства элементов, которые приводят к перекомпоновке.

Мы обновляем DOM-дерево в автономном режиме.

• В GWT мы используем UIBinder и HTMLPanel для создания интерфейсов.

Приятного чтения! Мы приветствуем вопросы.

Теги: #odnoklassniki #odnoklassniki.ru #odnoklassniki.ru #Социальные сети #Оптимизация серверов #платформа #java

• Анализ Портативного Компьютера Hp Dv5Z 1001X

  19 Oct, 24

• Привязка Dhcp К Dns

  19 Oct, 24

• Парализованный Мужчина Снова Смог Чувствовать Свое Тело

  19 Oct, 24

• Os1: Примитивное Ядро ​​Rust Для X86. Часть 3. Карта Памяти, Исключение Ошибки Страницы, Куча И Распределения

  19 Oct, 24

• Хранение Архива Изображений Для Веб-Сайта В Хранилище Blob Azure.

  19 Oct, 24

• Империя Наносит Ответный Удар 2

  19 Oct, 24

• Поддержка Biztalk Server: Полезные Советы. Часть 2

  19 Oct, 24

• Стартап: Новостной Агрегатор, Объединяющий Новости Одной Темы

  19 Oct, 24

• Мобильная Юридическая Система Iplex.profi

  19 Oct, 24

• Австралийцы Признают Интернет-Банкинг Более Важным Изобретением, Чем Ipod

  19 Oct, 24