可能你会面临这样一种状况,在架构设计以前,你对业务不甚了解,需求给到的也模棱两可,这个时候你既没法明确究竟是要使用单体架构仍是使用微服务架构,若是使用单体,后续业务扩展可能带来大量修改,若是使用微服务,前期可能在工期上把项目给耽误了,你该怎么办?这就是这篇文章想要研讨的面向微服务的单体架构的由来。html
咱们能够看到随着业务的升级,单块的代码的拆分会变得愈来愈困难,若是在前期没有作好规划和伏笔,那么后续的演化就是一场灾难。因此,目前的设计若是是企业级别的,都必然要作架构的适当冗余,由于没有人能知道将来长什么样,架构必然和业务同样是随着综合因素慢慢长出来的,不可能一蹴而就,一步到位。程序员
架构
并发
框架
分布式
如上所示,咱们能够看到API在拆解过程当中,基本没有作任何代码变动(具体代码能够查看个人GitHub或者你也能够参看个人视频《ABP vNext框架实战系列》),Domain的演化也只是作代码简单迁移,整个重构过程并无作多大的变化。这就是所谓“持续提高程序员幸福指数"的模块化之道啊。模块化
ABP vNext的模块化思想给了微服务演化提供了底层能力,我在这儿只是抛砖引玉,但愿有更多的人能参与进来进行分享。若是你想了解更多ABP vNext的地方,你也能够参看个人另一篇文字《浅谈Abp vNext的模块化设计》,谢谢您的捧场。微服务
Abp vNext是一款优秀的框架,可是要从零开始能把每一个角落都熟悉起来须要很多摸索时间,但愿经过本身的经验给你的快速学习赋能,抛开生成器,一块儿从零开始,手工打磨一款生产级别的框架,让你对AbpvNext知其然,知其因此然。高并发