CAP原则
CAP是什么?
CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。
- 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
- 可用性(A):保证每个请求不管成功或者失败都有响应。
- 分区容忍性(P):系统中任意信息的丢失或失败不会影响系统的继续运作。
分区容忍性在分布式系统中是必须满足的 所以只能才C A中选择
- zookeeper保证的CP
- Eureka保证的是AP
2.1 Zookeeper 保证的是 CP
当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但是不能接受服务直接 down 掉不可用。也就是说,服务注册功能对可用性的要求高于一致性。
但是 zookeeper 会出现这样的情况:当 master 节点因为网络故障与其他节点失去联系时,剩余节点会重新进行 leader 选举。问题在于,选举 leader 的时间太长, 30~ 120s,且选举期间整个 zookeeper 集群都是不可用的,这就导致在选举期间注册服务瘫痪。
2.2 Eureka 保证的是 AP
Eureka 各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而 Eureka 的客户端在向某个 Eureka 注册时,如果发现连接失败,则会自动切换至其他节点,只要有一台 Eureka 还在,就能保住注册服务的可用性,只不过查到的信息可能不是最新的,除此之外,Eureka 还有一种自我保护机制,如果在 15 分钟内超过 85% 的节点都没有正常的心跳,那么 Eureka 就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
- Eureka 不再从注册列表中移除因为长时间没有收到心跳而应该过期的服务。
- Eureka 仍然能够接受新服务的注册和查询骑牛,但是不会被同步到其他节点(保证当前节点依然可用)。
- 当网络稳定是,当前实例新的注册信息会同步到其他节点。
因此,Eureka可以很好的应对因为网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使得整个服务器瘫痪。
1.什么是微服务?
分布式:一个业务拆分成多个子业务,子业务分别部署在不同的服务器上
集群:同一个业务部署在多个服务器上
微服务就是把一个业务复杂的系统,拆分成为多个功能单一的小系统。对外提供api调用。每个服务都运行在自己独立的进程中。服务之间采用轻量级的通信机制相互沟通(http+rest),每个服务都能够独立部署。
2.服务之间是如何独立通信的
分为同步和异步
同步有:rest+http以及RPC TCP
REST 请求在微服务中是最为常用的一种通讯方式,它依赖于 HTTP\HTTPS 协议。RESTFUL 的特点是:
-
每一个 URI 代表 1 种资源
-
客户端使用 GET、POST、PUT、DELETE 4 个表示操作方式的动词对服务端资源进行操作:GET 用来获取资源,POST 用来新建资源(也可以用于更新资源),PUT 用来更新资源,DELETE 用来删除资源
-
通过操作资源的表现形式来操作资源
-
资源的表现形式是 XML 或者 HTML
-
客户端与服务端之间的交互在请求之间是无状态的,从客户端到服务端的每个请求都必须包含理解请求所必需的信息
RPC(Remote Procedure Call)远程过程调用,简单的理解是一个节点请求另一个节点提供的服务。它的工作流程是这样的: -
执行客户端调用语句,传送参数
-
调用本地系统发送网络消息
-
消息传送到远程主机
-
服务器得到消息并取得参数
-
根据调用请求以及参数执行远程过程(服务)
-
执行过程完毕,将结果返回服务器句柄
-
服务器句柄返回结果,调用远程主机的系统网络服务发送结果
-
消息传回本地主机
-
客户端句柄由本地主机的网络服务接收消息
-
客户端接收到调用语句返回的结果数据
异步是通过各种消息中间件
3.springcloud和dubbo的区别
-
spring cloud基于HTTP协议,以json传输数据,dubbo基于tcp协议,直接用字节数组传输,速度比spring cloud快
-
最大的区别:dubbo 底层是使用 Netty 这样的 NIO 框架,是基于TCP 协议传输的,配合以 Hession 序列化完成 RPC 通信。
SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的通信,相对来说,Http 请求会有更大的报文,占的带宽也会更多。但是REST 相比 RPC 更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖。
4.springboot和springcloud
- springboot专注于快速的开发单体服务
- springcloud是关注于全局的微服务协调治理框架
- springboot不依赖于springcloud 但是springcloud依赖于spring boot
5.什么是服务熔断什么是服务降级
- 服务熔断相当于保险丝超过一定的负荷断了,当服务的下游服务突然不可用或者响应过慢,上游服务为了保证服务可用,直接返回我们定义的fallbackmethod
- 服务降级是从整个系统的负荷考虑的,舍弃一些不经常用的服务来确保高频服务的正常运行。用户调用这些舍弃的服务时 也能正常调用,只不过返回的是我们定义的fallback
6.微服务的优缺点是什么,说说你在项目中遇到的坑
优点
- 每个服务足够内聚,代码容易理解
- 开发人员不需要理解整个微服务,只需要管自己负责的一个服务,开发更快捷
- 微服务松耦合,部署独立
- 每个微服务都有自己的存储能力,可以有自己的数据库,也可以使用统一的数据库
- 微服务只是业务逻辑代码,不会和html页面混合实现了真正的前后端分离
缺点
7.你所知道的微服务的技术栈有哪些
- 服务开发的spring boot
- 注册和发现的 eureka 和zookeeper
- 服务熔断降级的 hystrix
- 服务网关用的 zuul
- 负载均衡用的 ribbon
- 服务间接口调用的 fegin
- 配置中心用的 springconfig
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。