由单体版到微服务架构版的拆分思路

在进行微服务架构改造前，要对系统的功能进行归纳和总结，确定要拆分出哪些微服务，这样才能进行后续的服务化拆分和编码测试。笔者在开发微服务架构版时的拆分思路如下。

首先，拆分的粒度不能太细。比如，项目里有 10 张表，拆成 10 个微服务，这种做法既不合理，也没有必要，完全是为了拆分而拆分。

其次，拆分的粒度不能太粗。比如，项目里有 10 张表，拆成 2 个微服务，拿新蜂商城项目来说，把 用户表 和 管理员表 拆成一个用户微服务，剩余的表拆成商品订单微服务，这种做法也不是很好，有些糊弄的意味。如果用这种粗粒度拆分的方式，拆分后与拆分前没有什么区别，与微服务架构的初衷就背道而驰了。

新蜂商城项目中的 用户模块、商品模块、订单模块 间的功能边界是非常清晰的，所以这三个模块分别拆分出三个单独的微服务是没有问题的。以此为基础，可以把商城用户表、管理员用户表划分到用户微服务中，把商品分类表、商品表划分到商品微服务中，把订单表、订单项表划分到订单微服务中。

以上是最基本的划分，接下来分析剩余的表和功能模块。

轮播图模块与上述三个微服务没有强关联性，可以不划进任意一个微服务中。首页推荐模块与商品模块是有关联性的，可以将其放到商品微服务中。不过笔者觉得它可以和轮播图模块重新组合成一个推荐微服务，所以就把首页推荐模块和轮播图模块放在一起了。

购物车模块与商品模块有一定的关联性，与订单模块的关联性也很强，所以将其放到订单微服务中也是可以的。笔者在设计时考虑到分布式事务的问题，为了更好地演示和处理分布式事务，就将购物车模块单独作为一个微服务。

通过对数据库表和功能模块的总结，最终的拆分方案见表 14-2。

当然，笔者的拆分思路及最终实战项目的源代码只是一种实现思路。读者也可以不按照上述思路进行拆分。在熟悉和掌握了本书所讲解的微服务相关知识后，再自行实现另外一套拆分思路和源代码也是完全可以的。比如，把用户微服务拆分得更细一些，拆分为商城用户微服务和管理员微服务；不单独拆分出购物车微服务，而是把购物车模块放到订单微服务中；把商品推荐模块放到商品微服务中，而不是放到推荐微服务中；把收货地址模块放到用户微服务中，而不是放在订单微服务中。

以上就是新蜂商城微服务版的拆分思路，通过以上内容的讲解，读者应该对本书的最终实战项目有了更清晰的认识。当然，看完本节的拆分思路和拓展思路后，读者也可以确定自己的拆分思路，并且尝试着用编码去实现自己的想法。