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