Comments 13
На левом фото 10 мисок и 10 щенков, на правом 10 мисок и 9 щенков… Умоляю, напишите, что ни один из щенков не пострадал!
PS. Ура, обнаружил его заднюю часть во второй сверху группе — можно спать спокойно.
PS. Ура, обнаружил его заднюю часть во второй сверху группе — можно спать спокойно.
После прочтения возник ряд вопросов:
Следует ли из этого, что по мнению автора, без Swoole нельзя создать микросервис на php? Небольшой сервис, использующий php-fpm не будет считаться «микросервисом»?
Это вообще невероятно спорное утверждение, ничем не подкрепленное. На мой взгляд оно развнозначно словам «Замороженные пельмени позволяют: ускорить запросы, инкапсулировать логику [...]»
В итоге по-факту вы просто описываете кейс с применением swoole для создания долгоживущего приложения на php. При этом практически не затронута сама тема микросервисов и построения соотв. архитектуры.
Swoole позволяет использовать микросервисную архитектуру в php проектах
Следует ли из этого, что по мнению автора, без Swoole нельзя создать микросервис на php? Небольшой сервис, использующий php-fpm не будет считаться «микросервисом»?
Микросервисы позволяют: ускорить запросы, инкапсулировать логику, упростить код и избавится от дублирования зависимостей.
Это вообще невероятно спорное утверждение, ничем не подкрепленное. На мой взгляд оно развнозначно словам «Замороженные пельмени позволяют: ускорить запросы, инкапсулировать логику [...]»
В итоге по-факту вы просто описываете кейс с применением swoole для создания долгоживущего приложения на php. При этом практически не затронута сама тема микросервисов и построения соотв. архитектуры.
Спасибо за отклик!
Реализовать микросервисы можно на чем угодно. Вопрос только в удобстве использования, удобочитаемости кода, скорости разработки и простоты в поддержке. От использования нативного php для микросервиса меня отталкивают сложности в коммуникации с этим микросервисом. Swoole дает возможность использовать http/ws/tcp для коммуникации и делает приложение долгоживущим. Для этой задачи это было то, что нужно.
Посмотрел список характерных свойств у микросервисной архитектуры: модульность, сгруппированность по функциям, независимость при обновлении/изменении. Конфликт тут только с утверждением «ускорить запросы». Вы правы, оно касается только моего конкретного случая и следовало бы указать это.
Совершенно верно, я даже добавил пометку tutotial, что бы подчеркнуть что это некая инструкция на настройке и использованию swoole в подобных ситуациях.
Буду признателен за пояснение или какие либо примеры.
Следует ли из этого, что по мнению автора, без Swoole нельзя создать микросервис на php? Небольшой сервис, использующий php-fpm не будет считаться «микросервисом»?
Реализовать микросервисы можно на чем угодно. Вопрос только в удобстве использования, удобочитаемости кода, скорости разработки и простоты в поддержке. От использования нативного php для микросервиса меня отталкивают сложности в коммуникации с этим микросервисом. Swoole дает возможность использовать http/ws/tcp для коммуникации и делает приложение долгоживущим. Для этой задачи это было то, что нужно.
Это вообще невероятно спорное утверждение, ничем не подкрепленное. На мой взгляд оно развнозначно словам «Замороженные пельмени позволяют: ускорить запросы, инкапсулировать логику [...]»
Посмотрел список характерных свойств у микросервисной архитектуры: модульность, сгруппированность по функциям, независимость при обновлении/изменении. Конфликт тут только с утверждением «ускорить запросы». Вы правы, оно касается только моего конкретного случая и следовало бы указать это.
В итоге по-факту вы просто описываете кейс с применением swoole для создания долгоживущего приложения на php.
Совершенно верно, я даже добавил пометку tutotial, что бы подчеркнуть что это некая инструкция на настройке и использованию swoole в подобных ситуациях.
При этом практически не затронута сама тема микросервисов и построения соотв. архитектуры.
Буду признателен за пояснение или какие либо примеры.
На самом деле swoole тут совсем не к месту. Поясню слегка...
Использование swoole подразумевает отсутствие блокирующих операций. Как только таковые встречаются, карета превращается в тыкву. Использование неспециализированного http клиента, например. Или тот же echo. В общем и целом весь профит от swoole свёлся к демонизации приложения. Но с таким же успехом можно было взять RoadRunner и не париться. Ну и да, каким боком тут микросервисы затесались совсем не понятно
Использование swoole подразумевает отсутствие блокирующих операций.
Почему вы считаете, что подразумевает? Несомненно, это необходимое условие для того, что бы swoole мог обеспечить высокий RPS. Но меня не интересует работа при высоких RPS, меня интересует время отклика на одиночные запросы и упрощение работы с telegram api.
Тут вспоминается анекдот:
— А у тебя машина заводится в -25?
— Хрен ее знает, двери не открываются!
Нет никакого смысла в высоких RPS, ведь уже при 3 запросах в секунду телеграм заблокирует аккаунт за флуд и сервис превратится в тыкву :)
Но с таким же успехом можно было взять RoadRunner и не париться.
Можно было взять много чего. Если рассматривать только php, то есть еще amp. Но есть несколько факторов, из за которых я выбрал swoole:
- он популярнее amp и roadrunner, если судить по звездам на гитхабе
- помимо сервера у него есть много дополнительных возможностей среди которых: корутины, асинхронные операции
- субьективное: код для запуска сервера на swoole выглядит аккуратнее
Единственный для меня минус: нет возможности использовать на shared хостингах или на VPS c openVZ, если swoole не установлен хостером.
Почему вы считаете, что подразумевает?
Потому что кооперативная многозадачность?
Вы для чего брали swoole? что бы демона сделать? Зачем? Для каких целей?
Ну, как бы микроскопом можно гвозди забивать, но стоит ли?
Можно было взять много чего. Если рассматривать только php, то есть еще amp.
он популярнее amp и roadrunner
Вы правда понимаете для чего нужны все перечисленные инструменты? В тексте чувствуется глубокое понимание темы.
помимо сервера у него есть много дополнительных возможностей среди которых: корутины, асинхронные операции
Те самые, что не будут работать должным образом из-за блокировки вами потока выполнения, да?
Единственный для меня минус: нет возможности использовать на shared хостингах или на VPS c openVZ, если swoole не установлен хостером.
Вы swoole притянули за уши только потому, что можете. Толку от него, как с козла молока и ни одного плюса нет (есть, но вы их все похоронили собственноручно)
Вы для чего брали swoole? что бы демона сделать? Зачем? Для каких целей?
Ну, как бы микроскопом можно гвозди забивать, но стоит ли?
Я абсолютно согласен, что инструмент должен подходить под цели.
Цель: демон на php, с которым легко наладить связь по http и который максимально легко написать, поддерживать и использовать. Почему вы считаете, что swoole не подходит для этих целей? Что подходит лучше? Roadrunner? Он точно проще?
Документация у него не самая полная. Например, что бы отправить медиа файл в swoole достаточно двух строк:
$response->header('Content-Type', 'image/jpeg');
$response->sendfile('%путь к файлу%');
У swoole, например, есть полный список методов для сервера и его вполне достаточно: www.swoole.co.uk/docs/modules/swoole-server-methods
А как это сделать в roadrunner я не смог найти. В документации всего один пример. Я даже не могу сказать, может ли roadrunner менять заголовки у ответов…
Hello, developer of MadelineProto here!
Thank you so much for using my library in your project, it's really awesome!
I wanted to rewrite my old PWRTelegram HTTP API for the new MadelineProto for a long time, and now you come up with a simple alternative, just perfect!
If you want to, I could make TelegramSwoole the official successor of PWRTelegram.
Reading the comments here, I see people saying that swoole is pretty useless in a blocking, non-async context; that's why I suggest you try to use the new async MadelineProto API based on amphp: I'm currently rewriting the whole library to fully support async operation, and most of the automatically-wrapped API methods are already fully async.
The async API is still rather alpha, and I haven't written proper docs yet, but you can take a look at the bot.php in the main repo or ask me in the groups for help, if you want to.
P.S. amphp is an extremely powerful set of coroutine-based libraries, with async clients/servers for TCP, UDP, HTTP, redis, MySQL, websocket, DNS, windows registry API, and many async backends supported (native PHP or extension-based), as well as hybrid multi-threaded async worker support for blocking operations that simply cannot be done using the amphp libraries (and even if I highly dislike and recommend against using anything multi-threaded in PHP, be it the extremely buggy pthreads or just the simple glitchy forks (both supported by amphp), or even the web-request multithreaded backend supported by amphp, it's cool that you can do so many amazing async things in PHP with a simple user-space library), I suggest you check it out)
Thank you so much for using my library in your project, it's really awesome!
I wanted to rewrite my old PWRTelegram HTTP API for the new MadelineProto for a long time, and now you come up with a simple alternative, just perfect!
If you want to, I could make TelegramSwoole the official successor of PWRTelegram.
Reading the comments here, I see people saying that swoole is pretty useless in a blocking, non-async context; that's why I suggest you try to use the new async MadelineProto API based on amphp: I'm currently rewriting the whole library to fully support async operation, and most of the automatically-wrapped API methods are already fully async.
The async API is still rather alpha, and I haven't written proper docs yet, but you can take a look at the bot.php in the main repo or ask me in the groups for help, if you want to.
P.S. amphp is an extremely powerful set of coroutine-based libraries, with async clients/servers for TCP, UDP, HTTP, redis, MySQL, websocket, DNS, windows registry API, and many async backends supported (native PHP or extension-based), as well as hybrid multi-threaded async worker support for blocking operations that simply cannot be done using the amphp libraries (and even if I highly dislike and recommend against using anything multi-threaded in PHP, be it the extremely buggy pthreads or just the simple glitchy forks (both supported by amphp), or even the web-request multithreaded backend supported by amphp, it's cool that you can do so many amazing async things in PHP with a simple user-space library), I suggest you check it out)
Hello, danog!
Im very pleased, its good to know that my work is useful! And i want to thank you for super easy step-by-step setup in madelineProto! :)
Thanks for example in bot.php, i will use async mode in madelineProto in my lib ASAP.
Also i'll try to use amphp in TelegramSwooleClient as alternative to swoole, when swoole extension is not available.
What do you need from me, to make TelegramSwooleClient official successor of PWRTelegram?
Im very pleased, its good to know that my work is useful! And i want to thank you for super easy step-by-step setup in madelineProto! :)
Thanks for example in bot.php, i will use async mode in madelineProto in my lib ASAP.
Also i'll try to use amphp in TelegramSwooleClient as alternative to swoole, when swoole extension is not available.
What do you need from me, to make TelegramSwooleClient official successor of PWRTelegram?
mmasiukevich спасибо за объективную критику, касательно блокирующих операций. Заменил стандартный Curl на \Swoole\Coroutine\Http\Client. Пришлось переписать всего 10 строк кода.
При одиночных запросах разницы нет, но когда идет одновременный запрос 5-10 медиа-файлов, то поведение TelegramRSS стало лучше. «Долгие» запросы на получение медиа файлов теперь не блокируют, например, отдачу главной страницы.
При одиночных запросах разницы нет, но когда идет одновременный запрос 5-10 медиа-файлов, то поведение TelegramRSS стало лучше. «Долгие» запросы на получение медиа файлов теперь не блокируют, например, отдачу главной страницы.
Sign up to leave a comment.
Микросервисы на php и swoole для конвертации телеграм каналов в RSS