ErgouTree's Blog

前言 首先，这篇文章你得会掌握 Spring Cloud Gateway 的基本使用和各种配置你能读懂，才能看懂 而且你也要知道网关是干什么的，在微服务中的作用是什么，这些内容要懂 Gateway 处理请求的逻辑是根据 配置的路由 对请求进行 预处理 和 转发 单体应用拆分成多个服务后，对外需要一个统一入口，解耦客户端与内部服务 image-20250726114502426 网关的作用你也要了解，在这里我不再说了，贴张图供大伙回顾一下 image-20250726114520193 而且你要懂计算机网络的基本知识和一些实现原理，因为我在这里不会细说 因为这篇文章会基于我上篇使用篇继续讲解 Gateway 的工作机制 实现一个网关的几种方式 基于 Socket Api 实现 image-20250726114045642 这是最基础、最底层的实现方式。它直接利用操作系统提供的 Socket API 来进行网络通信，从而构建网关。 实现的原理如下： 监听端口：网关服务器启动后，会创建一个...

前言 什么是网关 在复杂的微服务架构中，一个业务功能可能由多个微服务协同完成，每个微服务都有自己独立的网络地址。如果没有网关，客户端需要直接与各个微服务进行交互，这会带来一系列问题： 客户端复杂性增加： 客户端需要记录每个微服务的地址，并处理复杂的调用逻辑，增加了客户端的开发和维护成本。 认证授权复杂： 每个微服务都需要进行独立的认证和授权，导致重复开发和管理困难 跨域问题： 不同域的服务之间调用会存在跨域请求的问题，处理起来较为繁琐。 难以实现统一的非业务功能： 像日志记录、限流、熔断、监控等通用功能难以在每个微服务中统一实现和管理。 为了解决上述问题，API网关应运而生。它作为系统的唯一入口，封装了内部的系统架构，为客户端提供一个统一的、简化的API。也就是 一切访问都要通过网关转发给微服务 Spring Cloud Gateway 模块介绍 在微服务架构中，API网关扮演着至关重要的角色，它作为所有微服务的前置入口，统一处理客户端请求，并将其路由到相应的后端服务。Spring Cloud Gateway 作为 Spring...

