Більшість сервісів, які розробляє FAVBET Tech, є високонавантаженими. Велика частина з них на PHP – цією мовою не тільки підтримують застосунки, що вже є, але й створюють і розвивають нові продукти, які витримують сотні тисяч транзакцій на хвилину.
Як писати такі сервіси на PHP, у партнерському матеріалі розповідає Head of Engineering FAVBET Tech Михайло Горішний, який має 14 років досвіду в IT, з них сім – у highload-розробці.
Чому PHP добре підходить для високонавантажених систем
Head of Engineering FAVBET Tech Михайло Горішний
Ми пишемо та підтримуємо багато високонавантажених сервісів на PHP. Це й інтеграції з ігровими провайдерами, і сервіс турнірів і джекпотів, і нотифікації користувачам. На один такий сервіс приходиться сотні тисяч транзакцій за хвилину.
Раніше мова PHP не була заточена під високе навантаження, але починаючи із сьомої версії в неї дуже виріс перформанс. Тепер вона не тільки не відстає, а інколи навіть і виграє в інших мов.
Ми обираємо PHP, тому що це класна мова для написання бізнес-логіки. Код зрозумілий, усе розкладене структурно та можна писати великі системи.
Але в PHP є особливість: на кожен запит він народжується та помирає. Наприклад, щоразу треба наново приєднуватися (конектитись) до бази. Це потрібно враховувати при написанні коду і вміти обходити. Тому для роботи з PostgreSQL ми використовуємо pgBouncer. Це така проміжна частина, яка тримає для себе пул конектів до бази.
Для роботи з Rabbit MQ ми перейшли на відправку повідомлень у бекграунді. Бо вона часто не впливає на флоу роботи запиту. Тому ми робимо так: меседжі попадають у Redis (PubSub), а звідти в бекграунді відправляються в Rabbit. Докладніше про цей підхід можна почитати тут.
У PHP є два популярні фреймворки:
- Laravel дає багато всього «з коробки». Проте зі зростанням сервісу може виникати ситуація, коли багато його частин не використовуються, але й від’єднати їх неможливо. Через це відбувається деградація перфомансу.
- Symfony з коробки пустий, але в нього модульність. Модулями ви можете додавати тільки те, що вам потрібно. Тому він краще підходить для highload-систем.
Втім, ми в FAVBET Tech використовуємо обидва фреймворки. Наприклад, маємо на Laravel сервіс, який витримує дуже високе навантаження. Усе завдяки вдалому підбиранню підходів для використання фіч, які дає цей фреймворк.
До речі, якщо можливостей самої PHP не вистачає, завжди можна пустити в дію FFI (Foreign Function Interface) і викликати низькорівневу функцію на C++, Go або Rust. Це теж дає класний буст до перфомансу.
Навички і знання, необхідні розробнику для highload
Є великий перелік того, що має знати розробник високонавантажених систем. Найголовніше – це:
- Працювати з базами даних і знати різні підходи до баз. Ви маєте розуміти, коли варто використовувати SQL-бази, а коли in-memory, а також вміти писати оптимальні запити до них. До речі, ми ніколи не використовуємо ORM (об’єктно-реляційна проєкція – створення віртуальної об’єктної бази даних) для роботи з БД. З ними легко працювати, але вони не оптимальні.
- Працювати з кешуванням. Ви повинні розуміти, на яких рівнях які кешування та як із цим працювати.
- Працювати з івент-системами. Робота з Rabbit MQ, Kafka та іншими подібними системами.
Як бачите, це все – не про PHP, а про розробку в цілому. Це через те, яким чином розроблюються високонавантажені системи.
Ось приблизний список запитань, які варто поставити, перш ніж починати писати highload-застосунок:
- Які це будуть навантаження?
- Чи потрібно нам буде зберігання в базах даних і які це мають бути дані?
- Як працюватимемо з івент-системами?
- З якими сервісами ми спілкуватимемося?
Під деякі відповіді в нас уже є розроблені рішення. Наприклад, бази даних, які ми використовуємо сервіси. За дефолтом це PostgreSQL. Також може бути Clickhouse. Для оперативних рішень ми беремо не звичайні бази даних, а in-memory: наприклад, Redis чи AWS MemoryDB.
Коли доходимо до написання коду, варто тримати в голові, для чого він пишеться.
Наприклад, можна всі черги використовувати через один конс’юмер – і це працюватиме. Але з навантаженнями на продакшені система ляже – тож варто буде розділити, наприклад, exchange за топіками на десять різних конс’юмерів, кожен з яких виконуватиме свою функцію.
Інший приклад. Уявимо, що у вас є частина сервісу, логіка якого складна, але застосовують його дуже рідко. Натомість інша частина не має складної логіки, але має використовуватись часто й багато. Такі сервіси краще реалізувати окремими мікросервісами, щоб одне не тягнуло за собою інше.
Писати highload-застосунки – це не про те, щоб просто вивчити якусь технологію, а про те, щоб час від часу питати себе: чи є оптимальним той код, який я створив? Водночас при роботі з highload-системами на створення коду витрачається 10–15% часу, усе інше – оптимізація під навантаження.
Більше про можливості з FAVBET Tech.
Як перейти в highload-розробку
Щоб почати писати застосунки під highload, треба вивчати глибше не саму мову PHP, а загальні підходи та інші технології.
Наприклад, багато задач переїжджає в бекграунд на демони. Тому треба розуміти роботу з пам’яттю і збірниками сміття. Також багато роботи переїжджає в кеш. Тому треба розуміти системи, які можна для цього використовувати; розуміти логіку оперативної та архівної бази.
Гарна книжка для тих, хто хоче перейти в цю нішу: Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems авторства Мартіна Клеппманна (Martin Kleppmann). Але просто почитати недостатньо, варто практикуватися.
Знайти людей з досвідом роботи з високими навантаженнями складно, бо немає чіткого визначення, яке навантаження вважати високим. Людина може казати, що працювала з highload, але мати на увазі такі цифри за рік, які в нас збираються за годину.
Head of Engineering FAVBET Tech Михайло Горішний
Втім, ми в FAVBET Tech наймаємо людей без досвіду в цій ніші. Щоб визначити, чи підійде нам людина, на співбесіді ми ставимо практичні запитання. Таким чином дивимось, як фахівець думає, чи приймає логічні й оптимальні рішення. Ідеально, якщо не тільки оптимальні, а ще й прості.
Наприклад, у нас є сервіс інтеграції з ігровими провайдерами. Через нього проходять транзакції користувачів, він також спілкується з іншими сервісами в системі. Це важливий вузол, тому ми ретельно працювали з ним. Багато роботи було зроблено, усі пункти, про які ми говорили вище, використані на ньому. Зараз цей сервіс витримує сотні тисяч транзакцій на хвилину, а його середній час відповіді – 99 мс.
Щоб досягти цього, потрібно розуміти доменну зону сервісу, що він має, і що не обовʼязково робити саме в цей момент часу. Нюансів дуже багато, але результат того вартий, а створювати настільки складні речі дуже цікаво.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: