spring cloud

springcloud

一：springcloud-前言

1.微服务架构概念：简而言之，微服务架构就是将一个完整的应用从数据存储开始垂直拆分成多个不同的服务。每个服务都能独立部署、独立维护、独立扩展，服务与服务间通过诸如restfulapi的方式互相调用。即微服务是自治的服务单元。

2.springboot回顾：springboot让我们的spring应用变的更轻量化。具有如下优势：1.为所有spring开发者更快的入门2.开箱即用，提供各种默认配置来简化项目配置3.内嵌式容器简化web项目4.没有冗余代码生成和xml配置的要求

3.微服务架构进化服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务，而微服务在这个基础上要更彻底地去耦合，并且强调devops和快速演化。devops是英文development和operations的合体，他要求开发、测试、运维进行一体化的合作，进行更小、更频繁、更自动化的应用发布，以及围绕应用架构来构建基础设施的架构。

3.1.服务化之nginxnginx通过接受客户端http请求，根据路径配置，转发，跳转相应的服务。缺点：1.nginx配置中存在服务调用的逻辑2.服务消费者不知道，真正服务提供者的实例。3.服务提供者不易管理也正是以上的缺点，演变出dubbo

3.2.服务化之dubbodubbo是阿里开源的一个soa服务治理解决方案。服务消费者和提供者都可将服务信息注册到register，形成了服务中心的组件。通过monitor进行很好的服务管理，消费者可以进行负载均衡，服务降级等。缺点：1.致命的缺点-维护停止（阿里目前又着手维护）2.dubbo严重依赖于第三方组件（zookeeper／redis）3.由于dubbo的rpc调用，使得服务提供方与消费方有着代码层次的高强度耦合。

4.服务化之springcloudspringcloud提出是开发面向云端的application，为微服务提供了全套的组件技术支撑。值得注意的是：springcloud抛弃了dubbo的rpc通信，采用了基于http的rest方式通信。

4.1.springcloud的大家庭组成

服务治理：这是springcloud的核心。目前springcloud主要通过整合netflix的相关产品来实现这方面的功能（springcloudnetflix），包括用于服务注册和发现的eureka，调用断路器hystrix，调用端负载均衡ribbon，rest客户端feign，智能服务路由zuul，用于监控数据收集和展示的spectator、servo、atlas，用于配置读取的archaius和提供controller层reactive封装的rxjava。

分布式链路监控：springcloudsleuth提供了全自动、可配置的数据埋点，以收集微服务调用链路上的性能数据，并发送给zipkin进行存储、统计和展示。

消息组件：springcloudstream对于分布式消息的各种需求进行了抽象，包括发布订阅、分组消费、消息分片等功能，实现了微服务之间的异步通信。springcloudstream也集成了第三方的rabbitmq和apachekafka作为消息队列的实现。而springcloudbus基于springcloudstream，主要提供了服务间的事件通信（比如刷新配置）。

配置中心：基于springcloudnetflix和springcloudbus，spring又提供了springcloudconfig，实现了配置集中管理、动态刷新的配置中心概念。配置通过git或者简单文件来存储，支持加解密。

安全控制：springcloudsecurity基于oauth2这个开放网络的安全标准，提供了微服务环境下的单点登录、资源授权、令牌管理等功能。

命令行工具：springcloudcli提供了以命令行和脚本的方式来管理微服务及springcloud组件的方式。

二：sprintcloud服务发现与注册--eureka

1.选择eureka理由对于服务治理而言，核心部分就是服务发现与注册。一般常见的有zookeeper，而springcloud推荐使用的是eureka。因为在分布式系统中，有一个cap定理，即consistency（一致性）、availability（可用性）、partitiontolerance（分区容错性），三者不可得兼。zookeeper是hadoop的子项目，它的作用也多作为服务的发现与注册。zookeeper在cap定理中满足的cp，也就是一致性和分区容错性，但是它不能保证服务的可用性。比如，服务消费者通过注册列表获取数据时，倘若，zookeeper正在选主导致服务不可用，亦或者大多数服务宕机。在一般分布式系统的数据存储场景，数据一致性应该是首先被保证的。然而在服务发现的场景中，服务消费者能够消费才是首先保证的。

