【微服务】第10节：电商项目的微服务拆分

最新推荐文章于 2025-04-28 13:38:32 发布

枫蜜柚子茶

最新推荐文章于 2025-04-28 13:38:32 发布

阅读量1.5k

点赞数 12

分类专栏： ⭐微服务入门-超详细教程文章标签：微服务架构云原生 spring boot spring cloud java

本文链接：https://blog.youkuaiyun.com/m0_46013789/article/details/139610575

版权

1.微服务拆分

接下来，我们就一起将商城这个单体项目拆分为微服务项目，并解决其中出现的各种问题。

1.1.熟悉商城

首先，我们需要熟悉商城项目的基本结构：

大家可以直接启动该项目，测试效果。不过，需要修改数据库连接参数，在application-local.yaml中：

hm:
  db:
    host: 192.168.150.101 # 修改为你自己的虚拟机IP地址
    pw: 123 # 修改为docker中的MySQL密码

同时配置启动项激活的是local环境：

1.1.1.登录

首先来看一下登录业务流程：

登录入口在com.hmall.controller.UserController中的login方法：

1.2.2.搜索商品

在首页搜索框输入关键字，点击搜索即可进入搜索列表页面：

该页面会调用接口：/search/list，对应的服务端入口com.hmall.controller.SearchController中的search方法：

这里目前是利用数据库实现了简单的分页查询。

1.2.3.购物车

在搜索到的商品列表中，点击按钮加入购物车，即可将商品加入购物车：

加入成功后即可进入购物车列表页，查看自己购物车商品列表：

同时这里还可以对购物车实现修改、删除等操作。

相关功能全部在com.hmall.controller.CartController中：

其中，查询购物车列表时，由于要判断商品最新的价格和状态，所以还需要查询商品信息，业务流程如下：

暂时无法在飞书文档外展示此内容

1.2.4.下单

在购物车页面点击结算按钮，会进入订单结算页面：

点击提交订单，会提交请求到服务端，服务端做3件事情：

创建一个新的订单
扣减商品库存
清理购物车中商品

业务入口在com.hmall.controller.OrderController中的createOrder方法：

1.2.5.支付

下单完成后会跳转到支付页面，目前只支持余额支付：

在选择余额支付这种方式后，会发起请求到服务端，服务端会立刻创建一个支付流水单，并返回支付流水单号到前端。

当用户输入用户密码，然后点击确认支付时，页面会发送请求到服务端，而服务端会做几件事情：

校验用户密码
扣减余额
修改支付流水状态
修改交易订单状态

请求入口在com.hmall.controller.PayController中：

1.2.服务拆分原则

服务拆分一定要考虑几个问题：

什么时候拆？
如何拆？

1.2.1.什么时候拆

一般情况下，对于一个初创的项目，首先要做的是验证项目的可行性。因此这一阶段的首要任务是敏捷开发，快速产出生产可用的产品，投入市场做验证。为了达成这一目的，该阶段项目架构往往会比较简单，很多情况下会直接采用单体架构，这样开发成本比较低，可以快速产出结果，一旦发现项目不符合市场，损失较小。

如果这一阶段采用复杂的微服务架构，投入大量的人力和时间成本用于架构设计，最终发现产品不符合市场需求，等于全部做了无用功。

所以，对于大多数小型项目来说，一般是先采用单体架构，随着用户规模扩大、业务复杂后再逐渐拆分为微服务架构。这样初期成本会比较低，可以快速试错。但是，这么做的问题就在于后期做服务拆分时，可能会遇到很多代码耦合带来的问题，拆分比较困难（前易后难）。

而对于一些大型项目，在立项之初目的就很明确，为了长远考虑，在架构设计时就直接选择微服务架构。虽然前期投入较多，但后期就少了拆分服务的烦恼（前难后易）。

1.2.2.怎么拆

之前我们说过，微服务拆分时粒度要小，这其实是拆分的目标。具体可以从两个角度来分析：

💠 高内聚：每个微服务的职责要尽量单一，包含的业务相互关联度高、完整度高。
💠 低耦合：每个微服务的功能要相对独立，尽量减少对其它微服务的依赖，或者依赖接口的稳定性要强。

高内聚首先是单一职责，但不能说一个微服务就一个接口，而是要保证微服务内部业务的完整性为前提。目标是当我们要修改某个业务时，最好就只修改当前微服务，这样变更的成本更低。

一旦微服务做到了高内聚，那么服务之间的耦合度自然就降低了。

当然，微服务之间不可避免的会有或多或少的业务交互，比如下单时需要查询商品数据。这个时候我们不能在订单服务直接查询商品数据库，否则就导致了数据耦合。而应该由商品服务对应暴露接口，并且一定要保证微服务对外接口的稳定性（即：尽量保证接口外观不变）。虽然出现了服务间调用，但此时无论你如何在商品服务做内部修改，都不会影响到订单微服务，服务间的耦合度就降低了。

明确了拆分目标，接下来就是拆分方式了。我们在做服务拆分时一般有两种方式：

纵向拆分
横向拆分

所谓纵向拆分，就是按照项目的功能模块来拆分。例如商城中，就有用户管理功能、订单管理功能、购物车功能、商品管理功能、支付功能等。那么按照功能模块将他们拆分为一个个服务，就属于纵向拆分。这种拆分模式可以尽可能提高服务的内聚性。

而横向拆分，是看各个功能模块之间有没有公共的业务部分，如果有将其抽取出来作为通用服务。例如用户登录是需要发送消息通知，记录风控数据，下单时也要发送短信，记录风控数据。因此消息发送、风控数据记录就是通用的业务功能，因此可以将他们分别抽取为公共服务：消息中心服务、风控管理服务。这样可以提高业务的复用性，避免重复开发。同时通用业务一般接口稳定性较强，也不会使服务之间过分耦合。

当然，由于商城并不是一个完整的项目，其中的短信发送、风控管理并没有实现，这里就不再考虑了。而其它的业务按照纵向拆分，可以分为以下几个微服务：