分布式、微服务、集群、节点、远程调用、负载均衡、注册中心、网关等

1 微服务：
    就是将单体应用拆开，微服务就是拒绝大型单体应用，基于业务边界进行服务微化拆分，各个服务独立部署运行 代码、页面、sql语句等等    写在一个应用里面，导致的问题，如果有一处代码出现问题会导致整个应用不可用； 就是希望把我们这个大型的单体应用基于业务边界对它进行服务的微化和拆分，每个小模块称为一个微服务，这些模块合起来最终完成一个单体应用；这些微服务它们各自是独立部署运行的；运行在各自自已的进程中； 如果有一个微服务出现了问题，不会影响其它服务的正常运行；所以微服务是一种流行的架构风格； 微服务之间要进行通信，常使用http api协议的请求；如订单服务调商品服务；一个大型应用拆分成了好多微服务，每一个就是一个小服务，服务之间的调用关系网非常复杂， 这就给微服务的开发、部署、运维带来了挑战，就是我们要解决的问题
2 集群：
    集群是物理形态，只要是一堆机器合起来就叫集群，这堆机器是合起来做一件事情还是各自做各自的谁也不知道；分布式是个工作方式，一堆计算机合起来是集群，这个集群为我们提供一个服务，对于用户来说相当于是一个计算机；如京东是一个分布式系统，它的各个业务是运行在不同机器上的，所有业务构成一个大型的业务集群。每个服务如用户登录注册服务访问压力大，一台机器不够，可以为这一个服务让10台机器一起来运行；即用户服务做了一个集群化处理；
3 分布式
    集群不一定是分布式的：比如这10台机器集群的服务都是用户服务，它不是分布式的，整个京东系统才是分布式的；因为这个系统的各个业务运行个各个不同的地方；是分布式的工作方式；    即各自工作各自的合起来完成一个完整的系统，这叫分布式的工作方式；说白了集群是一堆机器合起来叫集群；而分布式是一堆不同机器上的不业务合起来叫业务集群【分布式是将不同的业务分布在不同的地方】【集群是将几台服务器集中在一起实现同一业务】
4 节点：就是分布式中的每一个服务器；
5 远程调用：
    在分布式系统中，各个服务可能处于不同主机，服务之间可能需要互相调用，称为远程调用；
    springcloud中使用http+json的方式完成远程调用；
    如订单模块给商品模块发一个http请求，在网络间传递数据可以转成json格式传递；
    这样做的好处就是天然的跨平台，json在任意平台、各种请求中都可以使用；
6 负载均衡：
    比如订单调用商品服务，商品服务压力很大，弄10台机器都来跑商品服务，
    订单可以请求任意一台商品服务，获取商品信息就使用负载均衡。
    负载均衡就一句话，不要让任何一台服务器太忙或太闲；提升网站的健壮性；
7 负载均衡的算法：
    轮询算法：第一次给a商品服务器发请求，第二次给b商品发请求...
    最小连接算法：优选选择连接数最少的服务器；
    散列算法：即同一个ip地址的请求也就是同一个用户的请求最终都会被负载到同一台服务器；
8 服务注册/发现：
    如订单服务调商品服务：
    商品有3台服务，这3台服务可能不稳定，可能有时某一台下线了，我们不知道那台服务现在能正常的提供服务；为了解决这个问题引入了注册中心，当商品服务一上线，它就把它这个服务注册到注册中心；注册中心就知道商品服务在那几台机器；这个过程叫服务注册；当订单服务想要调用商品服务时，可以先去注册中心发现一下，这个过程叫服务发现；即先看一个商品服务在那些机器有；就可以避免服务不可用的服务的问题；即服务上线注册到注册中心，服务调用从注册中心中发现；维护哪些服务在那些机器的这个清单就叫注册中心；
9 配置中心：
    当项目拆分成各个微服务以后，每个服务可能都会有大量的配置，而且每一个服务都可能部署在多台机器上；我们要变更配置，让相同服务的机器都能是变更后的最终配置，不可能把每个服务都停了改好后再上线吧；所以引入了配置中心，让每一个服务都自动从配置中心获取配置；只需要在配置中心改配置，各服务会自动从配置中心获取配置；配置中心用来帮我们集中管理微服务的配置；实现改一处配置，各个微服务的配置都自动的改掉；
10服务熔断&服务降级：
    各服务在不同的机器，网络通讯不可靠，请求就一直在等，一个服务不可用导致整个服务调用链不可用；高并发则导致请求积压，服务器资源耗尽，雪崩； 微服务之间是通过网络通信的，如A区的服务设用B区的服务，B区的服务调用C区的服务最终返回给A区；但是网络不可靠、不稳定，假设B区调用C区，C区宕机了，B区调用就得在这儿等，即C区服务的不可用导致了B区服务的不可用，B区服务在这等着也导致了A区服务等着；即一个服务不可用导致整个服务调用链不可用，最终导致服务器资源耗尽所有资源均不可用；假设多个请求都是这种情况，最终会导致请求积压，最终导致服务器资源耗尽所有资源均不可用；基于这种情况就引入了服务熔断和服务降级；
11服务熔断/断路器：
    指定返回的超时时间，失败达到某个阀之，请求就直接返回，比如返回null;；防止请求积压；
    B区调用C区服务的时候经常超时，我们给它指定个时间如3秒，只要C区3秒没有返回就说明请求失败了；如果经常C区服务失败即C区3秒没有返回，当经常失败达到某个阈值，比如10次请求全失败，就可以开启断路保护机制；后来的请求再调用C区服务时直接终断返回，比如返回null;而不用去调用C区的服务，这种就不会导致请求积压；
12服务降级：
    非核心业务降级，业务停机或业务简单处理返回；
    系统运行压力大时，把一些非核心业务给它降级运行；
    降级：即你请求C区的服务时直接返回null或抛异常或调用fallback处理、或不查数据了等等
13 api网关：
    http请求先到达网关(统一认证，限流(如只放行1w个过去)，服务熔断)，各服务的唯一入口；
    一个个的微服务都是使用springboot写的；
14结论
    如前后端分离的项目，前端http请求的方式获取数据；
    前端发来的所有请求都先到达网关，网关可以对所有请求进行如统一认证(哪此是合法请求哪些是非法的)、
    限流流控/限流、服务熔断、负载均衡等各种操作；
    能放行过来的请求就是后台需要处理的，放行不过来的请求后台也不必处理；
    高并发的情况下可以在网关级别对它进行限流流控，比如可以以恒定的速度进来；就不会受到达大的请求流量进来把服务器压垮；