springCloud—微服务简介
微服务简介
- 1.系统架构演变
-
- 1.1. 集中式架构
- 1.2.垂直拆分
- 1.3.分布式服务
- 1.4.服务治理（SOA）
- 1.5.微服务
- 2.远程调用方式
-
- 2.1.认识RPC
- 2.2.认识HTTP
- 2.3.如何选择？
- 3.Spring Cloud简介
-
- 3.1.简介
- 3.2.版本
- 5 Eureka注册中心
-
- 5.1 Eureka简介
- 5.2.原理图
- 5.3 Eureka详解
-
- 5.3.1 基础架构
- 5.3.2 高可用的Eureka Server
- 6 负载均衡Ribbon
- 7 Hystrix
-
- 7.1 雪崩问题
- 7.2 线程隔离&服务降级
- 7.3 服务熔断
问：为什么要学习Spring Cloud
答：在项目开发中随着业务越来越多，导致功能之间耦合性高、开发效率低、系统运行缓慢难以维护、不稳定。微服务 架构可以解决这些问题，而Spring Cloud是微服务架构最流行的实现
1.系统架构演变
随着互联网的发展，网站应用的规模不断扩大，需求的激增，随之而来的是技术上的压力。系统架构也因此不断的 演进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构。
1.1. 集中式架构
当网站流量很小时，只需要一个应用，将所有的功能都部署在一起，以减少部署节点和成本。
优点：
- 系统开发速度快
- 维护成本低
- 适用于并发要求较低的系统
缺点： - 代码耦合度高，后期维护困难
- 无法针对不同模块进行优化
- 无法水平扩展
- 单点容错率低，并发能力差
1.2.垂直拆分
当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分：
优点：
- 系统拆分实现了流量分担，解决了并发问题
- 可以针对不同模块进行优化
- 方便水平扩展，负载均衡，容错率提高
缺点： - 系统间相互独立，会有很多重复开发工作，影响开发效率
1.3.分布式服务
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。
优点：
- 将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率
缺点: - 系统间耦合度变高，调用关系错综复杂，难以维护
1.4.服务治理（SOA）
SOA（Service Oriented Architecture）面向服务的架构：它是一种设计方法，其中包含多个服务， 服务之间通过 相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调 用。
**SOA缺点：**每个供应商提供的ESB产品有偏差，自身实现较为复杂；应用服务粒度较大，ESB集成整合所有服务和 协议、数据转换使得运维、测试部署困难。所有服务都通过一个通路通信，直接降低了通信速度。
1.5.微服务
微服务架构是使用一套小服务来开发单个应用的方式或途径，每个服务基于单一业务能力构建，运行在自己的进程 中，并使用轻量级机制通信，通常是HTTP API，并能够通过自动化部署机制来独立部署。这些服务可以使用不同的 编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。 微服务结构图 ：
API Gateway网关是一个服务器，是系统的唯一入口。网关提供RESTful/HTTP的方式访问服务。而服务端通 过服务注册中心进行服务注册和管理。
微服务的特点：
- 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
- 面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言 无关，也不限定用什么技术实现，只要提供REST的接口即可。
- 自治：自治是说服务间互相独立，互不干扰
----团队独立：每个服务都是一个独立的开发团队。
----技术独立：因为是面向服务，提供REST接口，使用什么技术没有别人干涉
----前后端分离：采用前后端分离开发，提供统一REST接口，后端不用再为PC、移动段开发不同接口
----数据库分离：每个服务都使用自己的数据源
微服务和SOA比较：
| 功能 | SOA | 微服务 |
|---|---|---|
| 组件大小 | 大块业务逻辑 | 独任务或小块业务逻辑 |
| 耦合 | 通常松耦合 | 总是松耦合 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目标 | 确保应用能够交互操作 | 易维护、易扩展、更轻量级的交互 |
2.远程调用方式
无论是微服务还是SOA，都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？
常见的远程调用方式有以下几种:
(1)RPC：Remote Procedure Call远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度 快，效率高。早期的Web Service，现在热门的Dubbo，都是RPC的典型
(2)HTTP：HTTP其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信 基本都是采用HTTP协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。 现在热门的REST风格，就可以通过HTTP协议来实现。
2.1.认识RPC
RPC，即 Remote Procedure Call（远程过程调用），是一个计算机通信协议。 该协议允许运行于一台计算机的程 序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。说得通俗一点就是：A计算机提供一个 服务，B计算机可以像调用本地服务那样调用A计算机的服务。
RPC调用流程图：
2.2.认识HTTP
HTTP其实是一种网络传输协议，基于TCP，工作在应用层，规定了数据传输的格式。现在客户端浏览器与服务端通 信基本都是采用HTTP协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的提供和调用方 没有任何技术限定，自由灵活，更符合微服务理念。现在热门的REST风格，就可以通过HTTP协议来实现。
2.3.如何选择？
RPC的机制是根据语言的API（language API）来定义的，而不是根据基于网络的应用来定义的。如果你们公司全 部采用Java技术栈，那么使用Dubbo作为微服务架构是一个不错的选择。
相反，如果公司的技术栈多样化，而且你更青睐Spring家族，那么Spring Cloud搭建微服务是不二之选。会选择 Spring Cloud套件，因此会使用HTTP方式来实现服务间调用。
3.Spring Cloud简介
3.1.简介
Spring Cloud是Spring旗下的项目之一，官网地址：http://projects.spring.io/spring-cloud/
Spring最擅长的就是集成，把世界上最好的框架拿过来，集成到自己的项目中。
Spring Cloud也是一样，它将现在非常流行的一些技术整合到一起，实现了诸如：配置管理，服务发现，智能路 由，负载均衡，熔断器，控制总线，集群状态等等功能。其主要涉及的组件包括：
Netflix
- Eureka：注册中心
- Zuul：服务网关
- Ribbon：负载均衡
- Feign：服务调用
- Hystrix：熔断器
以上只是其中一部分，架构图：
3.2.版本
Spring Cloud的版本命名比较特殊，因为它不是一个组件，而是许多组件的集合，它的命名是以A到Z为首字母的一 些单词组成(其实是伦敦地铁站的名字)：
Spring Clound 和Spring Boot版本对应关系
| Release Train | Boot Version |
|---|---|
| Hoxton | 2.2.x |
| Greenwich | 2.1.x |
| Finchley | 2.0.x |
| Edgware | 1.5.x |
| Dalston | 1.5.x |
5 Eureka注册中心
5.1 Eureka简介
以网约车案例为切入点分析：
网约车出现以前，人们出门叫车只能叫出租车。一些私家车想做出租却没有资格，被称为黑车。而很多 人想要约车，但是无奈出租车太少，不方便。私家车很多却不敢拦，而且满大街的车，谁知道哪个才是愿意载人 的。一个想要，一个愿意给，就是缺少引子，缺乏管理啊。
此时滴滴这样的网约车平台出现了，所有想载客的私家车全部到滴滴注册，记录你的车型（服务类型），身份信息 （联系方式）。这样提供服务的私家车，在滴滴那里都能找到，一目了然。
此时要叫车的人，只需要打开APP，输入你的目的地，选择车型（服务类型），滴滴自动安排一个符合需求的车到 你面前，为你服务，完美！
那Eureka做什么？
Eureka就好比是滴滴，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉 Eureka，然后Eureka会把符合你需求的服务告诉你。
同时，服务提供方与Eureka之间通过 “心跳” 机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服 务列表中剔除。
这就实现了服务的自动注册、发现、状态监控。
5.2.原理图
基本架构：
- Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址 （Eureka是服务注册中心，只做服务注册；自身并不提供服务也不消费服务）
- 提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
- 消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
- 心跳(续约)：提供者定期通过HTTP方式向Eureka刷新自己的状态
工作原理图解析
5.3 Eureka详解
5.3.1 基础架构
Eureka架构中的三个核心角色：
- 服务注册中心
Eureka的服务端应用，提供服务注册和发现功能，就是刚刚我们建立的eureka-server - 服务提供者
提供服务的应用，可以是Spring Boot应用，也可以是其它任意技术实现，只要对外提供的是REST风格服务即 可。本例中就是我们实现的user-service - 服务消费者
消费应用从注册中心获取服务列表，从而得知每个服务方的信息，知道去哪里调用服务方。本例中就是我们 实现的consumer-demo
5.3.2 高可用的Eureka Server
Eureka Server即服务的注册中心，在刚才的案例中，我们只有一个EurekaServer，事实上EurekaServer也可以是 一个集群，形成高可用的Eureka中心 。
Eureka Server是一个web应用，可以启动多个实例（配置不同端口）保证Eureka Server的高可用
服务同步
多个Eureka Server之间也会互相注册为服务，当服务提供者注册到Eureka Server集群中的某个节点时，该节点会 把服务的信息同步给集群中的每个节点，从而实现数据同步。因此，无论客户端访问到Eureka Server集群中的任 意一个节点，都可以获取到完整的服务列表信息。
而作为客户端，需要把信息注册到每个Eureka中
所谓的高可用注册中心，其实就是把EurekaServer自己也作为一个服务进行注册，这样多个EurekaServer之间就 能互相发现对方，从而形成集群。
6 负载均衡Ribbon
1、通常所说的负载均衡都指的是服务端负载均衡，其中分为硬件负载均衡和软件负载均衡。
硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备，比如F5等；而软件负载均衡则是通过在服务器上安装一些具有负载均衡功能或模块的软件来完成请求分发工作，比如Nigix等。
2、硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备时，该设备按照某种算法（比如线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端的地址，然后进行转发。
3、客户端负载均衡和服务器负载均衡最大的不同点在于上面所提到的服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端的清单来自于服务注册中心。
7 Hystrix
主页：https://github.com/Netflix/Hystrix/
7.1 雪崩问题
Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务，防止出现级联失败。
微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用 链路：
如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。 如果此时，某个服务出 现异常：
例如： 微服务I 发生异常，请求阻塞，用户请求就不会得到响应，则tomcat的这个线程不会释放，于是越来越多的 用户请求到来，越来越多的线程会阻塞：
服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成 雪崩效应。
这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么 就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。 此时如果有很多个车型都需要这 个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大
Hystrix解决雪崩问题的手段，主要包括：
- 线程隔离
- 服务降级
7.2 线程隔离&服务降级
线程隔离示意图：
解读：
- Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队，加 速失败判定时间。
- 用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超 时，则会进行降级处理，什么是服务降级？
服务降级：可以优先保证核心服务。
用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回 友好的提示信息） 。
服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多会影响这个依赖服务对应的线程池中的资源，对其它 服务没有响应。 触发Hystrix服务降级的情况：
- 线程池已满
- 请求超时
7.3 服务熔断
在服务熔断中，使用的熔断器，也叫断路器，其英文单词为：Circuit Breaker 熔断机制与家里使用的电路熔断原理 类似；当如果电路发生短路的时候能立刻熔断电路，避免发生灾难。在分布式系统中应用服务熔断后；服务调用方 可以自己进行判断哪些服务反应慢或存在大量超时，可以针对这些服务进行主动熔断，防止整个系统被拖垮。
Hystrix的服务熔断机制，可以实现弹性容错；当服务请求情况好转之后，可以自动重连。通过断路的方式，将后续 请求直接拒绝，一段时间（默认5秒）之后允许部分请求通过，如果调用成功则回到断路器关闭状态，否则继续打 开，拒绝请求的服务。
Hystrix的熔断状态机模型：
状态机有3个状态：
- Closed：关闭状态（断路器关闭），所有请求都正常访问。
- Open：打开状态（断路器打开），所有请求都会被降级。Hystrix会对请求情况计数，当一定时间内失败请求 百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20 次。
- Half Open：半开状态，不是永久的，断路器打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半 开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进 行休眠计时
分析图：
