目录
6.2.2、Zookeeper 保证 CP(一致性 + 分区容错性)
6.2.3、Eureka 保证 AP(可用性 + 分区容错性)
1、SpringBoot和SpringCloud的区别？
- SpringBoot专注于快速方便的开发单个个体微服务。
- SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务。
2、SpringCloud和Dubbo的服务调用
- RPC：远程过程调用，自定义数据格式，传输层，速度快效率高；
缺点：生产者和消费者之间依赖太强(通过接口调用)，消费者需要为每一个微服务进行接口定义。
- Http：规定了数据传输格式，应用层，封装臃肿、但灵活性高。
2.1、Dubbo服务调用
Dubbo通过RPC进行服务间调用，常用Zookeeper作为注册中心，通过生产者和消费者协定好的接口进行服务调用。
服务调用基于接口进行双方交互：
- 双方协定好Dubbo调用中的接口(maven)；
- 生产者提供实现类并且注册(生产者)到注册中心；
- 消费者引入接口依赖，并将自己注册(消费者)到注册中心，即可对提供者进行调用。
2.2、SpringCloud服务调用
SpringCloud通过Rest风格的Http进行服务间调用，提供多种便捷访问远程http服务的RestTemplate模板进行服务间调用。
但是直接使用RestTemplate进行远程调用，还需要用户进行url拼接，所以SpringCloud提供了Feign(RestTemplate + Ribbon + Hystrix)进行服务间远程调用处理。
3、核心组件
- Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里；
代码中通过服务名找到对应的IP地址(IP地址会变，但服务名一般不会变)。
- Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台，默认为轮询算法；
- Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求；
- Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题；
-
舱壁模式(线程池隔离策略)：不同的服务使用不同的线程池，避免因请求过多导致正常服务无法访问。
Zuul/GateWay：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务，网关会根据请求中的一些特征，将请求转发给后端的各个服务。
4、微服务基本概念
4.1、SOA
4.2、服务雪崩
一个服务故障后，依赖该服务的其他服务也相继故障，最终导致整个服务链路的崩溃，叫做服务雪崩。
假设我们有两个访问量比较大的服务A和B，这两个服务分别依赖C和D,C和D服务都依赖E服务。
A和B不断的调用C,D处理客户请求和返回需要的数据。当E服务故障时，C和D的超时和重试机制会被执行。（E服务故障）
由于新的调用不断的产生，会导致C和D对E服务的调用大量的积压，产生大量的调用等待和重试调用，慢慢会耗尽C和D的资源比如内存或CPU。（CD服务故障）
A和B服务会重复C和D的操作，资源耗尽，然后down掉，最终整个服务都不可访问。（AB服务故障）
4.3、熔断机制(Hystrix)
当服务出现高并发时，SpringCloud的熔断机制会监控服务间的调用情况，当调用失败的次数达到一定阈值时，就会启动熔断机制(切断对下游系统的调用)。
熔断器有三个状态：
- Closed：关闭状态，请求被放行，调用失败次数积累到一定阈值时，则启动熔断机制，转为打开状态；
- Open：打开状态，所有请求都会被拒绝，直接返回失败；只有在经过一个设定的时间周期后，熔断器转为半开状态；
- Half-Open：允许一定量的服务请求被放行，如果调用都成功，则转为关闭状态，放行所有请求；如果调用失败，又转为打开状态。
-
4.4、服务降级
- Open：打开状态，所有请求都会被拒绝，直接返回失败；只有在经过一个设定的时间周期后，熔断器转为半开状态；
当某个服务熔断之后，客户端返回自己准备的一个默认值(或回调函数)，而不再调用崩溃的下游服务，从而保证服务可用。
4.5、服务网关
- API路由(转发请求到下游的微服务)；
- 基于Filter链提供鉴权、流量控制、熔断、日志监控等功能。
5、Feign和Dubbo的区别
Feign和Dubbo都是为了实现远程调用。包括相关的注册中心解耦、负载均衡、失败重试熔断、链路监控等。
- Dubbo除了注册中心，其余的负载均衡、熔断、链路监控都是自己实现的；
- Feign只有远程调用功能，其余的功能则需要Spring全家桶的实现，比如Ribbon，Hystrix等。
5.1、从协议上来看
- Feign是通过REST API实现的远程调用，基于Http传输协议。
- Dubbo是通过RPC调用实现的远程调用，支持多传输协议(Dubbo、Rmi、http、redis等等)，可以根据业务场景选择最佳的方式。默认的Dubbo协议：利用Netty，TCP传输，单一、异步、长连接，适合数据量小、高并发和服务提供者远远少于消费者的场景。
5.2、从通信性能来看
- Feign基于Http协议，属于应用层，在高并发场景下性能不够理想。
- Dubbo基于RPC协议，属于传输层 ，保持了长连接、高性能。
5.3、负载均衡
- Feign集成了Ribbon作为负载均衡组件。Ribbon的负载均衡策略：随机、规则轮询、空闲策略、响应时间策略。
- Dubbo的负载均衡策略：Dubbo支持4种算法，随机、权重轮询、最少活跃调用数、一致性Hash策略。
5.4、容错机制
- Feign集成了Hystrix作为服务熔断组件，利用熔断机制来实现容错。Hystrix提供了服务降级，服务熔断，依赖隔离，监控（Hystrix Dashboard）等功能。
- Dubbo支持多种容错策略，FailOver、FailFast、Failsafe、FailBack、Aviailable、Broadcast、Forking策略等。
6、注册中心
6.1、原理
主要角色：服务提供者(RPC Server)、服务消费者(RPC Client)和服务注册中心(Registry)
- RPC Server 提供服务，在启动时，根据服务发布文件 server.xml 中的配置的信息，向 Registry 注册自身服务，并向Registry 定期发送心跳汇报存活状态。
- RPC Client调用服务，在启动时，根据服务引用文件client.xml 中配置的信息，向 Registry 订阅服务，把Registry返回的服务节点列表缓存在本地内存中，并与 RPC Sever 建立连接。
- 当 RPC Server 节点发生变更时，Registry 会同步变更，RPC Client 感知后会刷新本地内存中缓存的服务节点列表。
- RPC Client从本地缓存的服务节点列表中，基于负载均衡算法选择一台 RPC Sever 发起 调用。
6.2、服务注册中心Eureka和Zookeeper的区别
当注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟之前的注册信息，但是不能接受服务直接down掉不可以。也就是说，服务注册功能对可用性的要求高于一致性。
6.2.1、分布式系统的CAP理论
C:Consistency(一致性)、A: Availability(可用性)、P：Partition tolerance(分区容错性)
一个分布式系统不可能同时满足这三个条件，最多只能满足其中两个。
一般情况下，分区容错性是必不可少的，所以分布式系统一般在一致性和可用性中做选择。
- CA：单机服务，不能保证分区容错性。
- CP：写入数据并同步从数据库数据时，锁定数据库，同步完成后再释放锁。锁定期间，用户请求会被阻塞，不满足可用性。
- AP：用户请求到来时，允许返回未同步的数据(master已更新，slave未更新)。
6.2.2、Zookeeper 保证 CP(一致性 + 分区容错性)
- 保证一致性：保证集群下所有副本数据一致。
- 不保证可用性：当主节点因为故障挂掉时，剩余节点会重新进行主节点选举，选举期间Zookeeper集群不可用。
6.2.3、Eureka 保证 AP(可用性 + 分区容错性)
- 保证可用性：集群部署的 Eureka 即使挂掉一定的数量，也可以保证有信息可以返回，依然可以提供注册和查询服务，只不过查到的信息可能不是最新的。
- 不保证一致性：Eureka集群节点挂掉时，集群间可能还未来得及同步数据，所以不保证一致性。
以上内容为个人学习理解，如有问题，欢迎在评论区指出。
部分内容截取自网络，如有侵权，联系作者删除。
扫一扫
2559
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
