以实例说明微服务拆分(以SpringCloud+Gradle)

前言

以前,我都是说了不少的关于微服务的概念,说到底,不少人看了以后会认为没有什么意思,由于没有实际的东西说明,即便每一个概念都明白了,也很难赋之实践。因此此次,我来用一个实际的例子去说明,在实际的项目过程当中咱们会如何去构建咱们的微服务。git

PS:咱们只是利用场景去模拟咱们微服务构建或者说拆分的整个过程,对于场景自己在实际中会出现的问题咱们不作考虑,说白了就是咱们不考虑场景自己在实际生活中是否是这样的。github

使用SpringCloud+Gradle构建架构

本文目的:让你体会到服务拆分自己,引发你对服务拆分的思考。并发

 

场景模拟

咱们首先模拟这样一个业务场景,积分兑换实体商品。流程大体以下:
一、用户登陆
二、选择商品
三、下单
四、积分支付
五、商品发货
六、订单完成异步

“抽离业务”这里为了简化咱们的实现,咱们去掉用户登陆和商品发货这样两个步骤,也就是默认用户登陆,默认订单必定完成。
若是使用单体架构,那咱们最后实现的状况应该大可能是这样的。
···
用户点击兑换 ->
【减小商品库存,操做商品表】
【生成订单,操做订单表】
【减小用户积分,操做用户积分表】
【添加用户积分记录,操做积分记录表】微服务

在不考虑并发的状况下,也须要使用事务,也就是说,其中任意一步操做出现问题,都会致使整个兑换出现问题,也就是所有回滚数据。这是咱们通常在单体应用中所常常实现的方式。spa

 

如何拆分红微服务

如今,不管是老板说了,仍是说就是想作,甭管由于什么,反正我就是想要把它作成微服务。怎么办?
那么一个看似耦合性很高的业务场景,咱们究竟如何将它拆分红微服务呢?blog

咱们拆分须要掌握的逻辑
一、若是咱们要拆分的业务自己耦合度较高,那么拆分的须要作的是拆离业务,说白了就是须要和产品商量业务上面须要进行部分改动。
二、若是咱们拆分的业务自己没有耦合度,那么随你拆???不是的,须要考虑两点,一个是粒度太细成本就会上去,一个是后期扩展是否会有影响事务

 

架构改变

下面两张图是咱们模拟架构改变先后大体画了一下的两张图,咱们能够简单从图中得到二者的大致差别get

 

 

具体拆分

如今我提出一种拆分的方式
一、减小商品库存建立订单放在一个微服务中,构成下单服务
二、减小用户积分和操做用户积分记录放在另外一个微服务中,构成支付服务

拆分后的逻辑
用户点击兑换 ->
【减小商品库存,操做商品表】
【生成订单,操做订单表】

【减小用户积分,操做用户积分表】
【添加用户积分记录,操做积分记录表】

拆分达到的效果:
即便用户积分由于种种缘由没有正常扣除,后续还能够进行支付

拆分的好处:
后期扩展上来说,后期若是支付方式不仅是积分,能够用别的,那么只须要对支付服务进行修改,对于下单来讲没有任何关系

 

拆分代码

https://github.com/LinkinStars/MicroServiceExample

 

分析总结

若是你看完代码你就知道,其实拆分自己没有你想象的那么复杂,虽然咱们简化了其中的部分细节,可是实际若是须要这样去拆分,逻辑上其实就这样的。没有你想象的那么复杂。
可是!!!
困难其实并不在拆分代码自己,以前一篇博客我就提到了,其实微服务的拆分并无实际想象的那么复杂,而困难来自于拆分后会致使的各类问题,由于其实对于业务自己来讲,不少时候咱们都会遇到一些耦合性的业务,这些业务自己很难拆分。因此和上面说的同样,在一些服务进行实际拆分的时候咱们会对业务进行调整,虽然对于用户感知自己是同样的,可是实际代码来讲是不同的。
总结如下几点供参考:
一、若是经验不足,先小拆,后大拆
二、假设异常,假设每一个服务都分别出现一次异常,会对你拆分后的服务形成什么样的影响
三、优先保证主线业务稳定
四、拆分的原则是为了后期业务扩展,那么你须要优先考虑到后期的扩展大体会怎么样

 

Follow up

我一直在强调一点就是,咱们这个只是一个业务场景的模拟,实际上会有什么问题呢? 一、当用户积分不够所带来的一直没法支付,对于这个订单的后期如何处理? 二、针对于一些大型项目,对于订单和商品都须要进行拆分,那么会对如今的系统形成什么影响呢? 三、减小用户积分(后期别的支付方式),其实添加记录不该该影响支付,那么如何解耦? ... 等等的一些问题,我以为你都应该去考虑,而后去尝试,而后去发现问题。 这里面就会有不少有趣的东西了,好比mq、异步等等,抛砖引玉、抛砖引玉 后面就看你的了!

相关文章
相关标签/搜索