微服务系统面经

微服务架构

秒杀微服务架构图

项目地址可以参考：秒杀系统

1 微服务基本概念

1.1 微服务的理解（优缺点）：

优势：可以独立开发、部署和扩展每个服务；更好的故障隔离；可以根据服务的需求使用不同的技术栈；更容易组织围绕业务能力的团队。
劣势：可能需要更多的资源来运行所有服务；网络延迟可能会增加；需要更多的跨服务管理工作（例如服务发现，负载均衡，断路器）；数据一致性可能更难保证。

1.2 服务拆分的原则及实践

• 单一职责原则：每个服务都应该只做一件事情，这样可以使其独立开发、部署和扩展。
• 业务驱动：服务的边界应该根据业务能力来确定，而不是根据技术考虑。
• 数据一致性：考虑数据如何在多个服务之间共享和保持一致性。
• 松散耦合：服务之间应该尽可能地解耦，这样一个服务的变化不会影响到其它服务。

2 微服务网关

2.1 你说的单一网关的情况，流量来自于微服务系统内部吗还是用户呢？

在一个单一网关的微服务架构中，这个网关通常处理来自于两个主要源的流量：

1. 外部用户：网关负责处理所有从外部用户或者第三方系统发出的请求。这可能包括来自于用户界面的请求、来自于第三方API的请求，或者其他来源的请求。

2. 内部服务：网关还可能负责处理来自于系统内部的服务间通信。例如，一个服务可能需要通过网关请求另一个服务的资源。

这个单一网关成为了所有请求的统一入口，提供了路由、认证、授权、限流、熔断、负载均衡等功能。然而，这种设计也可能带来一些问题，例如单点故障、性能瓶颈等。因此，在设计微服务系统时，需要根据实际的需求和约束来选择合适的网关策略。

2.2 一个java的微服务系统中有几个网关？

在一个Java的微服务系统中，网关的数量并不固定，这完全取决于系统的设计和需求。网关服务是微服务架构中的重要组件，它通常负责路由、认证、授权、限流、熔断、负载均衡等功能，为微服务提供统一的入口。

以下是几种可能的网关设计策略：

1. 单一网关：在一些简单的微服务架构中，可能只有一个网关服务，负责处理所有进入系统的请求。

2. 多网关：在更复杂的微服务架构中，可能会有多个网关，每个网关负责处理特定类型的请求。例如，可以有一个网关专门用于处理内部服务间的通信，另一个网关用于处理外部用户的请求。

3. 分域网关：在某些大规模或者多租户的微服务架构中，可能会根据业务领域或者租户划分多个网关。

在实际的系统设计中，微服务的网关数量取决于多种因素，包括系统的规模、业务复杂度、性能要求、安全性要求等等。所以，并没有一个固定的答案来确定微服务系统中应该有几个网关。

3 微服务系统内部的调用，比如A调用服务B这种需要经过网关吗？

在微服务系统的设计中，服务之间的调用是否需要经过网关取决于具体的设计决策。这主要受到以下两种设计模式的影响：

1. 直接服务调用：在某些情况下，一个服务（服务A）可能会直接调用另一个服务（服务B）。这种设计模式允许服务之间的通信不需要经过网关，通常可以提高性能并减少延迟。然而，这种模式需要在每个服务中实现鉴权、限流等功能，可能会增加设计和开发的复杂性。

2. 通过网关调用：在另一些情况下，服务之间的调用可能需要经过网关。这种设计模式允许所有的服务间通信都通过同一点进行，可以在这一点上实现统一的鉴权、限流、熔断等功能。这种模式可以简化服务的设计和开发，但可能会增加延迟并成为系统的单点故障。

以上都是可能的设计决策，实际的选择取决于微服务系统的具体需求和约束。例如，对于一些非常大或者复杂的微服务系统，可能会选择混合的模式，其中一部分服务调用通过网关，而另一部分服务调用则直接进行。

4 请求的接收和返回路径

1 一个请求到达最终的业务服务器可能会经过nginx网关，微服务网关等中间层，最终业务服务器执行完请求后的响应是按照原路返回吗还是直接打给发出请求的客户端？为什么?

