概要：关于电商的微服务划分和实践虽然多，但都讲的粒度都比较粗，简单的告诉你怎么划分，一把梭的上架构图，很多关键细节都没讲到位。而且看起来实际很多看起来和单体架构没什么区别，根本没发挥到微服务的优势。设计得很复杂的话中小企业压根没有人力物力去落地或者说开始想象太美好实际行动跟不上而夭折，所以针对资源有限的情况如何落地和迭代进行研究和实践，分享下经验，如有不足请多多指教。
服务划分
-
粒度如何把控？
刚开始设计时候，把握粒度是一件很让人纠结的问题，相信我，如果在没有经验的情况下，先粗后再细分，先上线，在运营过程中慢慢就会有思路了，至于有经验的，那就按你的经验来吧。 -
如何粗粒度设计微服务？
至于其他应该从哪方面考虑很难讲，举个栗子，再分析。
image.png
设计思路分析
-
根据共性来命名，边界清晰
虽然是粗粒度划分服务，但边界要明确，命名很关键，要有一定概括性。在电商业界，无论再多的业务，只要还在电商的范围，便逃不出#“买卖什么，怎么买卖”#的问题，而买卖什么即你拥有什么资源，资源也分虚拟的信息资源和有功能性的产品资源。至于怎么买卖就是业务流程问题，它记录并贯穿始终。资源（记录信息）和业务（记录过程）都分别独立的履行自己的责任，他们需要有动作来整合才能产生意义，就是交易！所以交易中心是聚合服务，它负责调度资源和业务的功能来完成。我在强行解释，凑合着理解把！ -
根据技术类型选型，避免大杂烩
开发往往针对不同性质业务采用不同技术体系，不同语言。
举个栗子，对于资源这种服务，功能无非就是CURD多，逻辑非常简单，但是数据结构可是丰富多样，你看商品，除了自己的信息，还有规格参数，sku组合，会员价格组合......（字段，结构变化还多！） 简直就是为#非关系型数据库#量身定制，再反观业务，看着文档就头秃，复杂的业务逻辑往往都是因为它们关系多，还有各种业绩报表，但是业务一但稳定就不会随便改，这种事情就是#关系型数据库#的强项。按技术类型拆分，减少项目复杂度。不同技术栈开发人员互不干涉。 -
根据迭代情况划分，降低部署时候服务相互影响
有多条业务线的情况下，有时候就某个条业务线发生不断迭代更新，好比如你电商有“买卖租借”，刚开始为了便捷放在同一个服务完成，后来租赁业务发展起来，想不断迭代改版，这时候拆分出来，那迭代过程中部署就不会影响到原来服务。所以，微服务划分是动态的。
关键问题下单扣减库存
一致性问题
按照上面说说划分，商品和订单分别是不同服务，但他们确是有交集，下单扣库存这坑，这也是电商领域的一个难题，如果用小白思路：用分布式锁锁住当前商品库存，扣减库存，成功后调用订单服务下单，这种情况下有可能会出现问题，扣减库存成功后出现异常，没法下单，那商品库存就没法恢复了，这时需要解决两服务间事务问题，采用2PC/TCC机制管理事务，开发量非常大，一般中小企业不会有这样的人力资源和技术给你搞这玩意。但如果你硬要把商品和订单放在一个服务那就当我没说，这样的微服务架构是没有灵魂的。
性能问题
如果采用分布式锁来锁住库存后扣减商品，那么在大量同一商品的订单下，会阻塞在分布式锁那里，导致性能十分差。
针对以上问题，设计一套可行性方案。
商品，订单，交易服务方案实现细节
-
前端请求交易服务，交易服务创建一个交易单号，然后交易服务只推一条下单的消息（带上交易单号），分别由商品和订单服务分别订阅。推送成功后，返回交易单号给前端。
-
商品服务处理：
- 下单监听事件： 监听到下单消息，根据交易号创建一条商品扣减日志，状态为未扣减。
- 扣减库存后台程序： 商品服务有一个后台持续运行的程序，它负责一直扫描那张扣减库存日志，每次扫描到的数据会按商品id分组，找到该商品id对应的扣减库存日志数据，再根据商品数量进行批量修改日志状态（改为扣减成功），因为是批量查询的，所以商品库存就不会每张订单都锁商品后扣减，而是把很多张相同商品的订单要的数量总和一起一次扣减。大大减少了锁商品产生的性能问题。
-
订单服务处理：
下单监听事件：监听到下单消息，创建一张待付款订单。 -
前端收到交易单号，会隔1s再访问商品服务，查询该交易单号对应的扣减库存日志是否被标记为扣减成功，成功了才允许用户付款。
下单.png
在秒杀系统这套体系非常适合，前端循环查询交易服务时候，交易服务如果查到该交易号没有扣减库存成功，可以查询下当前商品的扣减库存日志数量，从而返回当前排队人数，可以做排队效果。
网友评论