1.谷粒商城1-5文字版

01、简介-项目介绍

我这个架构图呢 我先快速的给大家过一遍 大家知道将会学到什么就行了 ，那我们后来呢会有详细的去来介绍，
首先呢，我们除了常规的业务开发 ，
比如我们开发后台管理系统也好，开发其他的商城业务也好 ，订单，购物车，除了这些常规的业务开发，我们所有的分布式微服务涉及到的这些方案，比如远程调用的Feign, SpringBoot里面的,以及网关、SpringCloud Gateway、以及我们的链路追踪、sleuth Zipkin包括注册中心 配置中心 Nacos、 以及我们的线上的监控系统pormetheus、Grafana、 和一套整套的预警，Altermanager、带上我们日志ELK组合,以及我们后边儿的存储、redis的集群 MySQL主从分片，以及RabbitMQ的整个镜像集群队列,ElasticSearch的全文检索等等这些功能,我们呢都会在开发期间全套涉及，那除了我们说的SpringBoot我不会从头到尾讲一遍外还有我们这个Redis,MySQL默认大家都会外，剩下的东西呢，我们都会带大家从入门到实战使用，
包括我们后来的整个CI/CD流程 最终我们通过部署一个K8S集群，就是K8S集群,然后呢能实现我们的这个Developer,我们的开发者,写完代码以后呢,我们自动化的去代码仓库里边儿拉取到代码，打包成文我们的Docker镜像, 然后使用JenKins流水线加入参数化构件, 手工确认, 将我们整个所有的项目全部部署到K8S集群里边儿, 我们也就是这一个项目, 会打通大家的整套链路, 最终希望大家呢,就站在一个上帝的视角, 能观看到我们整个javaEE开发的全貌, 那么谷粒商城呢就是这么一个项目, 希望能通过一个项目 ,把Java 从入门到入坟。
那我们这个项目整个背景， 快速的过一下 。
在众多的电商模式，B2B、B2C、C2B、C2C、O2O等等里边儿， 我们是属于一个B2C模式 那B2B呢是我们的商家对商家， 比如我们的1688 也就是我们的阿里巴巴，这个批发网站，商家跟商家之间进行一些批发， 互相购买，而B2C模式，就是我们说的商品卖给用户， 我们现在就是模拟B2C的自营模式，就像我们的京东 天猫 小米商城等等这些，以及我们电商的C2B模式， 消费者先有需求 ，企业在根据消费者的需求进行生产，当然，我们现在呢C2B模式的网站还不是很多， 还有我们的常见的C2C模式， 客户呢直接可以，自己把商品呢放到网上去卖 ，比如我们使用的淘宝 咸鱼，我们都可以发布个人的一些商品，还有我们说的O2O模式， 线上线下的， 也非常多 饿了么 美团 淘票票 这都是线上消费 线下服务 。
而我们整个谷粒商城呢就是一个B2C模式的电商平台， 我就是希望通过我们整个这个电商项目， 能把大家带到这麽样的一个高度，当然，要学这么多的知识， 大家会担心我们是不是对大家的要求非常高呢， 非常高倒不至于， 但是我们还是有一定的要求， 咱们这个项目里边儿呢， 包括但不局限于，我们将会给大家讲解非常多的这些技术， 比如一些特色 我们打通整个前后分离的全栈式开发， 以及我们SpringCloud的整套的解决方案, 不仅有SpringCloud 还有SpringCloud阿里巴巴以及我们微服务的整套治理方案 限流、网关 熔断 降级等等 我们全方位呢都会涉及以及我们整个的分布式事务， 分布式锁， 分布式缓存等等系统里面的重难点， 我们呢都不会回避 。包括高并发的一些编码方式， 线程池， 异步编排等等， 这些使用，包以及压力测试性能优化，项目里边儿呢 ，我们都会给大家进行讲解, 特别是各种的集群技术，我们去来如何部署一个redis  （）集群 ，MySQL的集群，（）以及（）等等， 这些集群技术呢，我们都会说 ，包括我们后边在架构师提升篇里边儿，给大家带来的整个全套的ci/cd流程， 而且是基于KS整套发布的，学习这么众多的知识呢， 大家需要有一个前置的要求， 比如默认大家是知道什么是Spring Boot的，也就是说最起码使用SpringBoot 哪怕开发过一个小小的简单的增删改查系统就行， 或者呢你会用spring boot也行， Spring Boot默认是会的， 然后呢而且你也会一些常见的整合方案，比如我们Spring Boot怎么整合MyBatis来进行一套增删改查开发, 这套呢我希望大家是前置掌握的 ,因为项目呢直接拿来使用， 包括也希望大家能了解什么是SpringCloud ,什么叫了解呢, 那你听过也行 ,你知道SpringCloud是干啥也行, 写过一个HellowWord就行了,  示录的东西呢 如果你实在不太会, 你在项目里边儿多用用，你也就知道了， 但git和maven, 这是每一个java开发人员的最基本要求, 以及linux,redis,docker 这个呢也已经演变成了一些基本操作， 但docker如果还是不熟悉的同学, 我们建议呢先先去谷粒学院，去来将这些不熟悉的课程docker啦，SpringBoot啊， 我们先都稍微补习一下， 也希望大家呢了解，我们前端的常见技术html css js vue等等, 但vue这个东西呢, 我们会快速的带大家过一遍,项目里边儿 用到的技术我们着重讲解， 说呢首先我们会体验到全栈开发， 然后呢加上分布式微服务的整套方案 ，以及大家只要熟练使用idea就行了, 不要老是按个快捷键,出来这个效果, 也不知道是什么快捷键 ,那最后一个小小的要求, 就是呢希望大家的操作系统，尽量呢是win10 因为win7 里边我们很多的软件可能会导致不兼容 ，但如果你的win7这些软件都运行良好的话 ，那也没啥问题， 那这就是我们整个谷粒商城项目的一个简单介绍， 包括这个架构图 ，那后来还会详细的来解释， 那下节课 我就给大家来演示一下我们整个项目的最终效果。

