Як ми пробували зробити криптобіржу на 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
синхронізація іноді «пливе»
треба постійно перевіряти баланс
Що вийшло

У результаті:

Як ми пробували зробити криптобіржу на PHP (P2P + спотова торгівля)

є робочий прототип
можна торгувати
є P2P частина
все працює без Python

Як приклад реалізації: mintscripts.net

Висновок

PHP — це не «стандарт» для таких задач, але:

для MVP — ок
для тестів — ок
для продакшена — вже треба думати про масштаб

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Ctrl + Enter
Ctrl + Enter

Так і не побачив, чомо суме php — не ок, як на мене вибір стеку це просто питання зручності.
Доречі, в єдиному прикладі кода у вас помилка яка може зламати порівняння повністю (в деяких кейсах).

Дякую за коментар! Абсолютно згоден — PHP не ідеальний для таких задач, і вибір стеку багато в чому залежить від зручності та досвіду команди.
Щодо прикладу коду — дякую за увагу, це дійсно може спричинити проблеми в певних сценаріях. Ми робили прототип швидко, і мета була показати ідею, а не готову production-систему.
Можливо, оновимо приклад, щоб він працював у більшості випадків.

Ні, я мав на увазі, що тут є висновок без аналізу:

PHP — це не «стандарт» для таких задач, але:

Тобто, читати немає що, окрім рекламного посилання.
Те що ви написали вище, взагалі не дає відповідей

PHP не дуже дружить з real-time
довелося використовувати cron
синхронізація іноді «пливе»
треба постійно перевіряти баланс

Бо:
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, опублікував нещодавно, тому поки більше як загальний кейс. У наступних постах постараюсь детальніше розкрити технічні моменти.

Підписатись на коментарі