面试必备干货 | 微服务相关组件

服务治理/Discovery

服务治理是微服务架构中最核心最基本的模块。用于实现各个微服务的自动化注册与发现。

常见注册中心

1. Zookeeper：分布式服务框架，可解决数据管理问题，例如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理。

2. Eureka（主要是做服务注册和发现。闭源了）

3. Consul：可以做服务注册和发现，配置管理，健康检查，分布式一致性保证等。本身是二进制可执行文件

4. Nacos：Spring Cloud Alibaba组件之一，可认为是Eureka+Config。

   关于Nacos：
   Nacos(服务注册中心，有着注册和发现的功能)很好的兼容了Feign(服务调用功能)， Feign默认集成了 Ribbon(负载均衡功能)， 所以在Nacos下使用Fegin默认就实现了负载均衡的效果。
   
   其中Feign和Ribbon都是Spring Cloud自带的组件。Feign是Spring Cloud提供的一个声明式的伪Http客户端， 它使得调用远程服务就像调用本地服务一样简单， 只需要创建一个接口并添加一个注解即可。
   

服务容错

在分布式系统中,由于网络原因或自身的原因,服务一般无法保证 100% 可用。如果一个服务出现了问题，调用这个服务就会出现线程阻塞的情况，此时若有大量的请求涌入，就会出现多条线程阻塞等 待，进而导致服务瘫痪。所以要做好服务容错避免服务瘫痪雪崩的扩散。

常见的容错思路有隔离、超时、限流、熔断、降级这几种。

常用的容错组件：

1. Hystrix：是由Netflflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库。

2. Resilicence4J：一款非常轻量、简单，并且文档非常清晰、丰富的熔断工具，这也是Hystrix官方推 荐的替代产品。不仅如此，Resilicence4j还原生支持Spring Boot 1.x/2.x，而且监控也支持和 prometheus等多款主流产品进行整合。

3. Sentinel ：阿里巴巴开源的一款断路器实现。

   关于Sentinel：
   Sentinel (分布式系统的流量防卫兵) 是阿里开源的一套用于服务容错的综合性解决方案。它以流量
   为切入点, 从流量控制、熔断降级、系统负载保护等多个维度来保护服务的稳定性。
   
   Sentinel 提供开箱即用的与其它开源框架/库的整合模块, 例如与 Spring Cloud、Dubbo、gRPC 的整合。只需要引入相应的依赖并进行简单的配置即可快速地接入Sentinel。
   
   Sentinel的主要功能就是容错，主要体现为下面这三个：
   1. 流量控制
   2. 熔断降级(“通过并发线程数进行限制”和“通过响应时间对资源进行降级”两种方式)
   3. 系统负载保护
   

服务网关/Gateway

所谓的API网关，就是指系统的统一入口，它封装了应用程序的内部结构，为客户端提供统一服务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、鉴权、监控、路由转发等等。

常用网关：

1. Ngnix+lua (使用nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用)
2. Kong（基于Nginx+Lua开发，性能高，稳定，有多个可用的插件(限流、鉴权等等)可以开箱用。但存在的问题是： 只支持Http协议；二次开发，自由扩展困难；提供管理API，缺乏更易用的管控、配置方式。）
3. Zuul
4. Spring Cloud Gateway

Spring Cloud Gateway内部执行大体流程：

1. Gateway Client向Gateway Server发送请求
2. 请求首先会被HttpWebHandlerAdapter进行提取组装成网关上下文
3. 然后网关的上下文会传递到DispatcherHandler，它负责将请求分发给RoutePredicateHandlerMapping
4. RoutePredicateHandlerMapping负责路由查找，并根据路由断言判断路由是否可用(断言可看做是限制条件)
5. 如果过断言成功，由FilteringWebHandler创建过滤器链并调用
6. 请求会一次经过PreFilter--微服务--PostFilter的方法，最终返回响应

链路追踪/ Sleuth

分布式链路追踪（Distributed Tracing），就是将一次分布式请求还原成调用链路，进行日志记录，性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

常见的链路追踪技术有下面这些：

1. cat：由大众点评开源，基于Java开发的实时应用监控平台，对代码的侵入性很大，集成成本高。风险大。
2. zipkin：由Twitter公司开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微服务架构中的延迟问题，包括：数据的收集、存储、查找和展现。该产品结合spring-cloud-sleuth使用较为简单， 集成很方便， 但是功能较简单。
3. pinpoint：是韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。
4. skywalking：是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端无代码侵入。
5. Sleuth：SpringCloud 提供的分布式系统中链路追踪解决方案。

Sleuth相关术语

Trace：通过传递一个TraceID记录整个请求从进入框架到请求返回的过程，将其串联在一起形成一个完整的请求链路。
Span：代表一组基本的工作单元。也是通过一个SpanID的开始和结束时间戳来记录该Span的调用时间。
Annotation：代表一段时间内的事件，与Span联用。

下面是一些Annotation事件的概念：
cs（Client Send）客户端发出请求，开始一个请求的生命
sr（Server Received）服务端接受到请求开始进行处理， sr－cs = 网络延迟（服务调用的时间）
ss（Server Send）服务端处理完毕准备发送到客户端，ss - sr = 服务器上的请求处理时间
cr（Client Reveived）客户端接受到服务端的响应，请求结束。 cr - sr = 请求的总时间