2.eureka组件eureka由多个instance(服务实例)组成，这些服务实例可以分为两种：eurekaserver和eurekaclient。为了便于理解，我们将eurekaclient再分为serviceprovider和serviceconsumer。eurekaserver：服务的注册中心，负责维护注册的服务列表。serviceprovider：服务提供方，作为一个eurekaclient，向eurekaserver做服务注册、续约和下线等操作，注册的主要数据包括服务名、机器ip、端口号、域名等等。serviceconsumer：服务消费方，作为一个eurekaclient，向eurekaserver获取serviceprovider的注册信息，并通过远程调用与serviceprovider进行通信。

2.1.eurekaservereurekaserver作为一个独立的部署单元，以restapi的形式为服务实例提供了注册、管理和查询等操作。同时，eurekaserver也为我们提供了可视化的监控页面，可以直观地看到各个eurekaserver当前的运行状态和所有已注册服务的情况。eurekaserver可以运行多个实例来构建集群，解决单点问题，与zookeeper不同的是，eureka的集群是peertopeer每个节点都是对等的，无主次之分，提高了服务的可用性。eurekaserver节点启动后，会首先尝试从邻近节点获取所有实例注册表信息，完成初始化。eurekaserver通过geteurekaserviceurls()方法获取所有的节点，并且会通过心跳续约的方式定期更新。默认配置下，如果eurekaserver在一定时间内没有接收到某个服务实例的心跳，eurekaserver将会注销该实例（默认为90秒，通过eureka.instance.lease-expiration-duration-in-seconds配置）。当eurekaserver节点在短时间内丢失过多的心跳时（比如发生了网络分区故障），那么这个节点就会进入自我保护模式。自我保护模式：默认配置下，如果eurekaserver每分钟收到心跳续约的数量低于一个阈值（instance的数量*(60/每个instance的心跳间隔秒数)*自我保护系数），并且持续15分钟，就会触发自我保护。在自我保护模式中，eurekaserver会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该eurekaserver节点就会自动退出自我保护模式。它的设计哲学前面提到过，那就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。该模式可以通过eureka.server.enable-self-preservation=false来禁用，同时eureka.instance.lease-renewal-interval-in-seconds可以用来更改心跳间隔，eureka.server.renewal-percent-threshold可以用来修改自我保护系数（默认0.85）。

2.2.eurekaclient2.2.1服务注册启动时，会调用服务注册方法，向eurekaserver注册自己的信息。eurekaserver会维护一个已注册服务的列表。当实例状态发生变化时（如自身检测认为down的时候），也会向eurekaserver更新自己的服务状态，同时用replicatetopeers()向其它eurekaserver节点做状态同步。

2.2.2续约与剔除服务实例启动后，会周期性地向eurekaserver发送心跳以续约自己的信息，避免自己的注册信息被剔除。续约的方式与服务注册基本一致：首先更新自身状态，再同步到其它peer。如果eurekaserver在一段时间内没有接收到某个微服务节点的心跳，eurekaserver将会注销该微服务节点（自我保护模式除外）。

2.2.3服务消费serviceconsumer本质上也是一个eurekaclient。它启动后，会从eurekaserver上获取所有实例的注册信息，包括ip地址、端口等，并缓存到本地。这些信息默认每30秒更新一次。前文提到过，如果与eurekaserver通信中断，serviceconsumer仍然可以通过本地缓存与serviceprovider通信。

