微服务

最新推荐文章于 2022-11-01 08:50:50 发布

原创最新推荐文章于 2022-11-01 08:50:50 发布 · 180 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#java #微服务 #springcloud

java 专栏收录该内容

129 篇文章

订阅专栏

微服务知识点

（1）服务注册发现

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

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

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

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

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

服务端发现
Consul
Consul：分布式、高可用、可横向扩展的用于实现分布式系统的服务发现与配置。
1.服务发现（Service Discovery）：
通过DNS或者HTTP接口的方式来注册服务和发现服务。一些外部的服务通过Consul很容易的找到它所依赖的服务。
2.健康检查（Health Checking）
Consul的Client可以提供任意数量的健康检查，既可以与给定的服务相关联(“webserver是否返回200 OK”)，也可以与本地节点相关联(“内存利用率是否低于95%”)。我们可以使用这些信息来监视集群的健康状况，服务发现组件可以使用这些信息将流量从不健康的主机路由出去。
3.Key/Value存储：
应用程序可以根据自己的需要使用Consul提供的Key/Value存储。 Consul提供了简单易用的HTTP接口，结合其他工具可以实现动态配置、功能标记、领袖选举等等功能。
4.安全服务通信：
Consul可以为服务生成和分发TLS证书，以建立相互的TLS连接。意图可用于定义允许哪些服务通信。服务分割可以很容易地进行管理，其目的是可以实时更改的，而不是使用复杂的网络拓扑和静态防火墙规则。
5.多数据中心：
Consul支持开箱即用的多数据中心. 这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。
使用场景
包括服务发现、服务隔离、服务配置：
服务发现场景中consul作为注册中心，服务地址被注册到consul中以后，可以使用consul提供的dns、http接口查询，consul 支持health check。
服务隔离场景中consul支持以服务为单位设置访问策略，能同时支持经典的平台和新兴的平台，支持tls证书分发，service-to-service加密。
服务配置场景中consul提供key-value数据存储功能，并且能将变动迅速地通知出去，借助Consul可以实现配置共享，需要读取配置的服务可以从Consul中读取到准确的配置信息。
Eureka
Eureka ：Spring Cloud 体系中最核心、默认的注册中心组件。
核心概念
Eureka Server：注册中心服务端，提供了三个功能：服务注册、提供注册表、同步状态。
Eureka Client：注册中心客户端，有Register: 服务注册、Renew: 服务续约、Eviction 服务剔除、Cancel: 服务下线、GetRegisty: 获取注册列表信息。
工作流程
1、Eureka Server 启动成功，等待服务端注册。在启动过程中如果配置了集群，集群之间定时通过 Replicate 同步注册表，每个 Eureka Server 都存在独立完整的服务注册表信息。

2、Eureka Client 启动时根据配置的 Eureka Server 地址去注册中心注册服务。

3、Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求，证明客户端服务正常。

4、当 Eureka Server 90s 内没有收到 Eureka Client 的心跳，注册中心则认为该节点失效，会注销该实例。

5、单位时间内 Eureka Server 统计到有大量的 Eureka Client 没有上送心跳，则认为可能为网络异常，进入自我保护机制，不再剔除没有上送心跳的客户端。

6、当 Eureka Client 心跳请求恢复正常之后，Eureka Server 自动退出自我保护模式。

7、Eureka Client 定时全量或者增量从注册中心获取服务注册表，并且将获取到的信息缓存到本地。

8、服务调用时，Eureka Client 会先从本地缓存找寻调取的服务。如果获取不到，先从注册中心刷新注册表，再同步到本地缓存。

9、Eureka Client 获取到目标服务器信息，发起服务调用。

10、Eureka Client 程序关闭时向 Eureka Server 发送取消请求，Eureka Server 将实例从注册表中删除。

Etcd
目标是构建一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法，etcd基于Go语言实现。

etcd作为服务发现系统，有以下的特点：
简单：安装配置简单，而且提供了HTTP API进行交互，使用也很简单。
安全：支持SSL证书验证。
快速：根据官方提供的benchmark数据，单实例支持每秒2k+读操作。
可靠：采用raft算法，实现分布式系统数据的可用性和一致性。

SmartStack
Airbnb的自动服务发现和注册框架。
它通过透明地处理你组织中运行代码的创建、删除、异常及维修工作使工程师的日常工作更便利。

（2）API 网关

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

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

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

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

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

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

安全认证

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

（3）配置中心

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

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

zookeeper配置中心
配置中心数据分类

（4）事件调度

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

（5）服务跟踪（starter-sleuth）

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

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

（6）服务熔断（Hystrix）

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

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

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