Комментарии 12
HTTP/2 в качестве транспорта — можно прекратить выполнение запроса на сервере, а еще переиспользовать один cокет для нескольких параллельных запросов.
Сомнительное преимущество, по крайней мере в такой формулировке.
Голый TCP стрим позволяет всё тоже самое — писать в стрим можно сколько угодно, так что конкурентные (не параллельные, кстати!) запросы есть сразу из коробки. Прекратить выполнение запроса на сервере — если сервер поддерживает, то можно и в рамках отдельной PDU иметь такой функционал.
Кажется HTTP здесь только добавляет оверхэд.
Например, у нас были проблемы с
таймзонами — и было решение, но на PHP.
А какого рода и как решили?
Операторы звонят людям по МСК (GMT +3), условно, с 10 до 20. Но если клиент, скажем, из Иркутска, у него GMT+8 — пять часов разницы. Поэтому плохо звонить ему в 17 вечера по МСК, ведь в Иркутске будет 22 — клиент будет не очень рад.
Значит, нужно с определенного времени по МСК этим клиентам перестать звонить. Просто считаем промежуток времени по МСК, когда можно звонить, а когда нельзя.
Значит, нужно с определенного времени по МСК этим клиентам перестать звонить. Просто считаем промежуток времени по МСК, когда можно звонить, а когда нельзя.
Если поменять формулировку на «Операторы (находясь в GMT+3) звонят людям по UTC, условно, с 7 до 17», то количество проблем с таймзонами снизится примерно вдвое.
То что клиент из Иркутска (GMT +8) — информация тоже важная, но её можно дополнительно сформулировать иначе: клиент будет рад звонку в диапазоне с 02:00 до 12:00 по UTC.
Соответственно где-то в алгоритме обзвона будет переменная «текущее время по UTC».
Таким нехитрым образом можно избавиться от всех проблем с таймзонами =)
То что клиент из Иркутска (GMT +8) — информация тоже важная, но её можно дополнительно сформулировать иначе: клиент будет рад звонку в диапазоне с 02:00 до 12:00 по UTC.
Соответственно где-то в алгоритме обзвона будет переменная «текущее время по UTC».
Таким нехитрым образом можно избавиться от всех проблем с таймзонами =)
для чата использую gRPC C++. Асинхронный вариант вполне устраивает. запрос — ответ. Но может кто посоветует — как отправлять сообщения с сервера на клиент ( то есть без запроса). Например, клиент в канале отправляет сообщение. Это сообщение приходит на сервер и должно отправиться всем подписчикам канала. Но без запроса от клиентов я не могу им отправить. Конечно можно добавить запрос на новые сообщения от клиентов раз в таймоут или чтобы все клиенты по stream сообщениям общались — но как по мне это серьезно повысит нагрузку. Сейчас использую промежуточный сервер с booost::asio. Но может есть решение с gRPC?
как сгенерировать код с неймспейсами в нашем протофайле
На самом деле в протобуфе есть специальный message, отвечающий за настройки генерации исходников из протофайла на любом языке.
protoc знает о нём из коробки, и соответственно задать нужные нам настройки генерации файлов можно в три строки:
option php_namespace = 'Your\\Namespace\\Here\\';
option php_metadata_namespace = 'Your\\Namespace\\Here\\GPBMetadata';
option go_package = "github.com/whatever/lib"
package в proto нужен не только и не столько для неймспейсов в PHP — с точки зрения protobuf все proto находятся в одном, глобальном нейспейсе. Поэтому мессадж MyMessage{} из pds2.proto будет пересекаться с методом MyMessage{} из totally_different.proto, если у них не прописаны / совпадают package.
Это (на мой взгляд) вообще не очевидно, т.к. и сервис, и клиент после генерации прекрасно работают, но когда нужно подключить второй proto — бабах! Возможно, вы даже получите об этом ошибку, но это не точно.
Вообще, gRPC и protobuf в PHP, как мне кажется, писал какой-то штрафбат, т.е. сотрудники, которых реально наказали за что-то, поэтому там качество соответствующего уровня:
Например, поддержка proto2 там была просто закомментирована if (proto == «proto2») {ошибка}. Или вот тикет — сломали uint32 на x84-64. Или вот — дедлок внутри gRPC потому что никто не проверяет результаты функций.
Но самый мой любимый кейс такой — в модуль gRPC пришлось специально добавлять (довольно костыльно) поддержку fork(). Авторы сказали, что они не расчитывали на то, что этот код будет использоваться в языках, где есть fork(). Код при этом написан на Си (facepalm.jpg).
В общем, мы всё ещё собираем грабли, которые сотрудники Google заботливо разбросали по всему коду grpc и protobuf. Надеюсь, они уже подходят к концу.
Это (на мой взгляд) вообще не очевидно, т.к. и сервис, и клиент после генерации прекрасно работают, но когда нужно подключить второй proto — бабах! Возможно, вы даже получите об этом ошибку, но это не точно.
Вообще, gRPC и protobuf в PHP, как мне кажется, писал какой-то штрафбат, т.е. сотрудники, которых реально наказали за что-то, поэтому там качество соответствующего уровня:
Например, поддержка proto2 там была просто закомментирована if (proto == «proto2») {ошибка}. Или вот тикет — сломали uint32 на x84-64. Или вот — дедлок внутри gRPC потому что никто не проверяет результаты функций.
Но самый мой любимый кейс такой — в модуль gRPC пришлось специально добавлять (довольно костыльно) поддержку fork(). Авторы сказали, что они не расчитывали на то, что этот код будет использоваться в языках, где есть fork(). Код при этом написан на Си (facepalm.jpg).
В общем, мы всё ещё собираем грабли, которые сотрудники Google заботливо разбросали по всему коду grpc и protobuf. Надеюсь, они уже подходят к концу.
а еще переиспользовать один cокет для нескольких параллельных запросов
Кажется в PHP, который после каждого запроса умирает, это работать не может
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
НЕкостыль: gRPC-клиент на PHP в продакшене