整体上架构如上图，Nginx负责负载均衡，分发流量到多个Django服务，Django处理逻辑，需要异步任务就交给Celery，然后数据量比较大的地方使用Redis做缓存。同时还有实时消息通知的需要使用了Nginx Push Module。
问题与优化方式：
- Django并发性能差 使用uWSGI Master+Worker 配合 gevent 携程支持高并发
- Redis连接数过多 使用redis-py自带的连接池来实现连接复用
- MySQL连接数过多 使用djorm-ext-
pool（https://github.com/djangonauts/djorm-ext-pool）连接池复用连接 - Celery配置gevent支持并发任务
随着开发的功能越来越多，Django下的app也越来越多，这就带了发布上的不方便，每次发布版本都需要重启所有的Django服务，如果发布遇到问题，只能加班解决了。而且单个Django工程下的代码量也越来越多，不好维护。
二、服务拆分
随着后端团队的壮大，分给每个同事的需求也越来越细，如果继续在一个工程里面开发所有的代码，维护起来的代价太高，而我们的上一个架构中在Django里面已经按模块划分了一个个app，app内高类聚，app之间低耦合，这就为服务的拆分带来了便利。
拆分的过程没有遇到太大的问题，初期的拆分只是代码的分离，把公用的代码抽离出来实现一个公用的Python库，数据库，Redis还是共用，随着负载的增加，数据库也做了多实例。
首先是在接入层引入了基于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。
四、领域驱动设计
伤心的辣条 
微信公众号 
主要分享测试的学习资源，帮助快速了解测试
来源：普通网友
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！