C
Size: a a a
2021 January 24
в
Konstantin dmz9
да я тож против виндовой разработки, просто многие защитники пишут мол там все ок. ну вот оказывается что все еще не ок😂
Да нихера не ок, под виндой разве что на дотнете писать
в
PHpstorm вроде предупреждает о таком случае если у тебя регистры проекта и файловой системы не совпадают
А не факт что джун на эти варнинги смотрит
C
А не факт что джун на эти варнинги смотрит
Джун хороший, не обижайте его). Но ситуация в целом показательна, поэтому рассказал
в
Ладно)
А
Всем привет, у меня назрел вопрос про микросервисы и PHP:)
Я знаком с единственным способом приготовить микросервисы на PHP — это message queue. И схема там простая — есть брокер (Kafka, RabbitMq, etc.) и на него подписаны воркеры микросервисов, ловящие события.
Такой подход решает проблему последовательного вызова микросервисов друг другом, т.е. поток выполнения не ждет http response, а бросает событие в очередь и ок.
Подход применим на операции записи и имеет прямой профит, когда на одно событие должен прореагировать больше чем 1 микросервис. А операции чтения проходят через API Gateway прямым пробросом запроса до нужного микросервиса.
Эта телега выше чиста, чтоб мое текущее миропонимание закомитить.
И соответственно, вопрос, как строить микросервисы с gRPC? Какую роль оно играет?
Вопросы, детально:
1. Это же http вызовы, правильно понимаю? Т.е. по факту схема остается прежней — рядом с контейнером PHP приложения должен крутиться nginx, который дёргает php-fpm?
2. Не могу понять как оно в таком случае дружит с неасинхронным поведением PHP? Или не дружит?
3. В чем профит?) Я правильно понимаю, что микросервисы теоретически можно проектировать как бандлы — высовывать наружу высокоуровневый интерфейс и вызывать его через gRPC?
Я знаком с единственным способом приготовить микросервисы на PHP — это message queue. И схема там простая — есть брокер (Kafka, RabbitMq, etc.) и на него подписаны воркеры микросервисов, ловящие события.
Такой подход решает проблему последовательного вызова микросервисов друг другом, т.е. поток выполнения не ждет http response, а бросает событие в очередь и ок.
Подход применим на операции записи и имеет прямой профит, когда на одно событие должен прореагировать больше чем 1 микросервис. А операции чтения проходят через API Gateway прямым пробросом запроса до нужного микросервиса.
Эта телега выше чиста, чтоб мое текущее миропонимание закомитить.
И соответственно, вопрос, как строить микросервисы с gRPC? Какую роль оно играет?
Вопросы, детально:
1. Это же http вызовы, правильно понимаю? Т.е. по факту схема остается прежней — рядом с контейнером PHP приложения должен крутиться nginx, который дёргает php-fpm?
2. Не могу понять как оно в таком случае дружит с неасинхронным поведением PHP? Или не дружит?
3. В чем профит?) Я правильно понимаю, что микросервисы теоретически можно проектировать как бандлы — высовывать наружу высокоуровневый интерфейс и вызывать его через gRPC?
АГ
Misha Fomin
Так на 20 мин быстрее
На 20 минут быстрее начать, но в процессе будет потрачено гораздо больше на поиск не типичных проблем.
VK
Всем привет, у меня назрел вопрос про микросервисы и PHP:)
Я знаком с единственным способом приготовить микросервисы на PHP — это message queue. И схема там простая — есть брокер (Kafka, RabbitMq, etc.) и на него подписаны воркеры микросервисов, ловящие события.
Такой подход решает проблему последовательного вызова микросервисов друг другом, т.е. поток выполнения не ждет http response, а бросает событие в очередь и ок.
Подход применим на операции записи и имеет прямой профит, когда на одно событие должен прореагировать больше чем 1 микросервис. А операции чтения проходят через API Gateway прямым пробросом запроса до нужного микросервиса.
Эта телега выше чиста, чтоб мое текущее миропонимание закомитить.
И соответственно, вопрос, как строить микросервисы с gRPC? Какую роль оно играет?
Вопросы, детально:
1. Это же http вызовы, правильно понимаю? Т.е. по факту схема остается прежней — рядом с контейнером PHP приложения должен крутиться nginx, который дёргает php-fpm?
2. Не могу понять как оно в таком случае дружит с неасинхронным поведением PHP? Или не дружит?
3. В чем профит?) Я правильно понимаю, что микросервисы теоретически можно проектировать как бандлы — высовывать наружу высокоуровневый интерфейс и вызывать его через gRPC?
Я знаком с единственным способом приготовить микросервисы на PHP — это message queue. И схема там простая — есть брокер (Kafka, RabbitMq, etc.) и на него подписаны воркеры микросервисов, ловящие события.
Такой подход решает проблему последовательного вызова микросервисов друг другом, т.е. поток выполнения не ждет http response, а бросает событие в очередь и ок.
Подход применим на операции записи и имеет прямой профит, когда на одно событие должен прореагировать больше чем 1 микросервис. А операции чтения проходят через API Gateway прямым пробросом запроса до нужного микросервиса.
Эта телега выше чиста, чтоб мое текущее миропонимание закомитить.
И соответственно, вопрос, как строить микросервисы с gRPC? Какую роль оно играет?
Вопросы, детально:
1. Это же http вызовы, правильно понимаю? Т.е. по факту схема остается прежней — рядом с контейнером PHP приложения должен крутиться nginx, который дёргает php-fpm?
2. Не могу понять как оно в таком случае дружит с неасинхронным поведением PHP? Или не дружит?
3. В чем профит?) Я правильно понимаю, что микросервисы теоретически можно проектировать как бандлы — высовывать наружу высокоуровневый интерфейс и вызывать его через gRPC?
А в чем разница gRPC и http?
А
А в чем разница gRPC и http?
Да хрен его знает, почитал и не понял
Судя по всему gRPC это что-то аля веб-сервер
Судя по всему gRPC это что-то аля веб-сервер
VK
Да хрен его знает, почитал и не понял
Судя по всему gRPC это что-то аля веб-сервер
Судя по всему gRPC это что-то аля веб-сервер
Иди почитай еще)
А
Иди почитай еще)
Спасибо, дорогой
VK
Тогда вопрос уйдет сам собой
в
Дааа, грпс это прям вебсервер-вебсервер
в
Апач, не иначе
А
Тогда вопрос уйдет сам собой
А вы то мне зачем нужны?)
SM
У меня в команде есть джун, он работает на винде с опенсервером. Недавно был случай - у него код работает ок, а на сервере пишет что не может найти класс.
В итоге причина оказалась в том, что в винде пути - case insensitive, а в Линуксе, понятно, case sensitive. А в одном новом пакете в проекте был неверно указан неймспейс (с регистром промахнулись, не по PSR4). В винде это проглатывалось, а в Линуксе нет.
Вывод - разрабатывайте на системе, максимально близкой к продакшну.
В итоге причина оказалась в том, что в винде пути - case insensitive, а в Линуксе, понятно, case sensitive. А в одном новом пакете в проекте был неверно указан неймспейс (с регистром промахнулись, не по PSR4). В винде это проглатывалось, а в Линуксе нет.
Вывод - разрабатывайте на системе, максимально близкой к продакшну.
Я когда был джуном, то мне просто сказали шо онли убунта. И оказались правы. Теперь и так джунам говорю.
VK
А вы то мне зачем нужны?)
Действительно