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

Инструменты

Для разработки платформы инвестирования был выбран старый добрый PHP и очень быстрый и хорошо себя зарекомендовавший в прошлых проектах PHP-фреймворк Yii первой версии.

База данных

Разрабатывая новую систему, в первую очередь задумываешься об объемах и формате данных, которые необходимо будет хранить.
Заглядывая далеко вперед, мы основательно подошли к разработке архитектуры платформы.
Подход к ее расширяемости и масштабируемости был продиктован максимальными показателями (на тот момент) Кикстартера.

А именно:

• 3.000.000 юзеров
• 100.000 проектов
• каждый юзер в среднем инвестирует в 3-10 проектов, но бывают и исключения по 500-700 проектов
• каждый юзер подписывается на 20-50 проектов
• а вот в каждом проекте может быть
• 2000-5000 инвесторов и 5000-20000 подписчиков

Следовательно, пришлось бы делать запросы к таблицам с миллиардами записей. Дабы этого избежать, было решено реализовать горизонтальный шардинг таблиц базы данных.

Особенности горизонтального шардинга:

• Части одной и той же таблицы могут находиться на разных физических серверах
• В web-приложении нужное соединение с каждой из бд выбирается по заранее определенному алгоритму
• Перед каждым обращением к таблице выбирается нужное соединение

В основе всех сущностей данных платформы лежит стартап, поэтому он и лег в основу алгоритма выбора соединения. Был написан класс работы с базой данных, который сам в зависимости от ID стартапа выбирет требуемое подключение и таблицу, не требуя где-либо в коде явных указаний.

Работает это так: необходимо получить количество подписчиков для определенного проекта, допустим с id 600. При построении запроса класс доступа к базе данных определяет, что необходимо использовать спот номер 2. Из конфигурационного файла извлекается соединение db и название таблицы subscriber2, и автоматически подставляется в запрос.

Конфигурационный файл связи спотов, серверов и таблиц БД очень упрощенно выглядит приблизительно так:

В качестве СУБД был выбран надежный и производительный PostgreSql. Пока что наши web-серверы используют всего один сервер баз данных, поскольку тщательное кэширование запросов, страниц и фрагментов страниц практически лишило его нагрузки.
Еще один сервер БД отдан под реплики.

Web-серверы

Как известно, вертикальное масштабирование (докупить оперативку, более производительное железо) дорого стоит и имеет быстро достижимый предел наращивания ресурсов, поэтому мы выбрали горизонтальное масштабирование web-серверов, которое обеспечивает больший прирост производительности за меньшие средства.

Для обработки запросов от пользователей было решено построить следующую схему:

Наружу в интернет выглядывает только один сервер — балансировщик nginx, к которому непосредственно обращаются пользователи, заходя на сайт. В конфигурации балансировщика прописаны все доступные backend-сервера, на которые будут перенаправляться запросы пользователей, и которые будут отдавать им контент.

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

Для того, чтоб не было расхождения между версиями контента, отображаемого пользователям, backend’ы используют единый кэш и сессии, которые хранятся в высокопроизводительном key-value хранилище Redis.
Помимо кеша и сессий в Redis хранятся все счетчики, некоторые списки данных и статистика по посещениям пользователей, проектам и т.д.

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

При резком увеличении нагрузки на сервера, мы можем очень легко добавить любое количество backend-серверов, разворачивание нового сервера из snapshot’а занимает около трех минут.

Amazon

В ходе разработки встал вопрос о том, где же хранить файлы и картинки проектов, да так, чтоб каждый из серверов имел к ним доступ, например, когда пользователь хочет обрезать уже загруженную картинку. На помощь пришел Amazon Simple Storage Service (S3).

К слову, Амазон выручил нас дважды, для отправки писем пользователям мы подключили Amazon Simple Email Service (SES), который позволил нам делать массовые рассылки и обеспечил высокий процент попадание писем к пользователям, минуя спам-фильтры.

Последний штрих

После множества этапов функционального тестирования мы выполнили ряд нагрузочных тестов. Помог нам в этом, в первую очередь, сервис нагрузочного тестирования loaddy.com.
Тестировали в основном 4 страницы — главную страницу платформы, доступную всем неавторизованным пользователям, страницу с проектами, которая является главной для авторизованных пользователей, главную страницу отдельного проекта и промо страницу VCStart.com/start/, на которой миловидные девушки держат счетчик времени, оставшегося до финального запуска платформы.

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

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

Ждем вас, инвесторы, и вас, авторы стартапов, на нашей первой в России краудинвестиционной платформе VCStart.com!
Если интересуют какие-то подробности, буду рад ответить на них в комментариях

Автор: bediary

Источник