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

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

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

  

  

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

为什么不用微服务架构？

微服务痛点

• 数据一致性分发
• 数据聚合 Join
• 分布式事务
• 单体系统解耦拆分

什么时候开始用微服务

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

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

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

      

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

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

微服务兼容的单体架构

演化方便——低代码演化

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

总结

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

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