grpc-spring 通信(选型,grpc-ecosystem/grpc-spring)

需求

需要一个在稳定网络环境里高性能且开发和部署成本较小,且多平台,且对视频传输和消息订阅和推送的支持比较好的, 一套环境

先说结论因为结论先得到的, 问AI了, 发现一个新东西gRPC ,看了下非常好。
再说过程,首先存在订阅和推送的场景所以传统的http/1.1就都不行,之前做过前台的长连接来实现页面实时k线图,百度的一个什么前台插件,忘了。一来讨厌前端二来gRPC基于的http/2.0 原生支持这些场景,甚至发视频的时候每个视频帧的通信都不需要客户端返回,貌似能节省最多一半的cpu和网络时间。

github上找了springboot + gRPC的项目

https://github.com/grpc-ecosystem/grpc-spring/

开始

Gradle用来替代maven,正如maven替代Ant,没用过。Srping 不太会用不喜欢
git clone https://github.com/grpc-ecosystem/grpc-spring.git

运行例子
文档里是
./gradlew :example:local-grpc-server:bootRun
老子找了半天example来自哪,找不到。试了下
./gradlew :examples:local-grpc-server:bootRun
深感震惊,居然可以
./gradlew :exa:local-grpc-server:bootRun
也可以,荒唐
AI说

在Gradle中,可以使用拼写不完整的单词进行任务或配置的原因是其基于Groovy的领域特定语言(DSL)具有高度灵活性和容错能力

易用性过高导致严谨性没有了, 我去搜exa是期望找到些东西的,但其实他可以代表examples。这是不可接受的
幂等原则的类似,不同的命令不应该有同样的输出,一一对应是最严谨的

约定大于配置是个非常的,过于提高易用性的东西,提高了学习成本,必然你得知道约定了什么,而配置就可以没有学习成本,遇到的东西都已经配置好了,全局搜索就可以明白所有东西。我讨厌约定
感觉到了之前玩nodejs的痛苦经历,为了照顾新手把东西都弄得看起来很简单,把东西都封起来张三李四王二麻子全都搞一个封装 规则 约定,github里完全找不到两个用同一套工具的项目,乱成一锅粥。好像最佳实践这样的东西不存在一样

我觉得优秀的工具或者框架,应该不看文档只看两个例子就可以完全上手整套流程,文档只需要一些枚举值
现在很多甚至主流的工具,来用我吧用我你就可以当白痴也能开发,还能比别人写的代码少就能完成一样的功能,
但是你原理都不明白成了某个工具使用者而不是开发。写个helloworld打包一个G,
这不好,开发是要解决所有问题的,任何一个环节的的问题,如何能这样呢,是你了解所有东西,一个G的helloworld你不可能了解,他有问题了你完全解决不了
触类旁通是一个可能最重要的能力,但工具使用者做不到。精通一个东西从内到外,才能解锁这个能力,浮于表面看不到本质是没有用的

spring开了这个头,万恶之首,追踪代码变成了很难的事,把一个准确的严肃的东西变成了卖弄雕虫小技


吐槽归吐槽,也不能因为不好用不喜欢就不用他,开始玩,不,折腾他

./gradlew tasks --all 可以看到所有命令,太多的话可以
./gradlew :ex:local-grpc-server:tasks 可以看到某个moudle下的命令

bootRun是 spring-boot-gradle-plugin 提供的
bootJar就可以生成 可以直接 java -jar xx.jar 运行的jar了。
生成目录:\local-grpc-server\build\libs

idea里gradle的配置
在这里插入图片描述
没看怎么配置镜像仓库,梯子直接连美国完事,
build完成后
在这里插入图片描述
这个窗口才会有内容,原来以为maven的这个优点居然没继承,看了下比maven的好

gRPC使用proto是为了通信的java input output对象的序列化 (google自家的)
如何编写.proto文件:

https://protobuf.dev/programming-guides/proto3/

编辑 .proto 之后执行 generateProto 得到一堆java文件

build命令报错

https://cloud.tencent.com/developer/article/1764107

代码里的空格报错方块问号。 改了之后空格报错为· ,之后把那段注释删掉,报错里还有那段注释。 (看吧,这就是不严谨的结果) (执行build有个提示Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.)
build不通过,直接bootRun ,跑起来了,bootRun会把以来的task都先跑了,没跑build 看来build已经不在生命周期里了,但idea的插件里tasks列表里还有这个命令。那就不管他

这是一个常识,写的简单易懂

