На протяжении многих лет команда Compo Soft успешно создавала eCommerce‑решения, клиентские порталы, PIM‑системы и другие решения малого и среднего бизнеса. Для этих задач было достаточно привычного стека на PHP и связанных с ним технологий. Когда в 2018 компания приняла стратегическое решение о выходе в сегмент Enterprise — встал вопрос о новом стеке. Им стала Java. В этой статье решили поделиться своим пониманием и опытом — почему сделан такой выбор, и почему PHP «не вывозит» Enterprise‑решения. 

К моменту переноса стратегии развития продуктов с СМБ на Enterprise, Compo Soft имела более чем 10-летний опыт разработки цифровых платформ в сегменте B2B. Но каждая новая версия и новые фичи давались все труднее — по мере роста требований заказчиков и уровня кастомизации их проектов становилось очевидно, что возможности прежней технологической базы (PHP) достигли потолка.

Акцент на построение масштабируемых, модульных и высоконагруженных решений потребовал пересмотра архитектурных подходов, выбора нового технологического стека и переосмысления принципов разработки. Мы выбрали переход от PHP‑монолита к Java и MACH‑архитектуре (Microservices, API‑first, Cloud‑native, Headless) — современному стеку, отвечающему требованиям крупного бизнеса.

О проблемах развития прежней PHP‑платформы Compo Soft

Мы не хотим говорить, что платформа на PHP — это что‑то условно плохое. Нет, просто для каждого типа решений нужен адекватный технологический стек с перспективой долгосрочного развития.

PHP, на котором Compo Soft разрабатывала свои продукты с 2011 года, долгое время успешно справлялся с нашими задачами. Основной версией платформы был MVC движок, дополненный некоторыми компонентами Symfony. После этого был предпринят переход на Laravel — и довольно успешный. Это решило тактические проблемы legacy в моменте, но не решило стратегических проблем.

Однако с ростом разнообразия бизнес‑кейсов, объема данных, заводимых клиентами в платформу и требований по кастомизации, архитектура по модели MVC начала тормозить развитие. Некоторые ограничения PHP стали критичными именно в момент перехода в сегмент Enterprise.

