• 企业400电话
  • 微网小程序
  • AI电话机器人
  • 电商代运营
  • 全 部 栏 目

    企业400电话 网络优化推广 AI电话机器人 呼叫中心 网站建设 商标✡知产 微网小程序 电商运营 彩铃•短信 增值拓展业务
    从0到1搭建后端架构的演进(MVC,服务拆分,微服务,领域驱动)

    产品是一款服务于人力资源的SaaS在线服务,面向HR有Web Android/iOS 小程序多个客户端

    后端采用RESTful风格API来提供服务。主要使用Python语言,方便快速迭代。

    架构的演进经历了4个大的阶段:

    一、MVC

    项目刚开始的时候,后端同事不超过5个,这个阶段主要的工作是实现产品的原型,没有太多的考虑架构

    使用Django来快速实现功能,DB的表结构设计好之后,抽象出功能View

    由于产品设计也很不完善,后端需要很多的预留设计,避免产品逻辑的变更带来整个表结构的变动

    在这个阶段代码上最重要的是确定适合团队的代码规范,代码检查规则。

    整体上架构如上图

    问题与优化方式:

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

    二、服务拆分

    随着后端团队的壮大,分给每个同事的需求也越来越细

    如果继续在一个工程里面开发所有的代码,维护起来的代价太高

    而我们的上一个架构中在Django里面已经按模块划分了一个个app

    app内高类聚,app之间低耦合,这就为服务的拆分带来了便利。

    拆分的过程没有遇到太大的问题,初期的拆分只是代码的分离

    把公用的代码抽离出来实现一个公用的Python库,数据库,Redis还是共用,随着负载的增加,数据库也做了多实例。

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

    问题与优化方式:

    三、微服务架构

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

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

    最终我们开发了类Duboo的RPC框架doge,代码主要参考了weibo开源的motan。

    四、领域驱动设计

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

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

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

    您可能感兴趣的文章:
    • 解读Serverless架构的前世今生
    • SSM框架前后端信息交互实现流程详解
    • 适合后台管理系统开发的12个前端框架(小结)
    • 详解Java 微服务架构
    • 浅谈SpringCloud实现简单的微服务架构
    上一篇:vscode 左侧扩展活动栏内容消失的问题及解决方法
    下一篇:分享软件测试必备的测试工具清单汇总
  • 相关文章
  • 

    © 2016-2020 巨人网络通讯 版权所有

    《增值电信业务经营许可证》 苏ICP备15040257号-8

    从0到1搭建后端架构的演进(MVC,服务拆分,微服务,领域驱动) 从,到,搭建,后端,架构,的,