当前位置: 首页>编程语言>正文

Spring Cloud for Cloud Foundry 说明 spring cloud service

SpringCloud微服务架构。包括 服务发现(Eureka),断路器(Hystrix),服务网关(Zuul),客户端负载均衡(Ribbon)、服务跟踪(Sleuth)、消息总线(Bus)、消息驱动(Stream)、批量任务(Task)等。

微服务:

1.微服务的核心思想便是服务拆分与解耦,降低复杂性。微服务强调将功能合理拆解,尽可能保证每个服务的功能单一,按照单一责任原则(Single Responsibility Principle)明确角色。 将各个服务做轻,从而做到灵活、可复用,亦可根据各个服务自身资源需求,单独布署,单独作横向扩展。

服务注册与发现:

1.@EnableEurekaServer  注解启动一个服务注册中心提供给其他应用进行对话。这个注解放在启动类上方。

2. Eureka分为服务注册中心,服务提供者 ,服务消费者。服务提供者 、服务消费者都必须指定注册中心。服务提供者提供服务,而服务消费者可以调用提供者的服务。

3.服务发现的接口DiscoveryClient类是Spring Cloud对服务治理做的一层抽象。

 @EanbleDiscoveryClient 注解,加在启动类main的上方,可以将应用注册为Eureka 客户端应用,以获取服务发现的能力。

4.Spring Cloud Consul项目: 可以将基于Spring Boot的微服务应用注册到Consul上,并通过此实现微服务架构中的服务治理。Consul的作用类似于Eureka。

5.下面是Eureka的治理机制:

服务提供者:

  • 服务注册:启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上,同时带上了自身服务的一些元数据信息。
  • 服务续约:在注册完服务之后,服务提供者会维护一个心跳用来持续告诉Eureka Server: "我还活着 ” 、
  • 服务下线:当服务实例进行正常的关闭操作时,它会触发一个服务下线的REST请求给Eureka Server, 告诉服务注册中心:“我要下线了 ”。

服务消费者

  • 获取服务:当我们启动服务消费者的时候,它会发送一个REST请求给服务注册中心,来获取上面注册的服务清单
  • 服务调用:服务消费者在获取服务清单后,通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。在进行服务调用的时候,优先访问同处一个Zone中的服务提供方。

Eureka Server(服务注册中心):

  • 失效剔除:默认每隔一段时间(默认为60秒) 将当前清单中超时(默认为90秒)没有续约的服务剔除出去。
  • 自我保护:EurekaServer 在运行期间,会统计心跳失败的比例在15分钟之内是否低于85%(通常由于网络不稳定导致)。 Eureka Server会将当前的实例注册信息保护起来, 让这些实例不会过期,尽可能保护这些注册信息。

 

服务消费者:

1.LoadBalancerClient接口 ,是一个负载均衡客户端的接口。

 2.RestTemplate对象,通过getForObject()等方法实现对服务提供者接口的调用。

getForObject(URI url, Class<T> responseType)

3.将eureka-server(服务注册中心)、eureka-client(服务提供者)、eureka-consumer(服务消费者)都启动起来,然后访问 eureka-consumer的Controller层方法对应的请求,可以观察eureka-consumer服务是如何消费eureka-client服务的Controller层方法接口的。

4.使用Spring Cloud Ribbon可以作为服务消费者,实现服务的调用以及客户端均衡负载。

5.在Ribbon中可以采用服务名的方式进行请求,因为Ribbon有一个拦截器,它能够在这里进行实际调用的时候,自动的去选取服务实例,并将实际要请求的IP地址和端口替换这里的服务名,从而完成服务接口的调用。

服务名是application文件中的spring.application.name 属性。

6. Feign是一套基于Netflix Feign实现的声明式服务调用客户端。Feign可以做为服务消费者。需要通过创建接口并用注解来配置它既可完成对Web服务接口的绑定。

@EnableFeignClients注解开启扫描Spring Cloud Feign客户端的功能

@FeignClient注解用来指定这个接口所要调用的服务名称。

7.Feign底层原理 :动态代理。

8.Ribbon底层原理:负载均衡。轮询。

分布式配置中心:

1.分布式配置中心,集中管理配置,"一次配置,随处可用"。

2.在SpringCloudConfig中,程序中bootstrap.yml中的配置优先级高于application.yml的配置。。

3.SpringCloudConfig主要由基于Git仓库的配置中心服务端 、 使用配置中心的客户端组成。

断路器:

1.熔断机制: 在分布式架构中,当某个服务单元发生故障(类似用电器发生短路)之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个错误响应,而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放,避免了故障在分布式系统中的蔓延。

2.Spring Cloud中使用了Hystrix 来实现断路器的功能。Hystrix具备拥有回退机制和断路器功能的线程和信号隔离,请求缓存和请求打包,以及监控和配置等功能。Hystrix具有融断机制。

