谷粒商城一介绍及基本架构todo

项目进度 前言

工作两年，技术依然在小白附近徘徊，即使有一些进步，但也不值一提

两年的工作内容，几乎就是cv加一些简单的百度，从细节方面说，经历的细节不算多，从架构方面讲，自己远远达不到那个级别。

谷粒商城主要是看尚硅谷在B站的教程，由于项目成熟，从开发到部署很完整，百度的生态也很好，决定从0开始开发谷粒商城，直到部署上线。

该笔记虽然是从头开发，但并不会事无巨细的详解每一个部分，每一种技术，因为就是混也是混两年了，多少还是懂一些的，但是会从头到尾，从架构图，设计文档，sql，到重难点源码、命令都会记录

看到有一些朋友收藏了这篇文章，如果你也正打算做这个项目，欢迎大家私信我，我们可以互相沟通。

看这篇文章的话我还是不建议大家收藏，没什么意义，这就和大部分书架上的书一样，

希望可以有人看到第二篇，第三篇。。。，再来收藏，更有意义一些

谷粒商城系列文章最后更新时间，2023.5.11

到此为止，分布式高级篇已经完成，我暂时不打算看接下来的部分，接下来偏运维多一些，打算复习谷粒商城和java部分，然后找工作，今年的行情这么惨淡，不知道能不能找到合适的

分布式基础篇总结

这个事儿啊，总是会和自己当初想象的不一样，

最开始的想法是要记录每一步，后来发现有些东西太简单，不值得记录，

然后就打算说那就只记录最重要的，现在是到第10篇了，就这样一篇篇写下去，发现又有冲突了，

之前接触过一些es，做过一些笔记，觉得如果整合到谷粒商城太麻烦，所以还是跟之前的笔记做一个补充，等真正应用到谷粒商城的时候再来下一篇笔记

分布式高级篇总结

服务之间是分布式的，将一个大型的商城业务拆分成了各种不同的服务，由这些服务共同组合成我们的商城。

nacos，注册中心与配置中心

将所有服务的配置都放到配置中心，这样通过nacos的控制台可以直接修改配置，修改完之后微服务就能动态的在不下线的情况下就能应用到最新的配置。，流量哨兵， 限流&熔断&降级seata，分布式事务oss，对象存储 feign，声明式远程调用，网关 + ，服务链路追踪 用到的其他技术

接口幂等性

希望服务中的所有接口都是幂等的，这样的话无论是调多次或一次最终的结果都是一样的，这是我们整个分布式系统中业务功能接口的保证。

可以通过加锁，数据库的乐/悲观锁字段加事务等等来做接口幂等性。

我们在系统中使用的是令牌机制，类似于验证码，发一个令牌，发请求的时候带上，用过一次就销毁。

事务

分布式事务。

seata，最好用的场景是后台管理系统，并发性能要求不高。

比如添加一个商品，保存的时候要把它的优惠，库存等各种信息在各个系统全部保存。要成功都成功，要失败都失败。

如果是并发性能超高，比如高并发下单等，都是使用最终一致性。

缓存与分布式锁

在分布式系统中，要保证接口的吞吐量，使性能往上提升，缓存是必须的。所以我们只有有了缓存才能极大的加速我们整个系统。

所以高并发中缓存是最重要的一个手段。

同时我们使用缓存期间又碰到了使用缓存的一些问题，缓存的击穿、雪崩、穿透。

我们使用分布式锁来解决这些问题，当大并发量请求全部要来查数据库，它先来查缓存的时候，我们使用分布式锁来锁住，只有一个请求进来，它查不到缓存再去查数据库，所以最终只会给数据库放一条查询。而其他人得到锁以后，他们只会下次继续来看一下缓存就行了，不去查数据库。

定时任务中也有用到分布式锁。定时任务上架秒杀商品有三台服务器，代码是一样的，所以会执行三个一模一样的定时任务，而我们只需要一个即可。

只要用了分布式锁，上架过了就不需要再上架了。分布式锁可以锁住所有的机器，让只有一个机器去来执行这个任务就行了。

es，商品的检索不能放在mysql中，性能非常低下。我们所有的检索功能，无论是按照分类、属性、名字检索，所有的检索数据全部保存在es中，它是一个非常专业的检索引擎。

在高并发系统中，异步是必要的，一定会编写的。

以前是new .start()，但如果在高并发系统中，每一个请求进来都这样干的话，资源会很快耗尽的。

所以为了控制整个系统的资源，我们要使用线程池，所有的异步任务都提交给线程池，这样线程池中会有一个最大量，就不害怕系统因为一些资源耗尽导致的崩溃。

即使有了异步任务提交给线程池，异步任务之间还可能有顺序，我们可以使用异步编排，异步编排。

登录

不同域名系统下需要用单点登录。

我们使用的是相同域名的，暂时可以不用使用单点登录。

