1.2 从单体项目到微服务架构项目的拆分思路

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

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

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

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

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

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

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

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

表1-2 拆分方案

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

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