Архитектура высоконагруженной системы Диадок

Размещаю здесь статью, которую когда-то писал для Хабра, чтобы не потерялась.

Те, кто интересуется highload-системами, читали про архитектуры Twitter, Facebook и прочие другие. Но никогда еще не было публикаций о системах такого класса, как Диадок. В отличие от Twitter, эта система не является бесплатной и доступной всем и содержит довольно большой слой бизнес-логики, предназначенной для решения задач из конкретной предметной области.


Пару слов вкратце о системе: для чего она предназначена. Чтобы было сразу понятно, что это такое, представьте web-интерфейс для почты, но это не совсем почта, точнее, совсем не почта. Данная система предназначена для обмена документами. Основные документы – это счета-фактуры и накладные. При этом электронные документы являются юридически значимыми, имеют такую же силу, как и бумажные документы с печатями и подписями.

Обмен электронными документами в России только начинает развиваться, и в не столь далеком будущем, вероятно, все счета-фактуры будут передаваться в электронном виде. Ежегодно в России создается 12 миллиардов счетов-фактур. Это в среднем 380 документов в секунду, а при пиковой нагрузке – тысячи документов в секунду. Любой проект, который нацелен на предоставление услуг по обмену электронными документами, должен рассчитывать на такие объемы и создавать соответствующую архитектуру.

Поподробнее о Диадоке с точки зрения бизнеса и бухгалтерии можно узнать на сайте Диадока, а здесь далее пойдут технические подробности.

Платформа

ОС: Windows, Linux
Язык: C#, .Net 4.0
Очередь сообщений: RabbitMQ
Хранилища данных: Cassandra, MySQL, Berkeley DB, Kanso (собственная разработка)
Протоколы: Thrift, Protocol Buffers
Кэширование в памяти: Redis
MVC: ASP.NET MVC, Razor (только для админки)
Балансировка нагрузки: Nginx.

Архитектура

Система является сервис-ориентированной (SOA). Основной формат данных для взаимодействия – Protocol Buffers от компании Google, позволяющий эффективно обмениваться данными между сервисами. Протокол взаимодействия – HTTP. При этом для публикации сервисов используется не IIS, а собственная реализация HTTP-обработчика. IIS используется только для web-интерфейса системы.
В схеме развертывания содержится список exe-файлов, которые вообще есть в системе, и при выкладывании на рабочую площадку определяется, какие сервисы на каком сервере будут работать. Если какой-либо компоненте требуется подключиться к какому-либо сервису, то происходит случайный выбор из работающих реплик сервиса и выполняется подключение.

Cassandra

Cassandra используется в основном для ведения логов благодаря высокой скорости записи данных, но последнее время применяется и для других целей, например, если нужно хранить персистентно ключ-значение. Нельзя сказать, что это идеальное key-value хранилище, но мы с ним научились работать. Для взаимодействия с Cassandra используется упомянутый протокол Thrift. Thrift – это аналог Protocol Buffers, разработанный компанией Facebook, находящийся сейчас под опекой Apache Software Foundation.

Kanso

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

MySQL

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

RabbitMQ

Этот сервис сообщений показал себя достаточно хорошо и используется для асинхронной обработки событий. Сообщения имеют ограниченный срок хранения и через несколько дней удаляются из очереди. Сюда мы, как и в http-сервисы, передаем структуры на основе Protocol Buffers.

Кэширование данных

Для кэширования данных и быстрого поиска информации используется Redis, а также целая группа сервисов на .net, которые при запуске читают данные из Kanso и записывают в свою локальную базу Berkeley DB.

Интеграция

Для публичного API также используется Protocol Buffers, но при этом есть возможность взаимодействовать через OLE Automation. Многие крупные компании сталкиваются с проблемами автоматизации интеграции, и разработчики Диадока помогают интегрировать проект с другими системами. Очень часто из внешних систем невозможно выгружать данные в XML или другом машиночитаемом формате, и мы вынуждены конвертировать данные из печатных форм (PDF) в наш формат.
Подробнее об интеграции см.:
https://diadoc.kontur.ru/sdk/IntegrationOptions.html
https://diadoc.kontur.ru/sdk/

Принципы разработки

• Очень часто используется парное программирование.
• Обязательный Code Review.
• Двухнедельное планирование итераций.
• Ежедневное совещание всей команды о текущем состоянии дел (Stand-up meeting).
• Прозрачность информации о состоянии проекта как с точки зрения маркетинга, так и с точки зрения разработки.

Инструменты разработки

• Visual Studio 2012
• Resharper
• TeamCity для Continuous Integration
• YouTrack в качестве issue tracker

Статистика

Количество программистов: 24
Количество серверов: ~40
Среднее время доставки документа: 7 сек
Зарегистрированных организаций: ~160 000