面试笔记之微服务篇

前言

       最近刚学完 Spring Cloud Netflix ,但是学完之后感觉虽然能写简单的微服务项目了，但是对微服务的一些组件还是一知半解的，甚至对一些组件作用都难以窥其全貌，所以特出此文章，了解微服务的组件作用，并且顺便整理一下微服务的面试题。随知随记，如果想了解更多的面试题可以关注我，私信我或者在文章下留言，谢谢！

正文

一，什么是微服务？

        微服务是一种架构模式或者说是一种架构风格，简称微服务架构，它提倡将单一应用程序划分成一组小的服务，每个服务能够独立运行，服务之间互相协调、互相配合，为用户提供最终价值。 服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

        微服务的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合,每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，可以拥有自己独立的数据库也可以共用一个数据库。

详细文章请参考官方文档：Microservices

二，微服务的优缺点？

优点：

• 每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求
• 开发简单、开发效率提高，一个服务可能就是专一的只干一件事。
• 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
• 微服务能使用不同的语言开发。
• 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Hudson, bamboo 。
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
• 微服务允许你利用融合最新技术。
• 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
• 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库

缺点：  

• 开发人员要处理分布式系统的复杂性
• 多服务运维难度，随着服务的增加，运维的压力也在增大
• 系统部署依赖
• 服务间通信成本
• 分布式数据一致性
• 系统集成测试
• 性能监控

三，微服务之间如何通讯？

1，REST HTTP 协议（同步）

    REST 请求在微服务中是最为常用的一种通讯方式, 它依赖于 HTTP\HTTPS 协议。RESTFUL的特点是：

• 每一个 URI 代表 1 种资源
• 客户端使用 GET、POST、PUT、DELETE 4 个表示操作方式的动词对服务端资源进行操作:GET 用来获取资源, POST 用来新建资源(也可以用于更新资源), PUT 用来更新资源,DELETE 用来删除资源
• 通过操作资源的表现形式来操作资源
• 资源的表现形式是 XML 或者 HTML
• 客户端与服务端之间的交互在请求之间是无状态的,从客户端到服务端的每个请求都必须包含理解请求所必需的信息

2，RPC TCP协议（异步）

   RPC(Remote Procedure Call)远程过程调用，简单的理解是一个节点请求另一个节点提供的服务。它的工作流程是这样的：

• 执行客户端调用语句，传送参数
• 调用本地系统发送网络消息
• 消息传送到远程主机
• 服务器得到消息并取得参数
• 根据调用请求以及参数执行远程过程（服务）
• 执行过程完毕，将结果返回服务器句柄
• 服务器句柄返回结果，调用远程主机的系统网络服务发送结果
• 消息传回本地主机
• 客户端句柄由本地主机的网络服务接收消息
• 客户端接收到调用语句返回的结果数据

3，同步和异步的区别？

        同步：所有的操作都做完，才返回给用户。这样用户在线等待的时间太长，给用户一种卡死了的感觉，并且这种情况下，用户不能关闭界面，如果关闭了，即迁移程序就中断了。 

        异步：将用户请求放入消息队列，并反馈给用户，系统程序已经启动，你可以关闭浏览器了。然后程序再慢慢地去写入数据库去。这就是异步。但是用户没有卡死的感觉，会告诉你，你的请求系统已经响应了。你可以关闭界面了                     

四，CAP理论

• Consistency(一致性)：更新操作成功并返回客户端后，所有节点在同数据完全一致。对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
• Availability(可用性)：即服务一直可用，而且是正常晌应时间。系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。
• Partition Tolerance（分区容错性）：分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。
• CP（高可用）和AP（高一致）：分区容错是必须保证的，当发生网络分区的时候，如果要继续服务，那么强一致性和可用性只能二选一。

五，BASE理论

        Basically Available（基本可用） 

        Soft state（状态）

        Eventually consistent（最终一致性）

        BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点采用适当的方式来使系统达到最终一致性。

• 基本可用:
• 晌应时间上的损失：正常情况下，处理用户请求需要0.55返回结果，但是由于系统出现故障，处理用户请求的时间变为3s。
• 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用
• 软状态：数据同步允许一定的延迟
• 最终一致性：系统中所有的数据副本,在经过一段时间的同步后,最终能够达到个一致的状态,不要求实时

六，请谈谈对SpringBoot 和SpringCloud的理解

1. SpringBoot专注于快速方便的开发单个个体微服务。
2. SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
3. SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot，属于依赖的关系.
4. SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。

七，什么是服务血崩？如何避免？

        服务血崩一般发生在多个微服务之间调用的时候，假设微服务A调用微服务B，微服务B调用微服务C，如果这条链路上服务B突然挂掉或者不可用，那么对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”，甚至这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。

