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 链路追踪的
