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

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

为何不用传统单体架构？

  

  

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

为何不用微服务架构？

微服务痛点

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

何时开始用微服务

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

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

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

      

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

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

微服务兼容的单体架构

演化方便——低代码演化

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

总结

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

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