Модель MVC — это архитектурный шаблон проектирования программного обеспечения (Model‑View‑Controller (Модель‑Представление‑Контроллер). MVC используется в веб‑разработке (и не только) для организации кода, чтобы его было проще поддерживать, масштабировать и развивать.

Архитектура MVC ограничивала масштабирование

Прежде всего, архитектура нашей платформы на PHP представляла собой монолит по классической модели MVC. Такое решение упрощало старт проекта, но в долгосрочной перспективе затрудняло масштабирование — изменения в одном месте могли повлечь цепочку непредсказуемых эффектов в других модулях.

Добавление новых функций превращалось в рискованную и затратную по рабочему времени затею. Например, при интеграции с новым каталогом товаров приходилось переписывать не только backend‑логику, но и менять фронтенд и механизмы импорта, что увеличивало сроки и стоимость проекта. Иными словами, базовая модель MVC, не позволяла масштабировать отдельные компоненты (например, каталог или корзину) без риска покрэшить остальную систему.

Пример: при повышенной нагрузке на модуль оформления заказа деградировала производительность всей платформы — нельзя было изолировать один компонент.

2. Ограничения по технологиям фронтенда

Ситуацию усугубляли ограничения технологии на стороне клиента. Фронтенд строился с использованием AngularJS и jQuery, а в качестве сборщика использовался Gulp. Это означало устаревшие подходы к архитектуре фронтенда, слабую поддержку SEO и невысокую производительность интерфейсов. Эти технологии не поддерживали современные требования к производительности, безопасности и адаптивности.

Рендеринг происходил на сервере, из‑за чего отклик от платформы до клиентского устройства (особенно в мобильных сетях) доходил медленнее, чем хотелось бы нашим заказчикам (которым клиенты жаловались в техподдержку).

Пример: отсутствие реактивного интерфейса и слабая поддержка мобильных устройств ограничивали производительность интернет‑магазинов, созданных на PHP, в периоды высокого спроса.

3. “Недопоиск” и отсутствие аналитики

Большой проблемой оказался и поиск. Вместо специализированного движка вроде Elasticsearch применялись обычные SQL‑запросы к базе данных. Это не позволяло реализовать такие базовые для eCommerce‑функции, как фасетная навигация, гибкие фильтры или подсчет количества товаров по категориям.

Пользователь не мог быстро отфильтровать, например, «все ноутбуки с 16 ГБ RAM и SSD от 512 ГБ» — база данных просто не выдерживала сложных агрегирующих запросов без потери производительности. Да, такие запросы можно было делать, но их выполнение длилось неприемлемо долго.

Пример: в поиске сложно реализовывались бизнес‑функции, повышающие средний чек, такие как «сопутствующие товары к вашей покупке».

4. Слабая интеграция и обмен данными

Интеграции с внешними системами, такими как ERP, логистика, маркетплейсы, происходили через протокол FTP и json‑файлы. Такой обмен был не только медленным, но и нестабильным — при возникновении ошибки, данные могли быть искажены или вовсе не доставлены, а механизмы контроля и повторной отправки отсутствовали.

Пример: было сложно реализовать брокеридж сообщений или очередь задач, что затрудняло асинхронное взаимодействие между модулями и системами.

5. Отсутствие централизованного DAM-хранилища

Цифровые активы на сайтах магазинов (фотографии, видео, документация, прайс‑листы) хранились локально или на сервере владельца магазина в разрозненных папках. Не было единого DAM‑хранилища с API‑доступом, контролем версий и тегированием.

Пояснение: централизованное DAM‑хранилище‑ это единая система управления цифровыми активами (Digital Asset Management), предназначенная для хранения, организации, поиска и распространения всех медиафайлов, используемых в ИТ‑решении: изображений, видео, документов.

Управление медиафайлами, — фотографиями, инструкциями, логотипами и так далее, — велось вручную. Из‑за этого одни и те же файлы могли дублироваться, иметь разные версии в разных разделах интернет‑магазина, а связка с товарными карточками могла теряться.

6. Ограниченные возможности фоновой обработки

Фоновая обработка была представлена отдельными CLI‑скриптами, которые запускались вручную или по расписанию. Это сильно ограничивало возможности автоматизации. Массовая выгрузка каталога могла выполняться часами, блокируя другие процессы и требуя постоянного контроля со стороны разработчиков.

Фоновая логика (например, генерация отчетов, пересчет цен, уведомления) реализовывалась через cron запуск команд (cron — это планировщик задач в Unix‑подобных системах, позволяет запускать команды или скрипты по расписанию). Это мешало автоматизации и не позволяло обрабатывать задачи в реальном времени.

Пример: загрузка каталога могла затем потребовать отладки на живой базе.

7. Отсутствие многопоточности и асинхронности

Еще один существенный недостаток PHP — отсутствие многопоточности и асинхронной обработки. PHP традиционно работает в однопоточном режиме: каждый запрос обрабатывается отдельно, без возможности эффективного использования ресурсов на уровне серверного ядра.

Поочередные запросы к внешним API, медленные SQL‑запросы, генерация отчетов — это тормозило работу всей системы. Ядро платформы не поддерживало асинхронную обработку и многопоточность, что критично для масштабируемых решений.

Пример: так как операции выполнялись последовательно, это тормозило обработку большого числа ecommerce заказов в пиковые даты («черная пятница» и тому подобное).

8. Низкий уровень типизации

PHP — динамически типизированный язык. Динамическая типизация в контексте PHP означает, что переменные не имеют жестко заданного типа данных, и этот тип определяется во время выполнения программы, а не заранее (в коде).

Соответственно, динамическая типизация усложняла контроль качества продукта, делала код трудночитаемым, а поведение функций — с риском непредсказуемости. С ростом объема кода это приводило к увеличению числа багов, времени на тестирование и отладку.

Пример: в сложных B2B‑сценариях это приводило к ошибкам на этапе выполнения и затрудняло реализацию желаемой клиентом бизнес‑логики (например, проверок по десяткам условий).

9. Зависимость от нестабильных библиотек

Использовались сторонние библиотеки с GitHub без надежной поддержки, часто без документации и обновлений. Это тормозило разработку, повышало риски безопасности и зависимость от стороннего кода.

Вот небольшой пример. Допустим возникает необходимость работы с брокером rabbitmq. Для PHP мы пользуемся библиотекой, поддерживаемой очень крутыми ребятами и энтузиастами. И даже rabbitmq ее в своем гайде рекомендует.

А вот для Java — сам rabbitmq непосредственно разрабатывает и поддерживает библиотеку. Несомненно, есть разница. И таких примеров тысячи.

Некоторые ключевые функции прежней платформы зависели от open‑source‑модулей, которые давно не обновлялись. При возникновении проблем приходилось самостоятельно изучать и патчить чужой код, что увеличивало риски багов и непредсказуемо удлиняло сроки разработки.

Таблица: Сводка ограничений старой платформы

Сухой остаток: Хотя мы по‑своему любим PHP, но накопившиеся недостатки платформы приходилось решать условными «костылями». Приходилось постоянно подстраиваться под инструмент, под нужную версию какой‑то чужой библиотеки и без возможности какого‑то адекватного развития. С функциональностью поиска приходилось изощряться на основе возможностей СУБД и писать хитрую логику, реализующую хоть какой‑то внятный поиск и фильтрацию.

Почему выбрали именно Java

Мы много консультировались с коллегами из разных компаний, включая банки и обсуждали с ними наши проблемы. Совет в 99% был классический — «начните переписывать компоненты» и потихоньку так переведите всю платформу на другую архитектуру. Так действительно принято делать и считается более безопасным. Однако мы посчитали что такой подход затянет переход и даст неразбериху — ведь придется иметь две команды (PHP + Java), то есть раздувать штат. Часть инженеров будет поддерживать новые компоненты, часть старые и как‑то между собой интегрироваться. Это путь к большому хаосу и поэтому было решено переписывать на Java всю платформу сразу.

Java нередко критикуют за многословность и, как считается, устаревшую модель ООП. Тем не менее в enterprise‑разработке у нее множество сильных сторон, которые сложно игнорировать. Эти сильные стороны и перевесили. Кстати говоря, для любителей большего удобства, лаконичности и современного подхода к программированию в java‑мире есть Kotlin. Который обладает всеми преимуществами языка Java, при этом в нем отсутствуют проблемы присущие Java, например, NPE, который многих до исступления доводит. А самое главное, что Kotlin и Java интероперабельны. То есть, мы, программируя на Kotlin, можем подключать java‑библиотеки и спокойно работать с ними.

Итак, решение перейти на Java было осознанным и стратегическим. Перед командой стояла задача не просто заменить один язык другим, а создать фундамент разработки, на котором можно строить зрелую, масштабируемую и надежную B2B‑платформу уровня серьезного Enterprise. Были рассмотрены альтернативы — Node.js,.NET, Python — но ни одна из них, как бы хороша не была, не обеспечивала требуемого баланса зрелости, производительности, богатства экосистемы и поддержки именно под наши условия.

Теперь подробнее, какие критерии мы принимали во внимание, выбирая Java.

Зрелость и стабильность языка и его развития

Java существует более 25 лет, входит в ТОП языков программирования в различных рейтингах, включая российские, и активно развивается под управлением Oracle и профессионально‑зрелого сообщества. Это не экспериментальный язык, не «фреймворк года», а технология, которая пережила целые поколения веб‑решений и доказала свою надежность в финансовых, государственных, телеком‑ и корпоративных системах.

Платформа Java поддерживает долгосрочные версии (LTS), имеет строгую обратную совместимость и предсказуемый релизный цикл. Это особенно важно для тех, кто строит продукт с горизонтом развития на 10+ лет.

Наличие проверенной временем экосистемы

Выбор Java открывает доступ к мощной и зрелой экосистеме:

• Spring Framework и его компоненты (Spring Boot, Spring AI, Spring Cloud, Spring Data, Spring Batch) позволяют быстро создавать микросервисы, REST API, интеграции с базами данных, брокерами сообщений и другими системами.

• Apache Kafka, Camel, Solr, Lucene, Hadoop — инструменты обработки данных, очередей, поиска и интеграций, изначально ориентированные на Java.

• Инструменты крупных компаний: Google активно использует Java (GCP SDK, Android), Microsoft обеспечивает поддержку Java в Azure, а IBM развивает корпоративные Java‑решения (WebSphere, Open Liberty).

Документация "корпоративного уровня"

Если в мире PHP часто приходится ориентироваться на статьи в блогах и фрагментированные туториалы, то в Java‑инфраструктуре документация — это полноценные спецификации, официальные мануалы от мировых вендоров, четкие стандарты.

Например:

• Spring имеет обширную официальную документацию с примерами, схемами и архитектурными рекомендациями;

• OpenJDK и Oracle JDK поддерживают версии LTS с подробной документацией по API;

• Apache и другие фонды публикуют white papers и производственные гайды.

Зрелая документация важна при проектировании сложных компонентов (например, обработки заказов, шлюзов, очередей, безопасности) — где используется не «хак» после долгого гугления, а устойчивое, предсказуемое решение.

Наличие качественного обучения, комьюнити и поддержки

Поскольку Java — один из самых популярных языков в мире, это отражается в доступности качественного обучения:

• Обширные курсы от Udemy, Coursera, JetBrains Academy, Stepik;

• Множество книг: «Effective Java», «Spring in Action», «Clean Code» (в том числе на русском);

• Активные комьюнити: Stack Overflow, Reddit, Spring Community;

• Конференции и митапы.

Кроме того, многие проблемы в стеке уже решены до нас — достаточно загуглить ошибку, и, скорее всего, она уже обсуждалась с десятком вариантов решения.

Производительность и инженерная дисциплина

Java показывает высокую производительность по сравнению с динамическими языками (в т.ч. PHP и Python), благодаря JIT‑компиляции, сборке мусора, многопоточности и оптимизации под железо.

Также Java приучает к инженерной культуре: строгая типизация, архитектурные подходы (DDD, Hexagonal, Clean Architecture), юнит‑тесты, CI/CD, работа с профайлерами и метриками — все это не «отдельные навыки», а часть каждодневной работы Java‑разработчика.

“Сухой остаток” по нашему выбору в пользу Java

Переход на Java не был попыткой следовать моде. Это было осознанный выбор архитектуры, направленный на создание надежной платформы, выдерживающей нагрузку и рост. Для нас были важны обеспечение совместимости с внешними системами и стандартами, возможность масштабирования по командам и сервисам и, конечно, повышение контроля над качеством и безопасностью кода.

Иными словами, Java и MACH‑архитектура стали основой трансформации платформы Compo Soft в полноценный Enterprise‑продукт, готовый к высоким требованиям крупнейших клиентов из B2B‑сегмента.

Таблица: Java и PHP в контексте Enterprise‑разработки

Краткий гайд: что делать вендорам, которые хотят масштабироваться со своим софтовым продуктом, но не могут (советы IT директору)

Обобщая наш опыт, возьмем на себя смелость дать совет другим вендорам. Если вы чувствуете, что ваша текущая платформа перестала справляться с ростом нагрузки или ее сложно масштабировать, стоит задуматься о смене архитектурного фундамента.

1. Вначале подсчитайте стоимость «ничего не делать, остаться как есть». Учитывайте технический долг, кадровые риски, узкие места, нестабильность зависимостей. Иногда проще и дешевле — сделать продукт заново на новом стеке.

2. Ориентируйтесь на лидеров. Изучите, на чем работают крупнейшие игроки в вашем сегменте (например, SAP, Salesforce, Adobe). Платформы уровня Enterprise редко строятся на PHP — и это факт.

3. Анализируйте тренды, а не только «модно‑молодежно». Посмотрите не только на популярность технологий, но и на то, как они развивались последние 5–10 лет. Java — один из немногих языков, который стабильно держится в Enterprise.

4. Сравните документацию и зрелость фреймворков. Хорошо написанная и регулярно обновляемая документация экономит месяцы на проекте. У зрелых стеков — системный подход, стандарты и lifecycle.

5. Соберите исследовательскую команду. Сформируйте пилотную группу (архитектор, разработчики, DevOps), дайте ей задачу протестировать альтернативы и создать прототипы на разных стеках.

6. Инвестируйте в переобучение команды. Разработчики, хорошо знающие предметную область, после переобучения могут быстро войти в продуктивную фазу и сохранить экспертизу внутри.

Заключение

Переход с PHP на Java для команды Compo Soft стал не просто техническим апгрейдом, а стратегическим решением: выйти на новый уровень разработки, стабильности и гибкости. MACH‑архитектура дала свободу строить действительно современную B2B‑платформу, а Java — язык, вокруг которого собрано все необходимое для Enterprise‑уровня.

Более подробно об архитектуре нашей платформы уже на Java можно посмотреть в презентации (запрос по ссылке).

И если вы находитесь в точке принятия такого решения — возможно, настало время пересмотреть и ваш стек.