python 微服务框架 知乎_序: 我需要一个什么样的微服务框架

前言

新坑第一篇文章, 做一个开篇的序吧.

开发了很多 python 的 web 微服务, 也使用过很多 web 框架, django, tornado, flask, 等等等等. 不同的 web 框架有不同的优缺点, 本文的重点并不是对比市面上的各种框架, 关于各种框架的优劣, 网上有很多总结很好的文章. 本文只是吐槽一下我开发中遇到的一些问题, 痛点, 以及作为一个开发人员, 理想中微服务框架的应该是什么样的.

开发

首先是开发上问题, 这里以 tornado 为例来说明. 当我需要开发一个微服务时, 首先需要跟前端的小哥哥对齐接口格式, 之前很 low, 用 word 文档来记录, 缺点太多以至于都没有优点, 很快就被放弃了. 后来改成在 readme 里更新, 除了可以用上版本管理工具了之外, 没比 word 强到哪里. 现在用上了 swagger, 感觉好了非常多. 但是 swagger 也是有缺点的, 它的最大问题是写起来太麻烦了. 在接口多次迭代的过程中, 也很难保证 swagger 每时每刻与代码保持一致.

接口定下来之后, 便是开发的过程. 首先要做的是从请求中, 获取所有的请求参数. 这个不困难, 但是非常繁琐. 有的参数来自 path, 有的参数来自 body, 有的参数来自 query, 有的参数来自 header. 总之, 这是一个非常容易提升你个人代码量的地方, 非常难做到 clean code. 获得参数之后, 还需要对参数进行合法性验证, 如果某个参数无法通过, 需要抛出 bad request 错误, 并在响应中提示出是哪个参数有问题. 又是一堆又臭又长的代码, 不断的 if, try, except, raise.

在成功获得参数之后, 开始实现业务逻辑. 跟前面繁琐的重复的代码相比, 这个虽然是最重要的. 但实际情况是, 开发者到这里已经很疲劳了. 如果这时候, 前端的小哥哥要追加一个参数的话, 你需要:修改 swagger 文档配置文件;

追加参数解析以及合法性校验的代码;

修改业务逻辑.

我们可以发现, 只要是接口出现变动, 开发者就面临着大量的代码修改以及文档更新. 这个过程不但繁琐, 而且非常容易出错, 以至于开发者很难聚焦于最核心的业务逻辑实现. 而需求变动, 对于某些项目来说是家常便饭. 总之一句话就是, 很难受.

用 tornado 的时候, 如果想用 get 方式访问一个 api, 需要先继承一个 RequestHandler 的类, 然后重载它的 get 方法. 如果需要修改访问方式, 需要修改代码, 如果一个方法同时支持多种访问方式时, 需要把函数复制到每个重载的函数中. 在这方面, flask 的通过修饰器的做法则要好一些.

不论是用 tornado 和 flask, 如果想废弃或者临时关闭一个服务, 都需要修改代码. 以 tornado 为例, 需要删除或者注释掉路由表中的对应代码. 而且, 缺乏角色控制, 即将不同服务器用同一套代码部署成不同的服务.

tornado 的一个很重要的优势是高并发, 然而, 异步的方法实现起来并不容易, 很多第三方库也不支持协程, 导致开发成本很高.

部署

微服务可以简单的分为 3 个部分: 代码, 数据, 和其它二进制文件.

代码可以用 git 或者 svn push 到远程代码仓, 并在服务器端 pull 下来. 数据也是存在于数据库中, 部署起来并没有什么问题. 有些大型的二进制文件, 就要挨个的拷贝到新的服务器中, 非常的麻烦. 远程服务器的配置, 比如 ip, 端口, 账号, 密码也不能写到代码中, 也需要在新的服务器上进行手动配置.

当然, 上述问题都可以用打包成 docker 解决, 但是还是不够方便.

运维

python 自带的 logging 模块比较好用, 但是距离运维还差的很远. 除此之外, 我们还需要记录用户发送的每一次请求和响应的信息;

当接口出现异常时希望能够及时收到通知;

接口需要记录用户的反馈数据, 以便持续提升服务的质量.

这些都可以很容易的实现, 但是问题是我需要给每一个接口都实现一遍. 就算用上修饰器, 也是个非常累人的工作, 尤其是当接口数量非常多的时候, 服务散布在各个文件中, 难以管理.

写在最后

吐槽了这么多, 还是希望有这么一个后端的架构, 可以在开发, 部署, 运维各个方面减轻开发者的工作量.

开发方面:全自动参数解析, 参数校验, 文档生成, 这些重复的工作交给代码来完成;

api_path 和访问方式的绑定方式更加灵活, 可以借鉴 flask 的方案, 但是我感觉还可以更灵活;

一键禁用开启服务, 一键开启异步模式, 一键开启定时任务;

基于配置文件服务器角色管理, 方便切换角色.

部署方面:一键部署

运维方面:logging 系统, 满足一般的运维需求;

recorder 系统, 自动记录的请求和响应数据, 便于复现现网问题;

watchmen 系统, 自动发现异常并通知运维人员, 第一时间发现系统问题;

feedback 系统, 自动获得用户反馈, 持续提升服务水平.