内容纲要

一、服务注册发现

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

服务注册有两种形式：

客户端注册
第三方注册

1.1 客户端注册（zookeeper）

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

1.2 第三方注册（独立的服务 Registrar）

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

1.3 客户端发现

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

1.4 服务端发现

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

1.5 Consul

官网文档地址：https://www.consul.io/docs

Consul是一款开源的、分布式的服务发现和配置管理工具，由HashiCorp开发。Consul的主要功能包括服务发现、健康检查、键值存储以及多数据中心支持。Consul旨在解决分布式系统中的服务发现和配置管理问题。

使用场景：在构建大型的微服务架构系统时，Consul可以作为服务发现和配置管理的基础设施。

优点：

易于集成和使用，支持HTTP和DNS协议。
支持多数据中心，可进行横向扩展。
基于Raft协议，保证了一致性和容错性。

缺点：

对于大量服务实例，性能可能会受到影响。
对于较小的项目，Consul可能会显得过于复杂。

1.6 Eureka

官网文档地址：https://github.com/Netflix/eureka/wiki

Eureka是Netflix开源的一款服务发现工具。主要功能包括服务注册与发现、健康检查以及负载均衡。Eureka旨在解决分布式系统中的服务发现和负载均衡问题。

使用场景：在构建基于Spring Cloud体系的微服务架构系统时，Eureka可以作为服务发现和负载均衡的基础设施。

优点：

与Spring Cloud生态集成良好。
支持自我保护模式，提高系统的可用性。
优秀的可视化界面。

缺点：

只支持Java编写的服务。
不支持多数据中心。

使用样例：https://spring.io/guides/gs/service-registration-and-discovery/

1.7 SmartStack

官网文档地址：http://nerds.airbnb.com/smartstack-service-discovery-cloud/

SmartStack是Airbnb开源的一款服务发现工具，包括两个组件：Nerve和Synapse。Nerve负责服务注册，而Synapse负责服务发现。SmartStack通过ZooKeeper实现服务发现和健康检查。

使用场景：在构建需要轻量级服务发现解决方案的系统时，SmartStack可以作为候选工具。

优点：

简单且轻量级。
支持多语言和多平台。
基于ZooKeeper，保证了一致性和容错性。

缺点：

社区支持较弱。
依赖于ZooKeeper，增加了系统复杂性。

使用样例：https://github.com/airbnb/smartstack-cookbook

1.8 Etcd

官网文档地址：https://etcd.io/docs/

Etcd是一个开源的、分布式的键值存储系统，由CoreOS开发。它主要用于配置管理、服务发现以及共享锁等分布式系统的核心功能。Etcd使用Raft协议保证了数据的一致性和容错性。

使用场景：在构建需要可靠的分布式系统和配置管理的应用时，Etcd可以作为基础设施。Kubernetes就是一个典型的使用Etcd作为其存储后端的例子。

优点：

高可用性和一致性，基于Raft协议。
轻量级且易于使用，支持多种编程语言的客户端。
支持多数据中心和横向扩展。

缺点：

对于较小的项目，Etcd可能会显得过于复杂。
需要一定的学习成本，特别是对于Raft协议的理解。

总结：

Consul：功能强大的服务发现和配置管理工具，适用于大型的微服务架构系统。

Eureka：与Spring Cloud体系集成良好的服务发现工具，适用于基于Spring Cloud的微服务系统。

SmartStack：轻量级的服务发现工具，适用于需要简单解决方案的系统。

Etcd：分布式键值存储系统，适用于需要可靠的分布式系统和配置管理的应用。

根据项目的具体需求和技术栈选择合适的服务发现和配置管理工具。

二、API 网关

API Gateway 是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade 模式很像。

API Gateway 封装内部系统的架构，并且提供 API 给各个客户端。它还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。

下图展示了一个适应当前架构的 API Gateway。

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

2.1 请求转发

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

2.2 响应合并

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

2.3 协议转换

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

1. SOAP（Simple Object Access Protocol）

SOAP是一种基于XML的轻量级通信协议，用于在分布式应用和网络服务之间进行数据交换。SOAP可以与任何传输协议一起使用，如HTTP、SMTP和TCP/IP等。SOAP主要用于实现基于Web服务的分布式系统。

使用场景：SOAP通常用于实现跨平台、跨语言的Web服务，特别是那些对安全性和事务性要求较高的企业级应用。

优点：

标准化，易于跨平台和跨语言整合。
支持复杂的数据类型和结构。
内置错误处理机制。
支持安全性和事务性。

缺点：

基于XML，导致数据传输量较大，性能较差。
学习和实现成本较高。

2. JMS（Java Message Service）

JMS是Java平台上的一种消息中间件API，用于在分布式应用之间发送和接收消息。JMS支持两种消息传递模型：点对点（P2P）和发布订阅（Pub/Sub）。JMS主要用于实现基于Java的分布式系统的异步通信。

使用场景：JMS通常用于实现Java平台上的企业级应用，特别是那些对可靠性、异步通信和解耦要求较高的系统。

优点：

支持异步通信，提高系统的可伸缩性和解耦性。
支持多种消息传递模型。
易于与Java平台集成。

缺点：

只支持Java编写的服务。
实现和部署相对复杂。
可能需要使用特定的消息中间件产品。

3. REST（Representational State Transfer）

REST是一种基于HTTP协议的软件架构风格，用于构建轻量级、易于维护和扩展的网络应用。REST使用标准的HTTP方法（如GET、POST、PUT和DELETE）对资源进行操作。RESTful API是遵循REST原则的Web服务接口。

使用场景：REST适用于构建面向公众或内部系统的轻量级Web服务，特别是那些需要与不同平台和编程语言整合的应用。

优点：

简单易用，基于HTTP协议。
轻量级，性能较好。
跨平台和跨语言支持。
无状态性，易于扩展和维护。

缺点：

无状态性可能导致每次请求都需要重新认证。
对实时通信和事务性支持较弱。

总结：

SOAP：适用于跨平台、跨语言的复杂Web服务，特别是对安全性和事务性要求较高的企业级应用。

JMS：适用于Java平台上的企业级应用，特别是对可靠性、异步通信和解耦要求较高的系统。

REST：适用于轻量级Web服务，特别是需要与不同平台和编程语言整合的应用。

根据项目的具体需求、技术栈和目标场景选择合适的通信协议。例如，

对于跨平台的复杂Web服务，SOAP可能是一个不错的选择；

对于基于Java的企业级应用，JMS是一个合适的解决方案；

对于轻量级、易于维护和扩展的Web服务，REST是更好的选择。

2.4 数据转换

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

2.5 安全认证

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

三、配置中心

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

3.1 zookeeper 配置中心

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

3.2 配置中心数据分类

四、事件调度（kafka）

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

五、服务跟踪（starter-sleuth）

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

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

六、服务熔断（Hystrix）

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

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

6.1 Hystrix 断路器机制

断路器很好理解：

当 Hystrix Command 请求后端服务失败数量超过一定比例(默认 50%), 断路器会换到开路状态(Open)。这时所有请求会直接失败而不会发送到后端服务。

断路器保持在开路状态段时间后(默认 5 秒), 自动切换到半开路状态(HALF-OPEN)。这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN)。

Hystrix 的断路器像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效求影响系统吞吐量, 并且断路器有自我检测并恢复的能力。

七、API 管理

SwaggerAPI 管理工具。
swagger-ui download

面试题 – 微服务