Python后端架构演进

来腾讯之前在前公司做了3年的后端开发,经历一款SaaS产品从0到10(还没有到100, 哈哈哈)的过程,3年间后端的架构逐步演变,在微服务的实践过程中遇到的问题也越来越多,在这里总结下。

产品是一款服务于人力资源的SaaS在线服务,面向HR有Web Android/iOS 小程序多个客户端,后端采用RESTful风格API来提供服务。主要使用Python语言,方便快速迭代。

架构的演进经历了4个大的阶段:1. MVC 2. 服务拆分 3. 微服务架构 4. 领域驱动设计

1. MVC

项目刚开始的时候,后端同事不超过5个,这个阶段主要的工作是实现产品的原型,没有太多的考虑架构,使用Django来快速实现功能,DB的表结构设计好之后,抽象出功能View,由于产品设计也很不完善,后端需要很多的预留设计,避免产品逻辑的变更带来整个表结构的变动,在这个阶段代码上最重要的是确定适合团队的代码规范,代码检查规则。

整体上架构如上图,Nginx负责负载均衡,分发流量到多个Django服务,Django处理逻辑,需要异步任务就交给Celery,然后数据量比较大的地方使用Redis做缓存。同时还有实时消息通知的需要使用了Nginx Push Module。

问题与优化方式:

1、Django并发性能差 使用uWSGI Master+Worker 配合 gevent 携程支持高并发

2、Redis连接数过多 使用redis-py自带的连接池来实现连接复用

