wordpress任务网站,电影在线观看,常州网警,wordpress做电商安全吗文章目录 1 概念1.1 你对微服务是怎么理解的1.2 微服务带来了哪些挑战#xff1f;1.3 说下微服务有哪些组件#xff1f;#x1f525; 2 注册中心2.1 注册中心有什么用#xff1f;#x1f525;2.2 SpringCloud可以选择哪些注册中心#xff1f;2.3 说下Eureka 和 Nacos的区… 文章目录 1 概念1.1 你对微服务是怎么理解的1.2 微服务带来了哪些挑战1.3 说下微服务有哪些组件 2 注册中心2.1 注册中心有什么用2.2 SpringCloud可以选择哪些注册中心2.3 说下Eureka 和 Nacos的区别2.4 Eureka实现原理了解吗 3 配置中心3.1 为什么微服务需要配置中心3.2 SpringCloud可以选择哪些配置中心3.3 Nacos配置中心的原理了解吗3.4 Nacos配置中心长轮询机制 4 远程调用4.1 能说下HTTP和RPC的区别吗4.2 Feign和Dubbo的区别4.3 服务端负载均衡器和客户端负载均衡器的区别?4.4 说一下Feign?4.5 为什么Feign第一次调用耗时很长4.6 Feign怎么实现认证传递4.7 Fegin怎么做负载均衡4.8 说说有哪些负载均衡算法 5 服务容灾5.1 什么是服务雪崩5.2 什么是服务熔断什么是服务降级5.3 Hystrix怎么实现服务容错5.4 Sentinel 是什么它是如何工作的5.5 Sentinel怎么实现限流的5.6 常见的限流算法有哪些 6 服务网关6.1 什么是API网关6.2 Spring Cloud Gateway核心概念 7 链路追踪7.1 为什么要用微服务链路追踪7.2 SpringCloud可以选择哪些微服务链路追踪方案7.3 SkyWalking提供了哪些工具7.4 SkyWalking中的数据是如何收集和传输的 8 服务监控8.1 你们的服务怎么做监控和告警8.2 你们的服务怎么做日志收集 9 OAuth29.1 OAuth2授权模式有哪些9.2 使用OAuth2有什么优点和缺点9.3 使用OAuth2时如何存储和传输敏感信息例如用户名和密码9.4 OAuth2的刷新令牌 本文作者夏日。 1 概念
1.1 你对微服务是怎么理解的
微服务是一种软件架构风格将应用程序拆分为一组小型、自治的服务。每个服务都专注于一个特定的业务功能并通过轻量级通信机制如 HTTP RESTful API进行通信。微服务架构的核心理念是将大型单体应用拆解为更小、更可管理的组件每个组件都可以独立开发、部署和扩展。
微服务与单体服务的区别在于规模和部署方式。微服务将应用程序拆分为更小的、自治的服务单元每个服务都有自己的数据库和代码库可以独立开发、测试、部署和扩展带来了更大的灵活性、可维护性、可扩展性和容错性。
1.2 微服务带来了哪些挑战
系统复杂性增加一个服务拆成了多个服务整体系统的复杂性增加需要处理服务之间的通信、部署、监控和维护等方面的复杂性。服务间通信开销微服务之间通过网络进行通信传递数据需要额外的网络开销和序列化开销可能导致性能瓶颈和增加系统延迟。数据一致性和事务管理每个微服务都有自己的数据存储数据一致性和跨服务的事务管理变得更加复杂需要额外解决分布式事务和数据同步的问题。部署和运维复杂性微服务架构涉及多个独立部署的服务对于部署、监控和容错机制的要求更高需要建立适当的部署管道和自动化工具以简化部署和运维过程。团队沟通和协作成本每个微服务都由专门的团队负责可能增加团队之间的沟通和协作成本。需要有效的沟通渠道和协作机制确保服务之间的协调和一致性。服务治理和版本管理随着微服务数量的增加服务的治理和版本管理变得更加复杂。需要考虑服务的注册发现、负载均衡、监控和故障处理等方面以确保整个系统的可靠性和稳定性。分布式系统的复杂性微服务架构涉及构建和管理分布式系统而分布式系统本身具有一些固有的挑战如网络延迟、分布式一致性和容错性。
1.3 说下微服务有哪些组件 注册中心用于服务的注册与发现管理微服务的地址信息。 Spring Cloud NetflixEureka、ConsulSpring Cloud AlibabaNacos 配置中心用于集中管理微服务的配置信息可以动态修改配置而不需要重启服务RefreshScope。 Spring Cloud NetflixSpring Cloud ConfigSpring Cloud AlibabaNacos Config 远程调用用于在不同的微服务之间进行通信和协作。 RESTful API如 RestTemplate、FeignRPC远程过程调用如 Dubbo、gRPC API 网关作为微服务架构的入口统一暴露服务并提供路由、负载均衡、安全认证等功能。 Spring Cloud NetflixZuul、GatewaySpring Cloud AlibabaGateway、Apisix 等 分布式事务保证跨多个微服务的一致性和原子性操作。 Spring Cloud AlibabaSeata 熔断器用于防止微服务之间的故障扩散提高系统的容错能力。 Spring Cloud NetflixHystrixSpring Cloud AlibabaSentinel、Resilience4j 限流和降级用于防止微服务过载对请求进行限制和降级处理。 Spring Cloud NetflixHystrixSpring Cloud AlibabaSentinel 分布式追踪和监控用于跟踪和监控微服务的请求流程和性能指标。 Spring Cloud NetflixSpring Cloud Sleuth ZipkinSpring Cloud AlibabaSkyWalking、Sentinel Dashboard
2 注册中心
2.1 注册中心有什么用
服务注册各个服务在启动时向注册中心注册自己的网络地址、服务实例信息和其他相关元数据。这样其他服务就可以通过注册中心获取到当前可用的服务列表。服务发现客户端通过向注册中心查询特定服务的注册信息获得可用的服务实例列表。这样客户端就可以根据需要选择合适的服务进行调用实现了服务间的解耦。负载均衡注册中心可以对同一服务的多个实例进行负载均衡将请求分发到不同的实例上提高整体的系统性能和可用性。故障恢复注册中心能够监测和检测服务的状态当服务实例发生故障或下线时可以及时更新注册信息从而保证服务能够正常工作。服务治理通过注册中心可以进行服务的配置管理、动态扩缩容、服务路由、灰度发布等操作实现对服务的动态管理和控制。
2.2 SpringCloud可以选择哪些注册中心
SpringCloud 可以与多种注册中心进行集成常见的注册中心包括
EurekaEureka 是 Netflix 开源的服务发现框架具有高可用、弹性、可扩展等特点并与 Spring Cloud 集成良好。ConsulConsul 是一种分布式服务发现和配置管理系统由 HashiCorp 开发。它提供了服务注册、服务发现、健康检查、键值存储等功能并支持多数据中心部署。ZooKeeperZooKeeper 是 Apache 基金会开源的分布式协调服务可以用作服务注册中心。它具有高可用、一致性、可靠性等特点。NacosNacos 是阿里巴巴开源的一个动态服务发现、配置管理和服务管理平台。它提供了服务注册和发现、配置管理、动态 DNS 服务等功能。etcdetcd 是 CoreOS 开源的一种分布式键值存储系统可以被用作服务注册中心。它具有高可用、强一致性、分布式复制等特性。
2.3 说下Eureka 和 Nacos的区别
我的项目采用的 nacos 作为注册中心选择 nacos 的一个重要原因就是它也支持配置中心。
共同点Nacos 与 eureka 都支持服务注册和服务发现都支持服务提供者利用心跳监测的方式做健康检测
Nacos 与 Eureka 的区别
Nacos 支持服务端主动检测提供者状态对于临时实例和 Eureka 一样采用心跳监测而非临时实例 Nacos 会主动检测服务提供者状态默认为临时实例。临时实例心跳不正常会被剔除非临时实例则不会被剔除。Nacos 在服务列表变更时可以主动推送消息给服务消费者服务列表更新更及时Nacos 集群默认采用 AP 方式当集群中存在非临时实例时采用 CP 模式Eureka 采用 AP 方式
总的来说Eureka 着重于服务注册与发现的简单易用适用于基于 Spring Cloud 的微服务架构Nacos 结合了服务注册与发现、配置管理等多种功能适用于云原生应用场景ZooKeeper 提供了强一致性和分布式协调的功能适用于更复杂的分布式系统。
2.4 Eureka实现原理了解吗
服务注册与发现: 当一个服务实例启动时它会向 Eureka Server 发送注册请求将自己的信息注册到注册中心。Eureka Server 会将这些信息保存在内存中并提供 REST 接口供其他服务查询。服务消费者可以通过查询服务实例列表来获取可用的服务提供者实例从而实现服务的发现。服务健康检查: Eureka 通过心跳机制来检测服务实例的健康状态。服务实例会定期向 Eureka Server 发送心跳也就是续约以表明自己的存活状态。如果 Eureka Server 在一定时间内没有收到某个服务实例的心跳则会将其标记为不可用并从服务列表中移除下线实例。服务负载均衡: Eureka 客户端在调用其他服务时会从本地缓存中获取服务的注册信息。如果缓存中没有对应的信息则会向 Eureka Server 发送查询请求。Eureka Server 会返回一个可用的服务实例列表给客户端客户端可以使用负载均衡算法选择其中一个进行调用。
3 配置中心
3.1 为什么微服务需要配置中心 集中管理配置 每个微服务都需要一些配置信息如数据库连接信息、端口号等。使用配置中心可以将这些配置信息集中管理方便统一配置和修改。 动态更新配置 配置中心可以实现配置的动态更新当配置信息发生变化时自动通知到各个微服务实例无需重启服务即可生效。 环境隔离和配置版本管理 微服务通常会部署在不同的环境中如开发、测试、生产环境等每个环境可能需要不同的配置信息配置中心支持配置版本管理。 动态路由和灰度发布 部分配置信息可能影响服务的路由策略或流量控制如限流配置、路由规则等。通过配置中心可以实现动态路由和灰度发布功能根据配置信息的变化调整服务的流量分发策略。 安全性和敏感信息加密 部分配置信息可能包含敏感信息如密码、密钥等。配置中心可以提供安全的配置管理机制支持敏感信息的加密存储和访问控制确保配置信息的安全性。
3.2 SpringCloud可以选择哪些配置中心
Spring Cloud Config官方推荐的配置中心支持将配置文件存储在 Git、SVN 等版本控制系统中并提供 RESTful API 进行访问和管理。Nacos Alibaba 开源的服务注册与配置中心支持服务注册与发现、配置管理、动态路由等功能。Nacos 提供了配置中心的功能可以将配置信息存储在 Nacos 的配置管理模块中并通过 Nacos 客户端来访问配置信息。
3.3 Nacos配置中心的原理了解吗 配置信息存储Nacos 默认使用内嵌数据库 Derby 来存储配置信息还可以采用 MySQL 数据库。 注册配置信息服务启动时Nacos Client 会向 Nacos Server 注册自己的配置信息这个注册过程就是把配置信息写入存储并生成版本号。 获取配置信息服务运行期间Nacos Client 通过 API 从 Nacos Server 获取配置信息。Server 根据键查找对应的配置信息并返回给 Client。 监听配置变化Nacos Client 可以通过注册监听器的方式实现对配置信息的监听。当配置信息发生变化时Nacos Server 会通知已注册的监听器并触发相应的回调方法。
3.4 Nacos配置中心长轮询机制
在长轮询模式下客户端定时向服务端发起请求检查配置信息是否发生变更。如果没有变更服务端会hold住这个请求即暂时不返回结果直到配置发生变化或达到一定的超时时间。 客户端向Nacos配置中心发送一个长轮询请求请求中包含客户端的配置信息和一个超时时间。 Nacos配置中心接收到请求后检查当前的配置信息是否有变更。如果没有变更Nacos会将该请求挂起等待配置变更或达到超时时间。 当有配置变更时Nacos会立即响应该挂起的请求并返回新的配置信息给客户端。 如果超时时间到达而且没有配置变更Nacos会返回一个空响应给客户端客户端收到空响应后会立即发送新的长轮询请求。
通过长轮询机制客户端可以实时地获取到配置变更而不需要频繁地向Nacos配置中心发送请求。这样可以减少网络开销和服务器负载提高配置更新的实时性和效率。
4 远程调用
4.1 能说下HTTP和RPC的区别吗
-HTTPRPC定义HTTP超文本传输协议是一种用于传输超文本的协议。RPC远程过程调用是一种用于实现分布式系统中不同节点之间通信的协议。通信方式基于请求-响应模型客户端发送请求服务器返回响应。基于方法调用模型客户端调用远程方法并等待结果。传输协议基于 TCP 协议可使用其他传输层协议如 TLS/SSL 进行安全加密。可以使用多种传输协议如 TCP、UDP 等。数据格式基于文本常用的数据格式有 JSON、XML 等。可以使用各种数据格式如二进制、JSON、Protocol Buffers 等。接口定义使用 RESTful 风格的接口进行定义常用的方法有 GET、POST、PUT、DELETE 等。使用 IDL接口定义语言进行接口定义如 Protocol Buffers、Thrift 等。跨语言性支持跨语言通信可以使用 HTTP 作为通信协议实现不同语言之间的通信。支持跨语言通信可以使用 IDL 生成不同语言的客户端和服务端代码。灵活性更加灵活适用于不同类型的应用场景如 Web 开发、API 调用等。更加高效适用于需要高性能和低延迟的分布式系统。
总结HTTP 是应用层协议用于传输超文本数据基于请求-响应模型常用于 Web 开发、API 调用等场景RPC 是远程过程调用协议用于实现分布式系统中不同节点之间的通信基于方法调用模型常用于构建面向服务的微服务架构。
4.2 Feign和Dubbo的区别
-FeignDubbo定义Feign 是一个声明式的 Web 服务客户端用于简化 HTTP API 的调用。Dubbo 是一个分布式服务框架用于构建面向服务的微服务架构。通信方式基于 HTTP 协议使用 RESTful 风格的接口进行定义和调用。基于 RPC 协议支持多种序列化协议如 gRPC、Hessian 等。服务发现通常结合服务注册中心如 Eureka、Consul进行服务发现和负载均衡。通过 ZooKeeper、Nacos 等进行服务注册和发现并提供负载均衡功能。服务治理不直接提供服务治理功能需要结合其他组件或框架进行服务治理。提供服务注册与发现、负载均衡、容错机制、服务降级等服务治理功能。跨语言性支持跨语言通信可以使用 HTTP 作为通信协议实现不同语言之间的通信。支持跨语言通信通过 Dubbo 的 IDL 生成不同语言的客户端和服务端代码。生态系统集成了 Spring Cloud 生态系统与 Spring Boot 无缝集成。拥有完整的生态系统包括注册中心、配置中心、监控中心等组件。适用场景适用于构建 RESTful 风格的微服务架构特别适合基于 HTTP 的微服务调用。适用于构建面向服务的微服务架构提供更全面的服务治理和容错机制。
4.3 服务端负载均衡器和客户端负载均衡器的区别? 服务端负载均衡器在服务端负载均衡模式下负载均衡器位于服务端用于分发客户端的请求到后端的多个服务实例。 服务端负载均衡器通常是作为服务网关或反向代理的一部分存在负责接收客户端请求并根据负载均衡策略将请求转发到后端的不同服务实例。典型的服务端负载均衡器包括Nginx、HAProxy等。 客户端负载均衡器在客户端负载均衡模式下负载均衡器位于客户端用于选择合适的服务实例来发送请求。 客户端负载均衡器通常集成在客户端的代码中根据负载均衡策略从服务发现中心获取服务实例列表并根据负载情况选择合适的服务实例发送请求。客户端负载均衡器可以更灵活地根据实际的业务需求选择服务实例并且减轻了服务端的压力提高了系统的可扩展性。
4.4 说一下Feign?
Feign 是一个声明式的 Web 服务客户端它简化了使用基于 HTTP 的远程服务的开发。
声明式 APIFeign 允许开发者使用简单的注解来定义和描述对远程服务的访问。通过使用注解开发者可以轻松地指定 URL、HTTP 方法、请求参数、请求头等信息使得远程调用变得非常直观和易于理解。集成负载均衡Feign 集成了 Ribbon 负载均衡器可以自动实现客户端的负载均衡。它可以根据服务名和可用实例进行动态路由并分发请求到不同的服务实例上提高系统的可用性和可伸缩性。容错机制Feign 支持集成了 Hystrix 可以在调用远程服务时提供容错和断路器功能。当远程服务不可用或响应时间过长时Feign 可以快速失败并返回预设的响应结果避免对整个系统造成级联故障。
4.5 为什么Feign第一次调用耗时很长
主要原因是由于 Ribbon 的懒加载机制当第一次调用发生时Feign 会触发 Ribbon 的加载过程包括从服务注册中心获取服务列表、建立连接池等操作这个加载过程会增加首次调用的耗时。
那怎么解决这个问题呢
可以在应用启动时预热 Feign 客户端自动触发一次无关紧要的调用来提前加载 Ribbon 和其他相关组件。这样就相当于提前进行了第一次调用。
4.6 Feign怎么实现认证传递
比较常见的一个做法是使用拦截器传递认证信息。可以通过实现RequestInterceptor接口来定义拦截器在拦截器里把认证信息添加到请求头中然后将其注册到 Feign 的配置中。
4.7 Fegin怎么做负载均衡
Feign 默认使用 Ribbon 来实现负载均衡。
Ribbon 是 Netflix 开源的一个客户端负载均衡器可以与 Feign 无缝集成为 Feign 提供负载均衡的能力。Ribbon 通过从服务注册中心获取可用服务列表并通过负载均衡算法选择合适的服务实例进行请求转发实现客户端的负载均衡。
只需要在使用 Feign 时指定服务的名称即可Feign 会自动利用 Ribbon 来进行负载均衡的选择。
4.8 说说有哪些负载均衡算法 轮询Round Robin按照顺序将请求依次分配给每个服务实例。轮询算法简单高效适用于负载均衡场景但不考虑服务实例的实际负载情况。 加权轮询Weighted Round Robin在轮询的基础上为每个服务实例分配一个权重值根据权重值来决定每个实例接收到的请求数量。权重值越高的实例接收到的请求越多。 随机Random随机选择一个服务实例来处理请求每个实例被选中的概率相等。随机算法简单但无法保证请求的均衡分配。 加权随机Weighted Random在随机的基础上为每个服务实例分配一个权重值根据权重值来决定每个实例被选中的概率。权重值越高的实例被选中的概率越大。 最小连接数Least Connections根据当前连接数来选择服务实例选择连接数最少的实例进行请求转发。这种算法适用于长连接的场景能够有效地降低服务实例的负载。 IP Hash根据客户端的 IP 地址计算哈希值然后将请求发送到相应的服务实例。这种算法保证相同 IP 的请求都会被发送到同一个服务实例适用于需要保持会话一致性的场景。 一致性哈希Consistent Hashing根据请求的内容或者哈希函数将请求分配到一致性哈希环上的某个节点上这样可以保证相同的请求总是被分配到同一个节点上。一致性哈希算法适用于需要在服务实例动态增减时保持请求的一致性分配的场景。
5 服务容灾
5.1 什么是服务雪崩
在微服务中假如一个或者多个服务出现故障如果这时候依赖的服务还在不断发起请求或者重试那么这些请求的压力会不断在下游堆积导致下游服务的负载急剧增加。不断累计之下可能会导致故障的进一步加剧可能会导致整个系统崩溃这就叫服务雪崩。
一般为了防止服务雪崩可以采用这些措施
服务高可用部署确保各个服务都具备高可用性通过冗余部署、故障转移等方式来减少单点故障的影响。限流和熔断对服务之间的请求进行限流和熔断以防止过多的请求涌入导致后端服务不可用。缓存和降级合理使用缓存来减轻后端服务的负载压力并在必要时进行服务降级保证核心功能的可用性。
5.2 什么是服务熔断什么是服务降级
服务熔断是一种容错机制。当某个服务失败次数达到一定阈值时熔断器会打开后续的请求将不再访问这个服务而是直接返回。经过一段时间后熔断器会尝试半开状态允许有限的请求尝试访问服务如果服务能够正常响应则关闭熔断器否则继续保持打开状态。
服务降级是指当系统出现异常或压力过大时为了保证核心功能的正常运行系统会主动关闭或降低一些非核心功能的可用性或服务质量。服务降级的目的是为了释放系统资源保证核心功能的稳定运行避免整个系统雪崩。
区别服务熔断主要是针对服务间的调用关系当某个服务出现故障或超时时中断对该服务的调用防止故障扩散和影响其他服务而服务降级主要是针对系统自身的功能当系统面临高负载或故障时暂时关闭一些不重要的功能保证系统的核心功能能够正常运行。
5.3 Hystrix怎么实现服务容错
服务熔断Hystrix 通过设置阈值来监控服务的错误率或响应时间。当错误率或响应时间超过预设的阈值时熔断器将会打开后续的请求将不再发送到实际的服务提供方而是返回预设的默认值或错误信息。这样可以快速隔离故障服务防止故障扩散提高系统的稳定性和可用性。服务降级当服务熔断打开时Hystrix 可以提供一个备用的降级方法或返回默认值以保证系统继续正常运行。开发者可以定义降级逻辑例如返回缓存数据、执行简化的逻辑或调用其他可靠的服务以提供有限但可用的功能。请求缓存Hystrix 可以缓存对同一请求的响应结果当下次请求相同的数据时直接从缓存中获取避免重复的网络请求提高系统的性能和响应速度。请求合并Hystrix 可以将多个并发的请求合并为一个批量请求减少网络开销和资源占用。这对于一些高并发的场景可以有效地减少请求次数提高系统的性能。实时监控和度量Hystrix 提供了实时监控和度量功能可以对服务的执行情况进行监控和统计包括错误率、响应时间、并发量等指标。通过监控数据可以及时发现和解决服务故障或性能问题。线程池隔离Hystrix 将每个依赖服务的请求都放在独立的线程池中执行避免因某个服务的故障导致整个系统的线程资源耗尽。通过线程池隔离可以提高系统的稳定性和可用性。
5.4 Sentinel 是什么它是如何工作的
Sentinel 是一款由阿里巴巴开源的流量控制和服务保护组件主要用于保护分布式系统中的微服务架构。它提供了实时的流量控制、熔断降级、系统负载保护等功能可以帮助开发者有效地保护和管理微服务应用。 流量控制 Sentinel 可以对微服务的入口流量进行实时监控和限制。开发者可以通过配置规则来定义流量控制策略从而保护后端服务不被过载和打崩。 熔断降级 Sentinel 可以自动识别出故障或异常的服务并对其进行熔断降级。 系统负载保护当系统负载超过阈值时Sentinel 可以自动限制流量或者拒绝请求从而避免系统过载和崩溃。 实时监控和统计 Sentinel 提供了实时的监控和统计功能可以监控服务的流量、响应时间、错误率等关键指标并生成实时的统计报告和告警信息。
5.5 Sentinel怎么实现限流的
Sentinel 通过动态管理限流规则根据定义的规则对请求进行限流控制。具体实现步骤如下
定义资源在 Sentinel 中资源可以是 URL、方法等用于标识需要进行限流的请求。配置限流规则在 Sentinel 的配置文件中定义资源的限流规则。规则可以包括资源名称、限流阈值、限流模式令牌桶或漏桶等。监控流量Sentinel 会监控每个资源的流量情况包括请求的 QPS每秒请求数、线程数、响应时间等。限流控制当请求到达时Sentinel 会根据资源的限流规则判断是否需要进行限流控制。如果请求超过了限流阈值则可以进行限制、拒绝或进行其他降级处理。
5.6 常见的限流算法有哪些
限流算法是一种用于控制系统访问速率的算法用于限制在一定时间内系统能够处理的请求数量或者速率。限流算法可以帮助系统应对突发流量、防止系统过载和崩溃保护系统的稳定性和可用性。 漏桶算法Leaky Bucket漏桶算法可以看作是一个漏水的桶水请求以固定的速率流入桶中。而桶有一个固定的容量当水流入桶时如果桶满了多余的水将被溢出这时请求将被拒绝或者进行排队等待。这种算法无法应对突发的流量因为只能以固定的速率处理请求。 令牌桶算法Token Bucket令牌桶算法中系统以固定的速率生成令牌并放入一个桶中。每个请求到来时需要从桶中获取一个令牌如果桶中没有足够的令牌则请求被拒绝或者进行排队等待。这种算法可以应对突发流量。 固定窗口算法固定窗口算法在固定的时间窗口内根据系统的负载情况对请求进行计数当请求数量达到设定的阈值时后续请求将被拒绝或者进行排队等待。这种算法相对简单直接但可能无法应对突发流量。 滑动窗口算法滑动窗口算法将时间划分为固定大小的窗口每隔一定时间滑动并在每个窗口中限制请求的数量。当请求到达时算法会检查当前窗口中的请求数量是否超过阈值超过则拒绝请求否则允许通过。
一般 nginx 限流采用的漏桶算法spring cloud gateway 支持令牌桶算法。
6 服务网关
6.1 什么是API网关
API 网关API Gateway是一种中间层服务器用于集中管理、保护和路由对后端服务的访问。它充当了客户端与后端服务之间的入口点提供了一组统一的接口来管理和控制 API 的访问。 路由转发API 网关根据请求的 URL 路径或其他标识将请求路由到相应的后端服务。通过配置路由规则可以灵活地将请求分发给不同的后端服务。 负载均衡API 网关可以在后端服务之间实现负载均衡将请求平均分发到多个实例上提高系统的吞吐量和可扩展性。 认证与授权API 网关可以集中处理身份验证和授权确保只有经过身份验证的客户端才能访问后端服务。它可以与身份提供者如 OAuth、OpenID Connect集成进行用户认证和授权操作。 缓存API 网关可以缓存后端服务的响应减少对后端服务的请求次数提高系统性能和响应速度。 监控与日志API 网关可以收集和记录请求的指标和日志提供实时监控和分析帮助开发人员和运维人员进行故障排查和性能优化。 数据转换与协议转换API 网关可以在客户端和后端服务之间进行数据格式转换和协议转换如将请求从 HTTP 转换为 WebSocket或将请求的参数进行格式转换以满足后端服务的需求。 API 版本管理API 网关可以管理不同版本的 API允许同时存在多个 API 版本并通过路由规则将请求正确地路由到相应的 API 版本上。
6.2 Spring Cloud Gateway核心概念
Route路由路由是 Spring Cloud Gateway 的基本构建块它定义了请求的匹配规则和转发目标。通过配置路由可以将请求映射到后端的服务实例或 URL 上。路由规则可以根据请求的路径、方法、请求头等条件进行匹配并指定转发的目标 URI。Predicate断言断言用于匹配请求的条件如果请求满足断言的条件则会应用所配置的过滤器。Spring Cloud Gateway 提供了多种内置的断言如 Path路径匹配、Method请求方法匹配、Header请求头匹配等同时也支持自定义断言。Filter过滤器过滤器用于对请求进行处理和转换可以修改请求、响应以及执行其他自定义逻辑。Spring Cloud Gateway 提供了多个内置的过滤器如请求转发、请求重试、请求限流等。同时也支持自定义过滤器可以根据需求编写自己的过滤器逻辑。Gateway Handler网关处理器网关处理器是 Spring Cloud Gateway 的核心组件负责将请求转发到匹配的路由上。它根据路由配置和断言条件进行路由匹配选择合适的路由进行请求转发。网关处理器还会依次应用配置的过滤器链对请求进行处理和转换。Gateway Filter Chain网关过滤器链网关过滤器链由一系列过滤器组成按照配置的顺序依次执行。每个过滤器可以在请求前、请求后或请求发生错误时进行处理。过滤器链的执行过程可以修改请求、响应以及执行其他自定义逻辑。
7 链路追踪
7.1 为什么要用微服务链路追踪
在微服务系统中服务之间存在复杂的调用关系和依赖关系一个请求可能需要经过多个不同的服务才能完成。那么就会面临一些问题
问题定位当某一个服务节点出现问题导致整个调用失败无法快速清晰地定位出现问题的服务。性能分析服务存在相互依赖调用的关系当某一个服务的接口耗时过长会导致整个接口调用变的很慢我们无法明确每一个接口的耗时。服务拓扑图随着需求迭代服务之间调用关系变化频繁靠人工很难梳理清楚服务之间的调用关系。服务告警当服务出现问题我们无法做到由系统自动通知相关人员。
而分布式链路追踪就可以解决上述问题它会将一次分布式请求的调用情况集中展示比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态、生成服务调用拓扑图等等。
7.2 SpringCloud可以选择哪些微服务链路追踪方案 Zipkin Zipkin 是一个开源的分布式实时追踪系统由 Twitter 开发并贡献给开源社区。Spring Cloud Sleuth 提供了与 Zipkin 的集成可以通过在微服务中添加相应的依赖和配置将追踪信息发送到 Zipkin 服务器并通过 Zipkin UI 进行可视化展示和查询。 SkyWalking Apache SkyWalking 是一款开源的应用性能监控与分析系统提供了对 Java、.NET 和 Node.js 等语言的支持。在 Spring Cloud 中可以通过 SkyWalking 提供的插件来实现微服务链路追踪和监控。 Pinpoint Pinpoint 是 Naver 开源的分布式应用性能监控系统支持 Java 和 .NET。它提供了与 Spring Cloud Sleuth 的集成可以将追踪数据发送到 Pinpoint 服务器并通过其 UI 进行分析和监控。 Jaeger Jaeger 是 Uber 开源的分布式追踪系统也被纳入了 CNCF云原生计算基金会的维护。通过使用 Spring Cloud Sleuth 和 Jaeger 客户端库可以将追踪信息发送到 Jaeger 并进行可视化展示和查询。
7.3 SkyWalking提供了哪些工具
在分布式系统中确定性能瓶颈是一个复杂而关键的任务。SkyWalking 提供的工具和技术来帮助进行故障排查 性能监控和指标收集SkyWalking 提供了性能监控和指标收集功能可以监控服务之间的调用、请求响应时间、错误率等指标。 分布式追踪SkyWalking 提供了分布式追踪功能可以跟踪请求在整个系统中的调用链帮助发现慢速调用和瓶颈服务。 日志分析SkyWalking 提供了日志分析功能可以集成各种日志系统如ELK Stack、Logstash并将日志与性能指标和追踪数据关联起来以帮助进行故障排查。 故障模拟和压力测试SkyWalking 提供了故障模拟和压力测试的功能可以对服务进行压力测试并监控系统的响应时间和错误率。 自动化警报和通知SkyWalking 提供了警报和通知的功能可以根据预设的条件和规则触发警报并通过邮件、短信等方式发送通知。
7.4 SkyWalking中的数据是如何收集和传输的
Apache SkyWalking 中的数据收集和传输是通过代理端和后端收集器之间的协作来完成的。以下是数据收集和传输的主要步骤 数据收集器 SkyWalking 的代理端Agent内置于各个应用程序中负责收集应用程序的性能指标、分布式追踪数据和日志信息。代理端通过字节码注入或者插件方式与应用程序集成能够在不修改源代码的情况下自动收集和监控应用程序的运行状态。 数据传输协议 SkyWalking 的代理端将收集到的数据以指定的格式打包并通过指定的传输协议将数据发送到后端收集器。 后端收集器 SkyWalking 的后端收集器Collector负责接收和处理代理端发送过来的数据。 数据存储和索引 后端收集器将收集到的数据存储到持久化存储中并建立相应的索引以支持数据的快速检索和查询。通常情况下SkyWalking 支持存储到关系型数据库如MySQL、时序数据库如Elasticsearch或者分布式存储如Hadoop、HBase中。 数据查询和展示 用户可以通过 SkyWalking 提供的查询接口和可视化界面对收集到的数据进行查询和分析。用户可以查看应用程序的性能指标、分布式追踪数据和日志信息并通过图表、报表等形式展示以帮助用户了解系统的运行状况和性能表现。
具体操作为在 JVM 中设置如下参数
-javaagent:/skywalking-agent.jar # 加载指定的 SkyWalking 代理文件其会注入到应用中
-Dskywalking.collector.backend_service127.0.0.1:11800 # 代理将数据发送到这个后端收集器地址
-Dskywalking.agent.service_nameContentApplication # SkyWalking的UI中这个名称作为应用的标识8 服务监控
8.1 你们的服务怎么做监控和告警 日志监控 使用日志框架例如Log4j、Logback记录关键业务逻辑的日志并结合日志分析工具例如ELK Stack、Splunk进行日志监控和分析。通过监控日志中的异常和错误信息可以及时发现问题并进行相应的处理。 指标监控 使用监控工具例如Prometheus、Grafana收集和展示 Java 服务的关键指标例如内存使用率、CPU 使用率、线程池情况等通过设置阈值和告警规则实现对关键指标的实时监控和告警。 应用性能监控APM 使用 APM 工具例如AppDynamics、New Relic、Dynatrace监控 Java 服务的性能指标例如响应时间、请求吞吐量、数据库访问等通过分析和可视化这些指标可以发现系统瓶颈和性能问题。 异常监控 使用异常监控工具例如Sentry、Rollbar捕获和记录 Java 服务中的异常信息通过实时监控异常信息可以及时发现并解决系统中的问题。 心跳检测 使用心跳检测工具例如Zabbix、Nagios对 Java 服务进行定时检测确保服务的正常运行。当服务出现异常或者宕机时可以及时发出告警通知进行故障排除和修复。 自定义监控 根据业务需求和技术栈开发自定义监控工具或者脚本对 Java 服务进行定制化监控和告警。例如通过定时发送HTTP请求来检测服务是否正常运行或者通过定时执行Shell脚本来监控系统资源使用情况。
8.2 你们的服务怎么做日志收集
我的项目中使用的是 Log4j2 和 RabbitMQ 结合的方式。
首先在项目的 pom.xml 中添加 Log4j2 和 RabbitMQ 的依赖在 src/main/resources 目录下创建一个 log4j2.xml 文件并设置 RabbitMQ Appender 用于将日志发送到 RabbitMQ之后需要创建一个 RabbitMQ 消息监听器来接收并处理通过 Log4j2 发送的日志消息按天数存储
数据量特别大时可以使用 ELK
ElasticsearchElasticsearch 是一个分布式搜索和分析引擎用于存储和索引大量的日志数据。它提供了快速的搜索和聚合功能可以高效地处理大规模的日志数据。LogstashLogstash 是一个用于收集、过滤和转发日志数据的工具。它可以从各种来源如文件、网络、消息队列等收集日志数据并对数据进行处理和转换然后将其发送到 Elasticsearch 进行存储和索引。KibanaKibana 是一个用于日志数据可视化和分析的工具。它提供了丰富的图表、仪表盘和搜索功能可以帮助用户实时监控和分析日志数据发现潜在的问题和趋势。
简单说这三者里Elasticsearch提供数据存储和检索能力Logstash负责将日志收集到 ESKibana负责日志数据的可视化分析。
9 OAuth2
9.1 OAuth2授权模式有哪些
OAuth 2.0 是一种开放标准的授权协议用于授权第三方应用程序访问用户在另外一个服务提供商上的资源而无需将用户的凭证如用户名和密码透露给第三方应用程序。OAuth 2.0 定义了多种授权模式也称为授权流程或者授权类型以满足不同场景下的授权需求。
授权码模式授权码模式是 OAuth 2.0 中最常用的模式之一也是最安全的一种模式。在这种模式下客户端先申请一个 Authorization Code授权码然后再用该码获取 Access Token访问令牌。隐藏/简化模式隐藏/简化模式是一种简化的授权码模式这种方式没有申请授权码这个中间步骤直接将访问令牌传递给客户端所以称为隐藏/简化模式。密码模式密码模式是一种在用户信任客户端的情况下使用的模式因为客户端需要直接从用户那里获取用户名和密码并将其作为 Client Credentials客户端凭证发送到认证服务器来换取访问令牌。但是这可能会使用户的密码泄露因此应该谨慎使用。客户端凭证模式客户端凭证模式是一种不基于用户的认证模式它允许客户端直接使用 Client Credentials 向认证服务器请求令牌
9.2 使用OAuth2有什么优点和缺点
优点
安全性OAuth 2.0 采用了授权码、令牌等机制将用户的凭证信息与第三方应用程序隔离开来减少了凭证信息被泄露的风险。灵活性OAuth 2.0 定义了多种授权模式如授权码模式、密码模式、客户端凭证模式等能够满足不同场景下的授权需求提供了更灵活的授权机制。适用性广泛OAuth 2.0 可以用于各种不同类型的应用程序和场景包括 Web 应用程序、移动应用程序、单页应用程序等适用性广泛。用户友好OAuth 2.0 允许用户授权第三方应用程序访问自己的资源但不需要提供自己的凭证信息如用户名和密码提高了用户的安全感和体验。
缺点
复杂性OAuth 2.0 协议包含多种授权模式和流程开发者需要理解并正确实现这些流程可能会增加开发成本和复杂度。单点故障OAuth 2.0 授权流程通常需要依赖认证服务器来进行用户身份验证和授权如果认证服务器出现故障或者不可用可能会影响到整个系统的正常运行。权限管理复杂OAuth 2.0 并未提供对权限管理的明确规范导致在实际应用中需要开发者自行实现对用户权限的管理和控制可能会增加开发和维护的工作量。
9.3 使用OAuth2时如何存储和传输敏感信息例如用户名和密码
在 OAuth 2.0 的授权流程中不会直接传输或存储用户的用户名和密码。OAuth 2.0 协议设计的初衷就是为了减少对用户凭证如用户名和密码的直接依赖提高安全性。
在授权码模式下第三方应用程序从授权服务器获取授权码然后使用授权码换取访问令牌。在这个过程中第三方应用程序不会直接接触到用户的用户名和密码而是通过授权码来获取访问令牌。
9.4 OAuth2的刷新令牌
为什么有刷新令牌访问令牌只是向资源服务器申请获取资源的凭证其有效期一般较短。当访问令牌过期后可以使用刷新令牌进行刷新刷新令牌的有效期一般较长。 刷新令牌的获取 如果授权服务器Authorization Server支持刷新令牌模式那么在获取访问令牌Access Token的同时也会返回一个刷新令牌。 刷新令牌的使用 当访问令牌失效时可以使用刷新令牌向授权服务器请求新的访问令牌而无需用户重新进行身份验证。刷新令牌的请求通常是通过特殊的端点如 /token 端点发送的并且需要包含刷新令牌和客户端凭证等信息。 新的访问令牌的获取 授权服务器接收到刷新令牌后会验证刷新令牌的有效性并生成一个新的访问令牌。新的访问令牌与之前的访问令牌具有相同的访问权限但具有不同的过期时间。 更新访问令牌 一旦新的访问令牌生成客户端应用程序将其存储起来并用它来替换之前失效的访问令牌。这样客户端应用程序就可以继续使用新的访问令牌来访问受保护的资源了。
需要注意的是刷新令牌的使用是有限制的通常情况下刷新令牌具有一定的有效期并且只能使用一次。一旦刷新令牌被使用过一次就会失效客户端应用程序需要使用新的刷新令牌来获取下一个访问令牌。另外刷新令牌也需要进行安全存储以防止被恶意获取和使用。
