python 创建 package 来与业务解耦

零、背景

我们团队负责一个通用服务，业务可能会用各种语言通过 RPC 协议来访问我们的服务。

这周我 oncall 值班，有个业务反馈说参考团队提供的 python 文档来 RPC 请求时出问题了，让我帮忙看下。

我目前主要的开发语言是 cpp 和 go，有很多年没写 python 了。

我要到业务的代码，看了下，吓一跳，团队提供的 python 文档有很大的问题。

问题1：参考样例里直接把 RPC 协议下载到了 demo 里。

这导致所有 python 业务都把协议下载到本地。

我预期的是 demo 文档里配置一个协议地址+版本，使用时动态拉取协议。
这样的好处是协议升级了，版本编号修改一下就行了。

问题2：RPC 协议没有进行封装，业务直接操作的原生协议。

这个导致两个问题。

第一个问题是原生协议比较复杂，demo 里只举例获得字符串的值，结果所有人都以为所有值都是字符串。
其实原生协议除了字符串，还有整数、浮点数、布尔值、数组、对象等等。

第二个问题是 RPC 换过接口，业务还在使用旧的接口。

第三个问题是 RPC协议的逻辑与业务逻辑写在一起，后来业务都参考着把业务逻辑与 RPC 协议混淆在一起。

我预期的是对 RPC 协议进行封装为 SDK 对象，定义一个输入与输出。
业务使用时，创建 SDK 对象，调用封装好的函数即可。

对于第一个问题，即协议直接下载的问题，其实只需要改成包的形式，动态下载即可。

结果我问了所有 python 的业务，大家都不知道怎么动态引入协议的包。
最终我在内部论坛上提问，python RPC 框架的同学指导后，我才解决。

总结下操作也很简单：

1、协议平台生成 python 包，可以得到一个 git 地址。
2、使用者在 requirements.txt 中配置包的 git 地址。
3、包的名字可以在 git 地址里的 setup.py 文件里看到。
4、from & import 引入协议对象即可。

对于第二个问题，其实是需要我们团队封装一个 python SDK 包的。

所以我就参考协议包的格式，创建了一个 SDK 库。
然后再创建一个 python demo ，引入 SDK 库和 RPC 协议库。
由此，第二个问题就得到解决。

就这样，通过包解决了两个问题。

一个是，RPC 协议包与业务彻底解耦。
另一个是封装 SDK 包，业务与协议细节以及RPC接口彻底解耦。