谈一谈微服务的那些事

面向面试的博客，以问答式Q/A方式呈现。

---

Question1：谈一谈 服务注册与服务发现 ？

Answer1：

服务注册就是维护一个登记簿，它管理系统内所有的服务地址。当新的服务启动后，它会向登记簿交待自己的地址信息。服务的依赖方直接向登记簿要Service Provider地址就行了。当下用于服务注册的工具非常多，如ZooKeeper，Consul，Etcd, 还有 Netflix 家的 eureka 等。服务注册有两种形式：客户端注册和第三方注册。

客户端注册 （zookeeper ）
客户端注册是服务自身要负责注册与注销的工作。当服务启动后向注册中心注册自身，当服务下线时注销自己。期间还需要和注册中心保持心跳。心跳不一定要客户端来做，也可以由注册中心负责（这个过程叫探活）。这种方式的缺点是注册工作与服务耦合在一起，不同语言都要实现一套注册逻辑。

客户端注册如下图所示：

对于上图解释：
需要注册的服务Sevice，直接于服务注册中心Service Register打交道，两者之间有三个方法，包括注册register()、心跳heartbeat()、注销/取消注册unregister()，在这里，需要注册服务与注册中心耦合在一起，不符合低耦合的设计思想，且看第三方注册(独立的服务Register)。

第三方注册 （ 独立的服务 Registrar ）
第三方注册由一个独立的服务Registrar负责注册与注销。当服务启动后以某种方式通知Registrar，然后 Registrar 负责向注册中心发起注册工作。同时注册中心要维护与服务之间的心跳，当服务不可用时，向注册中心注销服务。这种方式的缺点是 Registrar 必须是一个高可用的系统，否则注册工作没法进展。

第三方注册如下图所示：

对于上图解释：
需要注册的服务Sevice，与独立的第三方服务Registrar打交道，当服务启动后以某种方式通知Registrar，期间Registrar每隔固定时间向服务Service发出心跳检查heartcheck，检查服务是否存活。
这样一来，服务Service可以去完全自己的业务逻辑，不需要在额外注册、额外注销、实时心跳通知服务注册中心。
由独立的服务Registrar直接于服务注册中心Service Register打交道，两者之间有三个方法，包括注册register()、心跳heartbeat()、注销/取消注册unregister()。当服务启动后通知Registrar，Registrar向服务注册中心注册该服务；服务启动后，Registrar按间隔时间对服务进行心跳检查heartcheck，若服务存活，调用heartbeat()汇报给服务注册中心，若服务不存活，调用unregsister()向服务注册中心注销该服务。
小结：第三方注册使用独立的服务Registrar，将注册服务于注册中心分离开来，符合低耦合的设计思想，当然，这种方式相对于客户端注册要额外提供一个高可用的Registrar系统。

客户端发现
客户端发现是指客户端负责查询可用服务地址，以及负载均衡的工作。这种方式最方便直接，而且也方便做负载均衡。再者一旦发现某个服务不可用立即换另外一个，非常直接。缺点也在于多语言时的重复工作，每个语言实现相同的逻辑。

客户端发现如下图所示：

对于上图解释：
运行中的服务Sevice作为客户端Client，使用http请求直接与服务端打交道，直接查询可用服务地址，用来实现负载均衡的工作。这种方式设计简单，但是客户端服务与服务端耦合在一起，不符合低耦合的设计思想，且看服务端注册。

服务端发现
服务端发现需要额外的 Router 服务，请求先打到 Router，然后 Router 负责查询服务与负载均衡。这种方式虽然没有客户端发现的缺点，但是它的缺点是保证 Router 的高可用。

服务端发现如下图所示：

对于上图解释：
运行中的服务Sevice作为客户端Client，通过使用request请求与Router路由沟通，由 Router 负责查询服务与负载均衡，服务Service不再过问查询服务和负载均衡的事。
小结：服务端注册，通过Router路由来代替客户端查询服务端，减轻客户端Service负担，当然，这种方式相对于客户端发现要要额外提供一个高可用的Router系统。

---

Question2：介绍一下“API网关/API Gateway”?

Answer2：

API Gateway 是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade 模式很像。API Gateway 封装内部系统的架构，并且提供 API 给各个客户端。它还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展示了一个适应当前架构的 API Gateway。