相同域名下，登录一次相当于处处都要实现单点登录效果，我们整合了，将所有微服务的进行同步。登录成功之后，去哪一个微服务，都可以获取到数据。我们使用解决了分布式系统不一致的问题。

商城主要业务

商品上架、商品检索、商品详情、购物车、订单、秒杀，具体细节在商城业务.pdf中。

在商品详情中，用的最多的是缓存技术，除了把数据缓存到redis，我们还整合了方便的使用缓存。以后我们的全系统都应该使用这种方式来进行缓存。包括解决缓存的不一致、更新、清空问题，都可以帮我们方便的解决这些问题。

，分布式事务最终一致性

我们在做分布式事务实现最终一致性的时候，是一个很必要的工具。我们只需要a服务给b服务来发一个消息，它不用关心最终怎么做。

在订单这个场景下使用它做分布式事务，在秒杀中用它做削峰处理，将所有的流量排队放到队列中，由我们的后台慢慢消费。

如果引入队列，ab服务也不用关心接口调用了，a都不用调用b，所以相当于我们将应用之间进行了解耦。

的使用也非常深入，特别是在订单，我们在关单的时候，我们使用了的死信队列，保证需要关单的数据都能被关掉。

支付，整合支付宝的沙箱来进行支付

定时任务与分布式调度，秒杀商品的上架

最终，在高级篇构建一个高并发系统，除了引入和 相关组件外，高并发系统中还有以下三大重要手段。

项目背景 电商模式

市面上有 5 种常见的电商模式 B2B、B2C、C2B、C2C、O2O；

B2B 模式 B2B ( to )， 是指商家与商家建立的商业关系。 如：阿里巴巴、八方资源网等

B2C 模式 B2C ( to )， 就是我们经常看到的供应商直接把商品卖给用户，即“商对客” 模式，也就是通常说的商业零售，直接面向消费者销售产品和服务。如：亚马逊、当当等

B2C平台：天猫、京东、一号店等

C2B 模式 C2B ( to )，即消费者对企业。先有消费者需求产生而后有企业生产，即先 有消费者提出需求，后有生产企业按需求组织生产

C2C 模式 C2C ( to ) ，客户之间自己把东西放上网去卖，如：淘宝，闲鱼

O2O 模式 O2O 即 To ，也即将线下商务的机会与互联网结合在了一起，让互联网成为线 下交易的前台。线上快速支付，线下优质服务。如：饿了么，美团，淘票票，京东到家

P2P：在线金融，贷款，如：网贷之家、人人聚财等。

谷粒商城是一个 B2C 模式的电商平台，销售自营商品给客户。

电商模式的特点 分布式基础概念 微服务

简而言之：拒绝大型单体应用（以前是将所有的代码、页面包括sql语句等都写在一个应用里，这样会导致如果有一处代码出现问题，可能会导致整个项目都不能运行），

而我们就希望将大型单体应用基于业务边界进行拆分，将大型单体应用拆分成不同的小模块，每一个小模块我们就可以称为一个微服务，这些模块合起来就相当于一个单体应用，这些微服务都是独立部署运行的，如果有一个出现了问题，我们不希望影响其他服务的运行。

微服务是一种非常流行的架构风格，将大应用拆分成小服务之后，各个小服务都运行在自己的进程中，也就是互相隔离微服务之间也需要通信，例如订单服务向商品服务查询一些商品信息，通常使用HTTP API（轻量级机制通信）进行通信。

集群&&分布式&&节点

集群是个物理形态，分布式是个工作方式。

分布式是指将不同的业务分布在不同的服务器。

集群指的是将几台服务器集中在一起，实现同一业务。

例如某大型网站用户服务访问量高，那么用户服务就用十台机器一起来运行，我们随便访问哪台都可以，用户服务就是做了集群化处理。

分布式中的每一个服务器，都可以做成集群，而集群并不一定就是分布式的。

用户服务十台服务器运行就是集群，而十台服务器运行的用户服务不能被称为分布式。

节点：集群中的一个服务器

远程调用

在分布式系统中，各微服务可能处于不同服务器，但是服务之间不可避免的需要相互调用。

中推荐使用 HTTP+JSON的方式完成远程调用。

负载均衡

分布式系统中，A服务需要调用B服务，B服务在多台服务器中都存在（集群），A调用任意一个服务器均可完成功能。

为了使每一个服务器都不要太忙或者太闲，我们可以负载均衡的调用每一个服务器，提升网站的健壮性。

常见的负载均衡算法：

轮询：在服务器健康池中依此调用最小连接：优先选择连接数最少，也就是压力最小的后端服务器，在会话较长的情况下可以考虑采取这种方式。散列：根据请求源IP的散列（hash）来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。如果你的应用需要处理状态而要求用户能连接到和之前相同的服务器，可以考虑采取这种方式。 服务注册/发现&注册中心

A 服务调用 B 服务，A 服务并不知道 B 服务当前在哪几台服务器有，哪些正常的，哪些服务 已经下线。解决这个问题可以引入注册中心。

如果某些服务下线，注册中心可以实时的感知到其他服务的状态，从而避免调用不可用的 服务。

配置中心

每一个服务最终都有大量的配置，并且每个服务都可能部署在多台服务器上。我们经常需要变更配置，我们可以让每个服务在配置中心获取自己的配置。

配置中心用来集中管理微服务的配置信息

服务熔断&服务降级

在微服务架构中，微服务之间通过网络进行通信，存在相互依赖，当其中一个服务不可用时，有可能会造成雪崩效应。要防止这样的情况，必须要有容错机制来保护服务。

服务雪崩：A服务调用B服务，B服务调用C服务，C服务。。。，假如C服务挂了，那么A、B服务将无法正常运行，此时并发很大的话，更多的请求导致请求积压，请求将都会被阻塞，最终会因为一个服务的不可用导致服务器的资源耗尽，所有服务均不可用，导致整个服务的雪崩现象。

服务熔断

设置服务的超时，当被调用的服务经常失败到达某个阈值，我们可以开 启断路保护机制，后来的请求不再去调用这个服务。本地直接返回默认 的数据

服务降级

整体把控：在系统压力大，资源紧张的情况下，我们可以将非核心服务降级运行（停机不处理，或者简单处理）

在运维期间，当系统处于高峰期，系统资源紧张，我们可以让非核心业 务降级运行。降级：某些服务不处理，或者简单处理【抛异常、返回 NULL、 调用 Mock 数据、调用 处理逻辑】。

API 网关

在微服务架构中，API 作为整体架构的重要组件，它抽象了微服务中都需要的公共 功能，同时提供了动态提供路由服务，客户端负载均衡，服务自动熔断，灰度发布，统一认证，限流流控，日志统计等丰富的功能，帮助我们解决很多 API 管理难题。

API网关就像大商场唯一的唯一的一个安检入口，我们从这个入口进来，能放行过来的请求就是后台需要处理的

谷粒商城-微服务架构图

内网部署与外网部署

外网部署：面向用户访问的部署前端项目，可以有手机APP和WEB网站。

内网部署：整个后台的服务集群。

用户是通过使用客户端来完成相应的功能。

技术栈

todo 有的只是听说过，具体功能用法并不清楚，所以这块在之后的学习中需要补充

前端 nginx 前端技术栈类比

后端 2.5.5 – 微服务编写.0 – 认证 – 权限控制 服务治理 Nacos – 注册中心、配置中心Seata – 分布式事务 – 服务熔断、降级 Feign – 微服务调用 – 网关 – 负载均衡 + – 服务可视化追踪 数据支撑层 Redis – 缓存（分片集群、哨兵集群）Mysql – 持久化（读写分离、分库分表） – 消息队列（服务之间异步解耦、分布式事务的最终一致性） – 全文检索开放式存储服务OSS – 阿里云对象存储服务（图片、视频） 日志分析 – 存储 – 收集日志 – 从ES中检索，展示 应用监控 聚合分析 + – 搜集服务调用的信息 可视化展示（ 提供的） – 得到一些服务的告警信息，以邮件或者手机短信的方式通知开发或运维人员 运维（持续化集成） 微服务划分图

admin-vue 面向工作人员的后台管理系统shop-vue 面向用户访问的web系统todo app与小程序该项目并没有开发，自己试着看能不能弄出来 微服务名称端口号数据库

-

网关服务

88

-

秒杀服务

40000

-third-party

第三方服务

30000

-auth-

认证服务

20000

-cart

购物车服务

14000

-

搜索服务

13000

-

优惠卷服务

7000

-

会员服务

8000

-order

订单服务

9000

-ware

仓储服务

11000

-

商品服务

12000

备注：

10000端口是百度云的一个服务的端口，跳过

业务架构图

项目技术特色 应用监控、限流、网关、熔断降级等分布式方案 全方位涉及透彻讲解分布式事务、分布式锁等分布式系统的难点分析高并发场景的编码方式，线程池，异步编排等使用压力测试与性能优化各种集群技术的区别以及使用CI/CD 使用 软件版本

– 6.1.26

– 2.2.18

-ce（社区版，不要钱）-- 20.10.9

mysql – 5.7

redis – 6.2.6

jdk – 1.8

maven – 3.6.1

node.js – v14.15.1

尚硅谷学习视频B站链接：

我们口腔对美食的感觉来自于三观，

第一是我们舌跟口腔黏膜的味蕾体验，这是味道，

第二种是牙齿咬住的这种牙感，这个牙感可以有扎实感，一般讲咬定什么，咬住什么，这是安全感

第三个很重要的，是我们吞咽，吞咽的这个动作，其实带动我们整个胃肠道，向下蠕动，吞咽使我们大快朵颐的基础，这是获得感

圆桌新春派第2期