02、简介-项目整体效果展示

那接下来，我就给大家来演示一下我们这个项目，首先我们这个项目呢，分为三篇开发。
第一篇，基础篇
我们呢 会围绕我们后台管理系统，这是我们的后台管理系统，来登录进来，围绕我们电商的管理系统，来做一个整套的增删改查逻辑。比如我们来点进来，比如我们这个商品系统，我们整个都会来教大家来编写，这块呢，我们用的前后分离的方式，使用vue来进行开发，所以这一块呢，我们通过商品管理系统的编写。我们可以让大家全掌握基础的增删改查开发，包括我们这一块儿呢，也会远程调用微服务的一些功能，所以我们这个基础业务里边。来围绕整个商品系统的 所有的增删改查，来编码完了以后，那大家就应该会掌握具备我们进入公司的基本开发能力，这块的详细，我们就不演示了，编写呢，我们边给大家说，然后，这是我们的基础篇。我们主要呢，会围绕这个管理系统，来掌握我们所有基础开发要用的一些技巧，

好接下来 是我们这个分布式高级篇 
高级篇呢主要是围绕我们商城的前端流程系统，比如我们这个商城的首页，以及我们现在商城的商品检索页。包括我们要根据各种不同条件检索，要用到各种技术（）等等，检索完了以后 整套的其他逻辑加入购物车 结算 登录 等等逻辑，这是我们这个 前端商城系统， 我们要写的这个功能，比如我们去结算，结算呢没有登录，他还需要我们来进行登录，这登录呢，我们还可以使用微博社交登录，我们后来呢，都会给大家说，这是我们高级里边 我们整个呢 都是一个分布式的架构，我们都是微服务之间的调用，所以大家会看到我们这个微服务里边，比如有Feign，如果有人熟悉的话，我们这呢是一个远程调用失败，所以能经常会有这些问题，我们在高级篇呢，就会帮大家去来解决咱微服务开发里边的所有技术、问题、以及我们的一些方案、特别是在高级篇，他的一些周边治理方案，我们也都会给大家详细解答，比如我们这个流量控制，我们网站压力过大，我们要控制它的流量，我们可以使用阿里巴巴的sentinel来给大家演示一下,我们的流量控制，

来登录进Sentinel,我们的这个系统里边，这个系统里边，我们这个账号密码呢都叫Sentinel，我们登录进来以后呢，我们可以对我们后来的每一个微服务都来进行流量控制，比如我们这个商品服务，这呢，他能监控到，我们这个商品服务调了多少个链路，这个链路里边呢 比如我们想要进行流量控制，这个“/”那就是访问我们根目录的，我如果来，点击一个流控，QPS 意思呢 我们每秒，你访问我们这个“/”，这个请求，只能有几个，比如我写一个，只能有一个，来点击新增，那么来到这个商品详情页，我来刷新，那我们这个，刷快了，就会编程请求流量过大，只有正常了，一秒一个，我们在这一块呢，才是可以，但我没人去来现在这个首页，这是我们说的，限流，我们会来 也会交给大家然后呢 加上我们的，周边治理设施的注册中心，这一块呢大家可能 还不是很清楚，大家就看一下演示，我们将会有哪些功能就行了，我们所有的 后来上线的所有微服务，我们全部呢再注册中心里面 都会有上限，我们注册中心的 动态的来调动 我们哪个服务呢 该应该去哪个地方调用另外一个服务，这都是我们后来在高级篇里边要研究的所有东西。以及我们的链路追踪，比如我们这个微服务，整个链路我们这个调完了以后，我们线上为了定位问题，包括哪一块请求，太慢了，我们可以使用链路追踪技术。

我们点查找，该查到之前调研过的所有请求的链路，比如我们随便来点击一个进来，他这一块从网关，欸 下次呢又调到网关，这是一个空的请求，我们可以看复杂请求的比如我们来点查找，我们真正有复杂请求的，比如我们这个商品服务  我们还有购物车的，这一类服务，我们就该来点进他的整个链路，能看到从网关调到我们这个商品服务，包括呢， 什么情况 花了多长时间，我们这呢都会有，这是我们说的说的链路追踪，所以我们在高级篇开发的时候，无论是我们高级篇的一些知识，我们整个分布式里边的 所有要用到知识，还是我们周边的这些治理设施，我们呢全部都会给大家加上，这是我们说的，这个分布式高级篇，高级篇开发完了以后呢，大家一定会对我们整个分布式开发，有一个非常熟的掌握。那去来做任何的高级开发都没有任何问题，只需要来熟悉你的业务就行了，技术肯定没问题。

