springcloud 基础

面试题

SOA、分布式、微服务之间有什么关系和区别？

1.分布式架构是指将单体架构中的各个部分拆分，然后部署不同的机器或进程中去，SOA和微服务基本上都是分布式架构
师
2.SOA是一种面向服务的架构，系统的所有服务都注册在总线上，当调用服务时，从总线上查找服务信息，然后调用
3.微服务是一种更彻底的面向服务的架构，将系统中各个功能个体抽成一个个小的应用程序，基本保持一个应用对应的一个服务架构。

谈谈你对微服务的理解，微服务有哪些优缺点?

微服务是由Martin Fowler大师提出的。微服务是一种架构风格，通过将大型的单体应用划分为比较小的服务单元，从而降低
整个系统的复杂度。
优点：
1、服务部署更灵活：每个应用都可以是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性降低。
2、技术更新灵活：在大型单体应用中，技术要进行更新，往往是非常困难的。而微服务可以根据业务特点，灵活选择技术
栈。
3、应用的性能得到提高：大型单体应用中，往往启动就会成为一个很大的难关。而采用微服务之后，整个系统的性能是能够
得到提高的。
4、更容易组合专门的团队： 在单体应用时，团队成员往往需要对系统的各个部分都要有深入的了解，门槛是很高的。而采用
微服务之后，可以给每个微服务组建专门的团队。
5、代码复用：很多底层服务可以以REST API的方式对外提供统一的服务，所有基础服务可以在整个微服务系统中通用。
缺点：
1、服务调用的复杂性提高了：网络问题、容错问题、负载问题、高并发问题。。。。
2、分布式事务：尽量不要使用微服务事务。
3、测试的难度提升了:
4、运维难度提升：单体架构只要维护一个环境，而到了微服务是很多个环境，并且运维方式还都不一样。所以对部署、监
控、告警等要求就会变得非常困难。

高并发场景下如何实现系统限流？

限流一般需要结合容量规划和压测来进行。当外部请求接近或者达到系统的最大阈值时，触发限流，采取其他的手
段进行降级，保护系统不被压垮。常见的降级策略包括延迟处理、拒绝服务、随机拒绝等。
计数器法：
1、将时间划分为固定的窗口大小，例如1s
2、在窗口时间段内，每来一个请求，对计数器加1。
3、当计数器达到设定限制后，该窗口时间内的之后的请求都被丢弃处理。
4、该窗口时间结束后，计数器清零，从新开始计数。
滑动窗口计数法：
1.将时间划分为细粒度的区间，每个区间维持一个计数器，每进入一个请求则将计数器加一。
2.多个区间组成一个时间窗口，每流逝一个区间时间后，则抛弃最老的一个区间，纳入新区间。如图中示例的窗口T1变
为窗口T2
3.若当前窗口的区间计数器总和超过设定的限制数量，则本窗口内的后续请求都被丢弃。
漏桶算法：如果外部请求超出当前阈值，则会在容易里积蓄，一直到溢出，系统并不关心溢出的流量。从出口处限制请求速率，并不存在计数器法的临界问题，请求曲线始终是平滑的。无法应对突发流量，相当于一个空桶+固定处理线程
令牌桶算法：假设一个大小恒定的桶，这个桶的容量和设定的阈值有关，桶里放着很多令牌，通过一个固定的速率，往里边放入令牌，如果桶满了，就把令牌丢掉，最后桶中可以保存的最大令牌数永远不会超过桶的大小。当有请求进入时，就尝试从桶里取走一个令牌，如果桶里是空的，那么这个请求就会被拒绝。

什么是Hystrix？简述实现机制

分布式容错框架
·阻止故障的连锁反应，实现熔断
·快速失败，实现优雅降级
提供实时的监控和告警
资源隔离：线程隔离，信号量隔离
•线程隔离：Hystrix会给每一个Command分配一个单独的线程池，这样在进行单个服务调用的时候，就可以
在独立的线程池里面进行，而不会对其他线程池造成影响
信号量隔离：客户端需向依赖服务发起请求时，首先要获取一个信号量才能真正发起调用，由于信号量的数量有限，当并发请求量超过信号量个数时，后续的请求都会直接拒绝，进入fallback流程。信号量隔离主要是通过控制并发请求量，防止请求线程大面积阻塞，从而达到限流和防止雪崩的目的。

熔断和降级：调用服务失败后快速失败
熔断是为了防止异常不扩散，保证系统的稳定性

降级：编写好调用失败的补救逻辑，然后对服务直接停止运行，这样这些接口就无法正常调用，但又不至于直接报错，只是服务水平下降