一般情况对于这种情况主要有以下三种解决方案：

        熔断模式：这种模式主要是参考电路熔断，如果一条线路电压过高，保险丝会熔断，防止火灾。放到我们的系统中，如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。

        隔离模式：这种模式就像对系统请求按类型划分成一个个小岛的一样，当某个小岛被火烧光了，不会影响到其他的小岛。例如可以对不同类型的请求使用线程池来资源隔离，每种类型的请求互不影响，如果一种类型的请求线程资源耗尽，则对后续的该类型请求直接返回，不再调用后续资源。这种模式使用场景非常多，例如将一个服务拆开，对于重要的服务使用单独服务器来部署，再或者公司最近推广的多中心。

        限流模式：上述的熔断模式和隔离模式都属于出错后的容错处理机制，而限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。这种模式不能解决服务依赖的问题，只能解决系统整体资源分配问题，因为没有被限流的请求依然有可能造成雪崩效应。

八，什么是服务熔断，什么是服务降级？

        服务熔断：熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。

        在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制。熔断机制的注解是@HystrixCommand。

        服务降级：服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。

        一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。这样做，虽然水平下降，但好歹可用，比直接挂掉强。

九，你所知道的微服务技术栈有哪些？请列举一二

• 服务开发：Springboot、Spring、SpringMVC
• 服务配置与管理：Netflix公司的Archaius、阿里的Diamond等
• 服务注册与发现：Eureka、Consul、Zookeeper等
• 服务调用：Rest、RPC、gRPC
• 服务熔断器：Hystrix、Envoy等
• 负载均衡：Ribbon、Nginx等
• 服务接口调用(客户端调用服务的简化工具)：Feign等
• 消息队列：Kafka、RabbitMQ、ActiveMQ等
• 服务配置中心管理：SpringCloudConfig、Chef等
• 服务路由（API网关）：Zuul等
• 服务监控：Zabbix、Nagios、Metrics、Spectator等
• 全链路追踪：Zipkin，Brave、Dapper等
• 服务部署：Docker、OpenStack、Kubernetes等
• 数据流操作开发包：SpringCloud Stream（封装与Redis,Rabbit、Kafka等发送接收消息）
• 事件消息总线：Spring Cloud Bus

十，什么是 Eureka服务注册与发现

Eureka是Spring Cloud Netflix的五大核心组件之一

1，什么是服务治理？
        Spring Cloud封装了Netflix公司开发的Euraka模块来实现服务治理
在传统的rpc远程调用框架中，管理每个服务与服务之间依赖关系比较复杂，管理比较复杂，所以需要使用服务治理，管理服务与服务之间依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现与注册
2，什么是服务注册与发现？
        Eureka采用了CS的设计架构，Eureka Server作为服务注册功能的服务器，它是服务注册中心，而系统中的其他微服务，使用Euraka的客户端连接到Euraka Server并维持心跳连接。这样系统的维护人员就可以通过Euraka Server来监控系统中各个微服务是否正常运行
在服务注册与发现中，有一个注册中心，当服务器启动的时候，会把当前自己服务器的信息比如服务地址通讯地址等以别名方式注册到注册中心上。另一方（消费者|服务提供者），以该别名的方式去注册中心上获取到实际的服务通讯地址，然后再实现本地RPC调用

十一，作为服务注册中心，Eureka比Zookeeper好在哪里？

        著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。因此，Zookeeper保证的是CP, Eureka 则是AP

        当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s,且选举期间整个zookeeper集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zookeeper集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

        Eureka保证AP，Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务，而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。

        除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务，Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)，当网络稳定时，当前实例新的注册信息会被同步到其它节点中，因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

十二，什么是 Ribbon负载均衡，Ribbon负载均衡能干嘛？

        Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。

        简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。
        负载均衡(Load Balance)，在微服务或分布式集群中经常用的一种应用。
负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA。
常见的负载均衡有软件Nginx，LVS，硬件 F5等。
相应的在中间件，例如：dubbo和SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义。

        集中式LB：即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件，如F5, 也可以是软件，如nginx), 由该设施负责把访问请求通过某种策略转发至服务的提供方；

        进程内LB：将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。

注意：Ribbon属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。

十三，什么是 Feign 负载均衡？

        Feign是一个声明式WebService客户端。使用Feign能让编写Web Service客户端更加简单, 它的使用方法是定义一个接口，然后在上面添加注解，同时也支持JAX-RS标准的注解。Feign也支持可拔插式的编码器和解码器。Spring Cloud对Feign进行了封装，使其支持了Spring MVC标准注解和HttpMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。

