2020 подписчиков
📌 Golang RPC и все-все-все…
Disclaimer: this is not another one gRPC hate article... Oh, whait...
Начнем издалека - знаете, всегда было интересно, а почему, собственно, для golang существует такое большое разнообразие библиотек, для каких-то часто используемых сущностей, как-то - роутеры http (fasthttprouter забыли, как подсказали в коментах) или cache?
С выбором RPC вроде все просто, gRPC - наше всё (вы, кстати, в курсе, что g здесь - это не Google внезапно). Но не тут-то было...
Все просто без ума от Мэри gRPC (нет).
Начнем с того, что в golang изначально реализовали net/rpc со своим сериализатором gob. Типа есть потребность - в golang есть решение из коробки (так же история, что и с роутером http - он есть, но все используют сторонние решения из-за параметризованных путей запросов). И тут засада - этот rpc можно только между golang приложениями использовать. Потом выкатили gRPC и все заверте... Вкратце - gRPC использует http/2 и protobuf для сериализации (запомним, rpc - это протокол обмена плюс сериализатор). Причем gRPC реализация доступна для многих языков, фактически нет привязки, на чем писать клиентскую и серверную часть. So far, so good...
Однако не все так гладко... Понятно стремление Google объять все возможные кейсы, но! К оригинальной реализации gRPC со временем появилось куча вопросов. Иначе как объяснить, что куча контор начали пилить свои собственные реализации RPC (и/или сериализаторов)? Также, внезапно, выяснилось, что требования к RPC внутри облака (читай между микросервисами) и RPC между клиентами за пределами облака/датацентра и сервисами внутри него (за ingress/proxy/load balancer - как хотите называйте) как бы "немножко" разные? Да и выбор http/2 в качестве транспорта - ну кто-же знал, что внедрёж пойдет не так (быстро), как ожидалось.
➡️ Читать
1 минута
20 сентября 2022