jackyfei

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

为什么不用传统单体架构?

  

  

  我们可以看到随着业务的升级,单块的代码的拆分会变得越来越困难,如果在前期没有做好规划和伏笔,那么后续的演化就是一场灾难。所以,目前的设计如果是企业级别的,都必然要做架构的适当冗余,因为没有人能知道未来长什么样,架构必然和业务一样是随着综合因素慢慢长出来的,不可能一蹴而就,一步到位。

为什么不用微服务架构?

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

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

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

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

      

  “交叉点表明,业务已经到达了一定的复杂性,单块应用已经无法满足业务增长的需要,研发效率开始下降了,而微服务可以提升研发和交付的效率。这个点需要架构师去综合、权衡。个人经验,一般团队需要达到百人规模,才去考虑微服务。”

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

微服务兼容的单体架构

演化方便——低代码演化

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

总结

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

  Abp vNext是一款优秀的框架,但是要从零开始能把每个角落都熟悉起来需要不少摸索时间,希望通过自己的经验给你的快速学习赋能,抛开生成器,一起从零开始,手工打磨一款生产级别的框架,让你对AbpvNext知其然,知其所以然。

 

相关文章: