Roomwits电商服务演进之路
单体架构
架构简单
单个应用，所有功能都全部耦合在一个应用中
单个DB，所有的表都维护在一个DB中
-
可以快速响应业务研发需求，快速开发，快速上线
单体架构-面临的问题
所有的业务代码耦合在一个应用，随着业务的发展，代码越来越臃肿。
随着开发团队的壮大，团队成员技术水平的参差不齐，缺乏统一的代码规范，整个应用越来越乱。
新成员加入后，由于业务代码耦合在一起，需要阅读很多不是自己负责的业务代码，花费过多时间才能融入。
经常出现一些慢sql，影响整个DB性能，甚至影响整个DB挂掉，影响全部业务不能运转。
各种业务代码耦合在一起，开发效率低，每次测试以及上线发版，均需要消耗过多时间。
转变：垂直应用架构
从单体应用按照业务垂直拆分出多个应用
各个应用独立部署
每个应用拥有独立的DB
-
每个系统拥有独立域名
垂直应用架构-面临的问题
虽然按照业务线拆分系统，单拆分粒度过大，业务耦合依然严重
不同应用依然访问一个DB的情况，数据表拆分不彻底
业务团队各自为战，重复造轮子，浪费开发资源
-
多个业务系统边界不清晰
微服务架构-电商服务化架构
订单服务化:
原来的拆分粒度是比较大的，所以我们再次细分。分为订单售前和售后的服务。
订单的售前基础服务就是订单的CRUD，需要在他的上层做一次聚合，为订单的售前服务等。
......
订单服务化-举例取消订单服务交互：
取消订单的思考：
取消订单的流程大概是：先去查询订单，那就要去订单服务查询，订单里面有商品的信息，需要涉及到我们的商品服务，里面还可能有细分品牌服务、品类服务(spu、sku)，然后去验证一些规则是否可以取消。同时取消订单的时候，去营销服务返还优惠券的信息，占用的库存也需要去回滚，一系列的工作完之后，进入退款流程，则是去支付服务走退款流程。(线头颜色代表不同的服务去向)
原文作者：二进制跳动；如有侵权，请联系管理员删除。
