写了个轮子 fast-grpc,用 Python 轻松开发 grpc 接口

353 天前
 yatao

简介

Fast-GRPC 旨在为开发者提供更轻松快捷的 Python gRPC 接口开发方式,受到 FastAPI 的启发,用更 human 的方式编写 gRPC 接口,通过使用 Python schema 直接定义 gRPC 接口,然后自动生成 grpc proto ,从而省去了在 proto 文件中再次定义接口的繁琐工作;框架简化了 Python gRPC 开发流程,同时提供与 FastAPI 类似的接口编写风格,接口可以支持同步和异步写法,并且还可以使用 Middleware (代替 grpc 拦截器,自带的拦截器感觉不太好用)。个人认为,在 Python 微服务实践中,结合 FastAPI 和 gRPC 并利用流行的微服务基础设施(比如微软 dapr ),将是一个不错的选择。

安装

需要 python 3.7+

pip install python-fast-grpc

快速上手

下面是一个简单的 Fast-GRPC 示例,展示如何创建一个 gRPC 服务

from fast_grpc import BaseSchema, FastGRPC, ServicerContext, method

app = FastGRPC()

class HelloRequest(BaseSchema):
    name: str

class HelloReply(BaseSchema):
    message: str

class Greeter:
    @method("SayHello", request_model=HelloRequest, response_model=HelloReply)
    async def say_hello(self, request: HelloRequest, context: ServicerContext) -> HelloReply:
        return HelloReply(message=f"Greeter SayHello {request.name}")

app.add_service(Greeter)  # 添加 Greeter 服务
# 启动 gRPC 服务。无需手动编写 proto 文件,Fast-GRPC 会根据你的 Python 代码自动生成 proto 文件,并编译为 Python gRPC 代码,最后启动 gRPC 服务
app.run()

在上面的示例中,我们首先使用 FastGRPC 创建了一个 gRPC 应用。接下来,定义了一个 gRPC 服务 Greeter,使用 method 装饰器标记了一个 RPC 方法 say_hellomethod 接受三个参数:RPC 方法名、请求模型 HelloRequest 和响应模型 HelloReplysay_hello 方法可以支持同步和异步代码,对于同步代码,会使用线程来模拟异步执行。

最后,我们将 Greeter 服务添加到 gRPC 应用中,并通过 run 方法启动 gRPC 服务器。Fast-GRPC 会根据添加的 Greeter 服务的接口定义自动生成 .proto 文件和 Python gRPC 代码,简化了 Python gRPC 的开发步骤,更符合 Python 的使用习惯。

接下来,我们通过一个客户端调用来演示效果:

import grpc
import greeter_pb2 as pb2
import greeter_pb2_grpc as pb2_grpc

channel = grpc.insecure_channel("127.0.0.1:50051")
stub = pb2_grpc.GreeterStub(channel)
response = stub.SayHello(pb2.HelloRequest(name="fastGRPC"))
print("Greeter client received: ", response)

相关链接

Fast-GRPC GitHub 仓库

下一步计划

目前,Fast-GRPC 支持的功能还比较简单,未来将继续改进和完善。如果您有任何建议或意见,欢迎提交 issue 或者 PR 。

1864 次点击
所在节点    Python
6 条回复
hauzerlee
351 天前
赞,我 fork 一个来搞搞。unix system-v rpc 已经是这种方式了,以前搞过
akaHenry
342 天前
https://github.com/bali-framework/bali

可以看看 Bali 框架, 基于 fastapi + grpc, 360 的团队开源的.
yatao
340 天前
@akaHenry 感谢推荐,但我觉得不是一个东西,抽象 django 那一套理论对于简单的增删改查确实方便不少,实际开发使用场景并不简单,尤其使用微服务架构之后,并且这种设计导致开发的代码都是和框架的思想深度绑定的,个人更喜欢整洁架构设计那套思想,我们实践中也是按照这套理论来实施的
akaHenry
340 天前
@yatao 嗯. bali 仿 django-rest-framework 设计了 API 层. 熟悉 drf 的用起来, 很方便.

另外, 其实 bali 也可以常规方式定义 route, 也就是可以不使用这套.

灵活性还是有的. (这项目和我无关, 碰巧看你这个轮子, 刚好匹配)

当然, 轮子还是自己造的香. (毕竟也很简单, 用啥都 OK)
yatao
331 天前
@akaHenry 嗯,特地去看了下这个项目,说下我的个人看法
从架构设计的角度来看,bili 做的是业务的抽象层,它在业务层抽象了一层标准,开发按照这个标准去写,然后它会将业务代码转换为相应的基础框架(如 FastAPI 和 gRPC )所需的代码。这不是我想要的东西,我们也有自己通用的业务脚手架,比如标准的 REST 处理 handler ,如果是一些简单的增删改也很方便。这取决于公司的开发规范和标准,我估计 bili 想做的也是这个事,毕竟 python 在工程方面也没统一标准。
相比之下,FastgRPC 的目标是仅提供 gRPC 框架,就像 FastAPI 封装了 Starlette 一样。我个人也比较看好 typing 的风格,也是一个很好的方向。
akaHenry
331 天前
嗯. 都行. 👌🏻️

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/941131

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX