теперь симфу нельзя будет упрекнуть в тормознутости?

ранее это был один из основных аргументов "против"

ну судя по бенчмаркам 4.0 довольно вкусная по сравнению с 3.4

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

я пару своих консольных команд перевел на 4ку, заметил что по памяти примерно на 20% меньше жору

да Тейлор неадекват или медийный образ такой у него )

подскажите плс, когда внес изменения в конфиги, нужно докер контейнер билдить?

не нужно, подхватило

ранее это был один из основных аргументов "против"

Надуманный аргумент, какая разница пхп работает 5мс или 50мс если проблема на проектах висящие по несколько секунд sql запросы

совсем разные проблемы

говорю как есть

проблема с "висящие sql запросы" решается

а вот 50мс оверхед от симфони ты никуда не денешь

Очень часто я слышал следующее Вопрос: Почему вы не выбрали симфони? Ответ: 1. Порог входа высокий, сложная слишком 2. Тормознутая

и судя по тому куда двигается симфа и ее дока - они как раз с этими вопросами и разбираются в первую очередь

а вот 50мс оверхед от симфони ты никуда не денешь

50мс не смертельно, а искать программистов на супер оптимизированный фалкол со знанием зефира это имхо большая проблема

фалкон не нужен

ну как сказать не смертельно

если у тебя скажем цепочка из 4х сервисов которые надо вызвать последовательно

и на каждом звене по +50мс

помимо времени которое нужно для обработки

то 200мс это довольно много выйдет

А зачем симфони в такой цепочке

то 200мс это довольно много выйдет

В общем согласен

А зачем симфони в такой цепочке

а зачем мне что-то другое?)

смотря какие требования к времени выполнения всей цепочки

а зачем мне что-то другое?)

Так симфони был фулстек

а вот 50мс оверхед от симфони ты никуда не денешь

php-pm)

если у тебя скажем цепочка из 4х сервисов которые надо вызвать последовательно

обычно все же делают воркеры которые через какой pub/sub работают

а в этом случае оверхэда в 50 милисекунд не будет

ну а если ты решил мутить микросервисы и у тебя куча зависимостей между ними и каждый микросервис на ларавели какой с оверхэдом в 100 милисекунд... ну сам себе злой буратино)

опять же если нужно будет - уберешь оверхэд

обычно все же делают воркеры которые через какой pub/sub работают

не всегда это возможно

не всегда это возможно

единственная причина по которой можно придумать кейс что "не возможно" - обратная совместимость и отсутствие контроля за частью сервисов

скорее это создание лишней сложности

скорее это создание лишней сложности

а в чем сложность?)

если тебе нужна синхронная обработка

то через pub/sub лепить rpc это сложно

начнем с того зачем ты вообще изначально начал пилить распределенное приложение

это уже сложно, и "лепить rpc на pub/sub" по сравнению со всеми остальными вариантами - это уже не так сложно как может показаться

раз уж решил нарушить первое правило распределенных приложений (не писать их если можешь) - то значит надо)

Очень часто я слышал следующее Вопрос: Почему вы не выбрали симфони? Ответ: 1. Порог входа высокий, сложная слишком 2. Тормознутая

в ларавел дока хорошая + laracasts, плюс класс как модель проще для понимания

сам ларавельщик, щас симфони изучаю

в ларавел дока хорошая + laracasts, плюс класс как модель проще для понимания

можешь поподробнее про "класс как модель"

я не очень понимаю что ты имеешь ввиду

User, Order

User, Order

модель поведения или модель данных?)

и пошел фигачить все там. Active Record

порог входа действительно ниже

конкретно в моем кейсе щас цепочка из 3х сервисов, но будет 4 в будущем запрос в веб -> сообщение ушло к воркеру -> ушло к другим воркерам -> вызывается сервис агрегатор -> агрегатор дергает другие сервисы конкретных провайдеров вот то что "ушло к воркеру и ушло к другим воркерам" это станет 4м сервисом в цепочке некоторые провайдеры дают SDK на jvm, и чтобы оно не подтекало и не выдавало фокусов, они все работают в изоляции в разных приложухах

Евенты понятные, Service Container понятный. Нет миллиона yaml конфигов

порог входа действительно ниже

надо кривую обучения использовать и порог при котором сделать что-то более сложное будет требовать намного больше знаний...

хотя у симфони те же проблемы)

ну когда ты начинаешь, ты же не осознаешь такие вещи

берешь то что смог

конкретно в моем кейсе щас цепочка из 3х сервисов, но будет 4 в будущем запрос в веб -> сообщение ушло к воркеру -> ушло к другим воркерам -> вызывается сервис агрегатор -> агрегатор дергает другие сервисы конкретных провайдеров вот то что "ушло к воркеру и ушло к другим воркерам" это станет 4м сервисом в цепочке некоторые провайдеры дают SDK на jvm, и чтобы оно не подтекало и не выдавало фокусов, они все работают в изоляции в разных приложухах

тебе надо изначальному гейтвею получить в итоге какой-то результат когда вся цепочка отработает?

почему kassir.ru, citilink, etc… не на симфони? крупные проекты

не осилили :D

почему kassir.ru, citilink, etc… не на симфони? крупные проекты

почему фэйсбук на php.... наверное потому что авторы знали php.

ну

на самом деле - это все вкус и цвет

тебе надо изначальному гейтвею получить в итоге какой-то результат когда вся цепочка отработает?

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

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

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

ну то есть тебе тут pub/sub в целом норм, нет?

в ларавел много чего из коробки, не нужно столько бандлов. Jobs, Queues, JsonResponse, хуяк хуяк и вродакшен

