前言

工作两年，技术依然在小白附近徘徊，即使有一些进步，但也不值一提
两年的工作内容，几乎就是cv加一些简单的百度，从细节方面说，经历的细节不算多，从架构方面讲，自己远远达不到那个级别。
谷粒商城主要是看尚硅谷在B站的教程，由于项目成熟，从开发到部署很完整，百度的生态也很好，决定从0开始开发谷粒商城，直到部署上线。

该笔记虽然是从头开发，但并不会事无巨细的详解每一个部分，每一种技术，因为就是混也是混两年了，多少还是懂一些的，但是会从头到尾，从架构图，设计文档，sql，到每一段源码，部署的每一条命令都会记录，期望是如果稍懂技术的人看到，直接cv，就可以在短时间内从0开始完成谷粒商城

分布式基础概念

微服务

简而言之：拒绝大型单体应用（以前是将所有的代码、页面包括sql语句等都写在一个应用里，这样会导致如果有一处代码出现问题，可能会导致整个项目都不能运行），而我们就希望将大型单体应用基于业务边界进行拆分，将大型单体应用拆分成不同的小模块，每一个小模块我们就可以称为一个微服务，这些模块合起来就相当于一个单体应用，这些微服务都是独立部署运行的，如果有一个出现了问题，我们不希望影响其他服务的运行。

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

集群&&分布式&&节点

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

分布式是指将不同的业务分布在不同的地方。
集群指的是将几台服务器集中在一起，实现同一业务。

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

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

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

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

远程调用

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

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

负载均衡

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

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

常见的负载均衡算法：

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

服务注册/发现&注册中心

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

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

配置中心

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

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

服务熔断&服务降级

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

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

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

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

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

API 网关

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

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

谷粒商城-微服务架构图

内网部署与外网部署

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

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

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

技术栈

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

前端

1. nginx

前端技术栈类比

后端

1. SpringBoot 2.5.5 – 微服务编写
2. OAuth2.0 – 认证
3. SpringSecurity – 权限控制

服务治理

• SpringCloud Alibaba 2021.1

1. Nacos – 注册中心、配置中心
2. Seata – 分布式事务
3. Sentinel – 服务熔断、降级

• SpringCloud 2020.0.4

4. Feign – 微服务调用
5. Gateway – 网关
6. Ribbon – 负载均衡
7. Sleuth + Zipkin – 服务可视化追踪

数据支撑层

1. Redis – 缓存（分片集群、哨兵集群）
2. Mysql – 持久化（读写分离、分库分表）
3. RabbitMQ – 消息队列（服务之间异步解耦、分布式事务的最终一致性）
4. ElasticSearch – 全文检索
5. 开放式存储服务OSS – 阿里云对象存储服务（图片、视频）

日志分析

1. ElasticSearch – 存储
2. LogStash – 收集日志
3. Kibana – 从ES中检索，展示

应用监控

1. Prometheus 聚合分析 Sleuth + Zipkin – 搜集服务调用的信息
2. Grafana 可视化展示
3. Altermanager（Prometheus 提供的） – 得到一些服务的告警信息，以邮件或者手机短信的方式通知开发或运维人员

运维（持续化集成）

1. Docker
2. K8S
3. Jenkins

微服务划分图

1. admin-vue 面向工作人员的后台管理系统
2. shop-vue 面向用户访问的web系统
3. todo app与小程序该项目并没有开发，自己试着看能不能弄出来

1. gulistore_coupon – 优惠卷服务 7000
2. gulistore_product – 商品服务
3. gulistore_member – 会员服务
4. gulistore_order – 订单服务
5. gulistore_ware – 仓储服务
6. gulistore_gateway - 网关服务 88

项目技术特色

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

软件版本

VirtualBox – 6.1.26
Vagrant – 2.2.18
docker-ce（社区版，不要钱）-- 20.10.9
mysql – 5.7
redis – 6.2.6
jdk – 1.8
maven – 3.6.1
node.js – v14.15.1

尚硅谷学习视频B站链接：
https://www.bilibili.com/video/BV1np4y1C7Yf?p=3

我们口腔对美食的感觉来自于三观，
第一是我们舌跟口腔黏膜的味蕾体验，这是味道，
第二种是牙齿咬住的这种牙感，这个牙感可以有扎实感，一般讲咬定什么，咬住什么，这是安全感
第三个很重要的，是我们吞咽，吞咽的这个动作，其实带动我们整个胃肠道，向下蠕动，吞咽使我们大快朵颐的基础，这是获得感

圆桌新春派第2期