从源码部分详细分析 Gateway 的各部分实现原理 我这篇内容会比较多，因为我看到什么东西都想说说，怕讲不明白）））))) Gateway在项目启动过程如何实现自动配置的 项目启动肯定是离不开 run 方法了，我们也是直接进入，分析一下它的启动流程，看他会进行什么样的初始化配置 首先，在 SpringApplication 的构造函数中，它会进行一些早期的初始化 会推断应用类型（在 Spring Cloud Gateway 的场景下，由于依赖了 spring-boot-starter-webflux，应用类型会被推断为 REACTIVE）。 还会从 META-INF/spring.factories 文件中加载 ApplicationContextInitializer 和 ApplicationListener 的实现类。先看这个，因为这是旧一些版本的基础，因为这个依旧有实际意义 1234567891011121314public SpringApplication(ResourceLoader resourceLoader,...

Fegin 实践 使用 Fegin 的步骤编写 Http 客户端的步骤 首先肯定要添加项目依赖，你需要什么放什么，我都放出来了在这里 12345678910111213141516171819202122232425<dependencies> <!-- Spring Cloud OpenFeign --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> </dependency> <!-- 服务注册发现（以 Eureka 为例）--> <dependency> <groupId>org.springframework.cloud</groupId> ...

Fegin 前言以及介绍 Fegin是做什么 首先，Fegin 是一个声明式的 HTTP 客户端，它的主要作用是简化微服务之间的 HTTP 调用流程。 通过 Feign，开发者可以像调用本地方法一样调用远程服务的接口，无需手动编写复杂的 HTTP 请求代码（如使用 RestTemplate 构建请求、处理响应等）。 Feign 不做任何请求处理，通过处理注解相关信息生成 Request，并对调用返回的数据进行解码，从而实现 简化 HTTP API 的开发，和 RestTemple 一样，Feign 基于接口和注解的方式，自动生成 HTTP 请求的实现，开发者只需定义接口并添加注解（如 @FeignClient），即可实现对远程服务的调用，大幅减少模板代码。 Spring Cloud 对Feign进行了增强，使得Feign支持了更多实用的注解，并整合了 Ribbon 和 Eureka，从而让 Feign 的使用更加方便。与 Spring Cloud 的集成更加一体化。 在Spring Cloud生态中，Feign...

...

波动方程的求解 波动方程是描述波传播现象的基本偏微分方程，在物理、工程等领域有着广泛应用，例如弦的振动、声波、电磁波的传播等。理解波动方程的解法及其物理意义是数理方程学习的核心内容之一 达朗贝尔公式 达朗贝尔公式解法也叫行波法，旨在一维波动方程求定解问题，主要用于求解无界区域内的一维波动方程定解问题。尽管其适用范围有限，但它在波动问题中具有独特的优点，是数理方程的基本解法之一。 因为行波法只能用于求解无界区域内波动方程的定 解问题。虽有很大的局限性，但对于波动问题有其特殊的优点，所以该法是数理方程的基本解法之一。 弦振动方程的达朗贝尔解法 问题和方程的引入 如果我们所考察的弦线长度很长，而我们需要知道的又只是在较短时间且离开边界较远的一段范围内的振动情况，那么边界条件的影响就可以忽略，所以不妨把所考察弦线的长度视为无限。 我们首先考察无限长弦的自由振动问题，其定解问题形式如下： $$ \begin{cases} u_{tt} = a^2 u_{xx} + f(x, t) & (-\infty < x < +\infty, t...

枢都 夏莲 夏篇路线 左边 Rinne Save 01 ……切那 (→有本事说出我的名字啊) (→不要爱上我啊) 我是三千界切那, 请多指教 Save 02 准备[对时间旅行者装备] [(→纱罗是我老婆) (→钟爱夏莲) 我觉得凛音很可爱 Save 03 放弃使命 (→进行时间旅行) 寻找粘合剂 (→按3部构成的节奏讲) 按2小时的节奏讲 (→还是放弃吧) 攻略玖音 Save 04 与夏莲和纱罗一起去游泳 Save 05 在这个岛上找到真正的自己 我是这个时代的人 Save 06 接受现在 夏莲路线 ​ Save 07 (→我错了) (→抱歉) 对不起 Save 08 昨天的事 (→因为迷上你了) (→因为爱你) 因为喜欢你 (→一起离开岛吧) (→去说服你父亲) 和我交往吧 我喜欢夏莲 夏莲 End End 回收 ◆Load 1 我就是我 End → 轮回的终结 ◆Load 2 ……莫名其妙 End → 第二位时间旅行者 ◆Load 3 执行使命 End...

Nacos 配置中心的实践 Nacos 配置中心的基本实践和配置刷新实践 复习一下 Maven 等来导入 Naocs 相关依赖的内容 首先我们声明项目的版本信息 1234567891011121314151617181920212223242526272829303132<!-- 只声明依赖，不引入依赖 --><dependencyManagement> <dependencies> <!-- 声明springBoot版本 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> ...

...

Nacos 配置中心原理解析 Nacos 配置中心的主要作用 本来我寻思把这篇文章放到负载均衡那个讲的，结构感觉那样会很长，我感觉没有人想读论文那样长的技术博客，就算了 在分布式系统中，配置管理面临三大核心挑战：配置分散（多服务、多环境配置散落在各节点）、更新繁琐（修改配置需重启服务）、一致性难保证（多节点配置易出现不一致）。Nacos 配置中心的核心作用就是解决这些问题 配置集中化管理 将所有服务的配置（如数据库连接、接口地址、限流规则等）集中存储在 Nacos Server，替代传统的本地配置文件（如 application.yml），避免配置分散在各服务节点的文件系统中，便于统一维护。 动态配置更新 支持配置在运行时动态修改并生效，无需重启服务。例如：修改数据库连接池参数、调整日志级别、更新限流阈值等，通过 Nacos 推送机制实时同步到所有相关服务，极大提升系统灵活性。 多维度配置隔离 通过「命名空间（Namespace）+ 分组（Group）+ Data ID」三级结构，实现多环境（如 dev/test/prod）、多业务（如支付...

Nacos 上的负载均衡 服务多级存储模型 在之前我们讲解 Nacos 的数据模型可以了解，Nacos 实例 Key 由如下三元组唯一确定，命名空间，分组，服务名 12345678Namespace（命名空间）├─ group（服务分组）│ ├─ service（服务名）│ │ ├─ instance 1（实例1：IP+端口）│ │ ├─ instance 2（实例2：IP+端口）│ │ └─ ...│ └─ other service（其他服务）└─ other group（其他分组） 在之前，我们的服务模型都是按照两层划分的，一个服务就是一个业务的微服务，一个服务下可以有多个实例 不过随着我们的业务规模越来越大，为了增加稳定性和容灾性，我们会将一个实例部署在多个机房，所以 Nacos 引入了地域 (Zone) 的概念，把同一个服务的多个实例部署到不同地域的机房中 (鸡蛋分开不同的篮子放) ；又把在同一个地域的机房的多个服务实例称为集群 (Cluster) 。比如，杭州机房的 2 个用户服务 user-service 称为杭州...

Nacos 的工作流程剖析 image-20250719124926528 Nacos 服务注册部分 有这么一个包，spring-cloud-commons image-20250719124212246 在这里，你会看到一个熟悉的包，loadbalancer，这就是我们之前深度分析的负载均衡的包，Nacos的负载均衡先不讲，在这个包下面，有个 serviceregistry包，这个包的作用就是服务注册相关内容的包 image-20250719125222356 其中，ServiceRegistry 包是关注与服务注册相关的核心接口，这个ServiceRegistry接口是Spring Cloud提供的服务注册的标准，集成到SpringCloud中实现服务注册的组件，都需要实现这个接口。看一下它的代码 1234567891011121314151617181920212223242526272829303132333435363738394041424344package...