Hystrix可以进行服务降级、服务隔离、服务熔断。

3.在Ribbon中需要引入Hystrix依赖。否则服务不可用时,会返回404。

而Feign中已经依赖了Hystrix,不需要再引入,会直接返回内部错误(500) 。

4.@SpringCloudApplication注解,它整合了@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker。

5.当服务提供者不可用时,断路器Hystrix会返回错误响应。

6.使用了@HystrixCommand来将某个函数包装成了Hystrix命令,这里除了定义服务降级之外,Hystrix框架就会自动的为这个函数实现调用的隔离。所以,依赖隔离、服务降级在使用时候都是一体化实现的.

 7.服务隔离: Hystrix使用"舱壁模式"实现线程池的隔离,它会为每一个Hystrix命令创建一个独立的线程池,这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况,也只是对该依赖服务的调用产生影响,而不会拖慢其他的服务。
通过对依赖服务实现线程池隔离,应用更加健壮,不会因为个别依赖服务出现问题而引起非相关服务的异常。

8.hystrix-dashboard,可以对服务进行监控,展示数据。

 9.Hystix底层原理 :线程池。

服务网关:

1.服务网关:通过服务网关统一向外系统提供REST API的过程中,具备服务路由、均衡负载、权限控制等功能。Spring Cloud Netflix中的服务网关为Zuul。

一般微服务架构中都必然会设计一个网关在里面,像android、ios、pc前端、微信小程序、H5等等,不用去关心后端有几百个服务,就知道有一个网关,所有请求都往网关走,网关会根据请求中的一些特征,将请求转发给后端的各个服务。而且有了网关之后,还有很多好处,比如可以做统一的降级、限流、认证授权、安全,等等。

2.服务路由:通过服务路由的功能,在对外提供服务的时候,只需要通过暴露Zuul中配置的调用地址就可以让调用方统一的来访问我们的服务,而不需要了解具体提供服务的主机信息了。

3.服务过滤:在服务网关中定义过滤器只需要继承ZuulFilter抽象类实现其定义的四个抽象函数就可对请求进行拦截与过滤。

高可用服务集群:

1.配置高可用的Eureka服务集群,多个服务注册中心互相注册,如果有某个服务注册节点失效,那么还有其他节点可用。

消息驱动:

1.SpringCloudStream。

 

SpringCloud,微服务架构。包括 服务发现(Eureka),断路器(Hystrix),服务网关(Zuul),客户端负载均衡(Ribbon)、服务跟踪(Sleuth)、消息总线(Bus)、消息驱动(Stream)、批量任务(Task)等。

微服务:

1.微服务的核心思想便是服务拆分与解耦,降低复杂性。微服务强调将功能合理拆解,尽可能保证每个服务的功能单一,按照单一责任原则(Single Responsibility Principle)明确角色。 将各个服务做轻,从而做到灵活、可复用,亦可根据各个服务自身资源需求,单独布署,单独作横向扩展。

服务注册与发现:

1.@EnableEurekaServer  注解启动一个服务注册中心提供给其他应用进行对话。这个注解放在启动类上方。

2. Eureka分为服务注册中心,服务提供者 ,服务消费者。服务提供者 、服务消费者都必须指定注册中心。服务提供者提供服务,而服务消费者可以调用提供者的服务。

3.服务发现的接口DiscoveryClient类是Spring Cloud对服务治理做的一层抽象。

 @EanbleDiscoveryClient 注解,加在启动类main的上方,可以将应用注册为Eureka 客户端应用,以获取服务发现的能力。

4.Spring Cloud Consul项目: 可以将基于Spring Boot的微服务应用注册到Consul上,并通过此实现微服务架构中的服务治理。Consul的作用类似于Eureka。

5.下面是Eureka的治理机制:

服务提供者:

  • 服务注册:启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上,同时带上了自身服务的一些元数据信息。
  • 服务续约:在注册完服务之后,服务提供者会维护一个心跳用来持续告诉Eureka Server: "我还活着 ” 、
  • 服务下线:当服务实例进行正常的关闭操作时,它会触发一个服务下线的REST请求给Eureka Server, 告诉服务注册中心:“我要下线了 ”。

服务消费者

  • 获取服务:当我们启动服务消费者的时候,它会发送一个REST请求给服务注册中心,来获取上面注册的服务清单
  • 服务调用:服务消费者在获取服务清单后,通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。在进行服务调用的时候,优先访问同处一个Zone中的服务提供方。

