全文目录
1：谈一谈你对微服务的理解？
2：微服务之间是如何独立进行通讯的？
3：springcloud和dubbo有哪些区别？
4：springboot和spring cloud得区别？
5：Eureka和ZooKeeper都可以提供服务注册与发现的功能,说说二者的区别？
6：什么是熔断？ 什么是服务降级？
7：说一下你所知道的微服务技术栈？
8：说一下CAP定理
1：谈一谈你对微服务的理解？
最初我们学习Java的时候接触的都是单机项目,会把各种业务需求，数据库链接，页面展示等都会糅合在一个项目中，如果说这个项目越来越大，功能模块越来越多，无论是部署还是维护都是比较麻烦的事情，针对这么情况就慢慢衍生出了微服务，简单的来说微服务架构的核心目标是把复杂问题简单化，通过模块划分，把一个完整的系统拆分成多个高内聚、低耦合的小的子系统。使得每个子系统可以独立的运行、升级和测试。然后再通过一些集成手段将这些子系统组合在一起，对外提供完整功能的过程。
2：微服务之间是如何独立进行通讯的？
- 同步：通过HTTP协议进行调用，接口使用restful风格的，数据格式采用json格式。dubbo采用的协议是rpc协议。
- 异步：mq,kafka
3：springcloud和dubbo有哪些区别？
- 采用的协议不同：springcloud采用HTTP协议，dubbo采用的是rpc协议。
- 两者的模块组成：Dubbo主要分为服务注册中心，服务提供者，服务消费者，还有管控中心；而SpringCloud则是一个完整的分布式一站式框架，他也有服务注册中心，服务提供者，服务消费者，管控台，断路器，分布式配置服务，消息总线，以及服务追踪等；
4：springboot和spring cloud得区别？
- SpringBoot是Spring推出用于解决传统框架配置文件冗余,简化Spring应用的初始搭建以及开发过程,可以快速搭建web应用;
- 而SpringCloud专注于解决各个微服务之间的协调与配置,服务之间的通信,熔断,负载均衡等技术维度,并且SpringCloud是依赖于SpringBoot的,而SpringBoot并不是依赖与SpringCloud,甚至还可以和Dubbo进行优秀的整合开发
总结:SpringBoot专注于快速方便的开发单个个体服务,SpringCloud是关注全局的微服务协调整理治理框架,整合并管理各个微服务,为各个微服务之间提供,配置管理,服务发现,断路器,路由,事件总线等集成服务SpringBoot不依赖于SpringCloud,SpringCloud依赖于SpringBoot。属于依赖关系SpringBoot专注于快速,方便的开发单个的微服务个体,SpringCloud关注全局的服务治理框架
5：Eureka和ZooKeeper都可以提供服务注册与发现的功能,请说说两个的区别
Eureka和ZooKeeper作为注册中心都可以给客户端提供可供调用的服务列表，客户端在进行远程调用时，根据服务提供方的服务地址从服务列表选择可被调用的服务。二者的区别在于zookeeper当节点出现故障的时候，它会在剩余的节点中重新选择主节点。但这个过程消耗时间会相对长，虽然最后也能恢复正常，但是选取主节点的过程中会导致服务不可用，这是不可容忍的。相比eureka各个节点是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，但是缺点就是查到的信息可能不是最新的(不保证强一致性)。
著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。Zookeeper保证的是CP, 而Eureka则是AP。
6：什么是熔断？ 什么是服务降级？
首先解析一下熔断出现的情景：假设系统中有A，B，C三个服务，服务A是上游，服务B是中游，服务C是下游,一旦下游服务C由于某些原因变得不可用，积压了大量请求，服务B的请求线程也随之阻塞。线程资源逐渐耗尽，使得服务B也变得不可用。紧接着，服务A也变为不可用，整个调用链路则被拖垮。进而引起系统崩溃这种情况就是所谓的“雪崩效应”。
扫描二维码关注公众号，回复： 13118037 查看本文章
在这种时候，就需要熔断机制来挽救整个系统，当某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是10秒内调用20次，如果失败，就会启动熔断机制。熔断机制的注解是@HystrixCommand。
服务降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。这样做，虽然水平下降，但好歹可用，比直接挂掉强。
7：说一下你所知道的微服务技术栈？
- 服务注册与发现：Eureka、Consul、Zookeeper等
- 服务调用：Rest、RPC、Feign
- 服务熔断器:Hystrix、Envoy等
- 负载均衡:Ribbon、Nginx等
- 消息队列：Kafka、RabbitMQ、ActiveMQ等
- 服务配置中心管理：SpringCloudConfig、Chef等
- 服务路由：（API网关）gateway、Zuul等
- 服务监控：Zabbix、Nagios、Metrics、Spectator等
- 全链路追踪:Zipkin，Brave、Dapper等
- 服务部署：Docker、OpenStack、Kubernetes等
- 数据流操作开发包：SpringCloud Stream（封装与Redis,Rabbit、Kafka等发送接收消息）
- 事件消息总线：Spring Cloud Bus
8：说一下CAP定理
CAP:指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
一致性：在分布式系统中的所有数据备份，在同一刻是同样的值（等同于在访问所以的节点的时候，主副数据一致）。
可用性：在集群中一部分的节点故障后，集群整体是否还能响应客户端的读写请求（对数据更新具有高可用）。
分区容错性：系统如果不能在时限内达成数据的一致性，就意味着发生了分区的情况，必须就当前的操作在C和A之前作出选择。
这三个要素最多只能同时实现两点，要是AP,要么CP,不可能三者兼顾(AC一般不考虑)。
欢迎关注公众号！公众号回复:入群 ，扫码加入交流群！
