Як ми пробували зробити криптобіржу на PHP (P2P + спотова торгівля)
Зазвичай, коли мова йде про криптобіржі, всі одразу думають про Python або Node.js. Це логічно — багато бібліотек, асинхронність і т.д.
Але у нас була інша задача — швидко зібрати прототип і перевірити, чи взагалі це можна зробити на PHP без «танців з бубном».
Чому взагалі PHP
Якщо чесно — не через «кращий вибір», а скоріше через практичність:
вже є досвід
швидко піднімається бекенд
не потрібно окремо розгортати складну інфраструктуру
І головне — хотілось перевірити: чи реально PHP витягне таку логіку.
Що входило в задачу
Ми хотіли реалізувати базові речі:
спотова торгівля
P2P частина
робота з ордерами
інтеграція з зовнішньою ліквідністю
Без цього біржа — це просто «муляж».
Архітектура (спрощено)
Все максимально просто:
PHP — вся логіка
база — для користувачів і ордерів
фронт — звичайний JS
І окремо: інтеграція з API біржі для ліквідності
Спотова торгівля
Найбільша складність — це матчинг ордерів.
Ми зробили просту логіку:
є список ордерів
новий ордер проходить по списку
якщо ціна співпадає — виконується угода
function matchOrder($newOrder, $orders) {
foreach ($orders as $order) {
if ($order['price'] == $newOrder['price'] && $order['type'] != $newOrder['type']) {
executeTrade($newOrder, $order);
}
}
}
Це не ідеально, але для прототипу працює.
P2P і ліквідність
Щоб не робити «порожню біржу», підключили зовнішній API.
Ідея проста:
беремо ордери
синхронізуємо
показуємо їх у себе
Що було складно
Ось тут найцікавіше:
PHP не дуже дружить з real-time
довелося використовувати cron
синхронізація іноді «пливе»
треба постійно перевіряти баланс
Що вийшло
У результаті:

є робочий прототип
можна торгувати
є P2P частина
все працює без Python
Як приклад реалізації: mintscripts.net
Висновок
PHP — це не «стандарт» для таких задач, але:
для MVP — ок
для тестів — ок
для продакшена — вже треба думати про масштаб
4 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівТак і не побачив, чомо суме php — не ок, як на мене вибір стеку це просто питання зручності.
Доречі, в єдиному прикладі кода у вас помилка яка може зламати порівняння повністю (в деяких кейсах).
Дякую за коментар! Абсолютно згоден — PHP не ідеальний для таких задач, і вибір стеку багато в чому залежить від зручності та досвіду команди.
Щодо прикладу коду — дякую за увагу, це дійсно може спричинити проблеми в певних сценаріях. Ми робили прототип швидко, і мета була показати ідею, а не готову production-систему.
Можливо, оновимо приклад, щоб він працював у більшості випадків.
Ні, я мав на увазі, що тут є висновок без аналізу:
Тобто, читати немає що, окрім рекламного посилання.
Те що ви написали вище, взагалі не дає відповідей
Бо:
1. Що означає «не дружить з real-time», та що взагалі мається на увазі під соусом «real-time»?
2. Cron — це php може стосуватися так само як будь якої іншої мови, і це тільки один з варіантів реаліації запуску періодичних задач. Тобто теж не дає відповіді.
3. Що саме там іноді «пливе» і як це пов’язано саме з мовою — загадка.
4. Перевірки балансу можуть бути в будь якому функціоналі який відноситься до фінансів, і це взагалі — нормально.
Дякую за детальний фідбек, це якраз той рівень дискусії, якого не вистачає 🙂
Ви праві — у статті вийшло більше узагальнень, ніж конкретики. Спробую пояснити, що саме мав на увазі.
1. Щодо «real-time»
Під цим мався на увазі не просто «швидко», а саме робота з постійними оновленнями:
стрім ордерів
митчинг в реальному часі
WebSocket-підключення
У PHP це менш зручно, бо класична модель — request/response.
Тобто для постійно відкритих з’єднань або стрімінгу треба або додаткові інструменти (ReactPHP, Swoole), або костилі.
2. Про cron
Згоден, це не проблема PHP як мови.
Скоріше мова про те, що в нашому випадку довелось використовувати cron як заміну event-driven підходу (наприклад, як це частіше роблять у Node.js або Go).
3. «Пливе синхронізація»
Тут мова не зовсім про PHP, а про сам підхід:
є зовнішній API (ліквідність)
є локальна книга ордерів
Через polling (а не стрім) виникає затримка → дані можуть тимчасово не співпадати.
Це більше про архітектуру, але з PHP частіше приходиш саме до polling-рішень.
4. Перевірка балансу
Тут повністю згоден — це стандарт для будь-якої фінансової системи.
Я скоріше мав на увазі, що при відсутності нормальної конкурентної обробки (race conditions) це стає критичніше.
Загалом, ви праві — багато з цього більше про архітектуру, ніж про саму мову.
Це моя перша стаття на DOU, опублікував нещодавно, тому поки більше як загальний кейс. У наступних постах постараюсь детальніше розкрити технічні моменти.