Eureka Server(服务注册中心):

  • 失效剔除:默认每隔一段时间(默认为60秒) 将当前清单中超时(默认为90秒)没有续约的服务剔除出去。
  • 自我保护:EurekaServer 在运行期间,会统计心跳失败的比例在15分钟之内是否低于85%(通常由于网络不稳定导致)。 Eureka Server会将当前的实例注册信息保护起来, 让这些实例不会过期,尽可能保护这些注册信息。

 

服务消费者:

1.LoadBalancerClient接口 ,是一个负载均衡客户端的接口。

 2.RestTemplate对象,通过getForObject()等方法实现对服务提供者接口的调用。

getForObject(URI url, Class<T> responseType)

3.将eureka-server(服务注册中心)、eureka-client(服务提供者)、eureka-consumer(服务消费者)都启动起来,然后访问 eureka-consumer的Controller层方法对应的请求,可以观察eureka-consumer服务是如何消费eureka-client服务的Controller层方法接口的。

4.使用Spring Cloud Ribbon可以作为服务消费者,实现服务的调用以及客户端均衡负载。

5.在Ribbon中可以采用服务名的方式进行请求,因为Ribbon有一个拦截器,它能够在这里进行实际调用的时候,自动的去选取服务实例,并将实际要请求的IP地址和端口替换这里的服务名,从而完成服务接口的调用。

服务名是application文件中的spring.application.name 属性。

6. Feign是一套基于Netflix Feign实现的声明式服务调用客户端。Feign可以做为服务消费者。需要通过创建接口并用注解来配置它既可完成对Web服务接口的绑定。

@EnableFeignClients注解开启扫描Spring Cloud Feign客户端的功能

@FeignClient注解用来指定这个接口所要调用的服务名称。

7.Feign底层原理 :动态代理。

8.Ribbon底层原理:负载均衡。轮询。

分布式配置中心:

1.分布式配置中心,集中管理配置,"一次配置,随处可用"。

2.在SpringCloudConfig中,程序中bootstrap.yml中的配置优先级高于application.yml的配置。。

3.SpringCloudConfig主要由基于Git仓库的配置中心服务端 、 使用配置中心的客户端组成。

断路器:

1.熔断机制: 在分布式架构中,当某个服务单元发生故障(类似用电器发生短路)之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个错误响应,而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放,避免了故障在分布式系统中的蔓延。

2.Spring Cloud中使用了Hystrix 来实现断路器的功能。Hystrix具备拥有回退机制和断路器功能的线程和信号隔离,请求缓存和请求打包,以及监控和配置等功能。Hystrix具有融断机制。

Hystrix可以进行服务降级、服务隔离、服务熔断。

3.在Ribbon中需要引入Hystrix依赖。否则服务不可用时,会返回404。

而Feign中已经依赖了Hystrix,不需要再引入,会直接返回内部错误(500) 。

4.@SpringCloudApplication注解,它整合了@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker。

5.当服务提供者不可用时,断路器Hystrix会返回错误响应。

6.使用了@HystrixCommand来将某个函数包装成了Hystrix命令,这里除了定义服务降级之外,Hystrix框架就会自动的为这个函数实现调用的隔离。所以,依赖隔离、服务降级在使用时候都是一体化实现的.

 7.服务隔离: Hystrix使用"舱壁模式"实现线程池的隔离,它会为每一个Hystrix命令创建一个独立的线程池,这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况,也只是对该依赖服务的调用产生影响,而不会拖慢其他的服务。
通过对依赖服务实现线程池隔离,应用更加健壮,不会因为个别依赖服务出现问题而引起非相关服务的异常。

8.hystrix-dashboard,可以对服务进行监控,展示数据。

 9.Hystix底层原理 :线程池。

服务网关:

1.服务网关:通过服务网关统一向外系统提供REST API的过程中,具备服务路由、均衡负载、权限控制等功能。Spring Cloud Netflix中的服务网关为Zuul。

一般微服务架构中都必然会设计一个网关在里面,像android、ios、pc前端、微信小程序、H5等等,不用去关心后端有几百个服务,就知道有一个网关,所有请求都往网关走,网关会根据请求中的一些特征,将请求转发给后端的各个服务。而且有了网关之后,还有很多好处,比如可以做统一的降级、限流、认证授权、安全,等等。

2.服务路由:通过服务路由的功能,在对外提供服务的时候,只需要通过暴露Zuul中配置的调用地址就可以让调用方统一的来访问我们的服务,而不需要了解具体提供服务的主机信息了。

3.服务过滤:在服务网关中定义过滤器只需要继承ZuulFilter抽象类实现其定义的四个抽象函数就可对请求进行拦截与过滤。

高可用服务集群:

1.配置高可用的Eureka服务集群,多个服务注册中心互相注册,如果有某个服务注册节点失效,那么还有其他节点可用。

消息驱动:

1.SpringCloudStream。

 


https://www.xamrdz.com/lan/5x21924528.html

相关文章: