Бележки за четене на https://time.geekbang.org/column/75

Моето предварително четене: Netty в действие е доста важно да разберете какво е Netty, преди да разгледате вътрешността на gRPC.

01 | Въведение в gRPC и как работи gRPC сървърът

Съществуващи RPC рамки:

  1. Многоезична поддръжка: gRPC от Google, Thrift от Facebook
  2. Ограничена езикова поддръжка: Motan
  3. Рамка за разпределена услуга: Dubbo

gRPC е високопроизводителна, OSS и RPC рамка с общо предназначение, базирана на HTTP/2.

gRPC извикване:

Характеристика:

  1. Езиково неутрален: многоезична поддръжка
  2. Базиран на IDL. Генериране на код чрез proto3.
  3. Базира се на HTTP/2, поддържа двупосочен поток, компресиране на заглавки, TCP мултиплекс, натискане на сървъра и т.н.
  4. Поддръжка на протоколен буфер и JSON.

Как се създава gRPC сървър:

  1. gRPC init NettyServer (базиран на Netty 4.1 HTTP/2).
  2. Сървърът регистрира реализациите на API, генерирани от прото инструмента, към неговия вътрешен регистър на услуги и когато постъпят заявки, той извиква регистриран екземпляр на услуга чрез търсене на име на услуга и име на метод вместо чрез отражение, което прави производителността още по-добра.
  3. gRPC сървър impl извиква стартовия метод на NettyServer, за да стартира HTTP/2 сървър и да получава потребителски заявки.

Как gRPC сървърът отговаря на потребителски заявки

  1. Netty 4.1 осигурява HTTP/2 поддръжка. gRPC внедрява Http2ConnectionHandler за управление на съобщения от HTTP/2.
  2. gRPC използва NioEventLoopGroup, за да избегне претоварването на ресурсите.

02 | Как работи gRPC клиентът

Създаване на gRPC клиент

gRPC се намира върху HTTP/2 и е протокол на приложния слой. От страна на клиента, той създава HTTP/2 клиент, базиран на Netty, осигурява баланс на натоварването и отговаря за обработката на заявките.

  1. Клиент инициира RPC извикване.
  2. Разрешете адреса на хоста чрез DnsNameResolver и използвайте LoadBalancer, за да изберете един от наличните екземпляри на gRPC сървъра.
  3. Сериализирайте PB и използвайте HTTP/2 поток за изпращане до gRPC сървъра.
  4. Десериализиране на PB отговора.
  5. Извикване на метод set(Response) в GrpcFuture извикване на блокираща клиентска нишка.

gRPC поддържа 3 начина за договаряне на протоколи

  1. Сървърът поддържа HTTP/2, спестява разходите за надграждане на протокола.
  2. Използвайте HTTP/1.1 за договаряне на протокола и надграждане след това.
  3. TlsNegotiator. Това е изградено директно върху TLS и използва ALPN разширение за преговори. Той използва „h2“ като маркер на протокола.

Как Netty настройва връзка за HTTP/2

Балансиране на натоварването

Два вида балансиране на натоварването

  1. LB от страна на сървъра (външен LB, делегиран LB)
  2. LB от страна на клиента (вътрешен LB и алго, внедрени от страна на клиента)

Пример за външен LB:

Плюсовете на тази архитектура са, че клиентската страна не трябва да прилага LB алгоритми, нито да поддържа списък със сървъри. Това също е от полза за изолацията на мрежата.

Пример за LB от страна на клиента:

По подразбиране gRPC използва LB от страна на клиента и предоставя механизми за разширяване.

03 | gRPC Анализ на модел на нишка

Това беше обсъдено в бележките за четене на Netty In Action, това е типичен модел на NIO реактор:

Ефективността на RPC рамката зависи от 3 ключови фактора:

  1. I/O модел. BIO/NIO или AIO.
  2. протокол. Rest + JSON или бинарен TCP протокол.
  3. Модел на резба. Къде се извършва декодирането/кодирането.