加上我们最后一篇，是高可用集群篇，在集群篇里边呢，我们还会给大家来搭建一个K8S集群，比如来看我的远程主机，我呢给我的这个远程电脑 我准备了第二台电脑，但大家要学集群篇的内容。也推荐大家再来准备一台电脑。我第二台电脑的内存都要32G，好 这个电脑呢 我们现在搭建了一个K8S集群，这个集群呢，将会为我们整个分布式提供我们的集群服务，包括我们还会结合我们的整个管理控制台，比如我们这个控制台呢，是一个（KUBESPHERE），我们来打开来给大家看一下。我们来通过这个控制台， 我们可以登录进来，掌控我们整个K8S的集群，好那进来看一下，我们这个集群里边，我们可以监控到我们整个集群的所有状态，我们现在呢有三台机器，然后呢它们的内存占用CPU等等，我都会来监控我们的集群状态，包括我们这个项目呢，在我们的部署篇里边，我们来讲每种技术的集群在我们的K8S里边，来发布我们的微服务外，我们还会给大家带来CI/CD，就是我们说的，持续集成，持续部署的功能，但是这一块呢 大家可能第一次听这个概念， 稍微呢比较不清楚，来说下持续集成的作用就是，我们最终，只要我们的开发人员敲完代码，

我们接下来呢，会一个流水线全部自动化的将我们这个代码代码打包、发布、测试、运行、一直最终上线到我们的环境。全部呢是一个自动化的流水。我们也可以来给大家看一下，这个自动化的流水，我们来登录到我们的这个平台，咱后边这些东西呢，全部都会教大家一一来搭建，我们在我们的这个devops工程里边,我们也会后来说 什么是devops,我们呢就会有我们的流水，这是我们称的流水线，这个流水线呢就能帮我们来，自动的去来拉取代码，拉取完以后打包镜像，并且把我们这个代码部署上来，来大家注意。我们现在这些流水呢，已经有很多运行成功的，来随便点一个，大家体会一下，只要我们开发人员敲完代码以后，来我们这还是一个可视化的，我们流水线，敲完代码以后呢，我们这个流水线会自动的，把代码从(getHap),等一些代码仓库里边拉取过来，然后呢并且对代码的质量进行一个分析，分析完以后会把我们的这个推送成镜像，镜像呢，相当于是我们后来要结合（）， 我们整个K8S集群就要用到（），然后呢， 最后把我们的这个服务，在来构建部署到整个K8S集群里边，然后呢我们服务的整个版本就会发布出去，这都是我们一个可视化的流水线，

后来我们都会教大家，一一的来做这个事情，那这个就是我们将，电商项目分为三篇开发，

那第一个基础篇，对标的就是大家能拥有我们这个基础开发技术的掌握，去任何公司干最基础的活，包括稍微难一点的活是没有任何问题的，就是正常过试用期啦，我们来拿个一万五六的薪资没有任何问题，

而我们这个高级篇，那就对标我们更多的高级技术，如果大家全部能将分布式系统里边，整体的高级技术全部都学会，我们后来也会给大家说一下我们整个电商项目的架构，它里面的所有高级技术都学会，我们自己也会架构，那您的技术就非常厉害了，只要有足够多的工作经验，我们也可以去来匹配一些架构师，或者项目经理，

那我们的这个集群篇，集群篇里边呢，都是我们现在非常流行的K8S集群，加上我们的，现在我们给大家推出的（KUBESPHERE），整个一站式平台， 那通过这个平台呢，我们全部教大家在我们的整个集群篇，如何去运维、部署、咱们项目发布、包括去来搭建集群，包括K8S的所有操作,如果我们这个集群篇也能掌握的话，那加上我们自己项目经验，工作经验，去来对标一个架构师，如果您有足够多的工作经验， 在技术程度上来说，去来做一个架构师也是可以的，那我们最终希望通过我们整个电商项目，我们做出的整套流程无论是我们后台管理系统，前台整体业务，周边的治理设施，还是我们后边的（）集群，大家能呢，站在一个上帝视角，来看到我们整个JavaEE开发的全貌，那我们最终希望我们的电商项目，能达到这么一个效果，那我们最终呢电商项目，肯定呢会非常大，非常长，

那我们推荐大家有基础的同学，你可以去来，觉得基础篇的增删改查不想开发了，去来跳过，如果你的高级篇也没问题了，你也可以去来跳过，然后如果你的集群片也没问题了，你也可以来跳过，我们每一篇呢其实都是单独成篇，那这样呢我们大家学习起来就像查字典一样，那最终呢学习自己感兴趣的，也是没问题的，特别是对于集群篇，我们也推荐非常多有工作经验的同学。然后呢我们只来单看集群篇，这样的话呢我们就是通过一个真实的项目架构案例，我们整个电商项目 将我们这个项目呢， 自动化的全部部署到我们的（）集群里边，从这一块起步也是没问题的，好那这就是我们整个电商项目的，也是和我们将来的这些介绍