3、MySQL连接数过多 使用djorm-ext-pool(https://github.com/djangonauts/djorm-ext-pool)连接池复用连接

4、Celery配置gevent支持并发任务

随着开发的功能越来越多,Django下的app也越来越多,这就带了发布上的不方便,每次发布版本都需要重启所有的Django服务,如果发布遇到问题,只能加班解决了。而且单个Django工程下的代码量也越来越多,不好维护。

2. 服务拆分

随着后端团队的壮大,分给每个同事的需求也越来越细,如果继续在一个工程里面开发所有的代码,维护起来的代价太高,而我们的上一个架构中在Django里面已经按模块划分了一个个app,app内高类聚,app之间低耦合,这就为服务的拆分带来了便利。拆分的过程没有遇到太大的问题,初期的拆分只是代码的分离,把公用的代码抽离出来实现一个公用的Python库,数据库,Redis还是共用,随着负载的增加,数据库也做了多实例。

如上图,服务之间尽量避免相互调用,需要交互的地方采用http请求的方式,内网的调用使用hosts指向内网地址。

问题与优化方式:

  • Nginx Push Module由于长时间没有维护,长连接最大数量不够,使用Tornado + ZeroMQ实现了tormq(https://github.com/zhu327/tormq)服务来支撑消息通知

服务之间的调用采用http的方式,并且要求有依赖的服务主机配置hosts指向被调用的地址,这样带来的维护上的不方便。以及在调用链的过程中没有重试,错误处理,限流等等的策略,导致服务可用性差。随着业务拆分,继续使用Nginx维护配置非常麻烦,经常因为修改Nginx的配置引发调用错误。每一个服务都有一个完整的认证过程,认证又依赖于用户中心的数据库,修改认证时需要重新发布多个服务。

3. 微服务架构

首先是在接入层引入了基于OpenResty的Kong API Gateway,定制实现了认证,限流等插件。在接入层承接并剥离了应用层公共的认证,限流等功能。在发布新的服务时,发布脚本中调用Kong admin api注册服务地址到Kong,并加载api需要使用插件。

为了解决相互调用的问题,维护了一个基于gevent+msgpack的RPC服务框架doge,借助于etcd做服务治理,并在rpc客户端实现了限流,高可用,负载均衡这些功能。

在这个阶段最难的技术选型,开源的API网关大多用Golang与OpenResty(lua)实现,为了应对我们业务的需要还要做定制。前期花了1个月时间学习OpenResty与Golang,并使用OpenResty实现了一个短网址服务shorturl用在业务中。最终选择Kong是基于Lua发布的便利性,Kong的开箱即用以及插件开发比较容易。性能的考量倒不是最重要的,为了支撑更多的并发,还使用了云平台提供的LB服务分发流量到2台Kong服务器组成的集群。集群之间自动同步配置。

饿了么维护一个纯Python实现的thrift协议框架thriftpy,并提供很多配套的工具, 如果团队足够大,这一套RPC方案其实是合适的,但是我们的团队人手不足,水平参差不齐,很难推广这一整套学习成本高昂的方案。最终我们开发了类Duboo的RPC框架doge,代码主要参考了weibo开源的motan。

4. 领域驱动设计

在这一架构中我们尝试从应用服务中抽离出数据服务层,每一个数据服务包含一个或多个界限上下文,界限上下文类只有一个聚合根来暴露出RPC调用的方法。数据服务不依赖于应用服务,应用服务可以依赖多个数据服务。有了数据服务层,应用就解耦了相互之间的依赖,高层服务只依赖于底层服务。

在我离职时领域驱动设计还在学习设计阶段,还没有落地,但是我相信前公司的后端架构一定会往这个方向继续演进。

总结

架构的设计,技术的选型,不能完全按照流行的技术走,最终还是服务于产品,服务于客户的需求。设计过程中由于团队,人员的结构问题,有很多的妥协之处,如何在妥协中找到最优解才是最大的挑战。

Service Mesh这种新一代的微服务架构正在成为主流,虽然现在的工作与微服务无关了,但是也还会继续关注学习。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Linux Python 加油站

揭秘Linux工程师一路走来都需要哪些技能

大公司也是从小公司一步步走过来的,而大公司之所以与小公司不同,不在于基础的技术体系不同,而是当数据量达到一定程度后,引发的质变而已。而在思考质变带来的性能问题中...

924
来自专栏13blog.site

大型网站技术架构(二)--大型网站架构演化

作者:13 GitHub:https://github.com/ZHENFENG13 版权声明:本文为原创文章,未经允许不得转载。 何谓大型网站 大型...

2966
来自专栏云计算D1net

公共云中的灾难恢复

1759
来自专栏云上大文件传输

值得纪念的日子:镭速RaySync FTP关键传输指标超越国际标杆Aspera产品

2018年3月19日对大部分人来说是一个普通的日子,但是对于我来说,是一个人生中值得纪念的日子。

4104
来自专栏还债之路

Zabbix告警升级机制图文详解

简单的配置第个,剩下的配置类似,重点不在于如何配置这个,重点在于如何配置“告警升级”和发送时间的理解

992
来自专栏杨建荣的学习笔记

迁移式升级的一点思考 (r10笔记第27天)

目前有一个很实际的需求,因为硬件老化严重,需要能够借助一次维护时机把数据库迁移到一台较好配置的机器上,避免潜在的硬件故障导致的业务停顿,也算防患于未然吧。 本来...

2577

关于监视容器我们了解的5件事

本文将介绍如何构建一个管理上万容器的可扩展的,高可靠的监控系统。本文是基于 Sysdig 容器监控工具的构建经历编写,如果您决定开发自己的工具,以下的设计决策可...

1739
来自专栏性能与架构

Hotjar在架构演进中总结的8条经验

Hotjar 提供了帮网站主了解用户行为的服务,网站接上此服务后,可以生成用户的点击热区,录制用户的行为,查看各个页面的跳出路径以及停留时间等,根据这些统计数据...

3406
来自专栏码神联盟

碎片化 | 第七阶段-11-小明的故事之集群、负载、并发-视频

如清晰度低,可转PC网页观看高清版本: http://v.qq.com/x/page/h0500917nyz.html 分布式、集群、高并发、负载、缓存、云端...

2697
来自专栏Java架构师学习

Java架构技术怎么学,做到年薪50W会这几点就够了

他们的共同特点是:10 年以上的工作经验,在大公司当过螺丝钉,也在创业公司做过技术 leader,有过一两段不算成功的创业经历。

632

扫码关注云+社区