项目中遇到的一些问题总结（八）

nacos如何支持消费者和服务端的高并发的读和写的“服务列表”？

copyOnWriter机制。某服务方拷贝一份“服务列表”并更新后，再替换服务注册中心的“服务列表”。客服端始终读取的是 “服务注册中心”的服务列表。

通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。

CopyOnWrite

CopyOnWrite（写时复制）是一种特殊的并发策略，它试图最小化并发访问的影响，特别是对于读取者而言。它的核心思想是，在容器上进行修改操作时，不会直接修改容器本身。相反，将会先进行一次容器拷贝（写操作），拷贝一个新的容器，然后再进行修改操作。

具体到Java中，在添加元素时，如果当前容器需要进行修改，就会先将当前容器Copy一份，然后对新容器进行修改操作，之后再将原容器的引用指向新的容器。在这个过程中，读取者仍然可以持续访问原容器，而不会被修改操作影响到。

相对于传统的并发容器，CopyOnWrite可以避免修改操作对读取操作的影响，但它的缺陷是在写操作时需要进行一次数据拷贝，可能会有性能问题。因此，CopyOnWrite适用于读多写少的场景，例如在Nacos中的服务注册中心，服务提供者注册或注销服务的次数相对读取服务列表的次数较少，适合使用CopyOnWrite来缓解并发写入的问题。

总之，CopyOnWrite机制有其适用的场景，能够在一定程度上提高数据的访问性能和并发能力，但也需要结合实际情况进行选择和考虑。

Nacos 客户端是怎么实时获取到 Nacos 服务端的最新数据的

Nacos 并不是通过推的方式将服务端最新的配置信息发送给客户端的，而是客户端维护了一个长轮询的任务，定时去拉取发生变更的配置信息，然后将最新的数据推送给 Listener 的持有者。

Nacos客户端可以实时获取到Nacos服务端的最新数据，主要有以下两种机制：

1. 长轮询机制

在Nacos客户端启动时，会向Nacos服务端发送一个长轮询请求，请求的内容包括客户端关心的服务信息（比如服务实例列表、服务配置信息等）。服务端会将这些请求记录下来，并给每个请求设置一个等待时间，然后将这些等待请求挂起。

当有服务信息发生变化时，Nacos服务端会检查当前是否有等待请求需要被唤醒，如果有，则会查看这些等待请求关心的服务信息是否发生了变化，如果发生了变化，则会立即返回给这些请求客户端最新的服务信息数据，并且继续挂起这些请求。如果等待时间超过了设置的超时时间，则会将这些请求返回给客户端，唤醒客户端继续发送新的长轮询请求。

通过这种长轮询机制，Nacos客户端可以在Nacos服务端的最新数据发生变化时及时获取到更新后的数据，从而实现实时同步数据。

2. 心跳机制

Nacos客户端在启动时会和Nacos服务端建立一个TCP长连接，并定时发送心跳包，以保持连接和触发服务端通知客户端一些事件、判断客户端是否存活。

如果服务端检测到客户端连接关闭或异常，服务端会将该客户端关注的服务信息从所有等待的请求中剔除。因此，当客户端重新连接时，需要重新发送查询请求。

通过这两种机制，Nacos客户端能够及时获取到Nacos服务端的数据变化，并实现对服务发现、服务配置等数据的实时更新，保证了服务治理的可靠性和实时性。

单点登录

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

单点登录技术通常需要以下三个组件：

1. 认证服务器（Authentication Server）

该组件负责用户身份认证，保存用户的登录信息和权限信息，并应对其他系统或应用的认证请求。常见的认证服务器包括OpenID、OAuth2、CAS等。

2. 服务提供者（Service Provider）

该组件是需要接入单点登录的系统或应用。它与认证服务器进行通信，接收已认证的用户信息，并根据这些信息判断用户是否有权限访问该系统或应用。

3. 用户代理（User Agent）

该组件是用户使用的终端设备，比如浏览器、移动设备等。用户代理与服务提供者进行通信，管理并传输用户的认证信息。

实现单点登录可以提高用户的登录和操作效率，并减轻系统管理员的管理负担，同时还能提高安全性，避免用户使用不同用户名和密码登录时因维护多个用户名和密码而带来的困境。

OAuth2

OAuth2 是一种授权协议，用于在不泄露用户凭据的情况下，授权第三方应用程序访问用户数据。

OAuth2框架中，有四个角色：

1. 资源所有者：一个拥有受保护资源的实体，可以是一个用户或应用程序的管理员。

