Привет всем, я Jianyu. В качестве вводной главы сегодня я представлю некоторые знания, связанные с gRPC. Короче говоря, gRPC — это инфраструктура RPC, разработанная на основе протокола HTTP/2, которая использует Protobuf в качестве IDL.
Вы когда-нибудь задумывались, что они из себя представляют? В этой статье будут представлены некоторые часто используемые знания и концепции, и более подробно будет дан адрес руководства, чтобы углубиться
1. ПКР
Что такое RPC
RPC означает удаленный вызов процедур, и его вызов включает в себя транспортный протокол и протокол кодирования (серийный номер объекта) и так далее. Позволяет программе, работающей на одном компьютере, вызывать подпрограмму на другом компьютере без дополнительного программирования взаимодействия разработчиком.
Фактическая сцена:
Есть два сервера А и Б. Приложение C на A хочет вызвать приложение D на сервере B, могут ли они быть вызваны напрямую локально?
Ответ — нет, но RPC очень удобен. Поэтому часто говорят, что использовать RPC так же просто, как вызвать функцию локально.
Фреймворк RPC
На мой взгляд, полная структура RPC должна включать в себя такие функции, как балансировка нагрузки, регистрация и обнаружение сервисов, управление сервисами и т. д., и быть масштабируемой для облегчения доступа к системам мониторинга трафика.
Тогда он полный, конечно. Некоторые относительно отдельные фреймворки RPC также могут соответствовать этому стандарту, комбинируя несколько компонентов.
Что вы думаете?
Общие фреймворки RPC
сравнивать
| \ | кросс язык | Мульти-IDL | Служба управления | Регистрационный центр | Управление услугами |
|---|---|---|---|---|---|
| gRPC | √ | × | × | × | × |
| Thrift | √ | × | × | × | × |
| Rpcx | × | √ | √ | √ | √ |
| Dubbo | × | √ | √ | √ | √ |
Почему RPC
Простой, универсальный, безопасный, эффективный
RPC через HTTP может сделать
RPC означает удаленный вызов процедур, который может быть основан на протоколе HTTP.
Некоторые люди обязательно скажут преимущество в эффективности, я вам скажу, что на основе HTTP/1.1, HTTP/2 оптимизирует многие проблемы (конечно, есть новые проблемы), поэтому вы видите тему этой статьи gRPC
2. Протобуф
вводить
Protocol Buffers — это независимый от языка и платформы масштабируемый метод сериализации структурированных данных, обычно используемый в протоколах связи, хранении данных и т. д. По сравнению с JSON, XML меньше, быстрее и проще, поэтому более популярен среди разработчиков.
грамматика
syntax = "proto3";
service SearchService {
rpc Search (SearchRequest) returns (SearchResponse);
}
message SearchRequest {
string query = 1;
int32 page_number = 2;
int32 result_per_page = 3;
}
message SearchResponse {
...
}
1. Первая строка (непустая строка без комментариев) объявляет использованиеproto3грамматика. Если вы не объявите, используйте его по умолчаниюproto2грамматика. В то же время я предлагаю использовать v2 или v3, обе должны указать версию, которую они используют.
2. ОпределениеSearchServiceСлужба RPC, которая содержит методы RPC.Search, входной параметрSearchRequestсообщение, вывод какSearchResponseИнформация
3, определениеSearchRequest,SearchResponseсообщение, первое определяет три поля, каждое из которых содержит три атрибута: тип, имя поля, номер поля
4. Компилятор Protobuf сгенерирует код интерфейса службы и заглушки соответствующего языка в соответствии с выбранным языком.
Наконец, вот простое введение в грамматику, пожалуйста, поверните направо, чтобы узнать подробности Language Guide (proto3)
Тип данных
| .proto Type | C++ Type | Java Type | Go Type | PHP Type |
|---|---|---|---|---|
| double | double | double | float64 | float |
| float | float | float | float32 | float |
| int32 | int32 | int | int32 | integer |
| int64 | int64 | long | int64 | integer/string |
| uint32 | uint32 | int | uint32 | integer |
| uint64 | uint64 | long | uint64 | integer/string |
| sint32 | int32 | int | int32 | integer |
| sint64 | int64 | long | int64 | integer/string |
| fixed32 | uint32 | int | uint32 | integer |
| fixed64 | uint64 | long | uint64 | integer/string |
| sfixed32 | int32 | int | int32 | integer |
| sfixed64 | int64 | long | int64 | integer/string |
| bool | bool | boolean | bool | boolean |
| string | string | String | string | string |
| bytes | string | ByteString | []byte | string |
Основное отличие v2 от v3
- Логика присутствия поля для удаления полей исходного значения
- удалить обязательные поля
- Удалите необязательное поле, по умолчанию
- удалить поле по умолчанию
- Удалите атрибут расширения и добавьте тип Any, чтобы заменить его.
- Поддержка удаления неизвестного поля
- новыйJSON Mapping
- Добавлена поддержка типа карты.
- исправить неизвестный тип перечисления
- многократное использование упакованной кодировки по умолчанию
- Представлены новые языковые реализации (C#, JavaScript, Ruby, Objective-C).
Выше приведены общие функции, связанные с повседневной жизнью.Если вы хотите узнать об этом больше, вы можете прочитатьProtobuf Version 3.0.0
Почему бы не использовать XML вместо Protobuf?
- проще
- Файлу описания данных требуется только от 1/10 до 1/3 оригинала.
- Скорость парсинга от 20 до 100 раз быстрее
- снижение неопределенности
- Созданы более простые в использовании классы доступа к данным
3. гРПЦ
вводить
gRPC — это высокопроизводительная платформа RPC общего назначения с открытым исходным кодом, предназначенная для мобильных устройств и HTTP/2.
многоязычный
- C++
- C#
- Dart
- Go
- Java
- Node.js
- Objective-C
- PHP
- Python
- Ruby
Функции
1. HTTP/2
2. Протобуф
3. Клиент и сервер основаны на одном и том же IDL
4. Хорошая поддержка мобильной сети
5. Поддержка нескольких языков
Обзор
объяснять
1. Клиент (gRPC Sub) вызывает метод A, чтобы инициировать вызов RPC.
2. Используйте Protobuf для компрессии сериализации объекта (IDL) для информации о запросе
3, сервер (gRPC Server) При получении запроса тело запроса декодирования, бизнес-логика и обработка возвращаются
4. Используйте Protobuf для сжатия сериализации объектов (IDL) в результате ответа.
5. Клиент получает ответ сервера и декодирует тело запроса. Вызовите вызываемый метод A, разбудите клиентский вызов, ожидающий ответа (блокировка), и верните результат ответа.
Пример
В этом разделе вы просто покажете пример кода клиента и сервера GRPC.Я надеюсь, что у всех будет базовое впечатление, которое будет представлено в следующей главе.
Соберите и запустите сервер
lis, err := net.Listen("tcp", fmt.Sprintf(":%d", *port))
if err != nil {
log.Fatalf("failed to listen: %v", err)
}
grpcServer := grpc.NewServer()
...
pb.RegisterSearchServer(grpcServer, &SearchServer{})
grpcServer.Serve(lis)
1. Слушайте указанный TCP-порт, чтобы принимать запросы клиентов.
2. Создайте экземпляр объекта gRPC Server.
3. Регистрация внутренних сервисов и маршрутов gRPC Server
4. Serve() вызывает сервер для выполнения блокирующего ожидания до тех пор, пока процесс не будет завершен или не будет вызвана функция Stop().
Создать клиента
var opts []grpc.DialOption
...
conn, err := grpc.Dial(*serverAddr, opts...)
if err != nil {
log.Fatalf("fail to dial: %v", err)
}
defer conn.Close()
client := pb.NewSearchClient(conn)
...
1. Создайте канал gRPC для связи с сервером gRPC (требуется адрес сервера и порт в качестве параметров).
2. Установите учетные данные DialOptions (например, учетные данные TLS, GCE, учетные данные JWT)
3. Создайте заглушку поискового клиента
4. Вызовите соответствующий сервисный метод
мыслительные вопросы
1. В каких сценариях подходит не Protobuf, а JSON и XML?
2. Что такое упакованная кодировка, упомянутая в разделе Protobuf?
Суммировать
Открывая содержание, я стараюсь воспользоваться кратким описанием, чтобы познакомить вас с очередными необходимыми, необходимыми знаниями. Я надеюсь, что вы можете получить что-то, рекомендуется перейти к ресурсам у меня для более глубокого изучения, это лучшее
?
Если у вас есть какие-либо вопросы или ошибки, добро пожаловать вissuesЗадавайте вопросы или вносите исправления, если вам нравится или вам помогают, добро пожаловатьStar, является своеобразным поощрением и продвижением автора.