3 总结
拜托!面试请不要再问我Spring Cloud底层原理_云深i不知处的博客-CSDN博客
最后再来总结一下,上述几个Spring Cloud
核心组件,在微服务架构中,分别扮演的角色:
Eureka
:各个服务启动时,Eureka Client
都会将服务注册到Eureka Server
,并且Eureka Client
还可以反过来从Eureka Server
拉取注册表,从而知道其他服务在哪里。Ribbon
:服务间发起请求的时候,基于Ribbon
做负载均衡,从一个服务的多台机器中选择一台。Feign
:基于Feign
的动态代理机制,根据注解和选择的机器,拼接请求URL地址,发起请求。Hystrix
:发起请求是通过Hystrix
的线程池来走的,不同的服务走不同的线程池,实现了不同服务调用的隔离,避免了服务雪崩的问题。Zuul
:如果前端、移动端要调用后端系统,统一从Zuul
网关进入,由Zuul
网关转发请求给对应的服务。
1.什么是微服务(提供了许多组件,对微服务进行治理)
1.2 2个 微服务框架的对比
二.组件1-服务治理(也就是注册中心的意思)-Eureka (与远程调用有关)
远程调用有2种 resttemplate(封装了代码,简单)和httpclient(效率高,代码复杂)
如果没有注册中心,那么b调用a服务就需要将(a的网络协议,ip,端口都写到配置文件里边),不能动态获取
3.搭建 Eureka服务端
1. Eureka服务端启动类添加注解
@EnbleEurekaServer 声明这是一个Eureka Server
表示开启Eureka注册中心服务端,启动类添加注解.
@EnableEurekaClient 则表明是Eureka的Client,当项目使用Eureka的时候,两个注解的作用一样。启动类添加注解
2.Eureka控制台地址的访问(在IDEA中EurekaServer项目中,启动启动类.配置文件的port就是想问的路径)
第四步:加注解@EnableEurekaClient, 修改配置文件的内容
第五步: restTemplate动态获取a服务的路径(b服务里边注入DiscoveryClient对象,启动类加注解,通过注入的对象,通过A服务的服务名称最终获取到ip和端口完成远程调用)
二.服务治理--Consul(yml的配置,b掉a服务的代码与Eureka基本一样的,区别就是Consul不用自己搭IDEA的server模块了)
它的下载安装和访问界面比较简单.(下载好之后,本地解压,是一个.exe的可执行文件,在黑窗口输入命令启动,然后在页面输入地址访问)
三.服务治理---Nacos (下载安装好,不用提供IDEA端的server模块,然后在2个辅助配置yml和添加注解,直接调用, 与Consul一样的操作. 代码比较简单)
四.负载均衡---Ribbon(做了集群,所以万一那个节点挂机,就需要负载均衡自动匹配)(在服务的消费方设置)
第一种代码方式:
第二种;yml配置的方法
五.feig你声明式服务调用(2个服务的调用)
feign和Openfeign的区别
OpenFeign服务接口调用_不断前进的皮卡丘的博客-CSDN博客
页面路径先到b服务,然后通过b服务的feign功能(2个注解启动类@EnableFeignClient和@FeignClient的value属性搭配,接口上的@RestMapping的路径映射去Eureka里边找服务a,最终完成调用)
以前有RestTemplate远程调用,Ribbon简化RestTemplate, feign最好用
HttpClient详细使用示例_justry_deng的博客-CSDN博客_httpclient
六.熔断器(预防雪崩现象的发生)---Hystrix (发生问题啦,它提供了2种功能,降级功能和熔断功能)
服务a掉b,b掉c. 如果c网络等问题,会导致b最终一直到c,自己资源耗尽也失败,然后a也同样的道理,a崩掉啦. 导致级联失败..
六.1 服务方和消费方降级方案
六.2 熔断功能
七.API网关---GateWay (IDEA要写一个网关模块的微服务)
以前页面到前端代码,一个请求过来,前端可能调用后端多个微服务,复杂度高,修改配置麻烦,现在在前后端加入网关功能...
七.1 网关的路由配置(静态路由,上边的配置写死的. 动态路由比较灵活)
七.2 网关过滤器
八,Config+BUS 实现动态文件的管理和维护
外部配置文件一般放到gitee仓库中:
九。Bus消息总线
十 Stream消息驱动:动态封装,可以切换mq的使用,同一套代码对不同的mq做编码的动作。(公司想切换mq的使用才能用到)
十二。Sleuth+Zipkin 链路追踪的