SpringCloud微服务学习基础知识（0）

一、背景

在从事java开发工作的路漫漫上，我们是披荆斩浪，不断学习，从Java的基础语法到工作项目上的各种框架，我们苦笑着知难而上，随着微服务的发展普及，掌握学习微服务是我们每个Java程序员必须掌握的知识，下面就跟着我一起搭建一下微服务项目吧。

二、知识准备

技术架构

Eureka + Springboot + OpenFeign + Hystrix + Gateway + Apollo + Zipkin + Sleuth

名词解释

Springboot

Springboot是Spring的一套快速配置脚手架，SpringCloud是基于SpringBoot实现的微服务架构开发组件，SpringCloud也需要对应SpringBoot的版本；Springboot专注于快速、方便集成的单个个体，SpringCloud是关注全局的服务治理框架；springboot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，SpringCloud很大的一部分是基于Springboot来实现。

Eureka

Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中，以实现SpringCloud的服务发现功能。

Eureka组件

Eureka包含两个组件：Eureka Server和Eureka Client。

Eureka Server

Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。

Eureka Server本身也是一个服务，默认情况下会自动注册到Eureka注册中心。
如果搭建单机版的Eureka Server注册中心，则需要配置取消Eureka Server的自动注册逻辑。毕竟当前服务注册到当前服务代表的注册中心中是一个说不通的逻辑。

Eureka Server通过Register、Get、Renew等接口提供服务的注册、发现和心跳检测等服务。

Eureka Client

Eureka Client是一个java客户端，用于简化与Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳,默认周期为30秒，如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。

Eureka Client分为两个角色，分别是：Application Service(Service Provider)和Application Client(Service Consumer)

Application Service
服务提供方，是注册到Eureka Server中的服务。

Application Client
服务消费方，通过Eureka Server发现服务，并消费。
在这里，Application Service和Application Client不是绝对上的定义，因为Provider在提供服务的同时，也可以消费其他Provider提供的服务；Consumer在消费服务的同时，也可以提供对外服务。

Eureka Server架构原理简介

Register(服务注册)：把自己的IP和端口注册给Eureka。

Renew(服务续约)：发送心跳包，每30秒发送一次。告诉Eureka自己还活着。

Cancel(服务下线)：当provider关闭时会向Eureka发送消息，把自己从服务列表中删除。防止consumer调用到不存在的服务。

Get Registry(获取服务注册列表)：获取其他服务列表。

Replicate(集群中数据同步)：eureka集群中的数据复制与同步。

Make Remote Call(远程调用)：完成服务的远程调用。

Gateway

服务网关的作用在微服务框架中可以提供统一入口、鉴权校验、动态路由、降低耦合度的功能；Gateway本身就是基于webflux（webflux是一个非阻塞的web框架，类似springmvc）基础之上实现的，底层则使用了高性能的Reactor模式通信框架Netty；一套非阻塞的网络异步网关，是在Spring生态系统之上构建的API网关服务,基于Spring5，SpringBoot2和ProjectReactor等技术。Gateway旨在提供-种简单而有效的方式来对API进行路由， 以及提供一些强大的过滤器功能， 例如: 熔断、限流、重试等。

三要素

1. Route(路由)
   路由是构建网关的基本模块，它由ID，目标URI，一系列的断言和过滤器组成，如果断言为true则匹配该路由
2. Predicate(断言)
   判断请求的转发条件
3. Filter(过滤)
   指的是Spring框架中GatewayFilter的实例，使用过滤器，可以在请求被路由前或者之后对请求进行修改。

工作原理

1. 客户端向Spring Cloud Gateway发出请求,然后在Gateway Handler Mapping中找到与请求相匹配的路由，将其发送到Gateway web hander
2. Handler再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前( “pre” )或之后( “post” )执行业务逻辑。
3. Filter在"pre” 类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等,在"post"类型的过滤器中可以做响应内容、响应头的修改,日志的输出，流量监控等有着非常重要的作用。

Apollo

架构图

Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。

Apollo服务端基于Spring Boot 和 Spring Cloud 开发，因此对于Spring Cloud项目能够很好的结合。官方提供 Java 和 .NET 两种语言的不依赖任何框架的客户端，另外还提供了 API接口，便于其他语言或整合到自有框架中使用。

Apollo支持四个维度Key-Value格式的配置

Application(应用) 实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置。每个应用都有对应的身份标识–appId，需要在代码中配置

Environment(环境) 配置对应的环境，Apollo客户端需要知道当前应用出于哪个环境，，从而可以去获取应用的配置；环境和代码无关，同一份代码部署在不同的环境就应该获取不同环境的配置；环境默认是通过读取机器上的配置(server.properties的env属性)指定的

Cluster(集群) 一个应用下不同实例的分组，例如按照不同数据中心划分，把上海机房的实例分为一个集群、把深圳机房的实例分为一个集群；对于不同的Cluster，同一个配置可以有不一样的值；集群默认是通过读取机器上的配置指定的(server.properties的idc属性)