上图表示，API网关要监控几乎所有其他的业务模块，shopping cart service购物车服务、shopping service购物服务、inventory service库存清单服务、recommendation service推荐服务、order service订单服务、review service评论服务、product catalog service产品种类服务。

API Gateway 负责请求转发、合成和协议转换。所有来自客户端的请求都要先经过 API Gateway，然后路由这些请求到对应的微服务。API Gateway 将经常通过调用多个微服务来处理一个请求以及聚合多个服务的结果。它可以在 web 协议与内部使用的非 Web 友好型协议间进行转换，如HTTP 协议、WebSocket 协议。

请求转发
服务转发主要是对客户端的请求安装微服务的负载转发到不同的服务上。

响应合并
把业务上需要调用多个服务接口才能完成的工作合并成一次调用对外统一提供服务。

协议转换
重点是支持 SOAP，JMS，Rest 间的协议转换。

数据转换
重点是支持 XML 和 Json 之间的报文格式转换能力（可选）。

安全认证

1. 基于 Token 的客户端访问控制和安全策略
2. 传输数据和报文加密，到服务端解密，需要在客户端有独立的 SDK 代理包
3. 基于 Https 的传输加密，客户端和服务端数字证书支持
4. 基于 OAuth2.0 的服务安全认证(授权码，客户端，密码模式等）

---

Question3：简要介绍一下微服务架构配置中心？

Answer3：

配置中心一般用作系统的参数配置，它需要满足如下几个要求：高效获取、实时感知、分布式访问。

举例：zookeeper 配置中心
实现的架构图如下所示，采取数据加载到内存方式解决高效获取的问题，借助 zookeeper 的节点监听机制来实现实时感知。

上图表示，配置中心zookeeper，一旦有任何信息变更，会被观察者watcher观察到，然后通知业务逻辑层，再到接入层。

配置中心数据分类

上图表示，配置中心(conf center，全称configuration center)包括服务配置、各类开关、业务配置。
服务配置包括数据库服务配置、队列服务配置、缓存服务配置等；
各类开关包括各类功能开关、各类业务开关、各类服务开关；
业务配置如上图，包括模块A application src A（app src A1+app src A2），模块B application src B（app src B1+app src B2）等。

---

Question4：简述一下 事件调度 （kafka ）？

Answer4：

消息服务和事件的统一调度，常用用 kafka ，activemq 等。

---

Question5：简要介绍一下 服务跟踪 （ starter-sleuth ）？

Answer5：

随着微服务数量不断增长，需要跟踪一个请求从一个微服务到下一个微服务的传播过程， SpringCloud Sleuth 正是解决这个问题，它在日志中引入唯一 ID，以保证微服务调用之间的一致性，这样你就能跟踪某个请求是如何从一个微服务传递到下一个。

1. 为了实现请求跟踪，当请求发送到分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识，同时在分布式系统内部流转的时候，框架始终保持传递该唯一标识，直到返回给请求方为止，这个唯一标识就是前文中提到的 Trace ID。通过 Trace ID 的记录，我们就能将所有请求过程日志关联起来。
2. 为了统计各处理单元的时间延迟，当请求达到各个服务组件时，或是处理逻辑到达某个状态时，也通过一个唯一标识来标记它的开始、具体过程以及结束，该标识就是我们前文中提到的 Span ID，对于每个 Span 来说，它必须有开始和结束两个节点，通过记录开始 Span 和结束 Span 的时间戳，就能统计出该 Span 的时间延迟，除了时间戳记录之外，它还可以包含一些其他元数据，比如：事件名称、请求信息等。
3. 在快速入门示例中，我们轻松实现了日志级别的跟踪信息接入，这完全归功于spring-cloud-starter-sleuth 组件的实现。在 Spring Boot 应用中，通过在工程中引入 spring-cloud-starter-sleuth 依赖之后， 它会自动的为当前应用构建起各通信通道的跟踪机制，比如：
   （1）通过诸如 RabbitMQ、Kafka（或者其他任何 Spring Cloud Stream 绑定器实现的消息中间件）传递的请求。
   （2）通过 Zuul 代理传递的请求。
   （3）通过 RestTemplate 发起的请求。

---

Question6：介绍一下服务熔断 （Hystrix ）？

Answer6：

在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。

熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费 CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。

Hystrix 断路器机制
断路器很好理解, 当 Hystrix Command 请求后端服务失败数量超过一定比例(默认 50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认 5 秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况,如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix 的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力。