超级会员免费看
目录
好，接下来呢，我们一起来看一下我们整个项目的微服务架构图和微服务划分图。
注：当然想要看懂这两个图之前，我们需要大家，对微服务以及分布式系统里边的一些基础概念，有一个简单了解。（先看第三点）
一、微服务架构图
二、微服务划分图
三、分布式基础概念
当然想要看懂这两个图之前，我们需要大家，对微服务以及分布式系统里边的一些基础概念，有一个简单了解。
好，我们先来回顾一下，什么叫微服务呢？
其实简而言之一句话，我们微服务就是拒绝大型单体应用，我们以前，将所有的代码页面，包括 sql 语句等等，全写在一个应用里边儿。
这样容易导致一个最大问题，如果有一处代码出现了问题，可能导致我们整个应用不可用。
那我们就希望呢，把我们这个大型的单体应用，可以基于业务边界，对他进行服务的规划和拆分。
我们将一个大的单体应用，拆成各个不同的小模块，每个小模块呢，我们就可以成为一个微服务。这些模块合起来，最终完成一个单体应用。
而这些各个微服务呢，他们却是独立部署运行的，说如果有一个出现了问题，我们希望不能影响其他服务的正常运行。
也就是说微服务是一种非常流行的架构风格，他将我们这些大应用拆分成小服务以后呢，我们各个小服务都运行在自己的进程中，也就是互相隔离。
但是呢，微服务之间也要进行通信，比如我们订单服务想要去商品服务查询一些商品信息。那么我们推荐呢，我们微服务啊，
可以走 HTTP API 的形式，也就是说从订单服务给商品服务发一个请求，把商品信息要过来就行了，这就是我们说的微服务。
1、微服务
微服务架构风格，就像是把一个 单独的应用程序 开发成一套小服务，每个 小服务 运行在 自己的进程 中，
并使用轻量级机制通信，通常是 HTTP API 。
这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。这些服务使用不同的编程语言书写，
以及不同数据存储技术，并保持最低限度的集中式管理。
简而言之，拒绝大型单体应用，基于业务边界进行服务微化拆分，每个服务独立部署运行。
那微服务在极端情况呢，可能长着一个这样子的一个大型应用，拆分成了好多微服务，每一个小方块呢，都是一个小服务，
这服务之间的调用关系网非常复杂。这就对我们的开发、部署和运维带来了极大的挑战，但这些挑战才是我们真正能学到的技术。
2、集群&分布式&节点
什么是集群、分布式以及节点？
接下来呢，来说一下什么是集群、分布式以及节点。
集群
那我们所说的集群呢，他其实是一个物理形态，而分布式呢，是一种工作方式。
也就是说只要是一堆机器合起来，我们就叫做集群。 但这一堆机器呢，是合起来做一件事情，还是各自做各自的，我们谁也不知道。
分布式
而对于分布式系统的定义，可以参照这本书《分布式系统原理与范型》，他是这样说的，分布式系统是若干独立计算机的集合，
也就是说有这么一堆计算机的集群，你可以称为集群，它合起来呢，为我们提供一个服务，而这些计算机对于用户来说像是使用单个系统，
而用户没有感受到在使用这一堆计算机，而是感受到他在使用一个系统。
比如举一个例子，京东，我们用户在购物的时候，敲 WWW点京东，进入京东的网站，完成整个购物流程。
我们没有感受到，京东网站后边有多少台服务器。因为京东它是一个分布式的系统，它的各个业务是运行在不同的机器上的，
这机器是合起来完成整个京东的功能。
所以说呢，我们这些服务啊，我们就可以把它称为一个大型的业务集群。
而且呢，每一个小的服务，比如京东里边呢，有一个叫用户服务。
用户服务呢，我们每天登录注册，登录注册可能并发量很大，访问压力大的时候呢，一台服务器肯定不够。
那京东，可以让用户服务就这一个服务，那十台机器一起来运行呢，你随便访问哪台都行，那这样的话呢，我们整个这个用户服务，
它又是做了一个集群化处理。
节点
通过这个简单的概念呢，我们可以理解一句话，分布式中的每一个节点，什么叫节点呢？就是分布式中的每一个服务器。
它都可以做集群，什么意思呢？
比如我们这个用户服务，它在这个服务器上，压力大的时候呢，我们可以把它做成集群。我们十台服务器同时来跑这个用户服务。
集群并不一定是分布式的
而集群呢，并不一定是分布式的。比如我们这个用户服务，这十台服务器都是用户服务，它是不是一个分布式的呢？不是
整个京东系统才是分布式的。
因为这个系统的各个业务运行在各个不同的地方，它们是以分布式的工作方式，
也就是说，各个工作，各自的合起来，完成一个完整的系统，这叫分布式的工作方式。
也就是说，分布式是将不同的业务，分布在不同的地方。比如京东各个业务呢，在各个不同的服务器有购物车、订单、商品，
而集群呢，指的是几台服务器集中一起实现同一业务。
比如我们这个购物车，一台服务器不够，我放十台服务器，那么他们呢，这十台服务器，都是去实现购物车业务，他们是实现同一业务。
集群是个物理状态，分布式是个工作方式
只要是一堆机器，也可以叫做集群，他们是不是一起协作干活，这谁也不知道。
《分布式系统原理与范型》定义：
“分布式系统是若干独立计算机的集合，这些计算机对于用户来说像单个相关系统”
分布式系统 (distributed system) 是建立网络之上的软件系统
分布式 是指将不同的业务分布在不同的地方
集群 指的是将几台服务器集中在一起，实现同一业务
例如：京东是一个分布式系统，众多业务运行在不同的机器上，所有业务构成一个大型的分布式业务集群，
每一个小的业务，比如用户系统，访问压力大的时候一台服务器是不够的，我们就应该将用户系统部署到多个服务器，
也就是每一个业务系统也可以做集群化；
分布式中的每一个节点，都可以做集群。而集群并不一定就是分布式的
节点：集群中的一个服务器
3、远程调用
远程调用
接下来呢，我们再来说一下远程调用，那为什么会有远程调用呢？
我们说在分布式系统中各个服务，也就是我们拆分的各个功能模块，我们呢，以后将每一个小功能模块我们就称为服务，
那么各个服务呢，可能处于不同的主机。
比如我把购物车这个模块放在A机器，订单放在B机器，商品放在C机器。那么不可避免的服务之间，就要产生互相调用，
比如我们订单模块想要去商品模块查询一些商品信息，那怎么办呢？
我们把这个调用就称为远程调用。
SpringCloud推荐使用HTTP加Json的方式完成远程调用。
也就是说从订单模块给商品模块发一个HTTP请求，那么他们之间传递在网络间传递数据，可以把数据转成JSON的方式来进行网络传输。
这样做的好处：就是天然的跨平台性，JSON在任意平台都可以使用，包括HTTP请求，什么都可以兼容。
PHP系统、C++等都可以接收和发送HTTP请求。
在分布式系统中，各个服务可能处于不同主机，但是服务之间不可避免的需要互相调用，我们称为远程调用
SpringCloud 中使用 HTTP+JSON 的方式来完成远程调用
4、负载均衡
负载均衡
那么我们既然要远程调用，就不可避免地要牵扯一个东西叫负载均衡。
什么是负载均衡呢？
比如我们这个订单服务想要调用商品服务，查一些商品信息。
那么商品服务呢，我们之前说过，每一个在分布式系统中，每一个节点，我们都可以做成集群。
例如商品服务，这个压力很大，我们可以给三、五台机器，都让它来跑商品服务，
这样的话呢，我们订单服务，可以去任意一台机器都能查出商品信息。
那我们要怎么查出商品信息呢？我们就可以使用负载均衡。
比如说如果我有一次，第一次我去A这个服务器查商品信息了，第二次呢，A这个服务器人爆满了，
那我就可以去B这个服务器，第三次呢，我们也可以去别的服务器。
总之，负载均衡就是一句话，不要让任何一台服务器太忙，也不要让他太闲，
我们可以根据不同的均衡算法，来提升我们网站的健壮性。
轮询算法
比如我们常见的一些均衡算法，有轮询算法，也就是说第一次呢，我给A这个服务器发请求，获取商品详情，
那么第一次调用过了A服务器了，第二次呢，就轮到B服务器，第三次轮到C服务器，第四次呢又可能回来轮到A服务器。
这儿呢，是我们一个简单的负载均衡算法轮询。
最小连接
也可以用最小连接，比如呢，我优先选择看，哪个服务器它现在的连接数最少的，也就是压力最小的，
这样呢，我跟它建立起连接，这样呢，我们总能找到一个最闲的服务器，能更快的处理连接。
散列
当然我们还可以根据散列算法，也就是呢，同一个IP地址的请求，也就是同一个用户的请求，最终呢都会被负载均衡到同一个服务器。
分布式系统中，A 服务需要调用B服务，B服务在多台机器中都存在， A调用任意一个服务器均可完成功能。
为了使每一个服务器都不要太忙或者太闲，我们可以负载均衡的调用每一个服务器，提升网站的健壮性
常见的负载均衡算法：
轮询：为第一个请求，选择健康池中的，第一个后端服务器，然后按顺序往后依次选择，直到最后一个，然后循环。
最小连接：优先选择连接数最少，也就是压力最小的后端服务器。在会话较长的情况下，可以考虑采取这种方式
散列：根据请求源的 IP 的散列（hash）来选择要转发的服务器。这种方式一定程度上保证特定用户能连接到相同的服务器。
如果你的应用需要处理状态而要求用户能连接到和之前相同的服务器，可以 考虑采取这种方式。
也就是说同一个 ip 地址的请求，也就是同一个用户的请求，最终都会被负载均衡到同一个服务器。
5、服务注册/服务发现&注册中心
接下来呢，我们来说一下服务的注册发现以及注册中心。为什么要有这个呢？我们先来想象一个场景，
假设呢，这有一个a服务，就是我们的订单服务，还有一个B服务是我们的商品服务，
订单服务呢，想要调商品服务，来查询商品的详情。那商品服务呢，在这B1、B2、B3三台机器都有，
而且呢，这三台机器可能有些不稳定，有的时候呢，B1他下线了，有些时候呢，B2、B3这两个下线了，
我们也不知道哪台机器，现在能提供正常的服务，那为了解决这个问题，我们可以引入一个东西叫注册中心。
当我们的商品服务，这个机器上线以后，他把他的这个服务呢，注册到注册中心中去，相当于告知注册中心，
比如：我这个B1机器呢上线了，我们把这个过程呢，就叫服务注册。它把它的服务注册到注册中心。
这样呢，三台机器如果都上线了，他们呢都会在注册中心中，注册这个服务，相当于告诉注册中心商品服务在B1号机器，
商品服务在B2号机器，商品服务在B3号机器，这三个机器都有。
那么当我们这个A服务想要调用B服务的时候，可以怎么办呢？
步骤1:
可以先去注册中心发现一下，我们把这个过程呢叫服务发现。
步骤2：
先去看一下我们的商品服务在哪些机器都有？发现在B1、B2、B3号机器都有，
都有以后呢，注册中心它可以随机的选择一个进行调用，可以根据一些负载均衡算法。
当某一个服务（假如B3）下线了以后，注册中心也能实时感知到。当A服务想要再来调B服务的时候，
他问注册中心这个B服务到底在哪儿有呢？其实现在呢，已经剩B1号服务器，跟B2号服务器了，
这样呢，我们就可以避免调用不可用的B3服务，那我们把这个过程就叫服务的注册/发现
步骤3：
服务，一上线把它注册到注册中心。别人想要调他，从注册中心中进行发现服务。
而我们整个维护，哪些服务在哪些机器上，相当维护这个清单的，这个我们就叫注册中心。
A 服务调用 B 服务，A 服务并不知道 B 服务当前在哪几台服务器有，哪些正常，哪些服务已经下线。解决这个问题，可以引入注册中心；
后续维护服务也可通过注册中心的服务清单维护。
例如：
B服务在某一台服务器上上线时将服务注册进注册中心即为服务注册，
A服务通过注册中心发现某一台服务器上正常运行的B服务称为服务发现
如果某些服务下线，我们其他人可以实时的感知到其他服务的状态，从而避免调用不可用的服务。
6、配置中心
同样呢，有一个概念叫配置中心，来想象一个场景。当我们项目拆分成各个微服务以后呢，最终每一个服务啊，
可能都有大量的这个配置，而且呢，每一个服务都可能部署在多台机器上，
比如我们A服务在三台机器上都有这个配置，B服务在三台机器上都有这个配置，而且呢，我们现在需要变更配置，
比如说A服务里边呢，有一个配置改掉了，我们想让全部机器都能用到最新配置，
我们就得把这三台机器A1、A2、A3的所有A服务先让他下线，然后呢，把改新改好的A服务，
让他重新给每台服务器上都部署上来，这样呢就做好了。
那么如果我们项目非常大，我们服务在几百台机器都有，那我们这么来改，肯定很麻烦。
那我们呢，可以做一个东西叫配置中心，让每一个服务呢，都从配置中心中自动获取它自己的配置，
这样呢，如果我们想要改我们每一个服务的配置，我们只需要在配置中心改一处，
那么A服务的这三台机器，从配置中心自动获取到新改的值。我们这个配置呢，就动态的修改了，
相当于呢，配置中心可以帮我们集中的管理微服务的配置信息，我们实现改一处配置，各个微服务呢，都自动地改掉。
当一个服务在多台机器上运行时，一旦需要更改服务的配置，就需要将每一台机器下线并一 一更改其配置，
而借助配置中心后，我们可以让每个服务在配置中心自动获取自己的配置。
配置中心 用来集中管理微服务的配置信息
7、服务熔断&服务降级
接下来呢，我们来说一下服务的熔断和降级。那么什么是熔断降级呢？
我们先来考虑一件事情，首先在我们微服务的架构中，微服务之间是通过网络通信的，
比如我们订单服务，它在A机器，商品服务在B机器，库存服务在C机器，如果我们想要下单，
那么我们A机器呢，就要给B机器发请求，去查订单里边的商品，然后这个商品还要去给C机器去来发请求，
查当前商品有没有库存，整个结束以后呢，下单操作才能完成。
但是呢，网络通信有不可靠和不稳定性，假设呢，我们这个库存服务宕机了，或者呢，他的这个网络通信慢了，
得等三秒五秒，可能十秒呢才能返回。那会出现什么事情？
1、当我们这个库存服务出现了故障，导致响应慢！
2、那我们这个商品服务呢，就得在这儿等，可能等到十秒以后，库存服务呢才能响应。
也就是说我们这个库存服务的不可用，导致了我们商品服务在这儿阻塞，
3、那么商品服务在这儿等待期间呢，那我们订单服务也得在这儿阻塞，
相当于一个服务不可用，导致整个服务调用链在这儿一直阻塞。也就是说如下图：
那这样呢，如果是高并发请求，第一个请求进来是要调这一串服务（订单-->商品-->库存），
那么在这儿阻塞住十秒还不出结果，
那么第二个请求进来，也一直在这儿阻塞住十秒，
那么更多的请求进来，就导致了请求积压，全部都阻塞在这，最终会导致我们整个服务器的资源耗尽，
一个服务的不可用，导致服务器资源耗尽，所有服务均不可用，导致我们整个服务的雪崩现象。
那么基于这个现象呢，我们就可以引申出服务的熔断和降级。
在微服务架构中，微服务之间通过网络进行通信，存在相互依赖，当其中一个服务不可用时，
有可能会造成雪崩效应。要防止这样的情况，必须要有容错机制来保护服务。
1）服务熔断
那什么是熔断呢？
比如我们来举一个例子，当我们商品服务想要调用库存服务的时候，库存服务经常超时，那怎么办呢？
我给他指定一个超时时间，比如三秒。只要你三秒库存服务没返回，我就认为你库存服务超时，失败了！
接下来怎么办呢？
如果经常库存服务失败，当失败达到某个阈值，比如十秒内100个请求，全失败了，那咋办呢？
我们就可以开启断路保护机制，下一个请求进来了，那我直接给你，不去调用库存服务了，
因为上一次100%的错误都出现了，那我们直接在此中断！
我们的商品服务，直接返回，比如返回一些默认数据，比如默认有库存，
或者直接返回库存，查出来的结果是null或者等等等等，我们可以本地直接返回默认数据。
而不用去调用远程的库存服务，这样就不会导致请求积压！
第一个请求进来，第二个请求进来，他们都调用失败了，比如达到我们指定的阈值了，两个请求都失败了，
我们开启了断路器，第三个请求一进来，我们的商品服务不用调库存服务了，直接会返回。
所以呢，我们这个请求，就会很快的处理结束，就不会有请求积压的现象。
那么就不会导致整个服务雪崩的现象，这是我们说的服务熔断，相当于我们开启断路保护机制。
设置服务的超时，当被调用的服务经常失败，到达某个阈值，我们可以开启断路保护机制，
后来的请求不再去调用这个服务。本地直接返回默认的数据
2）服务降级
当然还有服务的降级，这个降级呢，跟熔断稍微有点区别，降级是整体把控，
比如在我们运维期间，我们现在呢，系统压力很大，资源紧张，我们可以呢让一些非核心业务。
假设某个模块是非核心业务，我们直接把这个非核心业务给他降级运行，
所谓的降级运行就是指：比如我们这个业务，给他停机，也就是说不处理，或者呢简单处理，
那么这个业务呢，使用降级方法运行，我们可以直接，在你请求我的时候，我给你返回异常或者返回null，
我也不查数据库了，也不怎么做操作处理了，我给你快速返回！这都是一些降级处理的手段。
这就是我们说的服务的熔断和降级。当然更多的细节呢，我们还需要在开发中来慢慢的完善。
在运维期间，当系统处于高峰期，系统资源紧张，我们可以让非核心业务降级运行，
降级：某些服务不处理，或者简单处理【抛异常，返回NULL，调用默认数据，调用 FallBack 处理逻辑】
8、API 网关
接下来呢，我们来说一下API网关，
API网关是我们微服务架构中非常重要的一个组件。特别是呢，我们这个项目是前后分离开发，前端呢是给后台发送HTTP请求的方式，
来完成各种各样的功能，那么呢，我们就希望前端来发来的所有请求，都先到达一个地方，就叫网关。
这个网关呢，可以对我们的所有请求，进行一个统一认证。比如看一下哪些请求是合法的，哪些是非法的，
包括呢还可以进行限流、包括服务熔断、负载均衡等等各种操作。
网关呢，就像是我们大商场的一个安检入口，唯一入口，我们从这个入口呢进来，能放行过来的请求，就是后台需要处理的。
那么放行不过来的请求后台也无需处理。包括在高并发的情况下，我们可以在网关级别，对它进行一个限流流控，
那么比如以恒定的速率，将请求留在我们的后台服务集群，这样呢，
我们服务集群就不会收到，瞬时过大的请求流量进来，把我们的服务集群压垮。
以上呢，就是我们分布式系统中的一些基本概念，当然这些概念呢，我们在不断的开发中进行完善和深入，
大家先有一个基本的了解，这样呢，我们就可以在下节课来给大家简单的解释一下，
我们微服务的一些架构图和我们的服务划分图。
在微服务架构中，API Gateway 作为整体架构的重要组件，它抽象了微服务中都需要的公共功能，
同时它提供了客户端负载均衡，服务自动熔断，灰度发布，统一认证，限流流控，日志统计等丰富功能，帮助我们解决很多API管理的难题
1175
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