十四，Feign 能做什么？

        前面在使用Ribbon+RestTemplate时，利用RestTemplate对http请求的封装处理，形成了一套模版化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义。在Feign的实现下，我们只需创建一个接口并使用注解的方式来配置它(以前是Dao接口上面标注Mapper注解,现在是一个微服务接口上面标注一个Feign注解即可)，即可完成对服务提供方的接口绑定，简化了使用Spring cloud Ribbon时，自动封装服务调用客户端的开发量。

        Feign集成了Ribbon，利用Ribbon维护了MicroServiceCloud-Dept的服务列表信息，并且通过轮询实现了客户端的负载均衡。而与Ribbon不同的是，通过feign只需要定义服务绑定接口且以声明式的方法，优雅而简单的实现了服务调用。Feign通过接口的方法调用Rest服务（之前是Ribbon+RestTemplate），该请求发送给Eureka服务器（http://MICROSERVICECLOUD-DEPT/dept/list）,通过Feign直接找到服务接口，由于在进行服务调用的时候融合了Ribbon技术，所以也支持负载均衡作用。

十五，什么是 Hystrix断路器？

        Hystrix是用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等， Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

        “断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

十六，Hystrix断路器能干嘛？

        服务降级：整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来

        服务熔断：熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回”错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。

        在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。

        服务限流：接近实时的监控，除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控（Hystrix Dashboard），Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。

        Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面。

十七，什么是 zuul路由网关？

Zuul 包含了对请求的路由和过滤两个最主要的功能：

        其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础而过滤器功能则负责对请求的处理过程进行干预，

        是实现请求校验、服务聚合等功能的基础.Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。

注意：Zuul服务最终还是会注册进Eureka，实现 代理+路由+过滤三大功能整合

十八，什么是SpringCloud Config分布式配置中心

        SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。

十九，分布式配置中心能干嘛？

• 集中管理配置文件
• 不同环境不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release
• 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息
• 当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置将配置信息以REST接口的形式暴露

二十，Spring Cloud和Dubbo区别?

1. 服务调用方式Dubbo是RPC ，SpringCloud 是 Rest 基于HTTP、HTTPS
2. 注册中心,Dubbo是Zookeeper SpringCloud是Eureka，也可以是Zookeeper
3. 服务网关,Dubbo本身没有实现，只能通过其他第三方技术整合，SpringCloud有Zuul路由网关，作为路由服务器，进行消费者的请求分发,SpringCloud支持断路器，与git完美集成配置文件支持版本控制，事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。
4. Spring Cloud 是一站式微服务解决方案，包括服务注册与发现，负载均衡，网关，服务熔断与降级，bus总线等都有相应的组件，但是Dubbo只是一个半自动的，大部分都需要整合别的组件，相对于Spring Cloud来说完善程度和简单程度都不行，但是相对灵活，适合高手玩！

二十一，什么是 Spring Cloud Bus？我们需要它吗？

        记得我们Spring Cloud Config想要动态刷新配置文件时，每一次都要运维人员先手动发送一次post请求到客户端吗？这样子虽然解决了不需要客户端重启的问题。可是后期微服务实例多了起来，难不成改一次配置文件就要手动发送几十次甚至上百次的post请求吗？当然这个我们写一个shell脚本，但是后期需要增加微服务实例时，就要修改一次脚本。还有一个问题，修改配置文件之后，有一些微服务实例需要让它更新最新配置，而有一些不让它更新，也就是我们常说的定点通知。这个我们手动控制的话成本还是很大的。

        Spring Cloud Config还真解决不了这个问题，所以需要一个新的组件Spring Cloud Bus，也就是消息总线。

        什么是总线：在微服务架构的系统中，通常会使用轻量级的消息代理来构建一个共用的消息主题，并让系统中所有的微服务实例都连接上来。由于该主题中产生的消息会被所有实例监听和消费，所以称它为消息总线。在总线中的各个实例，都可以方便地广播一些需要让其它连接在该主题上的实例都知道的信息。

        而Spring Cloud Bus就是实现该功能的技术。它是将分布式系统中的节点与轻量级消息系统链接起来的框架。整合了Java的事件处理机制和消息中间件的功能。所以我们谈消息总线，注定不能离开消息中间件，目前Spring Cloud Bus支持的消息中间件技术有RabbitMQ与Kafka。

        应用场景：我们运维工程师在Github上修改完配置之后，分布式配置中心自动拉取最新的配置信息，同时触发post请求给一个微服务实例。这个微服务实例在收到post请求之后会自动动态更新配置文件，更新完之后顺便把这个消息告诉Spring Cloud Bus。Spring Cloud Bus收到之后就把这个消息告诉其它的微服务实例，其它的微服务实例也就更新配置。这样下来，就实现了自动的动态配置更新。

当然它能做的事情还有很多，不只是动态的更新配置文件。

Spring Cloud Bus能管理和传播分布式系统间的消息，就像一个分布式执行器，可用于广播状态更改、事件推送等，也可以当作微服务间的通信通道。

二十二， Eureka 自我保护机制是什么?

        当 Eureka Server 节点在短时间内丢失了过多实例的连接时（比如网络故障或频繁启动关闭客户端）节点会进入自我保护模式，保护注册信息，不再删除注册数据，故障恢复时，自动退出自我保护模式

                                    未完待续。。。