1.通过HystrixCommand或者HystrixObservableCommand 将所有的外部系统（或者称为依赖）包装起来，整个包装对象是单独运行在一个线程之中（这是典型的命令模式）。
2.超时请求应该超过你定义的阈值
3.为每个依赖关系维护一个小的线程池（或信号量）；如果它变满了，那么依赖关系的请求将立即被拒绝，而不是排队等待。
4.统计成功，失败（由客户端抛出的异常），超时和线程拒绝。
5.打开断路器可以在一段时间内停止对特定服务的所有请求，如果服务的错误百分比通过阈值，手动或自动的关闭断路器。
6.当请求被拒绝、连接超时或者断路器打开，直接执行fallback逻辑。
7.近乎实时监控指标和配置变化。

什么是服务降级、什么是熔断

降级是解决系统资源不足和海量业务请求之间的矛盾
在暴增的流量请求下，对一些非核心流程业务、非关键业务，进行有策略的放弃，以此来释放系统资源，保证核心业务的正常运行，尽量避免这种系统资源分配的不平衡，打破二八策略，让更多的机器资源，承载主要的业务请求。服务降级不是一个常态策略，而是应对非正常情况下的应急策略。服务降级的结果，通常是对一些业务请求,返回一个统一的结果，可以理解为是一种 FailOver 快速失败的策略。一般通过配置中心配置开关实现开启降级
熔断模式保护的是业务系统不被外部大流量或者下游系统的异常而拖垮。
如果开启了熔断，订单服务可以在下游调用出现部分异常时，调节流量请求，比如在出现10%的失败后，减少50%的流量请求，如果继续出现 50%的异常，则减少80%的流量请求；相应的，在检测的下游服务正常后，首先恢复30%的流量，然后是50%的流量，接下来是全部流量

SpringCloud和SpringCloudAlibaba都有哪些组件？都解决了什么问题?

Springclqud:
SpringCloud：提供了构建微服务系统所需要的一组通用开发模式以及一系列快速实现这些开发模式的工具。
通常所说的SpringCloud是指SpringCloud NetFlix，他和SpringCloudAlibaba都是SpringCloud这一系列开发模式的具体
实现。
SpringCloud NetFlix