2. 客户端：一个访问受保护资源的应用程序，可以是第三方应用或同一应用的不同部分。

3. 授权服务器：一个负责向客户端颁发访问令牌的服务器，经过资源所有者的认证后，可以用来代表用户授权访问令牌。

4. 资源服务器：托管受保护资源的服务器，可以根据访问令牌验证客户端访问权限，决定是否向客户端提供受保护资源。

OAuth2框架使用授权码机制进行授权。流程如下：

1. 客户端向授权服务器发送请求，请求访问资源。

2. 授权服务器询问用户是否在允许该客户端访问受保护资源，并要求用户认证。

3. 如果用户同意向客户端授权访问受保护资源，授权服务器将生成一个授权码，并将授权码返回给客户端。

4. 客户端使用授权码向授权服务器申请访问令牌，证明自己已经获得了用户的授权。

5. 授权服务器验证客户端提供的授权码，并向客户端颁发访问令牌。

6. 客户端使用访问令牌向资源服务器发送请求，请求访问受保护资源。

7. 资源服务器验证访问令牌，判断客户端是否有访问受保护资源的权限，如果有，则提供受保护资源。

8. 客户端获取到响应后，呈现数据，完成整个操作。

OAuth2框架的优势在于其能够为安全管理、第三方应用程序融合、和数据的安全传输提供一种开放的且易于集成的解决方案。

以微信扫码登录为例，OAuth2的授权过程

1. 客户端在微信开放平台注册，并获取客户端id和客户端密钥。

2. 用户在网站上点击微信登录按钮，客户端向网站后台发送请求，请求授权码。

3. 网站后台将请求重定向到微信开放平台认证授权界面，请求用户授权。

4. 用户在授权界面点击“同意授权”，微信开放平台将生成一个授权码，并将授权码返回到网站后台。

5. 网站后台使用客户端id和客户端密钥向微信开放平台申请访问令牌，证明自己已经获得了用户的授权。

6. 微信开放平台验证客户端提供的客户端id和客户端密钥，并向网站后台颁发访问令牌。

7. 网站后台使用访问令牌向微信开放平台请求获取用户的基本信息。

8. 微信开放平台验证访问令牌，向网站后台返回用户的基本信息。

9. 网站后台使用用户的基本信息创建一个新账号/登录后返回给客户端操作。

10. 客户端获取到响应后，呈现数据或执行下一步操作。

在整个过程中，微信开放平台充当了授权服务器和资源服务器的角色，而网站后台则充当了客户端的角色。通过OAuth2的授权过程，微信扫码登录可以方便地实现第三方应用与微信账号的集成，从而为用户提供更好的登录体验。

客户端在微信开放平台注册，并获取客户端id和客户端密钥

客户端在微信开放平台注册并获取客户端id和客户端密钥是OAuth2授权过程中的一个必要步骤。客户端id和客户端密钥被用来识别客户端并验证客户端的合法性。

在微信扫码登录中，客户端需要在后台向微信开放平台申请授权码和访问令牌，以获得用户的基本信息。为了保证授权过程的安全性，需要验证客户端的身份和合法性，因此客户端需要在微信开放平台中注册。在注册过程中，微信开放平台会为每个客户端生成一个客户端id和客户端密钥，用于标识和验证客户端。客户端id和客户端密钥需要妥善保存，以确保客户端可以正常访问和使用微信开放平台的授权API。同时，为了进一步增强安全性，客户端也需要设置相应的授权回调域名、授权范围等参数。

总之，通过客户端在微信开放平台注册并获取客户端id和客户端密钥，可以确保第三方应用与微信账号之间的授权过程的合法性和安全性。

cookie、session、token区别

Cookie、Session、Token是Web开发中常见的三种身份验证和跟踪用户状态的机制，它们之间的区别如下：

1. Cookie:
   Cookie是浏览器存储在客户端（用户浏览器）中的一小段文本，带有可实现用户跟踪的信息。服务器可以在响应客户端请求时通过HTTP响应头向客户端（浏览器）发送一个或多个cookie，客户端浏览器将cookie保存，以便之后对同一服务器发出请求时发送到服务器。Cookie的主要用途是记录用户身份信息，以便下次访问时可以记住用户身份信息。

2. Session:
   Session属于服务器端存储机制，对于每个会话，服务器会为其分配一个唯一的标识符SessionID，并将SessionID存在cookie中发送到客户端浏览器中。客户端浏览器每次向服务器发送请求时，都会自动添加SessionID的信息，服务器利用SessionID来判断该请求是否属于某个会话，并从会话存储中找到对应的数据。与Cookie一样，该机制可以实现用户状态跟踪和身份验证等功能。