2.3.eureka有三处缓存和一处延迟造成2.3.1eurekaserver对注册列表进行缓存，默认时间为30s。2.3.2eurekaclient对获取到的注册信息进行缓存，默认时间为30s。2.3.3ribbon会从上面提到的eurekaclient获取服务列表，将负载均衡后的结果缓存30s。

三：springcloud服务调用端负载均衡--ribbon

ribbon是netflix发布的开源项目，主要功能是为rest客户端实现负载均衡。常见的组件1.serverlist负载均衡使用的服务器列表。这个列表会缓存在负载均衡器中，并定期更新。当ribbon与eureka结合使用时，serverlist的实现类就是discoveryenabledniwsserverlist，它会保存eurekaserver中注册的服务实例表。2.serverlistfilter服务器列表过滤器。这是一个接口，主要用于对serviceconsumer获取到的服务器列表进行预过滤，过滤的结果也是serverlist。ribbon提供了多种过滤器的实现3.iping探测服务实例是否存活的策略。4.irule负载均衡策略，其实现类表述的策略包括：轮询、随机、根据响应时间加权等。5.iloadbalancer负载均衡器。这也是一个接口，ribbon为其提供了多个实现，比如zoneawareloadbalancer。6.restclient服务调用器。顾名思义，这就是负载均衡后，ribbon向serviceprovider发起rest请求的工具。

四：springcloud服务调用端熔断--hystrix“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（fallback），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。除了隔离依赖服务的调用以外，hystrix还提供了准实时的调用监控（hystrixdashboard），hystrix会持续地记录所有通过hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。

五：springcloud服务调用端代码抽象与封装--feignfeign是一个声明式的webservice客户端，它的目的就是让webservice调用更加简单。它整合了ribbon和hystrix，从而让我们不再需要显式地使用这两个组件。feign还提供了http请求的模板，通过编写简单的接口和插入注解，我们就可以定义好http请求的参数、格式、地址等信息。接下来，feign会完全代理http的请求，我们只需要像调用方法一样调用它就可以完成服务请求。

六：springcloud链路追踪--sleuthspringcloudsleuth可以结合zipkin，将信息发送到zipkin，利用zipkin的存储来存储信息，利用zipkinui来展示数据。1.提供链路追踪。通过sleuth可以很清楚的看出一个请求都经过了哪些服务。可以很方便的理清服务间的调用关系。2.可视化错误。对于程序未捕捉的异常，可以在zipkin界面上看到。3.分析耗时。通过sleuth可以很方便的看出每个采样请求的耗时，分析出哪些服务调用比较耗时。当服务调用的耗时随着请求量的增大而增大时，也可以对服务的扩容提供一定的提醒作用。4.优化链路。对于频繁地调用一个服务，或者并行地调用等，可以针对业务做一些优化措施

6.1术语：

span：最基本的工作单元。由spanid来标志。span也可以带有其他数据，例如：描述，时间戳，键值对标签，起始span的id，以及处理id（通常使用ip地址）等等。span有起始和结束，他们跟踪着时间信息。span应该都是成对出现的，所以一旦创建了一个span，那就必须在未来某个时间点结束它。起始的span通常被称为：rootspan。它的id通常也被作为一个跟踪记录的id。traceid：一个树结构的span集合。把相同traceid的span串起来。annotation：用于记录一个事件时间信息。cs：clientsend。客户端发送，一个span的开始cr：clientreceive。客户端接收。一个span的结束ss：serversend。服务器发送sr：serverreceive。服务器接收，开始处理。sr-cs和cr-ss:表示网络传输时长ss-sr:表示服务端处理请求的时长cr-cs:表示请求的响应时长

6.2采样率如果服务的流量很大，全部采集对存储压力比较大。这个时候可以设置采样率，sleuth可以通过设置spring.sleuth.sampler.percentage=0.1。不配置的话，默认采样率是0.1。也可以通过实现bean的方式来设置采样为全部采样(alwayssampler)或者不采样(neversampler)