springcloud核心组件及其作用
Eureka：服务注册与发现
注册：每个服务都向Eureka登记自己提供服务的元数据，包括服务的ip地址、端口号、版本号、通信协议等。eureka将各个服务维护在了一个服务清单中（双层Map，第一层key是服务名，第二层key是实例名，value是服务地址加端口）。同时对服务维持心跳，剔除不可用的服务，eureka集群各节点相互注册每个实例中都有一样的服务清单。
发现：eureka注册的服务之间调用不需要指定服务地址，而是通过服务名向注册中心咨询，并获取所有服务实例
清单（缓存到本地)，然后实现服务的请求访问。
Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台（被调用方的服务
地址有多个），Ribbon也是通过发起http请求，来进行的调用，只不过是通过调用服务名的地址来实现的。虽然说Ribbon不用去具体请求服务实例的ip地址或域名了，但是每调用一个接口都还要手动去发起Http请求
@Autowired
RestTemplate restTemplate;@GetMapping(“/ribbon-consumer”)public String helloconsumer(){
return
restTemplate.getForEntity("http:

Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求，简化服务间的调
用，在Ribbon的基础上进行了进一步的封装。单独抽出了一个组件，就是Spring Cloud Feign。在引入Spring
Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，通
过统计接口超时次数返回默认值，实现服务熔断和降级
Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务，通过与Eureka进行整合，将自身注册为Eureka下的应用，从Eureka下获取所有服务的实例，来进行服务的路由。Zuul还提供了一套过滤器机制，开发者可以自己指定哪些规则的请求需要执行校验逻辑，只有通过校验逻辑的请求才会被路由到具体服务实例上，否则返回错误提示。

分布式事务如何处理？怎么保证事务一致性?

怎么拆分微服务？怎样设计出高内聚、低耦合的微服务？有没有了解过DDD领域驱动设计？什么是中台？中台和微服务有什么关系?

拆分微服务的时候，为了尽量保证微服务的稳定，会有一些基本的准则:
1、微服务之间尽量不要有业务交叉。
2、微服务之前只能通过接口进行服务调用，而不能绕过接口百按话心对方的和样
3、高内聚，低耦合。
高内聚低耦合，是一种从上而下指导微服务设计的方法。实现高内聚低耦合的工具主要有 同步的接口调用和异步的事件驱动
两种方式。
大泥团： 不利于微服务的拆分。大泥团结构拆分出来的微服务依然是泥团机构，当服务业务逐渐复杂，这个泥团又会膨胀成
为大泥团。
DDD只是一种方法论，没有一个稳定的技术框架。DDD要求领域是跟技术无关、跟存储无关、跟通信无关。

所谓中台，就是将各个业务线中可以复用的一些功能抽取出来，剥离个性，提取共性，形成一些可复用的组件。 盒马鲜生、
团购
大体上，中台可以分为三类 业务中台、数据中台和技术中台。大数据杀熟-数据中台
电商 收银中台 支付风控中台
中台跟DDD结合：DDD会通过限界上下文将系统拆分成一个一个的领域，而这种限界上下文，天生就成了中台之间的逻辑
屏障。

DDD在技术与资源调度方面都能够给中台建设提供不错的指导.
DDD分为战略设计和战术设计。上层的战略设计能够很好的指导中台划分，下层的战术设计能够很好的指导微服务搭建。
在目前阶段，DDD还大都处在小范围实验的阶段。

你的项目中是怎么保证微服务敏捷开发的？微服务的链路追踪,持续集成、AB发布要怎么做?

开发运维一体化。
敏捷开发：目的就是为了提高团队的交付效率，快速迭代，快速试错。
每个月固定发布新版本，以分支的形式保存到代码仓库中。快速入职。任务面板、站立会议。团队人员灵活流动，同时形成各个专家代表。测试环境- 生产环境-》 开发测试环境SIT、集成测试环境、压测环境STR、预投产环境、生产环境PRD。文档优先。晨会、周会、需求拆分会。
链路追踪：1、基于日志。形成全局事务ID，落地到日志文件。filebeat-Logstash-Elasticsearch形成大型报表。2、基于
MQ，往往需要架构支持。经过流式计算形成一些可视化的结果。
持续集成：SpringBoot maven pom->build-> shell;Jenkins。
AB发布：1、蓝绿发布、红黑发布
老版本和新版本是同时存在的。2、灰度发布、金丝雀发布。

组件

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务.
Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案.
Alibaba Cloud OSS： 阿里云对象存储服务（Object Storage Service，简称OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。
您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。
Alibaba Cloud SchedulerX:阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任
务调度服务
Alibaba Cloud SMS：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。
更多组件请参考Roadmap。

Eureka：服务注册与发现

注册：每个服务都向Eureka登记自己提供服务的元数据，包括服务的ip地址、端口号、版本号、通信协议等。eureka将各个服务维护在了一个服务清单中（双层Map，第一层key是服务名，第二层key是实例名，value是服务地址加端口）。同时对服务维持心跳，剔除不可用的服务，eureka集群各节点相互注册每个实例中都有一样的服务清单。
发现：eureka注册的服务之间调用不需要指定服务地址，而是通过服务名向注册中心咨询，并获取所有服务实例
清单（缓存到本地)，然后实现服务的请求访问。

发现：eureka注册的服务之间调用不需要指定服务地址，而是通过服务名向注册中心咨询，并获取所有服务实例
清单（缓存到本地），然后实现服务的请求访问。

Ribbon：

服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台（被调用方的服务地址有多个），Ribbon也是通过发起http请求，来进行的调用，只不过是通过调用服务名的地址来实现的。虽然说Ribbon不用去具体请求服务实例的ip地址或域名了，但是每调用一个接口都还要手动去发起Http请求
@RestController
public class Consumercontroller {
@Autowired
RestTemplate restTemplate;
@GetMapping("/ribbon-consumer"public string helloConsumer(
return
restTemplate.getForEntity(“http://exampleservice/index”,String.class).getBody()

Feign：

基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求，简化服务间的调用，在Ribbon的基础上进行了进一步的封装。单独抽出了一个组件，就是Spring Cloud Feign。在引入Spring Cloud Feign后，我们只需要创建一个接口并用注解的方式来配置它，即可完成对服务提供方的接口绑定。
调用远程就像调用本地服务一样
@Restcontroller
public class Usercontroller {@GetMapping(“/getuser”)public string getuser(){
List list = new ArrayList<>()
1ist.add(“张三”);
string json = JSON.toJSoNString(1ist);
return json;
@FeigncTient(name =“user”)public interface Userclient@GetMapping(“/getuser”)string getuser();

Hystrix：

发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，通
过统计接口超时次数返回默认值，实现服务熔断和降级
Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务，通过与Eureka进行整合，将自身注册为Eureka下的应用，从Eureka下获取所有服务的实例，来进行服务的路由。Zuul还提供了一套过滤器机制，开发者可以自己指定哪些规则的请求需要执行校验逻辑，只有通过校验逻辑的请求才会被路由到具体服务实例上，否则返回错误提示。

Spring Cloud有哪些常用组件，作用是什么?

1.Eureka：注册中心
2.Nacos：注册中心、配置中心
3.Consul：注册中心、配置中心
4.Spring Cloud Config：配置中心
5.Feign/OpenFeign:RPC调用
6.Kong：服务网关
7.Zuul：服务网关
8.Spring Cloud Gateway：服务网关
9.Ribbon：负载均衡
10.Spring CLoud Sleuth：链路追踪
11.Zipkin：链路追踪
12.Seata：分布式事务
13.Dubbo：RPC调用
14.Sentinel：服务熔断15.Hystrix：服务熔断

Spring Cloud和Dubbo有哪些区别?

Spring Cloud是一个微服务框架，提供了微服务领域中的很多功能组件，Dubbo一开始是一个RPC调用框架，核心是解决服务调用间的问题，Spring Cloud是一个大而全的框架，Dubbo则更侧重于服务调用，所以Dubbo所提供的功能没有Spring Cloud全面，但是Dubbo的服务调用性能比Spring Cloud高，不过Spring Cloud和Dubbo并不是对立的，是可以结合起来一起使用的。

什么是服务雪崩？什么是服务限流?

1.当服务A调用服务B，服务B调用C，此时大量请求突然请求服务A，假如服务A本身能抗住这些请求，但是如果服务C抗不住，导致服务C请求堆积，从而服务B请求堆积，从而服务A不可用，这就是服务雪崩，解决方式就是服务降级和服务熔断。
2.服务限流是指在高并发请求下，为了保护系统，可以对访问服务的请求进行数量上的限制，从而防止系统不被大量请求压垮，在秒杀中，限流是非常重要的。

什么是服务熔断？什么是服务降级？区别是.

1.服务熔断是指，当服务A调用的某个服务B不可用时，上游服务A为了保证自己不受影响，从而不再调用服务B，直接返
回一个结果，减轻服务A和服务B的压力，直到服务B恢复。
2.服务降级是指，当发现系统压力过载时，可以通过关闭某个服务，或限流某个服务来减轻系统压力，这就是服务降级。
相同点：
最左前缀原则是什么
1.都是为了防止系统崩溃
2.都让用户体验到某些功能暂时不可用
不同点：熔断是下游服务故障触发的，降级是为了降低系统负载

SprinbCloud微服务简介

架构发展历史

SpringBoot由baiPivotal团队在2013年开始研发、2014年4月发布第一个du版本的全新开源的轻量级框架。

它基zhi于Spring4.0设计，不dao仅继承了Spring框架原有的优秀特性，而且还通过简化配置来进一步简化了Spring应用的整个搭建和开发过程。另外SpringBoot通过集成大量的框架使得依赖包的版本冲突，以及引用的不稳定性等问题得到了很好的解决

在2014 年底， Spring 团队推出 Spring Cloud, 目标使其成为Java 领域微服务架构落地的标准

微服务架构概述

应用架构的发展

软件架构有三种架构类型，分别是业务架构、应用架构、技术架构。它们之间的关系是业务架构决定应用架构，技术 架构支撑应用架构。架构的发展历程是从单体架构、分布式架构、SOA 架构再到微服务架构。

单体应用架构

单体架构在Java领域，就是一个war包，包含了所有的应用功能。按照mvc结构，是从controller到service到dao。

单体架构的优点：

1. 易千开发：开发人员使用当前开发工具在短时间内就可以开发出单体应用。
2. 易于测试：因为不需要依赖其他接口，测试可以节约很多时间。
3. 易于部署：你只需要将目录部署在运行环境中即可。

单体架构的缺点：

1. 灵活度不够：如果程序有任何修改，修改的不只是一个点，而是自上而下地去修改，
   测试时必须等到整个程序部署完后才能看出效果。在开发过程可能需要等待其他开发
   人员开发完成后才能完成部署，降低了团队的灵活性。
2. 降低系统的性能：原本可以直接访问数据库但是现在多了一层。即使只包含一个功能 点，也需要在各个层写上代码。
3. 系统启动慢：一个进程包含了所有业务逻辑，涉及的启动模块过多，导致系统的启动
   时间延长。
4. 系统扩展性比较差：增加新东西的时候不能针对单个点增加，要全局性地增加。牵一 发而动全身

分布式架构

按照业务垂直切分，每个应用都是单体架构，通过API 互相调用

面向服务的SOA架构

SOA 是不同业务建立不同的服务，服务之间的数据交互粗粒度可以通过服务接口分级，这样松散耦合提高服务的可重用性，也让业务逻辑变得可组合，并且每个服务可以根据使用情况做出合理的分布式部署，从而 让服务变得规范，高性能，高可用

SOA 架构中有两个主要角色： 服务提供者 ( Pro vider ) 和服务消费者 ( Consumer )。阿里开源的 Dubbo 是 SOA 的典型实现。

SOA 架构的优点：

1. 把模块拆分，使用接口通信，降低模块之间的耦合度。
2. 把项目拆分成若干个子项目，不同的团队负责不同的子项目。
3. 增加功能时只需要增加一个子项目，调用其他系统的接口即可。
4. 可以灵活地进行分布式部署。

SOA 架构的缺点：

系统之间的交互需要使用远程通信， 接口开发增加工作量

微服务架构

微服务是一种架构风格， 对于一个大型复杂的业务系统，它的业务功能可以拆分为多个相互独立的微服务，各个微服务之间是松耦合的， 通过各种远程协议进行同步／异步通信，各微服务均可以被独立部署、扩／缩容以及升／降级

基于SpringCloud 的 微服务解决方案

Spring Cloud 的技术选型是中立的， 因此可以随需更换搭配使用

服务发现:Eureka Consul etcd、阿里 Nacos
共用组件:服务间调用组件Feign、负载均衡组件 Ribbon、熔断器 Hytrix
网关:性能低： Zuul; 性能高： Spring Cloud Gateway 自研网关中间件
配置中心:Spring Cloud Config、携程阿波罗、阿里 Nacos
全链路监控:zikpin 、Pinpoint 、Skywalking

基于Dubbo 实现微服务解决方案

什么是Sp ring Cloud

Spring Cloud 也是一个中间件,Spring 官方开发维护， 基千 Spring Boot 开发， 提供一套完整的微服务解决方案。包括服务注册与发现、配置中心、全链路监控、API 网关、熔断器等选型中立的开源组件， 可以随需扩展和替换组装.

SpringCloud回顾一下哈

SpringCloud都有哪些组件

1.服务的注册和发现 eureka
2.服务的负载和调用 ribbon\restTemplate LoadBlance Fengin
3.服务熔断和降级 hystris
4.服务网关 Zuul and GatetWay
5.服务分布式配置 手动刷新 自动刷新 读取本地配置文件
6.SpringCloudAlibaba

springcloud 回顾 （二）

1）eureka 单机环境、
2）eureka集群环境
3）消费端调用 单一的服务端 ribbon+restTemplate
4）消费端调用 集群的服务端 ribbon+restTemplate +loadbance + 通过服务名调用 ；在集群环境中，服务端save接口需要新增注解@RequestBoday
5）eureka 自我保护机制是什么 ？默认是开启自我保护机制的，验证自我保护机制
6）修改ribbon负载均衡规则 ，他有哪些负载均衡规则，负载均衡的实现原理是什么？
7）服务发现，discoveryclient，获取注册到eureka上的服务信息
8）restTemplate getForObject/postForObject getForEntity/postForEntity
9) 服务注册到eureka上显示服务名称和ip信息
10）使用zookeeper作为注册中心，将服务端注册到zookeeper，消费端从zookeeper中获取服务信息调用服务端接口。

使用到的注解：
@SpringBootApplication
@EnableEurekaClient
@EnableEurekaServer
@RibbonClient(value = “CLOUD-PAYMENT-SERVICE”,configuration = {MyRibbonConfig.class})
@Configuration
@LoadBlance
@Bean
@RestController
@Slf4j
@Resource
@Autowrite
@RequestBody
@Value
@PostMapping
@GetMapping
@Service
@Mapper

Spring Cloud Eureka

服务发现及注册中心 在微服务时代为什么会出现？

在微服务时代， 底层运维方式发生了巨大的变化 ， 随着Docker 的流行， 业务服务不再部署在固定的虚拟机上， 其 ip 地址也不再固定， 这个时候前面的解决方案就显得捉襟见肘了。针对合格问题，不同的思考方式提出了不同的解决方案，这里列举几个。

方案一： 以 Nginx 为例， 在没有引入服务注册中心的时候， 那就是手工或是通过脚本的方式， 在部署的时候去更新 Nginx 的配置文件， 然后 reload。抑或是使用 ngx_http_dyups_module 通过 rest api 来在运行时直接更新upstream 而不需要 reload。

方案二：将服务注册中心作为一个标配的分布式服务组件，网关等都从服务注册中心获取 相关服务的实例信息 ， 实现动态路由。比如 consul-template+ Nginx 的方案， 通过 consul 监听服务实例变化， 然后更新 Nginx 的配置文件， 通过 reload 实现服务列表更新。又拍云的slardar 也是这个思路， 不过不是通过 reload 的方式来， 而是通过在运行时通过 consul 获取服务列表来实现动态 upstream 的路由。

由此可见，随着服务架构模式以及底层运维方式的变化，服务注册中心逐步在分布式系统 架构中占据了一个重要的地位

Eureka简介

Eureka 是 Netflix 公司开源的一款服务发现组件， 该组件提供的服务发现可以 为负载均衡、failover 等提供支持 。Eureka 包括 Eureka Server 及Eureka Client。Eureka
Server 提供 REST 服务， 而 Eureka Client 则是使用 Java 编写的客户端， 用千简化与 Eureka
Server 的交互。

Eureka Server 端采用的是P2P 的复制模式， 但是它不保证复制操作一定能成功， 因此它提供的是一个最终一致性的服务实例视图； Client 端在Server 端的注册信息有一个带期限的租约， 一旦 Serv er 端在指定期间没有收到Client 端发送的心跳， 则 Server 端会认为 Client 端注册的服务是不健康的， 定时任务会将其从注册表中删除。

Consul 与 Eureka 不同， Consul 采用
Raft 算法， 可以提供强一致性的保证 ， Consul 的 agent 相当千 Netflix Ribbon+ Netflix Eureka。

Client, 而且对应用来说相对透明， 同时相对千Eur eka 这种集中式的心跳检测机制， Consul 的
agent 可以参与到基于 gossip 协议的健康检查，分 散了 Serv er 端的心跳检测压力。除此之外，
Consul 为多数据中心提供了开箱即用的原生支持等。

那么基于什么考虑因素可以选择Eureka 呢， 主要有如下几点：

1. 如果团队是Ja va 语言体系的， 则偏好Java 语言开发的， 技术体系上比较统一， 出问题也好排查修复，对组件的掌控力较强，方便扩展维护。

2. 当然除此之外 ， 更主要的是 Eureka 是 Netfli x 开源套件的一部分 ， 跟 zu ul , ri bbon 等
   整合的比较好。

Spring Cloud Eureka 案例代码

根项目 springclouddemo pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>springclouddemo</groupId>
  <artifactId>chapter2-1</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>pom</packaging>
  <modules>
  	<module>chapter2-1-eureka-server</module>
  	<module>chapter2-1-eureka-client</module>
  </modules>
  
  <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.3.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <java.version>1.8</java.version>
        <spring-cloud.version>Finchley.RELEASE</spring-cloud.version>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>${spring-cloud.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <repositories>
        <repository>
            <id>spring-snapshots</id>
            <name>Spring Snapshots</name>
            <url>https://repo.spring.io/snapshot</url>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </repository>
        <repository>
            <id>spring-milestones</id>
            <name>Spring Milestones</name>
            <url>https://repo.spring.io/milestone</url>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </repository>
    </repositories>

    <pluginRepositories>
        <pluginRepository>
            <id>spring-snapshots</id>
            <name>Spring Snapshots</name>
            <url>https://repo.spring.io/snapshot</url>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </pluginRepository>
        <pluginRepository>
            <id>spring-milestones</id>
            <name>Spring Milestones</name>
            <url>https://repo.spring.io/milestone</url>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </pluginRepository>
    </pluginRepositories>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
  
</project>

Client

chapter2-1-eureka-client pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>springclouddemo</groupId>
    <artifactId>chapter2-1</artifactId>
    <version>0.0.1-SNAPSHOT</version>
  </parent>
  <artifactId>chapter2-1-eureka-client</artifactId>

	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
		<java.version>1.8</java.version>
	</properties>

	<dependencies>
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
		</dependency>
	</dependencies>

	<build>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
		</plugins>
	</build>
  
</project>

chapter2-1-eureka-client application.yml

spring:
  profiles:
    active: demo

chapter2-1-eureka-client application-demo.yml.yml

server:
  port: 8081

spring:
  application:
    name: demo-client1

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/

chapter2-1-eureka-client 启动类ChapterEurekaClientApplication

package cn.springcloud.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;

@SpringBootApplication
@EnableDiscoveryClient
public class ChapterEurekaClientApplication {
	public static void main(String[] args) {
		SpringApplication.run(ChapterEurekaClientApplication.class,args);
	}
}

Server

chapter2-1-eureka-server pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>springclouddemo</groupId>
    <artifactId>chapter2-1</artifactId>
    <version>0.0.1-SNAPSHOT</version>
  </parent>
  <artifactId>chapter2-1-eureka-server</artifactId>

	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
		<java.version>1.8</java.version>
		<spring-cloud.version>Finchley.RELEASE</spring-cloud.version>
	</properties>

	<dependencies>
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
		</dependency>
	</dependencies>

	<build>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
		</plugins>
	</build>
</project>

chapter2-1-eureka-server application.yml

spring:
  profiles:
    active: standalone #激活哪个配置文件 
  jackson:
    date-format: yyyy-mm-dd HH:mm:ss  #设置时间格式
    serialization:
      FAIL_ON_EMPTY_BEANS: false  # 忽略无法转换的对象
eureka:
  server:
    use-read-only-response-cache: false  #是否使用只读的response-cache 默认true
    response-cache-auto-expiration-in-seconds: 10 #设置readWriteCacheMap的expireAfterWrite参数，指定写入多长时间后过期 默认 180s
management:  
  endpoints:
    web:
      exposure:
        include: '*'     # 公开所有的监控端点

chapter2-1-eureka-server application-standalone.yml

server:
  port: 8761   #server 存在的端口号

eureka:
  instance:
    hostname: localhost  # eureka server 存活的ip
  client:
    registerWithEureka: false # 表示是否将自己注册到Eureka Server，默认为true。由于当前这个应用就是Eureka Server，故而设为false
    fetchRegistry: false  #表示是否从Eureka Server获取注册信息，默认为true。因为这是一个单点的Eureka Server，不需要同步其他的Eureka Server节点的数据，故而设为false
    serviceUrl:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/    #设置与Eureka Server交互的地址，查询服务和注册服务都需要依赖这个地址
  server:
      waitTimeInMsWhenSyncEmpty: 0  #当从其他节点同步实例信息为空时等待的时间   默认 5 * 60 * 1000
      enableSelfPreservation: false #是否开启自我保护  默认 true

chapter2-1-eureka-server 启动类ChapterEurekaServerApplication

package cn.springcloud.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer
public class ChapterEurekaServerApplication {
	public static void main(String[] args) {
		SpringApplication.run(ChapterEurekaServerApplication.class,args);
	}
}

eureka-server

https

eureka-admin

metadata 路由实例

结合ribbon，实现灰度发布或者不宕机升级

SpringCloud ribbon负载均衡规则继承关系

springcloud-feign

springcloud开发微服务的时候，各个微服务之间的通信都是以http接口的形式对外提供服务，因此在服务消费者调用服务提供者时，底层还是使用的是http-client的方式访问。
可以使用一下方式：
1.URLConnection
2.Apache HttpClient
3.RestTemplate

Feign的特新

1. 基于注解方式
2. 支持http编码器和解码器
3. 支持http请求的压缩
4. 支持hystrix和他的fallback
5. 支持ribbon的负载均衡

feignClient 注解中的fallback = XXXX.class

1. 验证结果：在FeignClient 中使用的 fallback = XXX.class 这种方式，仅仅能在服务端宕机时起作用，如果客户端中 出现异常，则依旧不会降级 。

SpringCloud Sleuth分布式请求链路追踪

1. 配置Java环境，下载zipkin-server-2.12.2-exec.jar，java -jar 启动该jar包
   在地址栏访问 http://localhost:9411/zipkin/
2. 在服务提供者和服务消费者对应的工程的pom中添加

  <dependency>
     <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-zipkin</artifactId>
  </dependency>

3. 在服务提供者和消费者对应的yml中新增如下篇日志

spring:
	……
  zipkin:
    base-url: http://localhost:9411
  sleuth:
    sampler:
    probability: 1

SpringCloudAlibaba 学习笔记

​
学习地址：

Spring Cloud Alibaba Reference Documentation

seata: http://seata.io/zh-cn/

http://seata.io/zh-cn/docs/overview/what-is-seata.html

sentinel:https://github.com/alibaba/Sentinel

nacos： https://github.com/alibaba/nacos/releases/tag/1.3.0

nacos
服务提供者 2

消费者 1

http://localhost:9001/payment/nacos/1

http://localhost:83/consumer/payment/nacos/1

nacos 既支持Ap 也支持CP

可以通过命令进行切换

配置中心

多项目

多环境

namespace+group+dataid

namespace集群环境

group：

nacos 集群配置 + 持久化配置

linux版本

sentinel
gitbub地址：https://github.com/alibaba/Sentinel

–异常 DegradeException

–sentinel的熔断机制是没有半开的这种状态的，要么死要么活

–先通断后降级

1.默认是懒加载机制，执行一次才能访问,下载jar包,8080端口，查看前台服务

2.初始化工程,簇点链路、流控模式

3.流控规则

基本介绍

流控模式

直接（默认）

直接快速失败 QPS(进入到程序之前) 线程数(进入到程序之后)

在快速访问失败之后，是否有用户自定义的失败提示呢

不一定都是blocked by sentinel (flow limiting ) ？？？？

Blocked by Sentinel (flow limiting)

关联

B惹事情，A挂了

链路

多个请求访问同一个微服务

流控效果

快速失败

预热 冷启动的方式 warm up

一下子启动10万的请求，直接打死微服务

阈值

冷加载因子coldfoctoe 默认是3

：阈值/冷加载因子 才会达到阈

— 秒杀系统

排队等待

匀速排队 — 漏桶算法？？？

4.降级规则 也叫降级策略

RT

平均相应时长 妙级 + 时间窗口期（QPS>=5） 同时满足 触发该规则

RT最大4900 可以通过命令设置 -Dcsp.sentinel.max.rt=XXXX

异常比例

设置的范围是【0到1】之间

分钟级

QPS>=5 + 异常比例数>阈值 触发降级

时间窗口期 过了之后 关闭降级

异常数

当资源1分钟之内的异常数达到阈值后进行熔断

分钟级

异常数达到阈值就会触发降级

时间窗口期？？？ 过了之后 关闭降级

5.热点key限流

https://github.com/alibaba/Sentinel/wiki/%E7%83%AD%E7%82%B9%E5%8F%82%E6%95%B0%E9%99%90%E6%B5%81

仅仅支持QPS模式

@SentinelResource 兜底方法

@GetMapping(“/test”)

@SentinelResource(value = “myMethod”,blockHandler = “m2”)

public Result doSomething(@RequestParam(“uid”)String uid ,Required = false ,

@RequestParam(“type”)int type,Required = false)

{

// some logic here…

}

//兜底方法

public Result m2(String uid, int type ,BlockException exception) {

}

—如果没有兜底方法,则显示错误页面

配置索引为0,检测的是请求方法中的第一个参数

路径显示

XXXXXX/test?uid=1111 效果Ok

XXXXXX/test?type=000 效果not ok --因为没有做配置索引

参数例外项：

参数支持：8中基本类型和String类型

在高级选项中做设置

在这种情况下出现异常时，则不做做处理

@SentinelResource：主管配置出错，运行出错则需要走异常处理

6.系统规则

LOAD

RT

线程数

入口QPS

CPU使用率

7.@SentinelResource

按照资源名称限流+后续处理

按照url地址限流+后续处理

兜底方法存在的问题

系统默认的，没有体现出业务要求

代码狗和，不直观

每个业务方法都有一个兜底方法，代码膨胀

全局统一的处理方法没有体现

客户自定义限流处理逻辑

更多注解属性说明

8.服务熔断功能

sentinel整合ribbon+openfeign+fallback

ribbon

启动nacos、sentinel

提供者9003/9004

建module

pom

yml

主启动类

业务类

测试地址

消费者84

配置config类,引入resttemplate

@SentinelResource(value = “myMethod”,blockHandler = “m2”,fallback = “m2”,exceptionsToIngore = {})

openfeign

加pom

yml中增加fengin对sentinel的支持

fengin：

sentinel：

enable：true

主启动了增加openfengin注解支持

新增接口,@FenginClient(value = “”,fallback = XXX.class)

新增fallbackServiceImpl实现类，即XXX

熔断框架比较

9.规则持久化

配置到nacos中

在sentinel中配置的流控规则，重新启动sentinel后，规则就没有了

pom

增加sentinel-datasource-nacos

yml

增加nacos 数据源配置

seata spribgcloudAlibaba分布式事务框架
1.分布式事务的问题

2.seata介绍

http://seata.io/zh-cn/docs/overview/terminology.html

全局事务ID

三个组件：

TC - 事务协调者

维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM - 事务管理器

定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM - 资源管理器

管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

处理过程

1.TM向TC申请开启一个全局事务.全局事务创建成功并生成一个全局唯一XID

2.XID在微服务调用链路的上下文中传播

3.RM向TC注册分支事务,将其纳入XID对应全局事务管理

4.TM向TC发起针对XID的全局提交或者回滚决议

5.TC调度XID下管辖的全局分支事务完成提交或者回滚请求

3.seata-server安装 相当于一个分布式事务服务器

官网地址

下载版本

修改seataconf中的file.conf中的配置

备份原来的文件

主要修改：自定义事务组名称+事务日志存储模式+数据库连接信息

file.conf

service模块

:自定义事务组名称

store模块

:事务日志存储模式 为DB

在mysql数据库中创建数据库

在创建好的数据库中插入数据（seata 自带的sql）

修改register.conf配置文件

调整seata的注册地址为nacos，配置nacos的地址信息

启动nacos 端口号8848

启动seata

4.订单/库存/业务账户数据库准备

启动nacos、seata两个服务

三个微服务 订单 库存 账户

下订单-扣库存-减余额-该订单状态

创建三个数据库seata_order订单、seata_storage库存、seata_account账户

在三个数据库中创建对应的业务表

按照上述三个库创建对应的回滚日志表：在srata conf有一个叫 db_undo_log.sql

5.订单/库存/业务账户微服务准备

Order_mudule

创建module stata-order-service2001

pom

yml

file.conf

register.conf

domain(传输实体、表实体)

DAO实现

Service接口和实现

Controller

config配置

主启动类

Storge_mudule

Account_mudule

6.test

—树逻辑

---

高可用、低延迟、高QPS

分布式事务ID

为什么UUID会导致入库性能变差？

1.无需，无法预测他的生成顺序，不能通过递增有序的数字

2.注解，ID作为主键在特定的环境中会存在一些问题

3.索引，B+树索引分裂

数据库自增主键

单机：

集群分布式：

基于redis生成全局唯一ID

increase increaseby

除了设置步长以外，还需要关注过期时间

配置麻烦XXXX

​