持续提高程序员幸福指数——使用abp vnext设计一款面向微服务的单体架构

可能你会面临这样一种状况,在架构设计以前,你对业务不甚了解,需求给到的也模棱两可,这个时候你既没法明确究竟是要使用单体架构仍是使用微服务架构,若是使用单体,后续业务扩展可能带来大量修改,若是使用微服务,前期可能在工期上把项目给耽误了,你该怎么办?这就是这篇文章想要研讨的面向微服务的单体架构的由来。html

为何不用传统单体架构?

  

  

  咱们能够看到随着业务的升级,单块的代码的拆分会变得愈来愈困难,若是在前期没有作好规划和伏笔,那么后续的演化就是一场灾难。因此,目前的设计若是是企业级别的,都必然要作架构的适当冗余,由于没有人能知道将来长什么样,架构必然和业务同样是随着综合因素慢慢长出来的,不可能一蹴而就,一步到位。程序员

为何不用微服务架构?

微服务痛点
  • 数据一致性分发
  • 数据聚合 Join
  • 分布式事务
  • 单体系统解耦拆分
何时开始用微服务

  这里引用架构师杨波(前Ebay架构师/携程/拍拍贷研发部总监,资深技术架构师,微服务技术专家)的一些观点:架构

“企业一开始不推荐直接使用微服务,由于微服务须要前期基础设施的投资,复杂性很高(详见下面微服务的四大痛点),若是对问题领域并非很理解,一开始用微服务,你很难去划分服务的边界,你的生产力反而会比较低,并且你花了很大精力进行开发,你的产品并无被市场验证过,有可能会失败,因此这个选项风险会比较高。因此咱们推荐的是单块优先,先从单块运用作起,这样成本低,团队成员也比较少,无须太多研发投入,就能够交付一些基本的功能给客户使用。并发

  随着应用愈来愈成功,客户增长,你的系统复杂度会愈来愈高,就会出现单块应用和团队规模之间的矛盾,生产力会随着业务复杂度逐渐下降。因此在一些初创型公司,你更多看到的是单块应用,只有一些中大型的公司会看到微服务架构。”框架

      

  “交叉点代表,业务已经到达了必定的复杂性,单块应用已经没法知足业务增加的须要,研发效率开始降低了,而微服务能够提高研发和交付的效率。这个点须要架构师去综合、权衡。我的经验,通常团队须要达到百人规模,才去考虑微服务。”分布式

  • 发量不高——业务流量并无达到千万或亿级别
  • 团队规模——团队成员并无达到百位规模
  • 系统复杂度——没有高并发也就谈不上复杂度
  • 适用场景——互联网/物联网

微服务兼容的单体架构

演化方便——低代码演化

  如上所示,咱们能够看到API在拆解过程当中,基本没有作任何代码变动(具体代码能够查看个人GitHub或者你也能够参看个人视频《ABP vNext框架实战系列》),Domain的演化也只是作代码简单迁移,整个重构过程并无作多大的变化。这就是所谓“持续提高程序员幸福指数"的模块化之道啊。模块化

总结

  ABP vNext的模块化思想给了微服务演化提供了底层能力,我在这儿只是抛砖引玉,但愿有更多的人能参与进来进行分享。若是你想了解更多ABP vNext的地方,你也能够参看个人另一篇文字《浅谈Abp vNext的模块化设计》,谢谢您的捧场。微服务

  Abp vNext是一款优秀的框架,可是要从零开始能把每一个角落都熟悉起来须要很多摸索时间,但愿经过本身的经验给你的快速学习赋能,抛开生成器,一块儿从零开始,手工打磨一款生产级别的框架,让你对AbpvNext知其然,知其因此然。高并发

相关文章
相关标签/搜索