could笔记

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	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	易维护、易扩展、更轻量级的交互

2.远程调用方式

无论是微服务还是SOA，都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？

常见的远程调用方式有以下几种：
RPC：Remote Procedure Call远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度 快，效率高。早期的Web Service，现在热门的Dubbo，都是RPC的典型。
HTTP：HTTP其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信 基本都是采用HTTP协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。 现在热门的REST风格，就可以通过HTTP协议来实现。

2.1.认识RPC

RPC，即 Remote Procedure Call（远程过程调用），是一个计算机通信协议。 该协议允许运行于一台计算机的程 序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。说得通俗一点就是：A计算机提供一个 服务，B计算机可以像调用本地服务那样调用A计算机的服务。

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	Release Train Boot Version
Hoxton	2.2.x
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

4.Eureka注册中心

4.1.Eureka简介

网约车

这就好比是网约车出现以前，人们出门叫车只能叫出租车。一些私家车想做出租却没有资格，被称为黑车。而很多 人想要约车，但是无奈出租车太少，不方便。私家车很多却不敢拦，而且满大街的车，谁知道哪个才是愿意载人 的。一个想要，一个愿意给，就是缺少引子，缺乏管理啊。
此时滴滴这样的网约车平台出现了，所有想载客的私家车全部到滴滴注册，记录你的车型（服务类型），身份信息 （联系方式）。这样提供服务的私家车，在滴滴那里都能找到，一目了然。
此时要叫车的人，只需要打开APP，输入你的目的地，选择车型（服务类型），滴滴自动安排一个符合需求的车到 你面前，为你服务，完美！

Eureka做什么？

Eureka就好比是滴滴，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉 Eureka，然后Eureka会把符合你需求的服务告诉你。
同时，服务提供方与Eureka之间通过 “心跳” 机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服 务列表中剔除。
这就实现了服务的自动注册、发现、状态监控。

4.2.原理图

Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
心跳(续约)：提供者定期通过HTTP方式向Eureka刷新自己的状态

5.负载均衡Ribbon

Ribbon是Netflix发布的负载均衡器,它有助于控制HTTP和TCP客户端的行为.为Ribbon配置服务提供者地址列表后,Ribbon就可基于某种负债均衡算法,自动地帮助服务消费者去请求.

提供相同服务的服务提供者通常有多个，形成集群，服务调用者要调取这种服务，那到底调取哪一个呢？Eureka中集成的负载均衡组件Ribbon提供了服务选用策略，Ribbon有很多负载均衡算法（即：服务选用策略），比如轮询、随机等，默认使用轮询。当然我们也可为Ribbon实现自定义的负载均衡算法.

6.Hystrix

主页:https://github.com/Netflix/Hystrix/

Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务，防止出现级联失败。

6.1.雪崩问题

微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用 链路：
如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。 如果此时，某个服务出现异常：

例如： 微服务I 发生异常，请求阻塞，用户请求就不会得到响应，则tomcat的这个线程不会释放，于是越来越多的 用户请求到来，越来越多的线程会阻塞：

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。
这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么 就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。 此时如果有很多个车型都需要这 个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大

Hystrix解决雪崩问题的手段，主要包括：
线程隔离
服务降级

6.2. 线程隔离&服务降级

6.2.1原理

线程隔离示意图

解读：
Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队，加 速失败判定时间。
用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超 时，则会进行降级处理.

服务降级：可以优先保证核心服务。
用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回 友好的提示信息） 服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多会影响这个依赖服务对应的线程池中的资源，对其它 服务没有响应。
触发Hystrix服务降级的情况：
线程池已满
请求超时

6.3 服务熔断

6.3.1熔断原理

在服务熔断中，使用的熔断器，也叫断路器，其英文单词为：Circuit Breaker 熔断机制与家里使用的电路熔断原理 类似；当如果电路发生短路的时候能立刻熔断电路，避免发生灾难。在分布式系统中应用服务熔断后；服务调用方 可以自己进行判断哪些服务反应慢或存在大量超时，可以针对这些服务进行主动熔断，防止整个系统被拖垮。 Hystrix的服务熔断机制，可以实现弹性容错；当服务请求情况好转之后，可以自动重连。通过断路的方式，将后续 请求直接拒绝，一段时间（默认5秒）之后允许部分请求通过，如果调用成功则回到断路器关闭状态，否则继续打 开，拒绝请求的服务。

Hystrix的熔断状态机模型：

状态机有3个状态：
Closed：关闭状态（断路器关闭），所有请求都正常访问。 Open：打开状态（断路器打开），所有请求都会被降级。Hystrix会对请求情况计数，当一定时间内失败请求 百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20 次。
Half Open：半开状态，不是永久的，断路器打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半 开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进 行休眠计时

分析图：

7.Feign

7.1.简介

为什么叫伪装？
Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等 等操作，一切都交给Feign去做。
项目主页：https://github.com/OpenFeign/feign