03、简介-分布式基础概念

好接下来呢，我们一起来看一下我们整个项目的微服务架构图，和微服务划分图，但想要懂这两个图之前，我们需要大家对微服务以及分布式系统里面的一些基础概念，有一个简单了解。

好，我们先来回顾一下什么叫微服务呢。

其实简而言之，一句话。我们微服务就是拒绝大型单机应用，我们以前将所有的代码，页面，包括SQL语句，等等全写在一个应用里边，这样容易导致一个最大的问题，如果有一处代码出现了问题，可能导致我们整个应用不可用，那我们就希望呢，把我们这个大型的单体应用，可以基于业务边界，对他进行服务的微化和拆分，我们将一个大的单体应用，拆成个个不同的小模块。每一个小模块呢,我们就可以称为一个微服务，这些模块呢，合起来最终完成一个单体应用，而这些个个微服务呢，他们却是独立部署运行的，如果有一个出现了问题，我们希望不能影响其他服务的正常运行，也就是说微服务啊，是一种非常流行的架构风格，哎它将我们这些大应用拆分成小服务以后呢，我们个个小服务运行在自己的竞争中，也就是互相隔离，但是呢微服务之间，也要进行通信，比如我们订单服务，想要去商品服务，查询一些商品信息，那我们推荐呢，我们微服务啊，可以走HTTP API的形式，也就是说，从订单服务给商品服务，发一个请求，把商品信息调过来就行了，这都，这就是我们说的微服务，那微服务在极端情况呢，可能长的一个这样子，一个大型应用拆分成好多微服务，每一个小方块呢，都是一个小服务，这服务之间的调用关系网非常复杂，这就对我们的开发，部署，和运维，带来了极大的挑战，但这些挑战才是我们真正能学到的技术，

接下来呢，来说一下什么是集群、分布式、以及节点。

那我们所说的集群呢它其实是一个物理形态，而分布式呢是一种工作方式，也就是说，只要是一堆机器合起来我们就叫做集群，但这一堆机器呢，是合起来做一件事情，还是各自做各自的，我们谁也不知道，而对于分布式系统的定义，可以参照这本书，他这样说的，分布式系统，是若干独立计算机的集合，也就是说有这么一堆计算机的集群，诶你可以称为集群，他合起来呢为我们提供一个服务，而这些计算机对于用户来说，像是使用单个系统，用户没有感受到在使用这一堆计算机，而是感受到，他在使用一个系统，比如举一个例子，京东，我们用户在购物的时候，敲3W点京东,进入京东的网站，完成整个购物流程，我们没有感受到京东网站后边有多少台服务器，因为京东他是一个分布式的系统，它的各个业务是运行在不同的机器上的，这些机器是合起来完成整个京东的功能，所以说呢我们这些服务啊，我们就可以把它称为一个大型的业务集群，而且呢，每一个小的服务比如京东里边，有一个叫用户服务，用户服务呢我们每天登录注册，登录注册，可能并发量很大，访问压力大的时候呢，一台服务器肯定不够，京东啊可以让用户服务就这一个服务，我们十台机器一起来运行，比如呢你随便访问哪台都行，那这样的话呢，我们整个这个用户服务他又是做了一个集群化处理，通过这个简单的概念呢，可以理解一句话，分布式中的每一个节点，什么叫节点呢，就是分布式中的每一个服务器，他呢都可以做集群，什么意思呢，比如我们这个用户服务，她在这个服务器上， 欸，压力大的时候呢我们可以把做成集群， 我们十台服务器，同时来跑这个用户服务，而集群呢，并不一定是分布式的，比如我们这个用户服务，这十台服务器，都是用户服务，他是不是一个分布式的呢，不是，整个京东系统才是分布式的，因为这个系统的各个业务，运行在各个不同的地方，他们是以分布式的工作方式，也就是说各个工作，各自的，合起来完成一个完整的系统，这叫分布式的工作方式，也就是说分布式是将，不同的业务分布在不同的地方，比如京东各个业务呢，在各个不同的服务器，有购物车，订单，商品，而集群呢，指的是几台服务器集中一起，实现统一业务，比如我们这个购物车，一台服务器不够，我放上十台服务器，那么他们呢这十台都是购物车，他们是实现统一业务，

接下来呢，我们再来说一下远程调用。

那为什么会有远程调用呢，我们说在分布式系统中， 各个服务，也就是我们拆分的各个功能模块，我们呢，以后将每一个小功能模块，我们就称为服务，那么各个服务呢，可能处于不同的主机，比如我把购物车这个模块，放在A机器，订单放在B机器，商品放在C机器，那么不可避免的，服务之间就要产生互相调用，比如我们订单模块，想要去商品模块， 查询一些商品信息，那怎么办呢，我们把这个调用就称为远程调用，Spring Cloud推荐使用HTTP+JSON方式完成远程调用，也就是说，从订单模块给商品模块发一个HTTP请求，那么他们之间传递 ，在网络间传递数据，可以把数据转成JSON的方式来进行网络传输，这样做的好处呢就是天然的跨平台性，JSON呢在任意平台，都可以使用，包括HTTP请求，欸，什么都可以兼容，HTTP系统C++等都，可以接收和发送，HTTP请求。