3. Token:
   Token是Web开发中的一种身份验证机制，它是一种基于令牌的方式，客户端请求发送给服务器时，会带上Token，服务器根据Token来识别和验证用户的身份，并根据结果给用户提供相应的服务。

总之，三种机制用途相似但实现方式不同，Cookie和Session一般用于用户状态跟踪，而Token一般用于身份验证。其中Cookie和Token存放在客户端（浏览器），Session存放在服务器。可以根据实际需求选择不同的机制来实现不同的功能。

JWT组成以及验证原理

JWT（JSON Web Token）是一种轻量级的，基于JSON的开放标准（RFC 7519）。JWT可以在用户和服务器之间安全地传递信息，作为用户身份验证和授权的一种有效方式。

JWT主要由三部分组成：

1. Header（头部）：JWT头部通常由两部分组成：令牌的类型（即JWT）和所使用的签名算法（比如HMAC SHA256或RSA等）
2. Payload（负载/有效载荷）：jwt有效载荷（payload）包含要传递的信息，主要有三个部分：标准声明、公开声明和私有声明。其中标准声明包括已经定义好的一些官方字段，公开声明包括自定义的一些公共字段，私有声明包括自定义的一些私有字段信息。
3. Signature（签名）：jwt签名部分对前面两部分进行签名，以确保数据不被篡改。签名需要使用的密钥必须是只有服务器知道的密钥，以确保安全性。

JWT的验证原理如下：

1. 客户端发送请求到服务端，请求头中带有JWT Token，服务器使用密钥来验证Token的签名是否正确。
2. 如果Token的签名正确，则服务器解密Token，并验证Payload的内容是否正常。
3. 如果Payload的内容也是正确的，则服务器可以信任这个Token，并使用其中包含的信息来完成相应的操作（比如进行用户身份验证或授权等）。
4. 如果Token的签名不正确或Payload内容有误，则服务器拒绝操作。

总之，JWT是一种开放的标准，通过在头部和负载中编码声明信息，并采用签名来验证信息的完整性，从而确保信息传输的安全性和可靠性。

JWT的验证是不是将前端传递的token中的头部和负载用密钥进行签名然后和token中的签名结果比较

是的，JWT 的验证就是将前端传递的 token 中的头部和负载部分通过相同的加密算法和密钥进行签名，生成一个新的签名，然后将新签名和前端传递的 token 中的签名进行比较，如果一致就认为 token 是有效的。

换句话说，一旦服务端通过自己的密钥对 JWT 签名进行了校验，就能够确认这个 token 是否是真实的，是否被篡改。这种验证方式具有较高的安全性和可靠性，因为 token 的签名是不可伪造的。只要密钥不泄露，就能够确保 token 的真实性。

需要注意的是，如果 JWT 中包含机密信息，一般需要使用 HTTPS 协议进行加密传输，以确保数据的安全性。

JwtAccessTokenConverter作用

JwtAccessTokenConverter 是 Spring Security OAuth2 框架中的一个组件，用于将 OAuth2 认证服务器生成的令牌（Token）转换为 JWT 格式的 Token。

在 OAuth2 认证流程中，认证服务器生成的 Token 通常是一个不具备可读性的一串字符串，这样的 Token 方便服务器进行认证和授权，但对于客户端来说，这样的 Token 却很难处理。

JWT 是一种可读性较强、自包含、无状态的 Token 格式，可以携带更为复杂的信息以支持更丰富的授权场景（比如用户角色、访问域、访问时间等）。因此，Spring Security OAuth2 提供了 JwtAccessTokenConverter 来将 OAuth2 Token 转换为 JWT 格式的 Token，以支持更为灵活的授权方式。

JwtAccessTokenConverter 具体的作用包括以下几个方面：

1. 解析默认的 OAuth2 Token 格式并将其转换为 JWT 格式。

2. 在 JWT 格式 Token 中添加自定义的信息，例如用户权限等。

3. 在 JWT 格式 Token 中添加签名信息，以保证 Token 的真实性和完整性。

4. 解析 JWT 格式 Token 并将其转换为 Map 格式以便进行后续的处理。

在实际的开发中，我们可以通过配置 JwtAccessTokenConverter 来实现个性化的 Token 处理，例如自定义签名算法、设置 Token 过期时间等操作，从而更好地满足项目需求。