7.2.Feign的客户端

@FeignClient("user-service") 
public interface UserClient { 
//http://user-service/user/123 
@GetMapping("/user/{id}") 
User queryById(@PathVariable("id") Long id); 
}

首先这是一个接口，Feign会通过动态代理，帮我们生成实现类。这点跟Mybatis的mapper很像
@FeignClient ，声明这是一个Feign客户端，同时通过 value 属性指定服务名称
接口中的定义方法，完全采用SpringMVC的注解，Feign会根据注解帮我们生成URL，并访问获取结果
@GetMapping中的/user，请不要忘记；因为Feign需要拼接可访问的地址

7.3.负载均衡

Feign中本身已经集成了Ribbon依赖和自动配置：

因此不需要额外引入依赖，也不需要再注册 RestTemplate 对象。
Fegin内置的ribbon默认设置了请求超时时长，默认是1000，我们可以通过手动配置来修改这个超时时长：

ribbon: 
	ReadTimeout: 2000 # 读取超时时长 
	ConnectTimeout: 1000 # 建立链接的超时时长

7.4.Hystrix支持

Feign默认也有对Hystrix的集成：

只不过，默认情况下是关闭的。需要通过下面的参数来开启：

feign: 
	hystrix: 
		enabled: true # 开启Feign的熔断功能

但是，Feign中的Fallback配置不像Ribbon中那样简单了。需要自己编写一个类,作为fallback的处理类

8. Spring Cloud Gateway网关

8.1. 简介

Spring Cloud Gateway是Spring官网基于Spring 5.0、 Spring Boot 2.0、Project Reactor等技术开发的网关 服务。
Spring Cloud Gateway基于Filter链提供网关基本功能：安全、监控／埋点、限流等。
Spring Cloud Gateway为微服务架构提供简单、有效且统一的API路由管理方式。
Spring Cloud Gateway是替代Netflix Zuul的一套解决方案。

Spring Cloud Gateway组件的核心是一系列的过滤器，通过这些过滤器可以将客户端发送的请求转发（路由）到对 应的微服务。 Spring Cloud Gateway是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息， 从而加强安全保护。Spring Cloud Gateway本身也是一个微服务，需要注册到Eureka服务注册中心。
网关的核心功能是：过滤和路由

8.2 Gateway加入后的架构

不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都可经过网关，然后再 由网关来实现 鉴权、动态路由等等操作。Gateway就是我们服务的统一入口。

8.3. 核心概念

路由（route） 路由信息的组成：由一个ID、一个目的URL、一组断言工厂、一组Filter组成。如果路由断言 为真，说明请求URL和配置路由匹配。
断言（Predicate） Spring Cloud Gateway中的断言函数输入类型是Spring 5.0框架中的 ServerWebExchange。Spring Cloud Gateway的断言函数允许开发者去定义匹配来自于HTTP Request中的 任何信息比如请求头和参数。
过滤器（Filter） 一个标准的Spring WebFilter。 Spring Cloud Gateway中的Filter分为两种类型的Filter，分 别是Gateway Filter和Global Filter。过滤器Filter将会对请求和响应进行修改处理

9.Spring Cloud Config分布式配置中心

9.1.简介

在分布式系统中，由于服务数量非常多，配置文件分散在不同的微服务项目中，管理不方便。为了方便配置文件集 中管理，需要分布式配置中心组件。在Spring Cloud中，提供了Spring Cloud Config，它支持配置文件放在配置服 务的本地，也支持放在远程Git仓库（GitHub、码云）。

使用Spring Cloud Config配置中心后的架构如下图

9.2.Git配置管理

知名的Git远程仓库有国外的GitHub和国内的码云（gitee）；但是使用GitHub时，国内的用户经常遇到的问题是访 问速度太慢，有时候还会出现无法连接的情况。如果希望体验更好一些，可以使用国内的Git托管服务——码云 （gitee.com）。 与GitHub相比，码云也提供免费的Git仓库。此外，还集成了代码质量检测、项目演示等功能。 对于团队协作开发，码云还提供了项目管理、代码托管、文档管理的服务。

10.Spring Cloud Bus服务总线

10.1.问题

前面已经完成了将微服务中的配置文件集中存储在远程Git仓库，并且通过配置中心微服务从Git仓库拉取配置文 件， 当用户微服务启动时会连接配置中心获取配置信息从而启动用户微服务。 如果我们更新Git仓库中的配置文 件，那用户微服务是否可以及时接收到新的配置信息并更新呢

10.2.简介

Spring Cloud Bus是用轻量的消息代理将分布式的节点连接起来，可以用于广播配置文件的更改或者服务的监控管 理。也就是消息总线可以为微服务做监控，也可以实现应用程序之间相互通信。 Spring Cloud Bus可选的消息代理 有RabbitMQ和Kafka。

10.3.完整架构图