grpc相关的服务和内容

  1. https://github.com/fullstorydev/grpcurl

    1. Like cURL, but for gRPC: Command-line tool for interacting with gRPC servers
    2. grpcurl是一个命令行工具，可让您与gRPC服务器进行交互。它基本上是curl针对gRPC服务器的。

  2. https://github.com/rfyiamcool/grpcall

    1. Easy request GRPC Server with reflect mode
    2. grpcall是具有反射模式的客户端库轻松请求GRPC服务器，然后它使grpc代理模式中间件，如grpc-gateway。
    3. 使用GRPC的反射模式来请求GRPC服务器。grpcall支持FileDescriptorSet和grpc/reflection模式。
    5. 支持事件挂钩
    6. 动态请求GRPC Server具有反射模式。
    7. 动态将protobuf转换为json并将json转换为protobuf
    8. grpc客户经理
    9. 支持流
    10. recv系统信号以更新新的描述符。

  3. https://github.com/fullstorydev/grpcui

    1. An interactive web UI for gRPC, along the lines of postman
    2. gRPC交互式Web UI
    3. grpcui是一个命令行工具，可让您通过浏览器与gRPC服务器进行交互。有点像Postman，但用于gRPC API而不是REST。

  4. https://github.com/fullstorydev/grpchan

    1. Channels for gRPC: custom transports
    2. gRPC的渠道：自定义传输
    3. 此存储库为RPC连接提供了一个抽象：Channel。的实现Channel可以提供替代的传输方式-与google.golang.org/grpc 软件包提供的基于HTTP/2的标准传输方式不同。

  5. https://github.com/grpc/grpc/blob/master/doc/command_line_tool.md

    1. c++版本的原生支持
    2. grpc_cli
    3. https://github.com/grpc/grpc-go/blob/master/Documentation/server-reflection-tutorial.md#grpc-cli

  6. Kratos是bilibili开源的一套Go微服务框架，包含大量微服务相关框架及工具

    1. https://gitee.com/mirrors/Kratos
    2. Features
      1. HTTP Blademaster：核心基于gin进行模块化设计，简单易用、核心足够轻量；
      2. GRPC Warden：基于官方gRPC开发，集成discovery服务发现，并融合P2C负载均衡；
      3. Cache：优雅的接口化设计，非常方便的缓存序列化，推荐结合代理模式overlord；
      4. Database：集成MySQL/HBase/TiDB，添加熔断保护和统计支持，可快速发现数据层压力；
      5. Config：方便易用的paladin sdk，可配合远程配置中心，实现配置版本管理和更新；
      6. Log：类似zap的field实现高性能日志库，并结合log-agent实现远程日志管理；
      7. Trace：基于opentracing，集成了全链路trace支持（gRPC/HTTP/MySQL/Redis/Memcached）；
      8. Kratos Tool：工具链，可快速生成标准项目，或者通过Protobuf生成代码，非常便捷使用gRPC、HTTP、swagger文档；

  7. https://github.com/jhump/protoreflect

    1. Reflection (Rich Descriptors) for Go Protocol Buffers
    2. Go协议缓冲区的反射（丰富的描述符）
    3. 此存储库为协议缓冲区（简称“ protobufs”）和gRPC提供了反射API 。protobufs中反射的核心是 描述符。描述符本身就是一个protobuf消息，它描述.proto源文件或其中的任何元素。因此，描述符的集合可以描述protobuf类型的整个架构，包括RPC服务。

  8. https://github.com/bufbuild/buf

    1. Buf的目标是让Protobuf不仅在技术优点上成为一个不错的选择，而且要易于使用，以至于决定是微不足道的。您的组织不必重新发明轮子就可以有效地使用Protobuf。不必担心您的Protobuf管理策略失控。我们会为您处理，因此您可以担心重要的事情。
    2. 一种使用协议缓冲区的新方法。
    3. 使用诸如协议缓冲区（“ Protobuf”）之类的IDL， 比JSON具有许多优势：
      1. 为您使用的每种语言生成的存根。
      2. 数据类型的向前和向后兼容性。
      3. 有效负载大小最多可缩小10倍。
      4. 序列化速度快100倍。
      5. API的结构化RPC，而不是记录的HTTP端点。

  9. http://gokit.io

  10. https://github.com/grpc-ecosystem/grpc-gateway

  11. https://github.com/envoyproxy/protoc-gen-validate

https://buf.build/docs/introduction

Buf的目标是让Protobuf不仅在技术优点上成为一个不错的选择，而且要易于使用，以至于决定是微不足道的。您的组织不必重新发明轮子就可以有效地使用Protobuf。不必担心您的Protobuf管理策略失控。我们会为您处理，因此您可以担心重要的事情。

简单的gRPC基准测试和负载测试工具

https://ghz.sh
ghz是一个简单的命令行实用程序和Go软件包，用于负载测试和基准测试gRPC服务。它旨在用于本地测试和调试服务，并用于自动连续集成环境中以进行性能回归测试。
https://github.com/bojand/ghz
http://ghz-demo.herokuapp.com/

