好几个月都没写过Blog,写个小记
公司业务向微服务迁移过程中接触到API Gateway这种中间件,评估了各种开源方案后,选择了在Openresty基础上实现的Kong.为了在Kong的基础上做二次开发,开始学习Openresty.
还是在好几年做测试的时候用过lua语言写测试脚本,lua语言特性很简单,想捡起来也很快.更多的感触是由于学习过Torando的源码,理解了Reactor模型,协程这些概念.学起Openresty只需要把相关概念套上去就很好理解了.这就是知识体系建立的好处,虽然不同语言,不同框架,还是能快速上手.
正好公司有个生成短链接的小项目,不限语言,先拿Openresty练练手,写了个shorturl.
之前实现了在Django环境下使用zerorpc的封装,api的组织单位是function.受到Google API 设计指南的启发,重新设计了一种基于Resources的api组织风格,并且约定Resource的方法名与Django Rest Framework的ViewSets中实现的action名称一致.
zerorpc默认只能在同一个Server上面注册一个对象,而我们需要注册多个类(一个类表示一Resources),在阅读zerorpc Server的代码后,想到一个简单的方式来注册Resources.
总结下最近看过的一些文章,然后想到的一些优化点,整理一下.
Django 默认DB配置提供了选项CONN_MAX_AGE用于配置在同一个thread/greenlet里面DB connection的最大存活时间,便于连接的复用,在实践中发现如果使用gunicorn+gevent的方式来启动WSGI服务,由于gunicorn会创建一个很大的gevent pool,导致数据库连接数会暴涨.所以这个选项被放弃了,另外的方式是使用connection pool.
instagram 使用 PostGreSQL 并且使用 Pgbouncer 这个中间件来管理连接池,MySQL也有Proxy这种中间件但是比较重,所以考虑在django mysql backend的基础上自己实现一个连接池.
https://gist.github.com/zhu327/94c22c7fa9c92cc38e998eab41e77c38
主要参考了Connector/Python的pool实现.
数据库连接池也不是”银弹”,在应用层做数据库连接池也不值得推荐,随着业务的扩展,使用一主多备搭建集群,通过读写分类中间件来做连接池管理,推荐ProxySQL.
随着系统架构从集中式单点服务器到分布式微服务方向的迁移,RPC是一个不可回避的话题.如何在系统中引入对开发者友好,性能可靠的RPC服务是一个值得深思的问题.
在调研了Thrift,gRPC,zerorpc等方案后,基于以下2点最后选择了zerorpc:
虽然zerorpc可以直接嵌入当前系统框架中,但是还是有一些问题需要去考虑解决
rpc 接口如何定义
rpc 服务如何启动
高并发情况下客户端的可靠性
发现一本Python的好书被翻译了，利用下班时间学习了一下，把相关代码都实现了一遍，包括：
以及一些算法