七：springcloud路由转发--zuul微服务场景下，每一个微服务对外暴露了一组细粒度的服务。客户端的请求可能会涉及到一串的服务调用，如果将这些微服务都暴露给客户端，那么会增加客户端代码的复杂度。将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，那么整个服务只需要暴露一个api，对外屏蔽了服务端的实现细节，也减少了客户端与服务器的网络调用次数。这就是apigateway。有了apigateway之后，一些与业务关系并不大的通用处理逻辑可以从apigateway中剥离出来，apigateway仅仅负责服务的编排与结果的组装。

映射：1.url映射2.serviceid映射

zuul:routes:api-node1:path:/ribbon/**#指定路径serviceid:spring-cloud-ribbon-consumer#指定服务api-node2:path:/feign/**url:http://localhost:8766api-node3:path:/wap/**url:forward:/wap

cookie与头信息默认情况下，zuul在请求路由时，会过滤http请求头信息中的一些敏感信息，默认的敏感头信息通过zuul.sensitiveheaders定义，包括cookie、set-cookie、authorization。

如果你使用@enablezuulproxy,你可以使用代理路径上传文件,它能够一直正常工作只要小文件.对于大文件有可选的路径"/zuul/*"绕过springdispatcherservlet(避免处理multipart).比如对于zuul.routes.customers=/customers/**,你可以使用"/zuul/customers/*"去上传大文件.servlet路径通过zuul.servletpath指定.如果使用ribbon负载均衡器的代理路由,在处理非常大的文件时,仍然需要提高超时配置.

八：springcloud配置中心--config

在分布式系统中，springcloudconfig提供一个服务端和客户端去提供可扩展的配置服务。我们可用用配置服务中心区集中的管理所有的服务的各种环境配置文件。配置服务中心采用git的方式存储配置文件，因此我们很容易部署修改，有助于对环境配置进行版本管理。

springcloudconfig就是云端存储配置信息的,它具有中心化,版本控制,支持动态更新,平台独立,语言独立等特性。其特点是：

a.提供服务端和客户端支持(springcloudconfigserver和springcloudconfigclient)b.集中式管理分布式环境下的应用配置c.基于spring环境，无缝与spring应用集成d.可用于任何语言开发的程序e.默认实现基于git仓库，可以进行版本管理f.可替换自定义实现

1.server端

拉取配置时更新git仓库副本，保证是最新结果支持数据结构丰富，yml,json,properties等配合eureke可实现服务发现，配合cloudbus可实现配置推送更新配置存储基于git仓库，可进行版本管理简单可靠，有丰富的配套方案

2.client端指明使用configserver上哪个配置文件即可

本项目介绍：eureka-server为整个springcloud项目的服务中心，除了之后的sleuth与stream相关的项目没有服务化，其余的均服务化。

最强的eureka-server

一：与eureka-provider-node*联合测试eureka的服务发现与注册

二：eureka-server本项目的测试多配置自由切换以及对等的集群部署

三：与ribbon-consumer以及eureka-provider-node*联合测试服务的消费，客户端的负载均衡，服务提供者的集群等

四：与feign-consumer以及eureka-provider-node*联合测试服务的熔断及上述第三点

五：与sleuth-*（除了stream）相关项目联合测试链路的追踪，其中实现为http的zipkin

六：与zuul,ribbon,feign联合测试路由的转发

七：与config-*相关测试配置中心读取配置文件，消息总线bug，集群等独立出来的sleuth-stream-*项目的测试链路追踪日志的持久化操作，该项目中持久化介质mysql,使用时，请初始化数据库连接。

八：springbootadminspring-boot-admin，简称sba，是一个针对spring-boot的actuator接口进行ui美化封装的监控工具。他可以：在列表中浏览所有被监控spring-boot项目的基本信息，详细的health信息、内存信息、jvm信息、垃圾回收信息、各种配置信息（比如数据源、缓存列表和命中率）等，还可以直接修改logger的level。