0到1搭建后端架构总结 - 网站源码_资源分享

来百度之前在前公司做了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，虽然商品在结构上也很不完善，后端须要很多的留出在结构上，避免商品方法论的变更增添整个表结构的变动，在这个期标识符上最重要的是确定适合项目组的标识符规范，标识符检查规则。 0到1搭建后端架构总结

整体上构架示意图，Nginx负责阻抗均衡，递送网络流量到数个Django服务项目，Django处理方法论，须要触发器各项任务就交给Celery，然后信息量比较大的地方性选用Redis做内存。同时还有动态消息通知的须要选用了Nginx Push Module。难题与强化形式：1、Djangomammalian性能差选用uWSGI Master+Worker 配合 gevent 携程网全力支持高mammalian2、Redis通话量过多选用redis-py便携式的相连池来同时实现相连F83E43Se3、MySQL通话量过多选用djorm-ext- pool（https://github.com/djangonauts/djorm-ext-pool）相连池F83E43Se相连4、Celery配置gevent全力支持mammalian各项任务随著合作开发的机能愈来愈多，Django下的app也愈来愈多，这就带了正式发布上的不方便，每次正式发布版都须要重新启动大部份的Django服务项目，假如正式发布碰到难题，只能上工解决了。而且一般而言Django工程建设下的标识符量也愈来愈多，不好保护。

2. 服务项目分拆

随著后端项目组的发展壮大，赏给每个同僚的需求也愈来愈细，假如继续在两个工程建设里头合作开发大部份的标识符，保护起来的代价太高，而我们的上两个构架中在Django里头已经按组件划分了两个个app，app裂稃通鉴，app间低谐振，这就为服务项目的拆分增添了便利。分拆的操作过程没碰到太大的难题，初期的分拆只是标识符的分离，把房屋建筑的标识符释放出来出来同时实现两个房屋建筑的Python库，资料库，Redis还是相连接，随著阻抗的增加，资料库也做了多示例。 0到1搭建后端架构总结

示意图，服务项目间尽量减少相互初始化，须要可视化的地方性选用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的开箱即用以及插件合作开发比较容易。性能的考量倒不是最重要的，为了支撑更多的mammalian，还选用了云平台提供的LB服务项目递送网络流量到2台Kong服务项目器组成的集群。集群间自动同步配置。饿了么保护两个纯Python同时实现的thrift协议框架thriftpy，并提供很多配套的工具, 假如项目组足够大，这一套RPC方案其实是合适的，但是我们的项目组人手不足，水平参差不齐，很难推广这一整套学习成本高昂的方案。最终我们合作开发了类Duboo的RPC框架doge，标识符主要参考了weibo开源的motan。

4. 领域驱动在结构上

在这一构架中我们尝试从应用服务项目中释放出来出数据服务项目层，每两个数据服务项目包含两个或数个界限上下文，界限上下文类只有两个聚合根来暴露出RPC初始化的方法。数据服务项目不依赖于应用服务项目，应用服务项目可以依赖数个数据服务项目。有了数据服务项目层，应用就解耦了相互间的依赖，高层服务只依赖于底层服务项目。在我离职时领域驱动在结构上还在学习在结构上期，还没落地，但是我相信前公司的后端构架一定会往这个方向继续重构。