https://blog.51cto.com/u_16099230/10254798
但是抄袭嫌疑
https://www.baeldung.com/java-grpc-streaming

至此

例子跑通了

是最简单的一问一答 , http/1.1完全可以做的
在这里插入图片描述

  1. 运行命令2,3
  2. 打开 client 用@RequestMapping(“/”) 暴露的http://localhost:8080/
  3. 通信成功

开始写steam的例子

Server streaming RPC

新增 .proto

syntax = "proto3";

option java_multiple_files = true;
option java_package = "net.devh.boot.grpc.examples.lib";
option java_outer_classname = "SteamTransferProto";

service SteamTransfer {
    //订阅某个传感器的观测值 监视
    rpc monitor (MonitorRequest) returns (stream MonitorReply) {
    }
}

message MonitorRequest {
    int32 monitSomeThing = 1;
}

message MonitorReply {
    int32 observedValue = 1;
}

服务端一秒返回一次,15次之后结束

@GrpcService
public class StreamTransferServerService extends SteamTransferGrpc.SteamTransferImplBase {

    @Override
    public void monitor(MonitorRequest req, StreamObserver<MonitorReply> responseObserver) {
    
        int a = req.getMonitSomeThing();
        
        new Thread(new Runnable() {
            @Override
            public void run() {
                for (int i = 0; i<15;i++ ) {
                    if (null != responseObserver) {responseObserver.onNext(MonitorReply.newBuilder().setObservedValue(
                                i +new Random().nextInt(10)
                        ).build());
                        System.out.println("send to client");
                    }
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
                responseObserver.onCompleted();
            }
        }).start();

    }
}

客户端

    @GrpcClient("local-grpc-server")
    private SteamTransferGrpc.SteamTransferStub steamTransferStub;
 
