基于Python的RPC服务治理框架,类似Dubbo,基于Gevent实现
找了很久都没有找到 Python 合适的 RPC 服务治理框架, 学习了下 motan-go 的源码, 自己造了个轮子, 努力更新中
https://github.com/zhu327/doge
Doge
Doge is a Python RPC framework like Alibaba Dubbo and Weibo Motan.
Features
- 服务治理, 服务注册, 服务发现
- 高可用策略, failover, backupRequestHA
- 负载均衡策略, RandomLB, RoundrobinLB
- 限流策略, gevent Pool
Quick Start
Installation
pip install dogerpc
你可以在examples找到以下实例
Doge server
- 新建 server 端配置文件
{
"registry": { // 注册中心
"protocol": "etcd", // 注册协议, 支持 etcd 与 direct, 默认 etcd
"host": "127.0.0.1", // 注册中心 host
"port": 2379, // 注册中心 port
// "address": "127.0.0.1:2379,127.0.0.1:4001", // 注册中心地址, 如果有 etcd 集群, 可配置多个 node
"ttl": 10 // etcd 注册 ttl, 用于 server 的心跳检查, 默认 10s
},
"service": {
"name": "test", // 服务名称
"node": "n1", // 节点名称
"host": "127.0.0.1", // 服务暴露 ip
"port": 4399, // 服务暴露 port
"limitConn": 100 // 服务最大连接数, 可选, 默认不限制
}
}
- 定义 RPC methods 类, 启动服务
# coding: utf-8
from gevent import monkey
monkey.patch_socket() # 依赖 gevent
import logging
logging.basicConfig(level=logging.DEBUG)
from doge.rpc.server import new_server
定义 rpc 方法类
class Sum(object):
def sum(self, x, y):
return x + y
if name == ‘main’:
server = new_server(‘server.json’) # 基于配置文件实例化 server 对象
server.load(Sum) # 加载暴露 rpc 方法类
server.run() # 启动服务并注册节点信息到注册中心
Doge client
- 新建 client 端配置文件
{
"registry": { // 注册中心
"protocol": "etcd", // 注册协议, 支持 etcd 与 direct, 默认 etcd
"host": "127.0.0.1", // 注册中心 host
"port": 2379, // 注册中心 port
// "address": "127.0.0.1:2379,127.0.0.1:4001", // 注册中心地址, 如果有 etcd 集群, 可配置多个 node
"ttl": 10 // etcd 注册 ttl, 用于 server 的心跳检查, 默认 10s
},
"refer": {
"haStrategy": "failover", // 高可用策略, 支持 failover backupRequestHA, 默认 failover
"loadbalance": "RoundrobinLB", // 负载均衡策略, 支持 RandomLB RoundrobinLB, 默认 RoundrobinLB
}
}
- 创建 client 并 call 远程方法
# coding: utf-8
from future import print_function
from gevent import monkey
monkey.patch_socket()
import logging
logging.basicConfig(level=logging.DEBUG)
from doge.rpc.client import Cluster
if name == ‘main’:
cluster = Cluster(‘client.json’) # 基于配置文件实例化 Cluster 对象
client = cluster.get_client(“test”) # 获取服务名对应的 Client 对象
print(client.call(‘sum’, 1, 2)) # 远程调用服务 Sum 类下的 sum 方法
Requirements
License
Apache License, Version 2.0
基于Python的RPC服务治理框架,类似Dubbo,基于Gevent实现
关注一波
我理解你想找一个类似Java Dubbo的、基于Gevent的Python RPC服务治理框架。目前Python生态中没有完全对等的成熟框架,但有几个不错的方案:
1. Nameko (推荐) 这是最接近Dubbo理念的Python微服务框架:
# service.py
from nameko.rpc import rpc
class GreetingService:
name = "greeting_service"
@rpc
def hello(self, name):
return f"Hello, {name}!"
# 运行服务
# nameko run service --broker amqp://localhost
# client.py
from nameko.standalone.rpc import ClusterRpcProxy
config = {'AMQP_URI': 'amqp://localhost'}
with ClusterRpcProxy(config) as rpc:
result = rpc.greeting_service.hello("World")
print(result) # Hello, World!
2. gRPC + 服务发现 虽然不基于Gevent,但这是生产级方案:
# protobuf定义服务,gRPC实现通信
# 配合Consul/Etcd做服务注册发现
3. 自研方案 如果坚持要Gevent,可以基于以下组件搭建:
- 通信层: zerorpc (基于ZeroMQ和Gevent)
- 服务注册: Consul/Etcd + python-consul2
- 负载均衡: 客户端实现轮询/随机策略
- 监控: Prometheus + Grafana
简单总结:Nameko是最接近的现成方案,自研则用zerorpc+Consul组合。
已 star,但是感觉这东西工作量不小,等下半年 istio 出 1.0 了,service mesh 成主流了也就不需要一个语言造一个轮子了
没有用 grpc 或者是 thrift 带有 scheme 更容易标准化扩展和其他语言交互的 rpc 框架么
没有,在团队里推不动写 proto 文件定义服务, 只能退而求其次用基于 messagepack 的 mprpc
很不错,乙关注
那我是不是可以实现俩台服务器 A,B,a 服务器安装 python2.7 运行 dcm 处理服务,B 服务器安装 python3.6 传输 dcm 文件到 a 服务器处理成 png 图片后返回给 B,最近遇到 gdcm 无法安装到 pyrhon3.6 上面,有不想用回 python2.7 需求
是可以的, Python2 3 测试都支持, 消息序列化没有差异
server 这边每个调用的处理都在一个 greenlet 协程中, 如果是 CPU 密集的计算, 会阻塞其它调用, 并发能力比较差