GRPC服务器反射协议

https://github.com/grpc/grpc/blob/master/doc/server-reflection.md

  1. 本文档将服务器反射描述为服务器的可选扩展，以帮助客户端在请求的运行时构造中而无需将桩头信息预编译到客户端中。
  2. 服务器反射的主要用例是编写（通常）命令行调试工具来与grpc服务器通信。特别是，这种工具将采用一种方法，并将有效载荷（以人类可读文本格式）将其发送到服务器（通常以二进制原型格式），然后获取响应并将其解码为文本以呈现给用户。
  3. 这大致涉及两个问题：确定服务器方法使用的格式（protobuf消息）以及确定如何在人类可读格式和（可能是二进制）有线格式之间转换消息。
  4. 第二个是服务器通过网络导出其google :: protobuf :: DescriptorDatabase。这在C ++中非常容易实现，并且类似协议的Google实现已在C ++，Go和Java中存在。
  5. 该协议主要返回FileDescriptorProtos，它是已解析的.proto文件的原型编码。它支持四个查询：
    1. 给定文件名的FileDescriptorProto
    2. 具有给定符号的文件的FileDescriptorProto
    3. 具有给定扩展名的文件的FileDescriptorProto
    4. 给定类型的已知扩展标签号码的列表
  6. 这些直接对应于google :: protobuf :: DescriptorDatabase的方法。请注意，该协议包括对扩展的支持，这些扩展已从proto3中删除，但仍在Google的代码库中广泛使用。

https://github.com/grpc/grpc-web

gRPC for Web Clients
浏览器客户端的gRPC的JavaScript实现。有关更多信息（包括快速入门），请参见gRPC-web文档。
gRPC-web客户端通过特殊的代理连接到gRPC服务。默认情况下，gRPC-web使用Envoy。

https://github.com/improbable-eng/grpc-web

https://github.com/easyCZ/grpc-web-hacker-news

protoc \
    --go_out=plugins=grpc:./server \
    --plugin=protoc-gen-ts=./app/node_modules/.bin/protoc-gen-ts \
    --ts_out=service=true:./app/src \
    --js_out=import_style=commonjs,binary:./app/src \
    ./proto/hackernews.proto

envoy

https://www.servicemesher.com/envoy/intro/arch_overview/grpc.html
Envoy 是能够正确支持 HTTP/2 trailers 的少数几个 HTTP 代理之一，因此也是可以传输 gRPC 请求和响应的代理之一。
gRPC-Web 由一个指定的过滤器支持，该过滤器允许 gRPC-Web 客户端通过 HTTP/1.1 向 Envoy 发送请求并代理到 gRPC 服务器。目前相关团队正在积极开发中，预计它将成为 gRPC 桥接过滤器的后续产品。
gRPC-JSON 转码器由一个指定的过滤器支持，该过滤器允许 RESTful JSON API 客户端通过 HTTP 向 Envoy 发送请求并获取代理到 gRPC 服务。

https://github.com/gusaul/grpcox

Like Postman, but for gRPC: web based GUI client for gRPC Development Testing
类似于Postman，但适用于gRPC：用于gRPC开发测试的基于Web的GUI客户端
将gRPCurl转换为基于Web的UI，非常易于使用

descriptor_set_out

protoc --proto_path=. \
    --descriptor_set_out=myservice.protoset \
    --include_imports \
    my/custom/server/service.proto

而我们经常遇到的情况是，拿到一个被protobuf序列化的二进制内容，但不知道它的类型，无法获得对应的类对象。这种多见于需要处理各种各样未知的ProtoBuf对象的系统。ProtoBuf提供了动态解析机制来解决这个问题，它要求提供二进制内容的基础上，再提供对应类的Descriptor对象，在解析时通过DynamicMessage类的成员方法来获得对象结果。

最后问题就是Descriptor对象从哪里来？这是通过protoc --descriptor_set_out=$outputpath 命令生成descriptor文件，进而得到的。接下来，我们看一些例子（使用proto3）
所谓动态解析，就是消费者不根据proto文件编译生成的类来反序列化消息，而是通过proto文件生成的descriptor来构造动态消息类，然后反序列化（解析）消息。代码如下：
生产者：通过proto文件编译产生的类构造一个消息（byteArray数组）；
消费者：1）根据proto文件生成descriptor文件；2）创建DynamicMessage类解析消息（byteArray数组）；
优点
生产者和消费者实现了解耦，消费者不再需要proto文件，而是使用proto文件生成的descriptor文件构造DynamicMessage类来解析生产者消息，一般我们可以把descriptor文件保存到某个地方，而不是每次都去生成。
缺点
上面那种方式不太友好，消费者每次都需要重新生成或者从某个地方获取descriptor文件内容，google提供了一个更为合理的方式Self-describing Messages，即：将descriptor、消息名、消息内容放到一个wrapper message中，消费者收到消息后从wrapper message中先获取descriptor和name，然后构造DynamicMessage类，最后通过它来解析消息内容。

posted @ 2020-07-21 16:37  白云辉  阅读(795)  评论(0)    收藏  举报