    public int steamTransfer(int one){
        steamTransferStub.monitor(MonitorRequest.newBuilder().setMonitSomeThing(one).build(), new StreamObserver<MonitorReply>() {
            @Override
            public void onNext(MonitorReply value) {
                System.out.println(Thread.currentThread().getName() + " observer value: " + value.getObservedValue());
            }

            @Override
            public void onError(Throwable t) {
                System.out.println("error:" + t.getLocalizedMessage());
            }

            @Override
            public void onCompleted() {
                System.out.println("onCompleted:");

            }
        });
        return 1;
    }

Client streaming RPC

暂时用不着

<think>好的,用户现在让我介绍一下github.com/grpc-ecosystem/go-grpc-middleware这个包。首先,我需要回想一下之前用户的问题历史。之前他们询问了Gin框架的跨域处理,现在转到了gRPC的中间件包,可能是在构建微服务架构,需要了解如何增强gRPC的功能。 首先,用户可能正在使用gRPC进行服务间通信,但发现需要一些通用功能,比如日志记录、认证、重试机制等。这时候,他们需要中间件来统一处理这些横切关注点,而go-grpc-middleware正好提供了这样的解决方案。 接下来,我需要确定这个包的主要功能和用途。这个仓库是gRPC中间件的集合,支持拦截器链,允许开发者组合多个中间件。常见的中间件包括日志、认证、监控、限流、重试、超时等。用户可能希望了解它的核心功能、使用场景、如何集成到现有项目,以及具体的例子。 然后,我需要考虑用户可能的真实需求。他们可能对gRPC有一定的了解,但不太清楚如何高效地管理中间件,或者如何将多个中间件组合使用。可能他们遇到了代码重复的问题,或者需要统一处理一些通用逻辑,比如认证和日志记录,而不想在每个服务中重复编写代码。 此外,用户可能关心如何安装和使用这个包,是否有示例代码,以及在生产环境中需要注意什么。比如,中间件的顺序可能会影响功能,或者某些中间件需要特定的配置,如认证中间件需要与具体的认证逻辑结合。 我需要分结构来介绍这个包,先讲它的作用,再讲核心功能,比如支持的中间件类型、链式调用、与各种工具的集成。然后给出安装方法和使用示例,比如如何添加日志和认证中间件。接着,说明适用场景,比如微服务中的统一日志、API限流、重试机制等。 还要注意比较与其他中间件库的不同,可能这个包的优势在于社区支持和丰富的中间件集合。同时,注意事项部分需要强调中间件顺序的重要性,性能影响,以及生产环境的配置建议,比如启用监控和链路追踪。 最后,用户可能有更深层次的需求,比如如何自定义中间件,或者如何处理复杂的拦截器链,这些可能需要进一步解释或提供文档链接。不过根据当前问题,先覆盖基本介绍和常见使用场景,确保用户能快速上手并理解其价值。</think>--- `github.com/grpc-ecosystem/go-grpc-middleware` 是一个为 gRPC 服务提供**链式中间件**支持的 Go 语言库。它通过拦截器(Interceptor)机制,帮助开发者在 gRPC 请求处理过程中插入通用逻辑(如日志、认证、监控等),是构建企业级 gRPC 服务的核心工具之一。 --- ### **核心功能** | 功能 | 作用 | 典型中间件示例 | |-------------------|---------------------------------------------------------------------------------------|------------------------------------------------------------------------------| | **链式拦截器** | 支持同时组合多个中间件(客户端和服务端均可使用) | `ChainUnaryServer(logger, auth, retry)` | | **常用中间件** | 提供开箱即用的中间件实现 | 日志、认证、重试、超时、限流、链路追踪、恢复(Recovery)等 | | **与生态集成** | 无缝对接 Prometheus、OpenTelemetry、Zap 等工具 | `grpc_prometheus.NewServerMetrics()` 用于 Prometheus 监控 | | **流式拦截支持** | 同时支持 Unary(一元)和 Streaming(流式)RPC 的拦截 | 流式请求的日志记录和超时控制 | --- ### **安装与基础使用** ```bash go get github.com/grpc-ecosystem/go-grpc-middleware/v2 ``` #### **服务端示例**(日志 + 认证) ```go import ( "github.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/logging" "github.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/auth" ) func main() { // 创建中间件链 chain := grpc.ChainUnaryServer( logging.UnaryServerInterceptor(logger), // 日志中间件 auth.UnaryServerInterceptor(authFunc), // 认证中间件(需自定义 authFunc) ) // 启动 gRPC 服务 server := grpc.NewServer(grpc.UnaryInterceptor(chain)) pb.RegisterYourServiceServer(server, &service{}) server.Serve(lis) } ``` --- ### **典型应用场景** | 场景 | 实现方式 | |---------------------|--------------------------------------------------------------------------| | **统一请求日志** | 使用 `logging` 中间件记录 RPC 方法、耗时、状态码 | | **JWT 认证** | 通过 `auth` 中间件解析请求头中的 Token | | **自动重试** | 客户端使用 `retry` 中间件实现幂等请求的重试逻辑 | | **API 限流** | 结合 `ratelimit` 中间件限制每秒请求数 | | **错误监控** | 集成 Prometheus 中间件统计 RPC 调用次数和延迟 | --- ### **关键中间件列表** | 中间件类型 | 功能说明 | |------------------|--------------------------------------------------------------------------| | `logging` | 结构化日志记录(支持 Zap、Logrus 等日志库) | | `recovery` | 捕获 panic 防止服务崩溃 | | `validator` | 自动验证请求参数(需结合 protoc-gen-validate 使用) | | `ratelimit` | 基于令牌桶算法的限流控制 | | `retry` | 客户端自动重试(可配置重试条件和次数) | | `opentracing` | 分布式链路追踪(兼容 Jaeger、Zipkin 等) | --- ### **高级用法示例** #### **自定义中间件开发** ```go // 实现一个 Unary 拦截器(统计请求耗时) func metricsInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) { start := time.Now() resp, err := handler(ctx, req) prometheus.ObserveLatency(info.FullMethod, time.Since(start)) return resp, err } ``` #### **流式拦截器组合** ```go // 流式 RPC 中间件链 streamChain := grpc.ChainStreamServer( logging.StreamServerInterceptor(logger), recovery.StreamServerInterceptor(), ) ``` --- ### **注意事项** 1. **中间件顺序** 中间件按添加顺序执行(类似洋葱模型),例如: ```go // 执行顺序:日志 → 认证 → 业务逻辑 → 认证 → 日志 grpc.ChainUnaryServer(loggingInterceptor, authInterceptor) ``` 2. **性能影响** 避免在拦截器中执行阻塞操作(如直接访问数据库),必要时使用异步处理。 3. **生产建议** - 启用 `recovery` 中间件防止服务崩溃 - 集成 Prometheus 监控关键指标 - 使用 `validator` 确保请求参数安全 --- 通过该库,开发者可以快速构建高可观测性、高可靠性的 gRPC 微服务,同时保持代码的简洁性。其模块化设计使得功能扩展和维护成本大幅降低。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值