这是为 gRPC 生态系统和现代 Java 构建的 Spring Boot 启动器。点击标题
项目背景：大约两年前，我的公司决定全面采用 gRPC 和现代 Java (17)。我们希望使用 Spring 和 gRPC 为我们的 Java 服务构建坚实的基础。因此，我研究了现有的 Spring 和 gRPC 集成，发现了两个相对成熟的实现：grpc-spring和grpc-spring-boot-starter。但它们都有类似的问题：
- 缺乏对 gRPC 生态系统的支持：他们不支持 gRPC 周围的基本工具。对我们来说，protobuf 消息验证（protoc-gen-validate / protovalidate）是必备的。后来，我们还需要grpc-gateway来使用单个代码库同时支持 gRPC 和 HTTP/JSON。
- 与较新的 Java 和 Spring 版本不太活跃且不友好：考虑到 Java 发展的速度，这不是一个好消息；这些框架可能会过时。
- 集成并不是 Spring 的“原生”功能：它们引入了不必要的概念和注释，甚至做了一些黑客的事情（比如他们注入 gRPC 客户端 bean 的方式）。
- 不支持 GraalVM：我不是 GraalVM 的忠实粉丝，但它绝对是一个不错的功能。
主要目标是：
- -拥抱现代 Java 和 Spring Boot：版本始终与 Spring Boot 同步。
- -为扩展而设计：根据您的需求轻松扩展它，并毫不费力地集成其他框架或库。
- -内置 Protobuf 消息验证：protoc-gen-validate和protovalidate。
- - 提供 gRPC-Gateway 的 Java 实现（可能是唯一一个）
- -集成优于抽象：该项目不会引入 Spring 和 gRPC 以外的概念。如果您熟悉 Spring 或 gRPC，您可以快速入门。
- -完整的 GraalVM 支持
顺便说一句，我知道 Spring 启动了spring-grpc。我查看了它的代码，它主要专注于客户端/服务器自动配置。我认为它距离投入生产还有很长的路要走。:)
网友： 一开始我还担心 gRPC 的依赖项大小，它甚至比 Spring 还要大。但在切换到 gRPC 之后，这种担忧完全消失了，因为 gRPC 速度非常快。增加一点包大小是完全值得的。
作为参考，快速启动 的最终包大小为 29MB，我完全可以接受这个大小。