以实例说明微服务拆分（以SpringCloud+Gradle）
前⾔
之前，我都是说了很多的关于微服务的概念，说到底，很多⼈看了之后会认为没有什么意思，因为没有实际的东西说明，即使每个概念都明⽩了，也很难赋之实践。所以这次，我来⽤⼀个实际的例⼦去说明，在实际的项⽬过程中我们会如何去构建我们的微服务。
PS：我们只是利⽤场景去模拟我们微服务构建或者说拆分的整个过程，对于场景本⾝在实际中会出现的问题我们不做考虑，说⽩了就是我们不考虑场景本⾝在实际⽣活中是不是这样的。
使⽤SpringCloud+Gradle构建
本⽂⽬的：让你体会到服务拆分本⾝，引起你对服务拆分的思考。
场景模拟
我们⾸先模拟这样⼀个业务场景，积分兑换实体商品。流程⼤致如下：
1、⽤户登录
2、选择商品
3、下单
4、积分⽀付
5、商品发货
6、订单完成
“抽离业务”这⾥为了简化我们的实现，我们去掉⽤户登录和商品发货这样两个步骤，也就是默认⽤户登录，默认订单⼀定完成。
如果使⽤单体架构，那我们最后实现的情况应该⼤多是这样的。
···
⽤户点击兑换 ->
【减少商品库存，操作商品表】
【⽣成订单，操作订单表】
【减少⽤户积分，操作⽤户积分表】
【添加⽤户积分记录，操作积分记录表】
在不考虑并发的情况下，也需要使⽤事务，也就是说，其中任意⼀步操作出现问题，都会导致整个兑换出现问题，也就是全部回滚数据。这是我们⼀般在单体应⽤中所经常实现的⽅式。
如何拆分成微服务
现在，⽆论是⽼板说了，还是说就是想做，甭管因为什么，反正我就是想要把它做成微服务。怎么办？
那么⼀个看似耦合性很⾼的业务场景，我们究竟如何将它拆分成微服务呢？
我们拆分需要掌握的逻辑
1、如果我们要拆分的业务本⾝耦合度较⾼，那么拆分的需要做的是拆离业务，说⽩了就是需要和产品商量业务上⾯需要进⾏部分改动。springcloud难学吗
2、如果我们拆分的业务本⾝没有耦合度，那么随你拆？？？不是的，需要考虑两点，⼀个是粒度太细成本就会上去，⼀个是后期扩展是否会有影响
架构改变
下⾯两张图是我们模拟架构改变前后⼤致画了⼀下的两张图，我们可以简单从图中获得两者的⼤体差异
具体拆分
现在我提出⼀种拆分的⽅式
1、减少商品库存创建订单放在⼀个微服务中，构成下单服务
2、减少⽤户积分和操作⽤户积分记录放在另⼀个微服务中，构成⽀付服务
拆分后的逻辑
⽤户点击兑换 ->
【减少商品库存，操作商品表】
【⽣成订单，操作订单表】
【减少⽤户积分，操作⽤户积分表】
【添加⽤户积分记录，操作积分记录表】
拆分达到的效果：
即使⽤户积分因为种种原因没有正常扣除，后续还可以进⾏⽀付
拆分的好处：
后期扩展上来讲，后期如果⽀付⽅式不只是积分，可以⽤别的，那么只需要对⽀付服务进⾏修改，对于下单来说没有任何关系
拆分代码
分析总结
如果你看完代码你就知道，其实拆分本⾝没有你想象的那么复杂，虽然我们简化了其中的部分细节，但是实际如果需要这样去拆分，逻辑上其实就这样的。没有你想象的那么复杂。
但是！！！
困难其实并不在拆分代码本⾝，之前⼀篇博客我就提到了，其实微服务的拆分并没有实际想象的那么复杂，⽽困难来⾃于拆分后会导致的各种问题，因为其实对于业务本⾝来说，很多时候我们都会遇到⼀些耦合性的业务，这些业务本⾝很难拆分。所以和上⾯说的⼀样，在⼀些服务进⾏实际拆分的时候我们会对业务进⾏调整，虽然对于⽤户感知本⾝是⼀样的，但是实际代码来说是不⼀样的。
总结以下⼏点供参考：
1、如果经验不⾜，先⼩拆，后⼤拆
2、假设异常，假设每个服务都分别出现⼀次异常，会对你拆分后的服务造成什么样的影响
3、优先保证主线业务稳定
4、拆分的原则是为了后期业务扩展，那么你需要优先考虑到后期的扩展⼤致会怎么样
Follow up
我⼀直在强调⼀点就是，我们这个只是⼀个业务场景的模拟，实际上会有什么问题呢？
1、当⽤户积分不够所带来的⼀直⽆法⽀付，对于这个订单的后期如何处理？
2、针对于⼀些⼤型项⽬，对于订单和商品都需要进⾏拆分，那么会对现在的系统造成什么影响呢？
3、减少⽤户积分（后期别的⽀付⽅式），其实添加记录不应该影响⽀付，那么如何解耦？
...
等等的⼀些问题，我觉得你都应该去考虑，然后去尝试，然后去发现问题。
这⾥⾯就会有很多有趣的东西了，⽐如mq、异步等等，抛砖引⽟、抛砖引⽟
后⾯就看你的了！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。