у меня коллега пилит на ларе систему, позволяющую лепить sql-запросы через интерфейс причем запросы там дикие приделал dbal и понеслась - на лару вроде не жалуется

ну то есть тебе тут pub/sub в целом норм, нет?

при взаимодействии сервисов между цепочками?

ERROR: S client not available

do something -> something patially done -> something other partially done -> aggregated -> done

в ларавел много чего из коробки, не нужно столько бандлов. Jobs, Queues, JsonResponse, хуяк хуяк и вродакшен

тут же есть обратная сторона медали - если тебе это нафиг не надо, получаешь оверхед

зануда мод он: JsonResponse в симфе есть искаропки

при взаимодействии сервисов между цепочками?

да, у тебя будет просто цепочка сообщений, ты всеравно последнее сообщение будешь пулингом дожидаться

в ларавел много чего из коробки, не нужно столько бандлов. Jobs, Queues, JsonResponse, хуяк хуяк и вродакшен

единственное что серьезно плюс - наличие нормальной абстракции для очередей из коробки.

а скажем такие вещи как контейнер зависимостей на данный момент, начиная с sf 3.3, сильно выигрывают у ларки

да, у тебя будет просто цепочка сообщений, ты всеравно последнее сообщение будешь пулингом дожидаться

мне не нужно чтобы сервисы знали о том кто их вызывает и зачем

а завязывать целую цепочку на одну шину это не то

мне не нужно чтобы сервисы знали о том кто их вызывает и зачем

так ты и не будешь экспоузить это знание. Просто на уровне контрактов воркеров будет прописано что как только ты закончил работу - сообщи об этом. Кто на это реагировать будет или кто изначально давал задачу воркер не парит

а завязывать целую цепочку на одну шину это не то

почему не то?)

если шина распределенная и не является единой точкой отказа - не вижу проблем)

окей, как вышестоящий сервис узнает о таймаутах, ошибках, как он будет дожидаться ответа?

да и шина то сама по себе тупая и никаких решений не принимает

окей, как вышестоящий сервис узнает о таймаутах, ошибках, как он будет дожидаться ответа?

еще раз схему опиши. У тебя сейчас есть скажем web который получает http запрос и запускает цепочку действий. Ну то есть "обработай что-то". Обработку действий мы можем представить в виде конвеера, так? ну мол есть этап A, B и C. После того как C отработал - надо что бы WEB отрепортовал пользователю что все гуд. Если на любом этапе произошла ошибка - надо отрепортовать что все не гуд.

так?

почти, только данные из C нужны в B, а из B нужны в A

конвеер в обратную сторону еще должен ехать в общем

почти, только данные из C нужны в B, а из B нужны в A

у тебя сейчас эти данные отправляются http запросом или буферизуются где-то временно?

конвеер в обратную сторону еще должен ехать в общем

типа что бы откатить изменения?

а там изменений и нет, там опрос данных

у тебя сейчас эти данные отправляются http запросом или буферизуются где-то временно?

все по http

а там изменений и нет, там опрос данных

ну так зачем конвеер в обратную сторону?

ну мол, вот A все сделал и данные отправил в B, B зафэйлился - зачем об этому знать A?

чтобы вышла обработка A(B(C(data)))

чтобы вышла обработка A(B(C(data)))

еще раз вопрос - зачем A знать о том что B зафэйлился если это нужно знать Web?

если А это тот что с юзером связан, то юзеру как бы надо показать что у нас не все окей

если А это тот что с юзером связан, то юзеру как бы надо показать что у нас не все окей

но показывает Web в нашей цепочке, не A

давай упростим цепочку

есть веб, которому нужны результаты чтобы показать юзеру. это либо результаты проверки ценников, либо ошибки есть шлюз, который опрашивает нужных провайдеров по ценникам есть прокси апишка "трололо", которая выступает в роли провайдера, поверх какого-нибудь замудреного SDK веб обращается к шлюзу с списком продуктов у которых нужно узнать ценник. шлюз определяет что часть продуктов относится к провайдеру "трололо" трололо возвращает данные в своем формате в ответ шлюзу. шлюз эти данные колбасит в общий формат и возвращает вебу. веб показывает ценники в случае ошибки трололо мы показываем конкретную ошибку(креденшиалы не подходят, провайдер недоступен и прочие ошибки которые нам возвращают из вне), эту ошибку передаем обратно шлюзу, шлюз знает че делать с этой ошибкой и в определенном виде отдает ее обратно в веб, веб показывает юзеру что конкретно пошло не так

есть веб, которому нужны результаты чтобы показать юзеру. это либо результаты проверки ценников, либо ошибки есть шлюз, который опрашивает нужных провайдеров по ценникам есть прокси апишка "трололо", которая выступает в роли провайдера, поверх какого-нибудь замудреного SDK веб обращается к шлюзу с списком продуктов у которых нужно узнать ценник. шлюз определяет что часть продуктов относится к провайдеру "трололо" трололо возвращает данные в своем формате в ответ шлюзу. шлюз эти данные колбасит в общий формат и возвращает вебу. веб показывает ценники в случае ошибки трололо мы показываем конкретную ошибку(креденшиалы не подходят, провайдер недоступен и прочие ошибки которые нам возвращают из вне), эту ошибку передаем обратно шлюзу, шлюз знает че делать с этой ошибкой и в определенном виде отдает ее обратно в веб, веб показывает юзеру что конкретно пошло не так

как ты сейчас обрабатываешь случаи когда какой-либо из этапов не зафэйлился но ответ по сети не дошел?

хттп ошибками

rpc на rabbitmq делал когда-нибудь?)