Как мы облачный PHP-сервис завернули в коробку — с защитой, лицензией, и при этом ускорились

Мы привыкли к облакам и сервисам по подписке (что называется сложным словом SaaS) . Заливаешь данные, строишь календарики — и не задумываешься, на чьих там они серверах хранятся. Удобно? Да. Безопасно? Ну, так… Обычно мы на это забиваем. Или не задумываемся. Или задумываемся, но всё равно забиваем.

Именно сервисом по подписке наша система управления проектами BIPULSE и была. Это такой «отечественный аналог» MS Project + Jira + некоторых других систем управления задачами. Работали долго, крутились в облаке, продавали лицензии. Но это ж B2B, не B2C — и чем дальше, тем больше российские проектные бизнесы переставали доверять облакам. Особенно вот с февраля, пресловутое импортозамещение.

Бизнес хочет решение у себя на сервере, чтобы контролировать данные. Всё-таки информационная безопасность. Там — не забивают. Там — не доверяют. И правильно делают. Поставляйте нам, говорят, коробку. Сервис классный, возьмём. Но как — коробку? У нас обычный веб-сервис, PHP + JS + Postgres. Почти 80% веба на этом стеке, он удобный и выполняет свои задачи. Но — он не предназначен для “отгрузки”, ведь поставлять нужно исходники. А делать это крайне не хочется.

Я расскажу, как нам удалось и защитить PHP-код, и сделать лицензирование, и наладить поставки, и при этом ускориться. В конце будет ссылка на техническую статью.

Open Source это конечно хорошо, но лишь когда ты потребитель. А когда ты поставщик и тебе хочется кушать, лучше иметь технические средства защиты помимо юридических.

Второй фактор: алгоритмы! Для обычных программ типа Redmine и похожих, там кроме простой прослойки между браузером и базой данных ничего нет. А у нас есть вычисления статистики, расчёт критической цепи (ага, той самой, про которую Э. Голдратт писал) , выравнивание ресурсов и другое — собственно, вся суть нашего продукта, куча функциональности. Это достаточно хитрые алгоритмы и хочется их защитить.

Для PHP есть средства типа ZendEncoder, Ioncube и другие но… но они снимаются легко за счёт выгрузки байт-кода и разворачивания его в исходный текст. А мы хотели иметь чуть лучшую защиту, чтобы направление взлома хотя бы требовало знания ассемблера, а не утилит декомпиляции.

:))) Конечно же! Чего там, на недельку делов — скажет любой студент. А любой опытный разработчик ответит: “Рабочая система, с 10-летней историей, десятки тысяч строк кода, сотни рабочих интеграционных тестов. Переписать? Это без меня, пожалуйста”. И пошлёт к студенту.

Для очистки совести, мы даже прикидывали варианты. Может, пересобрать это всё с C#, чем-то типа IronPHP? — .NET даст скорость исполнения, но не защитит от вскрытия. Портировать на С++? Синтаксис-то похож, да и часть функций это чистый POSIX (стандарт для unix систем) . — Перестанет быть поддерживаемо, и риск 100%, что увязнем в портировании.

И пока мы раз за разом отчаивались…

В конце 2020 года ВК выложили в open source свой компилятор. Оказывается, бэкенд ВКонтакте полностью написан на PHP, а с помощью KPHP они получают бинарник, который работает значительно быстрее оригинального PHP-кода. Точнее, KPHP транслирует PHP в С++, попутно делая ряд хитрых вещей, и плюсовые исходники уже в бинарник и превращаются.

C++! Бинарник! Вот ключевое слово для нас. Ведь бинарник — это по сути и есть коробка. Если упаковать туда весь код, сделать раздачу картинок и JS, закрыть лицензией… Может, ещё и ускорится? Ведь KPHP нужен ВК для производительности прежде всего.

Если после бессонных суток за компом исчезает блеск в глазах — не бескопойтесь: через ещё одни сутки он опять появляется:)

Это было реально долго. И не с первого раза. По трём причинам:

Во-первых, ВКонтакте делают в KPHP только то, что нужно им в работе. Например, базы данных PostgreSQL и Sqlite не поддержаны — а нам нужно. Сначала думали, что вообще не получится ничего — но потом ВК реализовали поддержку FFI (способ подключения любых внешних модулей), накидали прототип — базы заработали! Казалось бы, всё остальное — дело техники, но…

Во-вторых, KPHP не может взять и "прожевать" любой PHP-код. Код должен быть строгим, с типизацией, примерно как в С++ или Java. А обычно PHP-проекты пишутся не так, обычно PHP-код насыщен конструкциями, которых лучше бы не было. KPHP много ругался, и ругался по делу. Одних только ошибок типизации было 30 тысяч штук. Исправляли, матерились. Мол, компилятор, если ты такой умный — возьми и сам исправь :) Но тут гигантский плюс: мы нашли участки кода, которые работали лишь потому что везло, и могли сломаться в любой момент. Переход на строгую типизацию и отсутствие «грязных PHP-хаков» сделало код значительно надёжнее и понятнее, поддерживать его стало заметно проще. Эта боль стоила того.

В-третьих, помимо баз данных, KPHP много чего не умеет, что опять-таки не нужно было ВК. Запуск процессов, парсинг XML и прочее. Мы были на связи с разработчиками компилятора. Что-то они добавляли, что-то фиксили, где-то мы вставляли костыли и подпорки. Иногда падало, иногда работало по-другому. Почти всему находилось объяснение, почти всегда дело было в нашем коде. Месяца два мы были в состоянии “почти-почти”, казалось бы вот ещё исправить и заработает, но нет, что-то находилось ещё, а потом ещё и ещё. И это когда тебя бизнес каждую неделю пингует — нучотам, когда коробка?

В августе-сентябре мы начали поставки коробок клиентам, большим и маленьким. Пройдя семь кругов рефакторинга, сумели сделать лицензию. И скорость! Расчёты расписания ускорились в 3 раза. При этом мы вообще не занимались оптимизациями — а внутри KPHP есть много хитростей, коих нет в обычном PHP и что позволяет выжать ещё больше. Когда-нибудь поисследуем.

По хронологии, вышло так:

А стоило оно того, чтобы инвестировать уйму времени? Да!

Кстати, отдельно поясню: это НЕ переписывание на другой язык. Мы по-прежнему разрабатываем и тестируем на обычном PHP — а KPHP только для поставки в прод. В течение всего периода адаптации система оставалась рабочей и всегда запускалась на PHP. Исправили — проверили. Порефакторили — проверили. И в конце концов KPHP всё прожевал. Это эволюция, а не переписывание. Так можно. Переписывать — нет.

В общем, теперь команде ВКонтакте придётся поддерживать обратную совместимость: )

А за техническими подробностями — на Хабр