那么我们既然要远程调用，就不可避免地要牵着一个东西，叫负载均衡。

什么是负载均衡呢，比如我们这个订单服务，想要调用商品服务，查一些商品信息，那么商品服务呢，我们之前说过，每一个在分布式系统中，每一个节点，我们都可以做成集群，因为商品服务啊，这个压力很大，我们可以给三五台机器都让它来跑商品服务，这样的话呢，我们订单服务可以去任意一台机器都能查出商品信息，那我们要怎么查出商品信息呢，我们就可以使用负载均衡，比如说，如果我有一次，第一次我去这个服务器查商品信息了，第二次呢这个服务器人爆满了，那我就可以去这个服务器，第三次呢我们也可以去别的服务器，总之，负载均衡就是一句话不要让任何一台服务器太忙，也不要让它太闲，我们可以根据不同的均衡算法，来提升我们网站的健壮性。

比如我们常见的一些均衡算法。

有 轮询算法，比如说第一次呢我给这个服务器发请求，获取商品详情，那么第一次调用过了它了，第二次呢就轮到他， 第三次轮到它，第四次呢又回来轮到它，这样呢，是我们一个简单的负载均衡算法——轮询。

也可以用最小连接，比如呢，我优先选择，看哪个服务器，他现在的连接数最少的，也就是压力最小的，这样的我跟他建起连接，这样呢我们总能找到一个最闲的服务器，能更快的处理连接。

 但我们还可以根据散列算法，也就是呢同一个IP地址的请求，也就是同一个用户的请求，最呢，都会被负载均衡到同一个服务器。

接下来呢，我们来说一下服务的注册/发现&以及注册中心。

为什么要有这个呢，我们先来想象一个场景，假设呢，这有一个A服务，就是我们的订单服务,还有一个B服务，是我们的商品服务，订单服务呢想要调商品服务来查询商品的详情，但商品服务呢在这三台机器都有，而且呢这三台机器可能有些不稳定，有的时候呢它下线了，有些时候呢这两个下线了，而我们也不知道哪台机器现在能提供正常的服务，那为了解决这个问题，我们可以引入一个东西，叫注册中心，当我们的商品服务，欸，这个机器一上线以后，他把他的这个服务呢，注册到注册中心去，相当于告知注册中心，欸，我这个B机器呢，上线了，我们把这个过程呢，就叫服务注册，他把他的服务注册到注册中心，这样呢三台机器如果都上线了，他们呢，都会在注册中心中，注册这个服务，相当于告诉注册中心，商品服务在1号机器，商品服务2号机器，商品服务3号机器，这三个机器都有，那么当我们这个A服务想要调用B服务的时候，可以怎么办呢，可以先去注册中心，发现一下，欸，我们把这个过程呢，叫服务发现，先去看一下我们的商品服务在哪些机器都有，发现呢在123号机器呢都有，都有以后呢，他可以随机选择一个进行调用，可以根据一些负载均衡算法，当某一个服务下线了以后，注册中心也能实时感知到，当A服务想要再来调B服务的时候，它问注册中心，这个B服务，到底在哪有呢，其实现在呢，已经剩1号服务器跟2号服务器了，这样呢，就可以避免调用不可用的服务，那我们把这个过程就叫，服务的注册发现，服务呢一上线，把它注册到注册中心，别人呢想要调查，从注册中心中进行发现别的服务，而我们整个维护，哪些服务在哪些机器，相当维护这个清单的这个，我们就叫注册中心。

同样呢，有一个概念叫配置中心。

我们来想象一个场景，当我们项目拆分成各个微服务以后呢，最终每一个服务啊可能都有大量的这个配置，而且呢每一个服务都可能部署在多台机器上，比如我们A服务在三台机器上都有，B服务在三台机器上都有，而且呢我们现在需要变更配置，比如A服务里边呢，有一个配置改掉了，我们想让全部机器都能用到最新配置，我们就得把这三台机器的所有A服务先让它下线，然后呢我们把新改好的A让它重新给每一台服务器上，都部署上来，这样呢就做好了，那么如果我们项目非常大，我们服务在几百台机器都有，那我们这么来改肯定很麻烦，那我们呢可以做一个东西叫，配置中心，让每一个服务呢，都从配置中心中，自动获取他自己的配置，这样呢如果我们想要改我们每一个服务的配置，我们只需要在配置中心改一处，那么A服务的这三台机器，从配置中心自动获取到新改的值，而我们这个配置呢，就动态的修改了，相当于呢配置中心，可以帮我们集中的管理微服务的配置信息，我们实现改一处配置，各个微服务呢，都自动的改掉。

接下来呢我们来说一下服务的熔断和降级。

    那么什么是熔断降级呢，我们先来考虑一件事情，首先在我们微服务的架构中，微服务之间是通过网络通信的，比如我们订单服务，他在A机器，商品服务呢在B机器，库存服务呢在C机器，如果我们想要下单，那么我们A机器呢就要给B机器发请求，去来查订单里面的商品。包括呢，这个商品还要去给C机器去来发请求，查当前商品有没有库存，整个结束以后呢，下单操作，才能完成。

