Python3与Dubbo3.1通讯解决方案（dubbo-python）

【文章非VIP可读，如果发现阅读限制为系统自动修改阅读权限，请留言我改回】

概述

最近AI项目需要java与python通讯，两边都是比较新的版本。因此需要双方进行通讯，在这里记录一下所采用的方案和关键点。

JAVA调用Python

python通常采用flask作为API接口，其调用的模式采用http。而java执行http请求就很简单，目前采用的方式是OkHttpClient来调用。OkHttpClient本身支持池化调用，性能也不错，这里不再赘述，需要时搜一下就很多。

Python调用JAVA

这花了不少的时间，对比了几种方案

1）接口方案选型：

由于java采用的是dubbo微服务，可以调用http网关接口，也可以直接调用dubbo服务。对比优劣如下：

接口方案	复杂程度	性能	编码
HTTP	简单，直接对网关	低，需要经过网关转发	JSON
DUBBO	稍麻烦	高，直接对dubbo服务	Hession

最终采用性能较高的直接调用dubbo服务的方式。在研究过程，还有一种使用telnet的方式调用，需要给dubbo额外配置其它的兼容模式，未考虑。

2）JAVA直接调用Dubbo服务

这里又研究了两种方式：

2.1）SERVER-CLIENT RPC方式

dubbo官方推荐的方式，大概看了一下，需要在server和client端分别部署一套python服务，觉得路径太长，暂不考虑这种

2.2）直接调用Dubbo服务

全网找了一下，发现可用的开源较少。最终定位在dubbo-python上，对应的github

GitHub - apache/dubbo-python2: Python Dubbo Client

看了一下，支持的python还仅是python2，已经过时。想着会不会有人做了python3的适配，找了一下，还真有：

GitHub - huisongyang/dubbo-python3: 基于 python3 的 dubbo client

这位在python2的基础上进行扩展，支持了python3和升级了zk组件。

安装：

pip install python3-dubbo

使用方式：

from dubbo.client import DubboClient, ZkRegister# 支持从Zk中获取服务的provider，支持根据provider的权重选择主机
zk = ZkRegister('127.0.0.1:2181')
dubbo_cli = DubboClient('com.qianmi.pc.api.GoodsQueryProvider', zk_register=zk)# 支持不使用Zk，直接连接指定的远程主机
dubbo_cli = DubboClient('com.qianmi.pc.api.GoodsQueryProvider', host='127.0.0.1:20880')admin_id = 'A000000'
result = dubbo_cli.call('listByIdString', admin_id)

参数兼容性

python-dubbo支持以下Java类型的参数，表格右边一列代表了在Pyton中与指定Java类型所对应的类型

类型	Java	Python
布尔类型	boolean	bool
整型	int, long	int
浮点类型	float, double	float
字符串类型	java.lang.String	str
列表类型	Collection & Array	[]
自定义的对象类型	java.lang.Object	↓ 具体使用方法如下所示 ↓

DubboClient是dubber注册的Interface类，也就是@DubboService类implements的接口java类全名

它还支持自定义类型的请求，由于本人只采用简单参数调用，需要可以自行查看github。

以上的没什么特别，可以对比参考选型的方案。这里额外要写的，是本人踩过的坑

3）趟过的坑

3.1）版本找不到

如果像我的项目一样，只是简单的使用Dubbo，未定义version，那么大概率调用就会出错。因为示例的代码默认是找的v1.0.0。直接在DubboService注解里加上固然是可以，那么有没有办法不用加呢？直接在调用时，将版本传空字符串进去就可以了。这样：

client = DubboClient('org.yourgroup.service.IYourService', version='', host='192.168.1.1:20880')

3.2）KeyError: 'revision'

该错误是因为使用zookeeper注册中心的模式，没有配置version的方式，则revision也无法产生。而在获取zk的设置时，该值无法正常获取，导致出错。解决办法修改dubbo/client.py，找到方法_register_consumer大约255行，修改为：

'revision': provider_fields.get('revision',''),

3.3）关于zk模式的权重

作者生成可以根据接口weight决定权重，但简单模式配置没有配置这个参数，看了下源码，当没有配置时，实时采用的是random模式。如果想在没有配置weight时更均匀的采用顺序模式分发请求，可以修改dubbo/client.py的_routing_with_wight

3.4）第二次调用不了，进程CPU100%

这个坑有点大，直接跑示例是跑不出来的。因为示例不会长时间运行，只要稍微时间长一点超过1分钟，就会出现系统卡死并不断打印需要连接的主机IP的情况。

本人已修复该问题，解决方案请找到源码dubbo/connection/connections.py
修改_check_conn方法为如下：

    def _check_conn(self, host):"""对连接进行检查，查看是否超时或者已经达到最大的超时次数:param host::return:"""conn = self._connection_pool[host]# 如果未达到最大的超时时间，则不进行任何操作if time.time() - conn.last_active <= TIMEOUT_IDLE:return# 达到最大的超时次数，对此连接进行重连if self.client_heartbeats.get(host, 0) >= TIMEOUT_MAX_TIMES:self._new_connection(host)self.client_heartbeats[host] = 0conn.close()  # 关闭旧的连接logger.debug('{} timeout and reconnected by client.'.format(host))# 未达到最大的超时次数，超时次数+1且发送心跳包else:self.client_heartbeats[host] = self.client_heartbeats.get(host, 0) + 1invoke_id = get_invoke_id()req = CLI_HEARTBEAT_REQ_HEAD + list(bytearray(pack('!q', invoke_id))) + CLI_HEARTBEAT_TAILconn.write(bytearray(req))logger.debug('Send ❤ request for invoke_id {}, host={}'.format(invoke_id, host))

即可解决卡死的问题，主要由触发心跳后代码错误导致。