用户在电商网站中购买成功了，那么在微服务中经历了什么？

最新推荐文章于 2024-07-25 19:49:32 发布

殷十娘

最新推荐文章于 2024-07-25 19:49:32 发布

阅读量744

点赞数

分类专栏：架构资料文章标签：微服务数据库分布式多线程

本文链接：https://blog.csdn.net/sincegc/article/details/100197752

版权

本文探讨了用户在电商网站购买成功背后所经历的微服务架构设计。通过领域驱动设计（DDD）对电商系统进行模块划分，包括用户、商品、订单和支付四大模块。接着，介绍了如何利用DDD进行服务拆分，强调了建模和战略、战术建模的重要性。此外，文章还探讨了微服务的时序图、技术栈选型（选择Spring Cloud）、逻辑分层、分布式事务（MQ消息事务和TCC方案）、熔断限流隔离降级（使用Hystrix）以及集中式配置中心（Apollo）。最后，文章提到了调用链监控（Skywalking）和部署到生产时的容量预估。

摘要由CSDN通过智能技术生成

当我傻啊，用户在电商网站购买成功，还在微服务中，那肯定就是有一套微服务架构的电商系统。

设计一套电商系统还不简单

简单想象一下，既然是一个电商系统，有用户去购买，就肯定得有一个用户模块，购买什么东西总不是西北风吧，购买肯定是商品吧，省掉购物车，就得有商品模块吧，商品总得有库存吧，库存就暂时跟商品放一起吧，什么仓储物流先别管，就当作是虚拟商品好了，反正题目也没说不能是虚拟商品^_^，购买成功了，那就必须有订单吧，加个订单模块，下完单总得支付吧，不付钱人家凭什么把东西给你，那就得有个支付模块。

简单粗暴，四个模块

用户模块，商品模块（库存），订单模块，支付模块

好，几个模块搞定，外加下单流程图

等等，貌似题目说是微服务，既然是微服务就涉及到拆分服务的问题

DDD 领域驱动设计

刚刚确实是梳理了一下模块，既然是微服务，就得进行服务的拆分，服务怎么进行拆分呢，貌似按照刚次梳理模块来划分也是可以，不过这样好像显得我很不是专业，听说现在很多人都要使用DDD（领域驱动设计）来指导微服务的拆分。

参考DDD的设计，DDD官方的架构草图，总体架构分为四层，Infrastructure(基础实施层)，Domain(领域层)，Application(应用层)，Interfaces(表示层，也叫用户界面层或是接口层)

微服务结合DDD

不过对于领域设计而言代码层其实不是最重要，最要的是如何去划分领域，划分好边界。而对于微服务而言，非常适合从业务上去划分各个Modules，划分好各个业务板块，微服务 + DDD，个人觉得首先从微服务的角度考虑去划分大的业务模块，每个微服务都应该是一个可以独立部署，各司其职的模块。简单的说，在微服务实际的开发中，结合DDD的思想去划分所有属于自己的领域。

实施DDD的关键

第一点是使用通过的语言建立所有的聚合，实体，值对象。

第二点也就是最关键的“建模”

划分“战略建模”，从一个种宏观的角度去审核整个项目，划分出“界限上下文”，形成具有上帝视角的“上下文映射图”
还有一个建模“战术建模”，在我们的“战略建模”划分出来的“界限上下文”种进行“聚合”，“实体”，“值对象”，并按照模块分组。

构建我们电商系统的上下文映射图

先来确定我们的战略核心的领域是什么，我们的目的是什么，作为一个电商系统，我们的核心肯定是卖出更多的商品，获取更多订单更多的利润，那么销售可以作为我们的一个核心的领域。这个作为一个明确核心域确立下来。

确定完核心子域后，根据对这个领域的理解划分出各个上下文，然后根据上下文再确定其他的相关领域。

初步我们可以看出围绕销售核心域的包含的几大块内容，价格，销售方式，购买的方式，已经购买。然后我们对支撑着核心域的子域也做了划分，支撑着核心域的有商品域，用户域，通用域有订单域，物流域，支付域。

回到我们的主题，我们这次没有购物车，也没有各个会员销售价格，把一些上下文拿掉，并建立映射。

领域驱动设计看似简单，其实很难实施，因为在各个环节中都需要对应的领域专家的参加或指导，这样才能设计出最符合实际的上下文映射图，而且我们花费的精力可能相比以后的数据驱动开发模式更多，但在整体对项目的把控性能上说，领域比数据驱动更加抽象，更加的顶层设计，在对应互联网的多变情况看得更远。

我们将微服务拆分为5个领域，分别是销售域，商品域，用户域，订单域，支付域。

完美，接下来就可以开始开发了 ^ _ ^

等等，兵马未动，粮草先行；代码未动，图先行，先把时序图画出来

时序图

一个简单的下单流程，涵盖了几个领域

完美，接下来就可以开发微服务了^ _ ^

等等，微服务的技术栈还未选型

微服务技术栈选型

服务拆分完了，时序图也画完了，可以开始我们的微服务之旅了，目前主流的微服务有阿里大名鼎鼎的dubbo和Spring-Cloud全家桶，还有新浪的Motan。比较熟悉的还是dubbo和spring-cloud，也都使用过，究竟应该选用哪一个呢？

因为之前都使用过，做点简单，粗暴的总结。dubbo在很早之前就开始使用，当时的微服务还没有现在这么火，很多理论体系也未完善，dubbo更像是一套rpc整合框架，spring-cloud则更倾向微服务架构的生态。相比Dubbo，springCloud可以说是微服务一整套的解决方案，在功能上是dubbo的一个超级。Dubbo和SpringCloud比喻，Dubbo架构的微服务就像组装电脑，各个环节自由度很高。springCloud更像品牌机。

基于不折腾，简单快捷，更倾向选择spring-cloud，ok，就定下来技术栈使用spring-cloud，愉快的决定。