但是呢，网络通信有不可靠和稳定性，假设呢，我们这个库存服务宕机了，或者呢他的这个网络通信慢了，得三秒五秒十秒呢才能反馈，那会出现什么事情，当我们这个库存服务出现了故障，导致响应慢，那我们这个商品服务呢，就得在这等，可能等到十秒以后，库存服务呢才能响应。也又说我们这个库存服务不可用，导致了我们商品服务在这阻塞，那么商品服务在这儿等的期间呢，那我们订单服务也得在这阻塞，相当呢，一个服务不可用，导致整个服务调用量在这一直阻塞，那这样呢如果是高并发请求，第一个请求进来是要调这一串服务，那么在这阻塞住十秒还不出结果，那么第二个请求进来一直在这阻塞住十秒，那么更多的请求进来，就导致了请求积压，全部都阻塞在这，最终会导致，我们整个服务器的资源耗尽，一个服务的不可用，导致服务器资源耗尽，所有服务均不可用，导致我们整个服务的雪崩现象。

那么基于这个现象呢，我们就可以衍生出服务的熔断和降级。 

那什么是熔断呢，比如我们来举一个例子，当我们商品服务，想要调用库存服务的时候，库存服务经常超时那怎么办呢，我给他指定一个超时时间，比如三秒，只要你三秒库存服务没返回，我就认为你库存服务超时，失败了，那接下来怎么办呢，如果经常库存服务失败，当失败达到某个阈值，比如十秒内100个请求全失败了，那咋办呢，就可以开启断路保护机制，下一个请求进来了那我直接给你不去调用库存服务了，因为上一次百分之百的错误都出现了，那我们直接在此中断。我们呢，商品服务直接返回，比如反回一些默认数据，比如默认有库存，或者直接返回库存查出来的结果是null，或者等等等等。我们可以本地直接返回默认数据，而不用去调用远程的护送服务，这样就不会导致请求积压，第一个请求进来，第二个请求进来，他们都调用失败了，比如达到我们指定的阈值了，两个请求都失败了，我们开启了断路器，第三个请求一进来，我们呢商品服务不用掉库存服务了，直接会返回， 所以呢我们这个请求，就会被很快的处理结束，就不会有请求积压的现象，那么，就不会导致整个服务血崩的现象，这是我们说的服务熔断，相当我们开启断路保护机制。

当然，还有服务的降级，这降级呢跟熔断稍微有点区别，降级是整体把控，比如在我们运维期间，我们现在呢，系统压力很大，资源紧张，我们可以呢，让一些非核心业务，假设啊，假设这个是非核心业务，我们直接把这个非核心业务给他降级运行，所谓的降级运行就是指，比如我们这个业务给他停机，也就是说不处理，或者呢，简单处理，我们这个业务呢，使用降级方法运行，我们呢可以直接你请求我的时候，我给你返回异常或者返回null，我也不查数据库了，不怎么做了，我给你快速返回。这都是一些降级处理的手段。这就是我们说的，服务的熔断和降级，当然更多的细节呢，我们还要在开发中，来慢慢完善。

接下来呢我们来说一下，API网关。

API网关是我们微服务架构中非常重要的一个组件。特别是呢，我们这个项目是前后分离开发，前端呢是给后台发送HTTP请求的方式，来完成各种各样的功能，那么呢我们就希望，前台来发来的所有请求，都先到达一个地方，就叫网关，这个网关呢，可以对我们的所有请求，进行一个统一认证，比如看一下哪些请求是合法的，哪些是非法的，包括呢，还可以进行限流，包括服务熔断，负载均衡，等等，各种操作，网关呢，就像是我们大商场的一个安检入口，唯一入口，我们从这个入口呢，进来，能放行过来的请求，就是后台需要处理的，那么放行不过来的请求，后台也无需处理，包括在高并发的情况下，我们可以在网关级别，对它进行一个限流，流控，那么，比如以恒定的速率将请求，流向我们的后台服务集群，这样呢，我们服务集群就不会收到瞬时过大的请求流量进来把我们的服务器集群压垮，以上呢，就是我们分布式系统中的一些基本概念。当然这些概念呢，我们在不断的开发中，进行完善和深入，大家先有一个基本的了解，这样呢，我们就可以在下一节课，来给大家简单的解释一下微服务的一些架构图和我们的服务划分图。

04、简介-项目微服务架构图

上一节课，我们了解了分布式里边的一些基础概念，那么接下来呢，我们就基于这些概念，来看一下我们整个项目的微服务架构图，这里呢我们有一张高清版本的架构图，来 给大家点开，好，这个架构图呢就解释了我们整个项目的技术架构以及技术组合方案，但，只有大家完整的做完我们整个项目，才会有一个深刻的理解。

但是呢，我们可以先来简单的看一下我们整个架构图，如果接下来听不懂，也很正常，这些都是我们后来将要学习的技术。

首先，我们说，我们这个项目呢，是前后分离开发，我们分为内网部署和外网部署，外网也就是面向公众访问的，来部署我们的前端项目，可以由手机APP，当也可以由电脑的web网站，而内网部署的,是我们整个后台的服务集群，公众呢,是通过使用我们的客户端，来完成相应的功能，比如登录,注册,等都要通过客户端,给我们后台的这些服务来发送请求。当然呢请求不是直接过来的，所以我们完整的请求流程，应该是这样子的。