Namespace(命名空间) 一个应用下不同配置的分组，是配置项的集合，可以简单地把Namespace类别为(配置)文件，不同类型的配置存放在不同的文件中，例如数据库配置文件、RPC配置文件、应用自身的配置文件等；应用可以直接读取到公共组件的配置namespace，例如DAL、RPC等；应用也可以通过继承公共组件的配置namespace来对公共组件的配置做调整，如DAL的初始数据库连接数。

OpenFeign

OpenFeign是一种声明式、模板化的HTTP客户端。在SpringCloud中使用OpenFeign，可以做到使用HTTP请求访问远程服务，就像调用本地方法一样的，开发者完全感知不到这是在调用远程方法，更感知不到在访问HTTP请求。

Hystrix

Hystrix介绍：

1. 是用于处理延迟和容错的开源库。
2. 主要用于避免级联故障，提高系统弹性。
3. 解决了由于扇出导致的“雪崩效应”。
4. 的核心是“隔离”和“熔断机制”。

Hystrix主要作用：

1. 服务隔离和服务熔断
2. 服务降级、限流和快速失败
3. 请求合并和请求缓存
4. 自带单体和集群监控

设计模式
命令模式(Command Pattern)
命令模式 将客户端对服务直接调用，封装成一个待执行的请求，客户端和请求被封装为一个对象，对于服务方而言，每个不同的请求就是不同的参数，从而让我们可用不同的请求对客户进行参数化；命令模式的最大特征就是把客户端和服务端直接关系，通过命令对象进行解耦，在执行上，可以对请求排队或者记录请求日志，以及支持可撤销的操作。

线程池和信号量隔离
计算机系统中，线程作为系统运行的基本单位，可以通过划分指定的线程池资源的使用目的，对系统资源进行分离，具备资源限定的能力，进而保护系统；另外在Java中，Semaphore的信号量机制，也能提供资源竞争的隔离作用。
工作原理：

Sentinel

概述：Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

组成：
核心库（Java 客户端）： 不依赖任何框架 / 库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持
控制台（Dashboard）： 基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器

特征：
丰富的应用场景： Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷（对于突然到来的大量请求，您可以配置流控规则，以稳定的速度逐步处理这些请求，从而避免流量突刺造成系统负载过高）、集群流量控制、实时熔断下游不可用应用等

完备的实时监控： Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况

广泛的开源生态： Sentinel 提供开箱即用的与其它开源框架 / 库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel

完善的 SPI 扩展点： Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等

特性：

Zipkin

Zipkin 是 Twitter 的一个开源项目，它基于 Google Dapper 实现，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。 我们可以使用它来收集各个服务器上请求链路的跟踪数据，并通过它提供的 REST API 接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序，从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。除了面向开发的 API 接口之外，它也提供了方便的 UI 组件来帮助我们直观的搜索跟踪信息和分析请求链路明细，比如：可以查询某段时间内各用户请求的处理时间等。 Zipkin 提供了可插拔数据存储方式：In-Memory、MySql、Cassandra 以及 Elasticsearch。接下来的测试为方便直接采用 In-Memory 方式进行存储，生产推荐 Elasticsearch。

Zipkin 的基础架构，它主要由 4 个核心组件构成：

1. Collector：收集器组件，它主要用于处理从外部系统发送过来的跟踪信息，将这些信息转换为 Zipkin 内部处理的 Span 格式，以支持后续的存储、分析、展示等功能。
2. Storage：存储组件，它主要对处理收集器接收到的跟踪信息，默认会将这些信息存储在内存中，我们也可以修改此存储策略，通过使用其他存储组件将跟踪信息存储到数据库中。
3. RESTful API：API 组件，它主要用来提供外部访问接口。比如给客户端展示跟踪信息，或是外接系统访问以实现监控等。
4. Web UI：UI 组件，基于 API 组件实现的上层应用。通过 UI 组件用户可以方便而有直观地查询和分析跟踪信息。

Zipkin 分为两端，一个是 Zipkin 服务端，一个是 Zipkin 客户端，客户端也就是微服务的应用。 客户端会配置服务端的 URL 地址，一旦发生服务间的调用的时候，会被配置在微服务里面的 Sleuth 的监听器监听，并生成相应的 Trace 和 Span 信息发送给服务端。 发送的方式主要有两种，一种是 HTTP 报文的方式，还有一种是消息总线的方式如 RabbitMQ。

spring cloud sleuth主要功能就是在分布式系统中提供追踪解决方案，并兼容了zipkin，Zipkin是一个链路跟踪工具，可以用来监控微服务集群中调用链路的通畅情况。

三、开始搭建

此篇文章只作为基础知识的介绍，后面将对每一个模块进行服务搭建，喜欢的童鞋，请订阅我的Springcloud微服务学习篇哦，大家一起学习（免费的哦），有不对的地方请及时提出大家一起探讨学习。
下一篇: Eureka服务端搭建（1）.