启动微服务，调用之后，我们可以在控制台观察到sleuth的日志输出如下：
以下参数分别对应[微服务名称, traceId, spanid, 是否将链路的追踪结果输出到第三方平台]
[api-gateway,3977125f73391553,3977125f73391553,false]
[service-order,3977125f73391553,57547b5bf71f8242,false]
[service-product,3977125f73391553,449f5b3f3ef8d5c5,false]

链路追踪查看方式：

查看日志文件并不是一个很好的方法，当微服务越来越多日志文件也会越来越多，通过Zipkin可以将日志聚合，并进行可视化展示和全文检索。

关于ZIPkin

Zipkin 是 Twitter 的一个开源项目，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。
我们可以使用它来收集各个服务器上请求链路的跟踪数据，并通过它提供的REST API接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序，从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。
除了面向开发的 API 接口之外，它也提供了方便的UI组件来帮助我们直观的搜索跟踪信息和分析请求链路明细，比如：可以查询某段时间内各用户请求的处理时间等。
Zipkin 提供了可插拔数据存储方式：In-Memory、MySql、Cassandra 以及 Elasticsearch。

Sleuth和Zipkin的联用：

Zipkin分为两端，一个是 Zipkin服务端，一个是 Zipkin客户端，客户端也就是微服务的应用。 客户端会配置服务端的 URL 地址，一旦发生服务间的调用的时候，会被配置在微服务里面的 Sleuth 的监听器监听，并生成相应的 Trace 和 Span 信息发送给服务端。

消息队列/MQ

常见应用场景：

• 异步解耦（主要目的是减少请求响应时间和解耦。主要的使用场景就是将比较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列。同时，由于使用了消息队列 MQ，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响，即解耦合）
• 流量削峰

常用的MQ产品：

• ZeroMQ：如果做为消息队列使用，需要开发大量的代码。
• RabbitMQ ：使用erlang语言开发，性能较好，适合于企业级的开发。但是不利于做二次开发和维护。
• ActiveMQ ：历史悠久的Apache开源项目。实现了JMS1.1规范，可以和springjms轻松融合，实现了多种协议，支持持久化到数据库，对队列数较多的情况支持不好。
• RocketMQ ：阿里巴巴的MQ中间件，由java语言开发，性能非常好，能够撑住双十一的大流量，而且使用起来很简单。
• Kafka ：Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统， 相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。(集群管理时需要使用过ZooKeeper来管理)

RocketMQ发送不同类型的消息处理方式也不同

• 当发送普通消息时，RocketMQ有三种不同方式：可靠同步发送、可靠异步发送和单向发送

  1.可靠同步发送：是指消息发送方发出数据后，会在收到接收方发回响应之后才发下一个数据包的通讯方式。
  此种方式应用场景非常广泛，例如重要通知邮件、报名短信通知、营销短信系统等。
      
  2.可靠异步发送：是指发送方发出数据后，不等接收方发回响应，接着发送下个数据包的通讯方式。发送方通过回调接口接收服务器响应，并对响应结果进行处理。
  异步发送一般用于链路耗时较长，对 RT 响应时间较为敏感的业务场景，例如用户视频上传后通知启动转码服务，转码完成后通知推送转码结果等。
  
  3.单向发送：是指发送方只负责发送消息，不等待服务器回应且没有回调函数触发，即只发送请求不
  等待应答。
  适用于某些耗时非常短，但对可靠性要求并不高的场景，例如日志收集。
  

• 当发送顺序消息时，RocketMQ会按一种严格按照顺序来发布和消费。一般适用于需要按顺序来完成的任务，例如订单创建–>订单付款–>订单完成。

• 当发送事务消息时，会按照以下过程来保证分布式事务的一致性。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6BGw66Fw-1585497621959)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1583247859622.png)]

服务配置/Config

配置中心的出现是为了解决项目中微服务的配置文件相对分散、配置文件无法区分环境还有配置文件无法实施更新的问题。

配置中心的思路是：

1. 首先把项目中各种配置全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。
2. 当各个服务需要获取配置的时候，就来配置中心的接口拉取自己的配置。
3. 当配置中心中的各种参数有更新的时候，也能通知到各个服务实时的过来同步最新的信息，使之动态更新。

常用的配置中心

Apollo ：是由携程开源的分布式配置中心。特点有很多，比如：配置更新之后可以实时生效，支持灰度发布功能，并且能对所有的配置进行版本管理、操作审计等功能，提供开放平台API。

Apollo是由携程开源的分布式配置中心。特点有很多，比如：配置更新之后可以实时生效，支持灰

Disconf ：Disconf是由百度开源的分布式配置中心。它是基于Zookeeper来实现配置变更后实时通知和生效的。

SpringCloud Confifig ：这是Spring Cloud中带的配置中心组件。它和Spring是无缝集成，使用起来非常方便，并且它的配 置存储支持Git。不过它没有可视化的操作界面，配置的生效也不是实时的，需要重启或去刷新。

Nacos：这是SpingCloud alibaba技术栈中的一个组件，前面我们已经使用它做过服务注册中心。其实它也集成了服务配置的功能，我们可以直接使用它作为服务配置中心

分布式事务

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同 的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

本质上来说，分布式事务就是为了保证不同数据库的数据一致性。