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页面混合实现了真正的前后端分离
缺点