Модел на нишка от страната на сървъра

Създаването на HTTP/2 сървър, обработката на заявките се обработват от netty, а де/сериализацията се обработва от набора от нишки SerializingExecutor на gRPC.

Модел на нишка от страна на клиента

04 | Как работи gRPC Service Call

Няколко общи механизма за повикване на услугата:

  1. Синхронно повикване.
  2. Паралелно повикване за услуга.
  3. Айнхронно сервизно обаждане.

gRPC предоставя 2 начина за RPC повикване

  1. Нормално RPC повикване: поискайте и отговорете.
  2. База за поточно обаждане на HTTP/2. Направете възможно сървърът (или клиентът) да може да отговаря с множество отговори (като 1000 елемента за емисии, партида по партида).

05 | Дизайн на сигурността на gRPC

Комуникациите през границата на мрежата трябва да се предават чрез TLS/SSL.

Ако само част от предадените данни съдържа чувствителни данни, можем също така да шифроваме само тази част от данните:

Това може лесно да се постигне с Netty Handler.

Удостоверяване на самоличността

Има няколко начина за извършване на удостоверяване на самоличността: HTTP Basic Authentication, OAuth2, Token и др. Пример за удостоверяване на Token:

Удостоверяване на ниво на достъп

Често срещан подход е базирано на OAuth 2.0 удостоверяване:

  1. Клиент иска собственик на ресурс за удостоверяване (с потребителско име, парола и т.н.)
  2. Собственикът на ресурса се удостоверява въз основа на предоставената информация и присвоява маркер за удостоверяване на клиента.
  3. Клиентът използва токен от стъпка 2 и иска токен за достъп от сървъра за оторизация.
  4. Сървърът за оторизация издава токен за достъп, след като бъде валидиран.
  5. Клиентът носи токен за достъп до своето RPC извикване към бекенд ресурси.
  6. Бекенд услугите валидират токена за достъп за достъп.
  7. Ако токенът за достъп премине проверката, ресурсният сървър връща информация на клиента.

Цялостност и последователност на данните

Използвайте SHA & MAC.

gRPC механизми за сигурност

  1. Удостоверяване на канала По подразбиране се предоставя TLS въз основа на HTTP/2.
  2. Извикване Auth. Идентификационните данни се добавят към заглавките на съобщението за всяко RPC извикване.
  3. Combo Auth. 1 + 2.
  4. Google OAuth 2.0. Когато осъществявате достъп до API на Google с gRPC, той използва ключ за акаунти за услуги, за да поиска токен за достъп.

06 | gRPC сериализация

Обща рамка за сериализация

java.io.Serializable

Минуси:

  1. не може да пресича езици.
  2. не е производителен.

Пестеливост

Професионалисти:

  1. Поддържа тонове езици
  2. IDL е супер мощен
  3. Осигурява съвместимост напред

Минуси:

  1. Промените в структурата на данните изискват редактиране на IDL файл, повторно генериране на код.

MessagePack

Ефективен двоичен протокол.

Протобуфери

Зряла, междуплатформена/езикова/ефективна/ефективна и съвместимост напред.

Proto Buffers се поддържат в Netty. Просто трябва да добавите Codec Handler към ChannelPipeline.

Как работи gRPC сериализацията?

Диаграма:

  1. Използвайте модел на строител, за да зададете ключ-стойности въз основа на генерирания от ProtoBuf код и да настроите съобщение
  2. Сериализирайте съобщението в 1) и създайте ProtoInputStream.
  3. Създайте NettyClientStream и gRPC HTTP/2 заглавки.
  4. Опаковайте сериализираното съобщение в SendGrpcFrameCommand и го изпратете през NIO нишката на Netty.
  5. NettyClientHandler на gRPC инициира заявката за запис и използва Http2ConnectionEncoder, за да я изпрати през HTTP/2 стека на протокола на Netty.

Край на историята