У нас на фирме прикупили как-то лицензии на зенд сервер (ZS) пару лет назад. Цена вопроса по слухам была 6ти значной в евро за 3 года лицензии.
Из киллер фич было:
Возможность настраивать оповещения на различные события, например, превышение времени выполнения скрипта/URL, потребление памяти, exceptions
Профайлер мог включаться прямо в продакшене по событиям, по желанию если открыть страницу с секретным токеном, либо с какой-то вероятностью по определённому URL
Возможность записи краха приложения (по exceptions, например). При этом записовалось состояние приложения и в Zend Studio можно было прокрутить событие назад (тут могу немного ошибаться). Только работало это всё исключительно в ZendStudio, который мы уже почти не использовали.
Графики, счётчики
Возможность установки Zend Framework прямо на сервере без всяких composer. Идея была в том, что ZF выступал бы в роле сервера приложений и можно обновлять ZF на уровне сервера
С чем столкнулись в реальности:
Вроде всё работало стабильно, все заявленные фичи тоже работали.
Потратили уйму времени (где-то год почти) на интеграцию в инфраструктуру, обучение сисадминов, изменение деплоймента. Сам деплоймент усложнился, появилось промежуточное звено в виде zstool
Многие фичи оказались не нужны вообще. Всем было лень заглядывать в логи в поисках гипотетических проблем, графики тоже особо были не нужны.
Интеграция с Zend Studio оказалась ненужна
Фича по установке ZF прямо в сервер тоже оказалась не нужна и даже мешала. Были установлены какие-то внутренние модули, которые прописывались в spi_autoloader и это мешало нашему composer autoloader. Т.е. при загрузке страницы подгружались какие-то неведомые php файлы откуда-то из /var/lib/zend
Сисадмины имели большие проблемы с обновлениями безопасности и openssl, ведь ZS это не пакет в системе, это и есть система! Приходилось тревожить техподдержку зенда и пинать чтобы быстрее выпустили апдейты безопасности
Были глюки с конфигурацией apache vhost, обращались в поддержку, бездушный индийский саппорт на ломанном английском сказал, что не смог воспроизвести проблемы и значит её нету. Хотя мы описали подробнейшую инструкцию.
Для подготовки zip пакета для деплоймента надо было использовать zstool, оно умело делать зип архив только в один поток. Стоит ли говорить, что наше приложение было под 500МБ?
При деплое зип архива размером более в 500МБ деплоймент просто крэшился.
Все пакеты аккуратно складывались в sqlite базу данных на сервере!!! Вы когда-нибудь видели sqlite базу на сотни гигабайт? Я — да. Как их оттуда можно было удалять — я не знаю, этот вопрос как-то решали сисадмины.
На сервере у апача были memory leaks. Ничего лучше кроме как рестарта сервера раз в месяц мы не смогли придумать. Процессы превращались в зомби. Причину не нашли.
Лицензионная политика. Вроде как лицензия давалась на количество хостов, поэтому чтобы сэкономить нам пришлось на некоторых хостах запускать несвязанные между собой приложения.
С логами апача тоже была отдельная проблема в связи с комбо безопасность + закон о защите персональных данных. В итоге доступа к логам из интерфейса ZS не было.
Искренне надеюсь, что они доведут свой продукт до ума. Мы же всё переделали на php/apache, ansible и jenkins и рады.
Поправлю немного: за 250к в Мюнхене можно купить… да ничего собственно. Нормальное жильё, типа 3 комнаты 80 квадратов в черте МКАДа стоит 500-600к. В радиусе 30 км (радиус досягаемости S-Bahn — электрички) стоимость почти такая же, ну может в среднем на 100к ниже.
ЗП программеров в районе 55-70к, что даёт 3000-3800 евро в мес после вычета налогов (муж + неработающая жена).
На первоначальный взнос надо 20% от стоимости жилья. Могут дать кредит и без первоначального взноса, но банк просто просит оплатить некоторые расходы сразу (нотариус, запись в домовой книге итп, обычно эти расходы в районе 10% от стоимости жилья).
По всем моим расчётам, потянуть 500к кредита почти нереально. Имею ввиду расплатиться за 25 лет хотя бы. Надо чтобы семейный доход был 100к+, тогда есть шанс. Ну и наследство, конечно, решает тему.
Если кому интересно, могу инфу по кредитам предоставить, какой процент, сколько лет сидеть в ипотечной кабале и всё такое))
Позвольте дополнить самую последнюю фразу «Проблемы будут всегда.» данной статьи.
О некоторых багах phpamqp-lib. Баг репорты есть на гитхабе, до сих пор нету решения.
1. Consumer: допустим запустили мы consumer и активировали heartbeat. От тихо ожидает новых сообщений в этой точке github.com/php-amqplib/RabbitMqBundle/blob/master/RabbitMq/BaseConsumer.php#L53. Бесконечно долго, т.к. timeout = 0. Допустим, падает сетевое соединение на какое-то время, затем оно восстанавливается. Консьюмер по прежднему ждёт сообщения в той точке, а RabbitMQ уже закрыл соединение. Всё, консьюмер будет висеть в памяти до тех пор, пока его не прибьют сигналом каким-нибудь. Соответсвенно, если в консьюмере есть таймер для «самоубийства», то он не сработает.
2. Без heartbeat могут быть проблемы с незакрытыми соединениями на стороне RabbitMQ. Возможно тут ещё всему виной HAProxy, который в нашем случае стоит перед кластером RabbitMQ.
Из-за этих казалось бы незначительных проблем, код надёжного консьюмера выглядит как бесконечный try/catch и while loops, чтобы консьюмер мог реагировать на разрыв соединения и переподключаться. Такого функционала нету ни в какой высокоуровневой библиотеке (см. Enqueue, например, или бандл, описанный в данной статье)
Далее, есть очень хорошая инициатива — github.com/queue-interop/queue-interop — при помощи данных интерфейсов можно быть независимым от конкретной библиотеки, которая реализует AMQP протокол (phpamqp-lib, php extension, bunny lib). Интерфейсы позаимстованны из мира Java. Но они тоже на начальном этапе своего существования.
Например, в нашем проекты мы решили стать менее зависимыми от конкретной AMQP библиотеки. Посему перевели всех наших consumer/producer на github.com/php-enqueue/enqueue-dev. Проект не на Symfony, поэтому используем только имплементацию Queue Interop интерфейсов с использованием phpamqp-lib, чтобы в ближайшем будущем попробовать имплементацию от bunny lib.
Но тут ждало разочарование: такая фича, как Publisher Confirms, которая есть только в RabbitMQ, отсутсвует out-of-the-box в самих интерфейсах от Queue Interop (тикет на гитхабе есть). Пришлось делать костыли, очень нехорошие костыли. В проекте у нас договорённость о at-least-once delivery, потому и нужен Publisher Confirms.
Если всё подытожить, то вот мои рекомендации:
1. Подумайте 10 раз, нужин ли вам Message Broker вообще. Если можно, используйте MySQL/файлы/что угодно, что уже есть в вашем проекте. Тех поддержка самого RabbitMQ в продакшене — тот ещё геморой для Operations Team.
2. Если всё же решились на Message Broker, то ответьте на вопрос, можете ли вы потерять пару сообщений? Если можете — то используйте любые бандлы/библиотеки. В противном случае крайне рекомендую сначала написать пару consumer/producer на низком уровне (к примеру, используя phpamqp-lib без обёрток) и хорошенько пройдитесь отладчиком, разрывая соединение/физически отключая/аварийно выключая RabbitMQ. Вы удивитесь, как легко можно потерять сообщения. А уже потом подбирайте конкретные высокоуровневые бандлы под свои нужды.
Из киллер фич было:
С чем столкнулись в реальности:
Искренне надеюсь, что они доведут свой продукт до ума. Мы же всё переделали на php/apache, ansible и jenkins и рады.
ЗП программеров в районе 55-70к, что даёт 3000-3800 евро в мес после вычета налогов (муж + неработающая жена).
На первоначальный взнос надо 20% от стоимости жилья. Могут дать кредит и без первоначального взноса, но банк просто просит оплатить некоторые расходы сразу (нотариус, запись в домовой книге итп, обычно эти расходы в районе 10% от стоимости жилья).
По всем моим расчётам, потянуть 500к кредита почти нереально. Имею ввиду расплатиться за 25 лет хотя бы. Надо чтобы семейный доход был 100к+, тогда есть шанс. Ну и наследство, конечно, решает тему.
Если кому интересно, могу инфу по кредитам предоставить, какой процент, сколько лет сидеть в ипотечной кабале и всё такое))
О некоторых багах phpamqp-lib. Баг репорты есть на гитхабе, до сих пор нету решения.
1. Consumer: допустим запустили мы consumer и активировали heartbeat. От тихо ожидает новых сообщений в этой точке github.com/php-amqplib/RabbitMqBundle/blob/master/RabbitMq/BaseConsumer.php#L53. Бесконечно долго, т.к. timeout = 0. Допустим, падает сетевое соединение на какое-то время, затем оно восстанавливается. Консьюмер по прежднему ждёт сообщения в той точке, а RabbitMQ уже закрыл соединение. Всё, консьюмер будет висеть в памяти до тех пор, пока его не прибьют сигналом каким-нибудь. Соответсвенно, если в консьюмере есть таймер для «самоубийства», то он не сработает.
2. Без heartbeat могут быть проблемы с незакрытыми соединениями на стороне RabbitMQ. Возможно тут ещё всему виной HAProxy, который в нашем случае стоит перед кластером RabbitMQ.
Из-за этих казалось бы незначительных проблем, код надёжного консьюмера выглядит как бесконечный try/catch и while loops, чтобы консьюмер мог реагировать на разрыв соединения и переподключаться. Такого функционала нету ни в какой высокоуровневой библиотеке (см. Enqueue, например, или бандл, описанный в данной статье)
Далее, есть очень хорошая инициатива — github.com/queue-interop/queue-interop — при помощи данных интерфейсов можно быть независимым от конкретной библиотеки, которая реализует AMQP протокол (phpamqp-lib, php extension, bunny lib). Интерфейсы позаимстованны из мира Java. Но они тоже на начальном этапе своего существования.
Например, в нашем проекты мы решили стать менее зависимыми от конкретной AMQP библиотеки. Посему перевели всех наших consumer/producer на github.com/php-enqueue/enqueue-dev. Проект не на Symfony, поэтому используем только имплементацию Queue Interop интерфейсов с использованием phpamqp-lib, чтобы в ближайшем будущем попробовать имплементацию от bunny lib.
Но тут ждало разочарование: такая фича, как Publisher Confirms, которая есть только в RabbitMQ, отсутсвует out-of-the-box в самих интерфейсах от Queue Interop (тикет на гитхабе есть). Пришлось делать костыли, очень нехорошие костыли. В проекте у нас договорённость о at-least-once delivery, потому и нужен Publisher Confirms.
Если всё подытожить, то вот мои рекомендации:
1. Подумайте 10 раз, нужин ли вам Message Broker вообще. Если можно, используйте MySQL/файлы/что угодно, что уже есть в вашем проекте. Тех поддержка самого RabbitMQ в продакшене — тот ещё геморой для Operations Team.
2. Если всё же решились на Message Broker, то ответьте на вопрос, можете ли вы потерять пару сообщений? Если можете — то используйте любые бандлы/библиотеки. В противном случае крайне рекомендую сначала написать пару consumer/producer на низком уровне (к примеру, используя phpamqp-lib без обёрток) и хорошенько пройдитесь отладчиком, разрывая соединение/физически отключая/аварийно выключая RabbitMQ. Вы удивитесь, как легко можно потерять сообщения. А уже потом подбирайте конкретные высокоуровневые бандлы под свои нужды.