首先，通过任意客户端，给我们这发请求。请求呢，先来到我们的Nginx集群。当然，这一块儿呢，我们暂时先不用改，Nginx呢，将我们把请求转交给我们的后台服务。当然也不是直接转给我们制定的后台服务。Nginx呢会将所有的请求， 先转交给我们的API网关。

那么API网关呢，我们使用Spring Cloud Gateway,那网关可以完成什么功能呢,比如网关可以根据当前请求,动态的路由到指定的服务,看当前请求,是想要调用商品服务呢，还是购物车服务，还是检索等等等等等，等路由过来的时候呢，如果我们某一个服务众多，比如我们当前请求，是来查询商品的，商品呢在三个服务里边，都有咱们这个商品服务，那我们网关呢，还可以负载均衡的，去来调用商品服务，当然，当某些服务出现问题，我们也可以在网关这个级别，来对服务做统一的熔断和降级。那么这个熔断降级呢，我们使用Spring Cloud Alibaba提供的Sentinel这个组件，当然我们网关还有其他的功能，比如认证授权，请求过来以后呢，看是否合法，合法了再放行过去，包括呢，我们网关还可以进行限流，也就是限制我们的是瞬时流量，比如当前100万个请求同时进来了，我们害怕把所有的请求放过去，把整个后台服务压垮，那我们可以在网关处进行限流，流量控制，我们只给他放行1万个过去，那 让我们的后台业务集群，能很容易的处理完这些请求。

当然这些东西呢，我们后来，都会说，我们呢都是使用Spring Cloud Alibaba提供的Sentinel组件，来完成我们的限流、熔断、以及降级工作，当我们的请求，通过网关最终到达我们这个服务以后呢，我们服务就进行处理。

当然我们这些服务呢，都是使用Spring Boot来写的，一个个的微服务，但服务与服务之间，有可能会互相调用，比如下订单的时候，我们要调商品服务，来查询商品的一些信息，那我们使用的是Spring Cloud 的feign组件,而且呢,有些请求可能需要登录以后才能处理。

所以呢，我们专门还有一个，基于OAuth2.0的认证中心，我们除了有一般的登录，我们还整合了基于OAuth2.0的这些社交登录，那么整个应用里边的，安全以及权限控制，我们都是用Spring security来进行控制。特别是呢,我们这些服务要保存一些数据,或者呢我们要使用缓存等等，那我们缓存呢，使用的是我们Redis的集群，可以是分片集群，加上哨兵集群。

但我们 持久化存储数据，使用我们的MYSQL集群，我们可以做成读写分离， 也可以最终做分库分表，包括呢，我们服务跟服务之间，我们后来还会使用消息队列来进行异步解耦，包括完成分布式事务的最终一致性，那 我们使用的是整个集群来做我们的消息队列，包括呢，我们有些服务，比如检索，全文检索，检索一些商品信息，我们使用ElasticSearch，而且呢，我们有些服务在运行期间，可能要存取一些图片、视频等。我们使用的是阿里云的对象 存储服务，那这一块呢，就是我们整个服务关于数据存储相关的解决方案，包括在项目上线以后，我们为了快速定位项目中可能出现的一些问题，我们使用ELK来对日志进行相关的处理，也就是使用LogStash来收集我们业务里边的各种日志,把它呢,存储到ES中,然后再使用Kibana可视化界面,从ES中,检索出相关的日志信息，帮我们快速定位线上问题的所在。

接下来呢,我们再来看上面这些内容，首先我们说，在分布式系统中，由于我们每一个服务，都可能部署在很多台机器，而且服务跟服务之间，要互相调用，那么就得知道，彼此都在哪里，那么我们就推荐呢，将所有的服务都需要注册到注册中心，然后呢别的服务，可以从注册中心中，去来发现其它服务所在的位置。所以呢我们使用 Spring Cloud Alibaba、Nacos来作为我们服务的注册中心。

同样的，每一个服务的配置众多，我们后来要集中管理这些配置，实现呢改一处配置，这些服务呢都来自动修改掉。那我们需要一个配置中心， 我们也使用Spring Cloud Alibaba提供的Nacos作为我们的配置中心,我们的所有的服务呢,都可以从配置中心中,动态获取它的配置。

包括服务在调用期间,可能会出现一个问题,比如我们下订单服务,调用商品服务,商品服务再调用库存服务，可能呢，某一个链路出现了问题，我们呢就得追踪我们整个服务调用面，看哪里出现了问题，那 哪一块问题该怎么解决等等，那我们呢，可以使用服务追踪，那服务追踪呢，我们使用Spring Cloud提供的Sleuth加Zipkin,把我们每一个服务的这些信息，然后呢交给我们的开源的Prometheus进行聚合分析,再有Grafana进行可视化展示,通过Prometheus提供的Altermanager,我们实时的，得到我们一些服务的告警信息，把这个告警信息呢，可以以邮件或者手机短信的方式，通知我们的开发或者运维人员。