1. 一个网络请求在到达最终的业务服务器之前，确实可能会经过多个中间层，比如nginx代理，微服务网关等。当业务服务器完成请求处理并生成响应后，这个响应通常会按照原路返回，也就是说，它会首先返回到它来时所经过的那些中间层，然后才会返回到发出请求的客户端。

   这样做的原因有以下几点：

   • 层级架构和安全性：请求和响应都需要经过网络中的各层，因为这样的层级架构有助于管理网络流量，增强安全性，比如说防火墙、代理服务器、缓存服务器等都可以在请求和响应的路上对其进行处理。

   • 性能优化：有些中间层可能会对响应进行缓存或者其他形式的处理以提高性能。比如，一个代理服务器可能会缓存响应，这样当它收到相同的请求时，就可以直接从缓存中提供响应，而无需再次将请求发送到业务服务器。

   • 转换或扩展功能：有些中间层可能会修改响应，或者添加一些额外的功能。例如，一个API网关可能会将后端服务的响应转换为客户端能理解的格式，或者在响应中添加一些额外的头信息。

2 现在互联网大厂，使用的也是你说的这种返回方式吗？举一些例子

2. 是的，互联网大厂，包括Google，Facebook，Amazon，阿里巴巴，腾讯等，也通常使用这种按原路返回的方式处理请求和响应。这些公司都有大量的用户和巨大的网络流量，所以他们都会使用一种层级的网络架构来管理和优化他们的网络流量。

   举例来说：

   • Google使用他们的全球负载均衡器和HTTP(S)负载均衡器，以及全球的缓存服务来处理请求和响应。

   • Amazon则通过他们的AWS服务，如Elastic Load Balancing(ELB)和Amazon CloudFront等来处理和优化他们的网络流量。

   • 阿里巴巴和腾讯也有自己的大规模负载均衡系统和缓存服务来处理他们的网络请求和响应。他们的系统会根据请求的类型和目标，将请求和响应路由到正确的服务器或服务。

   这些例子都说明了在复杂的网络环境中，按原路返回的方式可以提供更好的控制和优化，这就是为什么这种方式在业界被广泛使用的原因。

5 那nginx不也算是一种网关吗？ 和 一般我们说的网关有什么区别？

Nginx是一个开源的Web服务器，同时也可以用作反向代理服务器、邮件代理服务器以及通用的TCP/UDP代理服务器。在微服务架构中，Nginx常常被用作一个网关，负责处理来自外部的请求并将其路由到合适的服务。

然而，Nginx本质上是一个反向代理服务器，它的主要职责是接受来自客户端的请求并将其转发到后端的服务器，然后将后端服务器的响应返回给客户端。Nginx可以处理静态内容，提供负载均衡和TLS/SSL处理等功能。

当我们在微服务中谈论网关时，通常指的是API网关。API网关是微服务架构的一部分，它提供了比Nginx更多的功能，包括请求路由、服务发现、负载均衡、身份验证和授权、限流和熔断、API组合和协议转换等。

简单来说，Nginx可以作为一个简单的API网关，但在微服务中，我们通常会使用一些更强大的工具作为API网关，例如Zuul，Spring Cloud Gateway，Kong等。这些工具可以提供更为复杂和强大的功能，以满足微服务架构的需求。

6 所以说nginx不是单独部署，而是类似于tomcat，netty服务器那样存在于每一个微服务的实例中？

不完全是这样。Nginx实际上通常被部署为一个独立的服务，它作为一个反向代理，坐在所有后端微服务前面。它接收从客户端发出的请求，然后将这些请求转发给相应的微服务。

举个例子，假设你有一个微服务架构，其中包含一个用户服务、一个订单服务和一个产品服务。你可以在这些服务前面部署一个Nginx服务，当收到一个请求时，Nginx可以根据请求的URL和其他规则将请求转发给用户服务、订单服务或产品服务。

Nginx和Tomcat、Netty这些应用服务器的关系是不同的。Tomcat和Netty通常被部署在每个微服务的实例中，它们负责接收并处理从Nginx（或其他反向代理）转发过来的请求。

在微服务架构中，你可能会有多个Nginx实例以实现负载均衡和故障转移。例如，你可能会在一个负载均衡器（如Amazon ELB或Google Cloud Load Balancer）后面运行多个Nginx实例。当负载均衡器接收到一个请求时，它可以将请求转发给任何一个可用的Nginx实例。然后，Nginx实例将请求转发给相应的微服务。

所以，Nginx并不是存在于每一个微服务实例中，而是作为反向代理存在于微服务和客户端之间。

7 一个java微服务项目的api-gateway子项目，如何写代码才能让流量走自己这儿

