EODHD API предлагает глобальный API фондового рынка, предоставляющий фундаментальные и исторические данные о ценах для акций, ETF, взаимных фондов и облигаций на крупных биржах по всему миру. Мы не начали API EODHD с венчурного финансирования или большой команды. Фактически, это началось с одного сервера за 10 долларов, боковой суеты и желания сделать высококачественные финансовые данные более доступными. Никаких ускорителей, нет внешнего капитала-просто упрямая настойчивость и много практических устранения неполадок.
Мы совершили бесчисленные ошибки по пути. Мы реструктурировали целые системы, перемещенные платформы, переписывали код спагетти и да, мигрировали услуги в середине ночи, чтобы избежать глобального простоя. Это история о том, как продукт и инженер загрузили компанию в реальном времени и уроки, которые мы извлекли в процессе.
Фаза 1: залив Единорога, начальная шутка и бесплатные кредиты
В 2015 году мы работали на полную ставку и строили то, что в конечном итоге стало бы API EODHD в наших вне часов. Первая итерация даже не была API EODHD — это была залива Unicorn, инвестиционная платформа, построенная PHP и Laravel на бэкэнд, и угловой на подходящем направлении. Это были инструменты, которые мы знали в то время — ничего особенного, только то, что сработало.
Поскольку у нас не было бюджета, мы прыгнули между поставщиками, предлагающими бесплатные облачные кредиты: OVHCloud, другие меньшие игроки и в конечном итоге Amazon AWS. Нам предоставили 10 000 долл. сша в виде кредитов AWS, что дало нам передышку и довольно мощный экземпляр 64 ГБ для проведения услуги.
Но по мере роста трафика мы столкнулись с скрытой стоимостью: AWS в значительной степени взимается за исходящий трафик. Наши кредиты быстро растопили. К апрелю 2017 года мы знали, что не можем остаться. Мы развернули фронтальный сервер за 10 долларов на DigitaloCean и все мигрировали.
Глобальное использование означало «Следуй за солнцем» — нам пришлось планировать время простоя в течение наименее болезненных часовых поясов. Наша первая крупная миграция произошла всего за пару часов запланированного простоя и много скрещенных пальцев.
Фаза 2: Рождение API EODHD — в один уик -энд, один клиент
Идея API EODHD пришла ко мне в пятницу вечером в 2017 году. К понедельнику у нас был рабочий сайт, подключенный к PayPal и один платящий клиент. С 2017 по 2019 год я справился со всем в одиночку — Бэкэнд, Фронтенд, поддержка и документация. Это не было устойчиво, но это сработало.
В ноябре 2019 года Evgenii Elesin присоединился к проекту на полный рабочий день в качестве технического директора. Именно тогда мы начали обращать реальное внимание на архитектуру. Но до тех пор наш подход всегда был одинаковым: построить быстро, исправьте позже.
Evgenii хотел чистые услуги с самого начала. Я предпочел простой прокси, чтобы заставить вещи жить. В конце концов, мы скомпрометировали — и, что удивительно, «быстрый и грязный» подход масштабировался дальше, чем ожидалось. Мы перешли от одного общего сервера, обрабатывающего все к пять бэкэндов и отдельных серверов для новостей, потоковой передачи WebSocket и Clickhouse.
Фаза 3: мучительно масштабируя, контролируя все
К 2020 году все начало ломаться под нагрузкой. Наша архитектура, которая никогда не предназначена для интенсивного движения, была ограничена. Мы представили реальный мониторинг (Datadog) после неудачной попытки передать наблюдением. Мы переписываем устаревшие подсистемы, изолированные компоненты и постепенно начали мигрировать в современные стеки.
Мы также обнаружили неожиданные горячие точки. Даже наши проверки с ограниченными показателями были узкими местами из-за неэффективных запросов MySQL. Именно тогда Redis вошел в картину — и помог резко сократить задержку.
Сегодня мы работаем на 17 серверах. У нас есть посвященные ящики для тестирования, разработки, различных трубопроводов данных и публичных API. Но наследие остается. Некоторые части все еще работают в старых версиях PHP и Laravel, и каждая модернизация — это битва со временем и приоритетами.
Инфраструктура и архитектура
1.1 Текущий макет сервера (всего 17): мы в основном размещены на капельте Digitalocean, со следующими ролями:
- Маркетинговый сайт и API Gateway
- MySQL Server и работники по обработке данных
- Пять выделенных бэкэнд -веб -серверов
- Служба новостей (обрабатывает как обработку данных, так и веб -трафик)
- Сервер WebSocket (node.js)
- Clickhouse Server
- Тестирование сервера
- Экспериментальные серверы:
-
- Внутренний ML (Python)
-
- Внешняя аналитика на основе искусственного интеллекта
-
- Аутсорсинговая поддержка проекта
- Поддержка инфраструктурного сервера
- VPN -сервер
- Один сервер с голой металлом, используемый для процессовых партийных задач
1.2 VM и стратегия контейнеризации: основные услуги работают на виртуальных машинах. Docker используется выборочно — в основном для удобства в развертывании и местных средах DEV, а не для масштабирования. Вспомогательные услуги часто работают в качестве контейнеров на одних и тех же виртуальных машинах.
1.3 Dev Tooling в облаке: мы используем реестр Docker и Bitbucket для поддержки процессов разработки и развертывания.
Данные в реальном времени и очередь
2.1 Архитектура очереди: мы используем очередь, поддерживаемые базой данных для распределения рабочих нагрузок обработки данных. Учитывая управляемую частоту, объем и сложность обновлений, нет необходимости в сложных брокерах сообщений, таких как Kafka-более простая очередь в DB достаточно.
2.2 Потоковая передача в реальном времени: наш единственный истинный поток в реальном времени обрабатывается с помощью службы Node.js, созданного на модулях Express и WS (WebSocket). Это прокси и потоковое время, чувствительное к временным рыночным данным.
Базы данных и хранение
3.1 Стек баз данных:
- MySQL (InnoDB) остается основным хранилищем для сильно взаимосвязанных данных.
- Clickhouse используется для больших объемов, тяжелых наборов данных-в основном благодаря превосходной эффективности диска.
- Sphinx интегрирован как полнотекстовая поисковая система.
- Дополнительные экземпляры MySQL используются в поддержку различных микросервисов.
- REDIS используется для эффективных проверок ограничения скорости и контроля доступа, значительно снижая задержку по сравнению с предыдущими реализациями на основе MySQL.
3.2 Стратегия данных: мы опираемся на MySQL для целостности транзакции и умеренного обновления/удаления активности. Модель Clickhouse только для приложения не подходит для всех рабочих нагрузок, но она превосходит, где аналитика и производительность имеют значение.
CI/CD и развертывание
Нам не нужен автоматический или полномасштабный CI/CD из-за предсказуемой природы наших рабочих нагрузок. Тем не менее, мы начали внедрять конвейеры Bitbucket для автоматических чеков и развертываний. Мы также исследуем инструменты, такие как Laravel, такие как Envoyer и Forge, чтобы еще больше уменьшить человеческие ошибки и оптимизированные выбросы.
Мониторинг и наблюдение
Мы используем:
- Sentry для отслеживания ошибок и агрегированных журналов.
- Datadog для системных метрик, внутренней/внешней доступности услуг и мониторинга производительности. Эта комбинация помогает нам исследовать инциденты и планировать будущее масштабирование.
Структура и эволюция API
Ранние API часто отражали то, что клиенты ожидали от других поставщиков, что привело к несоответствиям. По мере развития рынка API и были введены новые типы данных, мы начали объединять конечные точки и вводить версии. Сегодня:
- Мы используем спецификацию JSON: API (с модификациями для данных, не являющихся ресурсами).
- Мы документируем API с использованием OpenAPI.
- Мы по -прежнему прагматичны — если клиентам нужны пользовательские форматы, чтобы облегчить интеграцию, мы стараемся их поддержать.
Управление стеком и техническим долгом
7.1 Текущий технологический стек: у нас довольно стандартный стек LEMP. Первоначально построенный на PHP 5.6, MySQL 5 и Laravel 5.7, мы с тех пор модернизировали большинство услуг до PHP 8.4, MySQL 8 и Laravel 12. Однако некоторые унаследованные услуги все еще работают на PHP 7.4.
7.2 Стратегия технического обслуживания: теперь мы планируем регулярные периоды «замораживания функций» или «заточка». Эта практика обеспечила заметные преимущества.
Глядя в будущее
EODHD все еще растет. Сейчас мы масштабируем ответственность, инвестируем в более чистые системы и более сильную команду. Но по своей сути наша история не изменилась: создать вещи, которые нужно людям, и исправить их по ходу дела. Просто делай это немного лучше каждый раз.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Технологический профессионал с более чем 17 -летним опытом работы в области телекоммуникации, разработки программного обеспечения, DevOps, SRE и Kubernetes. Взвешенные технические команды, соучредители стартапы и внесли свой вклад в облачные проекты. Тренер и спикер сосредоточились на практическом наставничестве в DevOps/SRE, Cloud Technologies и AI. Подробнее от Дениса Василова
