Развитие нашей платформы началось еще в 2013 году, когда наша команда, полная вдохновения и энтузиазма, взялась за этот амбициозный и интересный проект, который позволит нам объединить средства тысяч мелких частных инвесторов и энтузиастов стартапов для реализации бизнес-идей.
Инструменты
Для разработки инвестиционной платформы мы выбрали старый добрый PHP и очень быстрый и хорошо зарекомендовавший себя PHP-фреймворк Yii, версия 1, хорошо зарекомендовавший себя в прошлых проектах.
База данных
Разрабатывая новую систему, вы в первую очередь думаете об объеме и формате данных, которые необходимо будет хранить.Заглядывая далеко вперед, мы тщательно подошли к разработке архитектуры платформы.
Подход к его расширяемости и масштабируемости был продиктован максимальными (на тот момент) показателями Kickstarter. А именно:
- 3 000 000 пользователей
- 100 000 проектов
- Каждый пользователь в среднем инвестирует в 3-10 проектов, но бывают исключения в 500-700 проектов.
- каждый пользователь подписывается на 20-50 проектов
- но в каждом проекте может быть
- 2000-5000 инвесторов и 5000-20000 подписчиков
Чтобы этого избежать, было решено реализовать горизонтальное шардинг таблиц базы данных.
Особенности горизонтального шардинга:
- Части одной и той же таблицы могут располагаться на разных физических серверах.
- В веб-приложении необходимое подключение к каждой из баз данных выбирается по заранее заданному алгоритму.
- Перед каждым обращением к таблице выбирается необходимое соединение
Написан класс для работы с базой данных, который в зависимости от ID запуска выбирает необходимое соединение и таблицу, не требуя явных указаний где-либо в коде.
Работает это так: нужно получить количество подписчиков конкретного проекта, скажем с id 600. При построении запроса класс доступа к базе данных определяет, что необходимо использовать спот номер 2. Соединение с БД и имя таблицы subscriber2 извлекаются из файла конфигурации и автоматически подставляются в запрос.
Файл конфигурации для подключения спотов, серверов и таблиц базы данных выглядит очень упрощенно вот так: 
В качестве СУБД была выбрана надежная и производительная PostgreSql. На данный момент наши веб-серверы используют только один сервер базы данных, поскольку тщательное кэширование запросов, страниц и фрагментов страниц оставило его практически незагруженным.
Еще один сервер базы данных выделен для реплик.
Веб-серверы
Как известно, вертикальное масштабирование (покупка дополнительной оперативной памяти, более производительного оборудования) стоит дорого и имеет быстро достижимый предел увеличения ресурсов, поэтому мы выбрали горизонтальное масштабирование веб-серверов, которое обеспечивает больший прирост производительности за меньшие деньги.
Для обработки запросов пользователей было решено построить следующую схему: 
В Интернет смотрит только один сервер — балансировщик Nginx, к которому пользователи напрямую обращаются при посещении сайта.
В конфигурации балансировщика указываются все доступные внутренние серверы, на которые будут перенаправляться запросы пользователей и которые будут предоставлять им контент. На данный момент наши запросы от пользователей обрабатываются 5 backend-серверами, которые практически не испытывают нагрузки, но при необходимости выдерживают тысячу и более подключений в секунду.
Чтобы гарантировать отсутствие расхождений между версиями контента, отображаемого пользователям, бэкенды используют единый кеш и сеансы, которые хранятся в высокопроизводительном хранилище ключей Redis. Помимо кеша и сессий, Redis хранит все счетчики, некоторые списки данных и статистику посещений пользователей, проектов и т. д. Балансировщик также позволяет установить веса (приоритет) каждого из бэкенд-серверов, количество неудачных попыток соединения с бэкенд-сервером, после чего он будет считаться неработоспособным, а запросы будут перенаправляться на оставшиеся серверы.
Если резко возрастет нагрузка на серверы, мы очень легко можем добавить любое количество серверных серверов; развертывание нового сервера из снимка занимает около трех минут.
Амазонка
В ходе разработки возник вопрос о том, где хранить файлы и картинки проектов, чтобы каждый из серверов имел к ним доступ, например, когда пользователь хочет обрезать уже скачанную картинку.На помощь пришел сервис Amazon Simple Storage Service (S3).
Кстати, Amazon нас выручил дважды; для отправки писем пользователям мы подключили Amazon Simple Email Service (SES), что позволило нам отправлять массовые рассылки и обеспечило высокий процент писем, доходящих до пользователей, в обход спам-фильтров.
Завершающий штрих
После многих раундов функционального тестирования мы провели серию нагрузочных тестов.В первую очередь нам в этом помог сервис нагрузочного тестирования loaddy.com. Мы тестировали в основном 4 страницы - главную страницу платформы, доступную всем неавторизованным пользователям, страницу с проектами, которая является главной для авторизованных пользователей, главную страницу отдельного проекта и промо-страницу VCStart.com/start/.
, на котором симпатичные девушки ведут счетчик времени, оставшегося до окончательного запуска платформы.
Тщательная работа над кэшированием заняла некоторое время, после чего результаты нагрузочных тестов стали более чем удовлетворительными — платформа выдерживала нагрузки до 1000 подключений в секунду, при этом среднее время ответа на запрос составляло менее двух секунд.
Столь тщательная подготовка к запуску проекта дала нам огромный запас возможностей для расширения аудитории, благодаря чему ожидаемое цунами хабраэффекта показалось нам лишь легким ветерком.
Ждем вас, инвесторы, и вас, авторы стартапов, на нашей первой в России крауд-инвестиционной площадке.
VCStart.com ! Если вас интересуют какие-либо подробности, буду рад ответить на них в комментариях.
Теги: #vcstart.com #масштабирование #высокие нагрузки #разработка #архитектура веб-приложений #разработка веб-сайтов
-
Глагол
19 Oct, 24 -
Маленькая Хитрость Ssh-Консоли
19 Oct, 24 -
Высокая Скорость Миграции. Что Выбрать?
19 Oct, 24 -
Услуга
19 Oct, 24