在Java的微服务架构中，API Gateway子项目的主要任务是接收所有来自客户端的请求，并将这些请求路由到相应的服务。如果你正在使用Spring Cloud（一种流行的Java微服务框架），你可以使用Spring Cloud Gateway或者Netflix Zuul作为你的API网关。

以下是一个简单的例子，说明如何使用Spring Cloud Gateway作为API网关：

1. 首先，你需要在你的项目中加入Spring Cloud Gateway的依赖。在你的pom.xml文件中，添加以下代码：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

2. 然后，你需要在你的application.yml或者application.properties文件中定义路由规则。例如：

spring:
  cloud:
    gateway:
      routes:
      - id: user_service
        uri: lb://user-service // lb是load balance的缩写，uri表示如果有权限，就会被路由到//user-service服务中。
        predicates:
        - Path=/user/**
      - id: order_service
        uri: lb://order-service
        predicates:
        - Path=/order/**

关于配置中的id, uri和predicates的关系，我们来具体解析一下：

1. id: 这是路由的唯一标识符，用于标记一个特定的路由规则，比如user_service就是一个路由的ID。

2. uri: 这是路由的目标地址。lb://user-service表示这个路由将流量导向名为"user-service"的服务。"lb://"是一个特殊的URI scheme，表示使用Ribbon客户端负载均衡。也就是说，这个路由将请求转发到"user-service"这个服务，由Ribbon进行负载均衡。

3. predicates: 这是路由的断言，决定了哪些请求可以进入这个路由。例如，- Path=/user/**表示只有路径以"/user/"开头的请求才会进入这个路由，其他的请求不会进入。

因此，根据上述配置，如果一个请求的URL路径以"/user/“开头，那么这个请求就会被路由到"user-service"这个服务上。同样，如果一个请求的URL路径以”/order/"开头，那么这个请求就会被路由到"order-service"这个服务上。在这个过程中，会使用Ribbon进行负载均衡。

在这个例子中，所有以/user/开头的请求将被路由到用户服务，所有以/order/开头的请求将被路由到订单服务。

4. 最后，确保你的API网关服务在所有微服务的前面，也就是说，所有来自客户端的请求首先到达API网关服务，然后由API网关服务将请求路由到相应的服务。

需要注意的是，上面的例子假设你已经设置好了服务发现（如Eureka或Consul），并且你的其他微服务已经注册到了服务发现中。lb://user-service和lb://order-service这样的URI表示这些请求将被路由到注册到服务发现中的对应服务。

Spring Cloud Gateway是Spring官方推出的第二代API网关框架，用来替代Netflix Zuul，用于微服务架构中的API网关服务。上述配置是Spring Cloud Gateway的路由配置，其中每一个"-"开头的项代表一个路由规则。

8 sprin

g cloud是不是一种rpc框架还是什么
Spring Cloud是一种构建和管理微服务的框架，它提供了在分布式系统（如配置管理、服务发现、断路器、智能路由、微代理、控制总线等）中常用模式的实现。所以，它并不是一个RPC框架，而是一个用于构建、部署和管理微服务的工具集。

RPC（Remote Procedure Call，远程过程调用）框架是一种通讯协议，它允许在一个网络中的一台计算机（客户端）调用另一台计算机（服务器）上的程序或者服务。常见的Java RPC框架有Dubbo、gRPC等。

Spring Cloud可以和这些RPC框架配合使用，实现微服务之间的通讯。例如，Spring Cloud提供了对gRPC的支持，可以方便地在Spring Cloud应用中使用gRPC。

另外，Spring Cloud主要基于HTTP/REST进行通信，但也支持其他通讯方式。例如，Spring Cloud Stream支持使用消息中间件（如RabbitMQ、Kafka）进行异步通讯，Spring Cloud OpenFeign提供了声明式的REST客户端等。

所以，Spring Cloud和RPC框架在微服务架构中扮演的角色是不同的，但他们可以一起使用，实现微服务的分布式通讯。

9 spring cloud的各大功能模块应该是解耦合的吧

是的，Spring Cloud的设计理念是微服务架构中各种通用模式的解耦合实现。它包含一系列的子项目（模块），这些模块大多都是可插拔的，并且可以根据具体的需求和场景来选择使用。每个模块都关注于微服务架构中的一个特定领域。以下是一些主要的Spring Cloud模块：

1. Spring Cloud Netflix：提供了一系列Netflix OSS组件的集成，包括Eureka（服务发现）、Hystrix（断路器）、Zuul（API网关）、Ribbon（客户端负载均衡）等。

2. Spring Cloud Gateway：作为Spring Cloud Netflix Zuul的替代品，提供了一种构建API网关的简单方式。

3. Spring Cloud Config：用于集中式配置管理，支持从远程服务器（如Git）读取配置。

4. Spring Cloud Sleuth：用于分布式追踪，兼容Zipkin。

5. Spring Cloud OpenFeign：提供了一种声明式的REST客户端。

6. Spring Cloud Stream：用于构建消息驱动的微服务，支持多种消息中间件。

7. Spring Cloud Bus：用于传播集群中的状态变化或事件，以实现服务之间的通信。

8. Spring Cloud Security：在微服务下提供安全机制，如OAuth2。

每个Spring Cloud模块都有自己的依赖，可以单独引入到项目中。因此，可以根据项目需求选择使用哪些模块，从而在微服务的开发中实现功能的解耦。

10 URL和URI的区别，为什么api网关进行路由时使用了URI？

URI（Uniform Resource Identifier）和URL（Uniform Resource Locator）都是用于识别资源的字符串，它们的设计目的是为了在网络上定位和获取资源。然而，它们之间有一些重要的区别。

• URI：是一个字符串，用来唯一标识抽象或物理资源的标准。它的目的是为了在网络上识别某一实体或者说是资源。它包括两个部分，URL和URN（Uniform Resource Name）。

• URL：是URI的一个子集，也是一个字符串，表示某一互联网上可达的资源。它表示的是资源的地点（在互联网上的位置）。它的语法包括协议、域名、端口、路径等部分。

简单来说，每个URL都是URI，但并非每个URI都是URL。因为URI还包括URN，URN只命名资源而不指定如何定位资源。

在进行路由时，通常使用URI而不是URL，原因如下：

• 使用URI可以提供更大的灵活性。比如在你的配置中的“lb://user-service”，这个URI并没有提供具体的位置信息（如IP地址和端口），而是提供了一个逻辑名。这个逻辑名在运行时会被解析成实际的位置，这样就可以在不改变配置的情况下动态地改变服务的位置。

• 使用URI可以更好地抽象服务。在微服务架构中，我们通常不关心服务的具体位置，而是关心服务的功能。通过使用URI，我们可以将服务当作一个黑盒，不关心服务的内部实现和位置，只关心服务的接口和行为。这是微服务架构的一种重要理念。

11 一个微服务系统应该有鉴权中心，什么时候请求会经过它呢？

一个微服务系统的鉴权中心（通常被称为认证中心或授权中心）主要负责系统的用户认证（确定用户是谁）和授权（确定用户可以做什么）。

以下是几种常见的情况，请求可能会经过鉴权中心：

1. 用户登录: 用户在进行登录操作时，请求会发送到鉴权中心。鉴权中心会验证用户的凭据（如用户名和密码），如果凭据有效，它将发放一个token给用户，以标记用户的会话状态。

2. 服务间调用: 在微服务架构中，服务之间可能会互相调用。为了保证服务间调用的安全性，通常也会经过鉴权中心进行鉴权和授权。例如，服务A调用服务B之前，可能需要先向鉴权中心请求一个授权令牌。

3. 访问受保护资源: 当用户尝试访问受保护的资源时（比如某个需要特定权限才能访问的API），请求需要经过鉴权中心。鉴权中心会检查用户的token，然后决定用户是否有足够的权限来访问这个资源。

在实际的设计中，为了提高性能和可用性，鉴权中心的部分功能可能会通过其他组件实现，比如使用API网关来进行token的检查，使用分布式缓存来保存token等。但无论怎样，鉴权中心都是整个系统中负责处理安全问题的核心组件。

12 如果使用jwt，是不是就可以让API网关进行token检查

是的，你的理解是正确的。使用JWT（JSON Web Token）可以让API网关来进行Token检查，而不需要每次请求都去鉴权中心（例如一个OAuth2服务器）验证。这种方法可以大大提高系统的性能，因为API网关通常会比鉴权中心更接近服务的调用者。

JWT是一种开放标准（RFC 7519），它定义了一种简洁的，自包含的方法用于通信双方之间安全地传输信息。JWT可以通过数字签名（例如使用HMAC算法或者RSA）来验证这个信息，并且可以被加密。

在微服务架构中，一种常见的使用JWT的场景是：鉴权中心在用户登录成功后，生成一个JWT，然后将这个JWT作为令牌发放给用户。当用户向API网关发送请求时，会在请求的头部（通常是Authorization头部）携带这个令牌。API网关收到请求后，可以使用预先共享的秘钥来验证JWT的签名，然后解析JWT中的payload部分，从而获取到用户的身份信息和权限信息。

使用JWT的好处是：一旦JWT被生成，就可以独立验证和解析，无需再去查询数据库或者鉴权中心，这样可以大大减轻鉴权中心的负载，并且提高系统的响应速度。

12.1 jwt的校验机制

13 一个ip地址为什么可以对应多个这样的域名呢

13.1 我可以增加一个这样的映射吗？比如 127.0.0.1 secondkill-user.xxx

可以的。你可以在你的hosts文件中添加任何你需要的域名到IP地址的映射，包括子域名。例如，你可以添加127.0.0.1 secondkill-user.xxx到你的hosts文件。

这样，当你的应用或者你的浏览器试图连接到secondkill-user.xxx时，系统将会把它解析为127.0.0.1。但是请记住，这个配置只在你的本地机器上有效。对于其他机器或者在互联网上，secondkill-user.xxx的解析需要一个真实的DNS服务器来处理。

同样要注意的是，如果你正在使用的域名（在这个例子中是.xxx）是一个真实的顶级域名，那么在真实的网络环境中这可能会导致冲突。因此，当你在开发环境中使用hosts文件映射时，通常会使用不存在的顶级域名，例如.local，.test等。

14 springboot中的tomcat

15 JWT相关

15.1 JWT与鉴权中心

JSON Web Tokens (JWT) 是一种开放标准（RFC 7519），定义了一种紧凑、自包含的方式，用于通信双方之间以 JSON 对象的形式安全地传输信息。这种信息可以被验证和信任，因为它是数字签名的。JWT 可以使用秘密（通过 HMAC 算法）或使用 RSA 或 ECDSA 的公/私钥对进行签名。

在鉴权中心中，JWT 是一种非常常见的技术，它提供了一种机制，可以在服务之间安全、有效地传递用户信息。以下是 JWT 在鉴权中心中的常见使用流程：

1. 客户端（例如 Web 浏览器）向鉴权中心发送登录请求，提供必要的凭证（如用户名和密码）。

2. 鉴权中心验证提供的凭证。如果凭证有效，鉴权中心将生成一个包含用户信息的 JWT，并将其返回给客户端。

3. 客户端将收到的 JWT 存储在本地（例如在浏览器的 localStorage 中）。

4. 客户端在后续的所有请求中，都会在请求头中包含这个 JWT。例如，它可以在 Authorization 头中以 Bearer <token> 的形式发送 JWT。

5. 服务端（或者其他任何需要验证用户身份的服务）接收到请求后，会从请求头中提取 JWT。然后使用公钥验证 JWT 的签名并解析出用户信息。

6. 如果 JWT 验证成功，服务端会根据 JWT 中的用户信息处理请求。否则，服务端会拒绝请求。

总的来说，JWT 在鉴权中心的作用就是为客户端和服务端提供了一个安全可靠的用户身份验证机制。

15.2 讲讲jwt以及jwt的生成和校验过程

JWT（JSON Web Token）是一种开放标准（RFC 7519），它定义了一种紧凑且自包含的方式，用于在各方之间安全地传输信息作为JSON对象。这个信息可以被验证和信任，因为它是数字签名的。

JWT由三部分组成，用.分隔：Header（头部）、Payload（有效载荷）和Signature（签名）。

1. Header（头部）：主要包含两部分，token的类型（即JWT）和采用的加密算法。

例如：

{
  "alg": "HS256",
  "typ": "JWT"
}

2. Payload（有效载荷）：存放有效信息，包含三个部分（也可以自定义其他部分）。

• 标准中注册的声明：这里有一些是JWT预定义的声明，如iss（token的发布者）、exp（token的过期时间）等。
• 公共的声明：可以添加任何的信息，一般添加用户相关信息或其他业务需要的必要信息，但不建议添加敏感信息，因为这个部分在客户端可解密。
• 私有的声明：为了防止冲突，私有声明一般由发布者自行定义。

3. Signature（签名）：是对前两部分的签名，以防止数据被篡改。

例如，如果你想使用HMAC SHA256算法，你需要使用base64url编码的header和payload以及一个密钥，然后进行哈希，来创建签名。

例如：

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

这样一来，JWT的三个部分就生成了。在JWT的使用过程中，这个token会在用户和服务端传递，服务端会对这个JWT进行验证。

JWT的验证过程：

当服务端收到JWT后，会进行以下步骤的验证：

1. 对比收到的JWT中header和payload的base64编码，并用.连接起来，然后用之前的密钥进行加密和第三部分进行对比，从而验证签名是否正确。

2. 验证标准中注册的声明，如过期时间，发布者等信息。

如果这两个步骤都验证通过，那么服务端就可以信任这个JWT中的信息进行处理，否则，JWT验证失败，请求被拒绝。

总的来说，JWT提供了一种方法来在服务端和客户端安全可靠地传递信息。

15.3 讲讲具体的签名和验证过程

具体的 JWT 签名和验证过程如下：

签名过程

1. 当用户向服务器发起认证请求（比如，输入用户名和密码登录）时，服务器验证用户的身份。

2. 当用户身份验证成功后，服务器会生成一个 JWT。这个 JWT 由三部分组成：header（头部）、payload（负载）和 signature（签名）。

3. Header 部分通常包含两部分：token 的类型（即 “JWT”）和签名的算法，比如 HMAC SHA256 或 RSA。

4. Payload 部分则包含声明。声明是关于实体（通常是用户）和其他附加数据的信息。

5. 签名部分是对 Header 和 Payload 的签名，它的生成方法如下：

   如果使用 HMAC SHA256 算法，则服务器会对 “base64UrlEncode(Header) + ‘.’ + base64UrlEncode(Payload)” 进行签名，使用的密钥就是服务器的私钥。

   如果使用 RSA 算法，服务器会用私钥对 “base64UrlEncode(Header) + ‘.’ + base64UrlEncode(Payload)” 进行签名。

6. 最后，服务器将生成的 JWT 返回给用户。用户在后续的请求中，都需要在请求的 header 中包含这个 JWT。

验证过程

1. 当用户发起请求时，会在请求的 header 中包含 JWT。服务器接收到请求后，会从 header 中提取出 JWT。

2. 服务器会对 JWT 进行解码，分别得到 Header、Payload 和 Signature 三部分。

3. 然后，服务器会用与签名时同样的算法，对 “base64UrlEncode(Header) + ‘.’ + base64UrlEncode(Payload)” 进行签名。

4. 如果使用的是 HMAC SHA256 算法，服务器使用的密钥仍然是服务器的私钥。

   如果使用的是 RSA 算法，服务器则会使用公钥进行签名。

5. 服务器将新生成的签名和 JWT 中的 Signature 部分进行比较。如果一致，那么就说明这个 JWT 是有效的；如果不一致，那么就说明这个 JWT 是伪造的，服务器应当拒绝这个请求。

总的来说，这就是 JWT 的签名和验证过程。通过这个过程，服务器能够验证用户的身份，并确保 JWT 不会被伪造。

15.4 JWT给微服务系统提供了一种去中心化验证的能力

是的，JWT （JSON Web Tokens）为微服务系统提供了一种去中心化的身份验证机制。在微服务架构中，可能有许多独立运行且彼此通信的服务。当服务需要验证调用者的身份时，传统的身份验证机制可能需要每个服务都去一个中心化的认证服务进行查询，这将导致额外的网络通信，并可能成为系统的瓶颈。

与此不同，JWT 的主要优点在于它是自包含的。一个 JWT 包含了用户的所有认证信息，这意味着一个服务只需要解码和验证来自客户端的 JWT，就可以知道这个 JWT 是否有效，以及 JWT 所表示的用户身份。

这种方式的优点在于：

1. 降低了网络开销：不需要额外的网络请求去查询用户的认证信息。

2. 解耦身份验证：每个服务可以独立地验证 JWT，不需要依赖于一个中心化的认证服务。

3. 可扩展性：因为每个服务都能独立地进行身份验证，所以添加新的服务不会对现有的认证机制造成影响。

总的来说，使用 JWT 可以在提高微服务系统性能和可扩展性的同时，提供强大的用户身份验证机制。文章来源地址https://www.toymoban.com/news/detail-611155.html

到了这里，关于微服务系统面经的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！