而且我们还提供了持续集成和持续部署，比如说我们项目发布起来呢，由于我们微服务众多，每一个都打包部署到服务器，太麻烦，那 有了持续集成，我们开发人员呢，可以将我们修改后的代码，提交给Github。然后呢我们的运维人员,可以通过自动化工具JenKins,然后呢从Github中获取的代码,将它打包成Docker镜像,最终呢,我们使用K8S来集成我们整个Docker服务,我们将服务呢,以Docker容器的方式来运行。

以上呢就是我们整个项目的微服务架构图，可能大家现在呢，满脸期待又一脸无助，没关系，除了Spring Boot、MYSQL、以及Redis,我什么都不讲,直接使用外,剩下的，所有牵扯到的技术，以及环境，我们都会在项目中一一讲解和搭建。
 

05、简介-项目微服务划分图

前面呢，我们看了一下，项目的微服务架构图，那么，基于这张图呢，我们再来说一下，我们的微服务的划分图。

那这个微服务划分图呢，他就反映了，我们整个谷粒商城里边，需要创建的一些微服务，以及相关的技术组合，那么，这个划分图呢，给大家有一个高清的版本，在我们的这个PPT里边，打开这个PPT，我们来看一下我们这个微服划分图。

首先呢，我们这个项目是基于前后分离的开发，所以呢，我们需要创建一些前端项目，而前端项目呢，我们分为这么几个。

首先，admin-vue是面向工作人员使用的后台管理系统，shop-vue是面向我们公众访问的WEB网站系统，当然我们也可以有手机的app,以及小程序等等，那这两个呢就先不管了.

那首先呢，我们请求会由前端，通过网关到达我们的业务的微服务群，当然，我们这个网关呢，还可以完成一些预先的工作，比如限流、鉴权、熔断、降级等等等等等。等请求到达我们这个业务微服务群以后呢，我们这些业务就进行处理，而我们这些业务呢，主要分为我列举的，以下这些业务。当然，可能有更多的业务，那我们列举了这些业务呢，就是我们后来需要编写的业务。

首先呢，我们这有商品服务，包含我们对商品的一些增删改查，以及商品的上下架，商品详情等等。

还有呢，我们的支付服务，那么支付服务里边呢，就集成了我们支付的功能、

包括呢，优惠服务，有我们商品相关的一些优惠信息，整个微服务。

还有呢我们的用户服务，比如我们要完成用户的一些个人中心 、用户的收货地址列表维护等等。

当然还有我们的仓储服务，我们每一个商品库存都有多少，存在哪个仓库。

还有呢，我们的秒杀服务，诶我们专门为秒杀呢，也创建一个服务。

包括呢，我们的订单服务，完成我们订单相关的功能，订单的一些增删改查，用户订单的列表等等。

还有我们的检索服务，主要完成我们商品的检索，我们商品的复杂检索，而且呢检索，我们是使用elastic来做全文检索功能。

包括呢,由我们的中央认证服务,也就是它来进行我们的登录、注册。包括呢，我们统一的单点登录功能，以及社交登录功能等等。

还有我们的购物车服务，比如我们商城的一些购物车的，商品的增删改查，包括购物车的结账等等功能，我们都在购物车服务里边。

还有我们独立的后台管理系统，那么我们想要通过后台，来添加一些优惠信息，或者新增一些商品等等等等，那我们呢后台管理系统，也是呢，是给其他服务来发送相应的请求。

这些呢，就是我们将要编写的，这些微服务，当然我们这些服务运行期间，可能还要依赖一些第三方的服务， 比如物流信息的检索，短信的发送，包括呢，我们金融相关的支付、退款、对账等等，包括呢，我们用户的一些身份认证，之所以呢，将他们称为第三方服务，是因为这些服务呢都不是我们编写的，是一些第三方的组织公司等等，帮我们写好，我们只需要进行调用即可。

当然在我们这众多微服运行期间，如何把他们治理好，让他们有条不紊的健壮的运行起来，那我们需要搭配这些技术，比如使用Nacos作为注册中心以及配置中心。使用Seata来做分布式事务的解决,包括使用Sentinel来进行服务的容错、降级、包括限流等等，那么这三个组件呢，这都是Spring Cloud Alibaba为我们提供的组件。当然，我们服务调用期间牵扯到的远程调用，我们使用Feign,包括呢，我们也用了Gateway作为一篇网关,包括我们使用Sleuth加Zipkin来做服务的可视化追踪,那以上这四个组件呢,这都是SpringCloud为我们提供的组件。包括呢，我们整个应用的状态监控信息，来 我们使用Prometheus和Grafana。

这些呢。就是我们使用微服进行分布式开发期间，需要牵扯到的一些周边的配套设施，当然我们整个微服务的数据支撑层，使用Redis作为缓存，使用MySQL来完成我们持久化操作，包括呢，我们后来还会使用ShardingSphere这个组件,来对MySQL完成分库、分表操作，包括使用RabbitMQ来做消息队列，使用elastic来做全文检索，使用阿里云的对象存储，来存储我们的图片、视频等等相关的静态文件，那么接下来呢，我们就应该按照我们的微服务划分图，搭建好我们的开发环境，创建好一个个的微服务，并使用相关的技术，来进行我们整个电商项目的开发。