引言 早期的业务都是基于单体节点部署，由于前期访问流量不大，因此单体结构也可满足需求，但随着业务增长，流量也越来越大，那么最终单台服务器受到的访问压力也会逐步增高。时间一长，单台服务器性能无法跟上业务增长，就会造成线上频繁宕机的现象发生，最终导致系统瘫痪无法继续处理用户的请求。 ❝ 从上面的描述中，主要存在两个问题：①单体结构的部署方式无法承载日益增长的业务流量。②当后端节点宕机后，整个系统会陷入瘫痪，导致整个项目不可用。 ❞ 因此在这种背景下，引入负载均衡技术可带来的收益： 「系统的高可用：」 当某个节点宕机后可以迅速将流量转移至其他节点。 「系统的高性能：」 多台服务器共同对外提供服务，为整个系统提供了更高规模的吞吐。 「系统的拓展性：」 当业务再次出现增长或萎靡时，可再加入/减少节点，灵活伸缩。 OK ，既然引入负载均衡技术可给我们带来如此巨大的好处，那么又有那些方案可供选择呢？主要有两种负载方案， 「「硬件层面与软件层面」」 ，比较常用的硬件负载器有 A10、F5 等，但这些机器动辄大几万乃至几十万的成本，因此一...

Nginx 核心架构设计和原理 Nginx 是一个免费的、开源的、高性能 Http 服务器和反向代理。Nginx 的架构设计是为了提供高性能、稳定性和可扩展性。 以下是 Nginx 的主要架构组件和工作原理： 1. Master 进程 ： Nginx 的运行始于一个 master 进程，它负责管理所有的工作进程。 master 进程负责读取和解析配置文件，并启动工作进程。 2. 工作进程 ： 一旦 master 进程启动，它会生成一组工作进程。 每个工作进程都是独立运行的，负责处理来自客户端的连接和请求。 工作进程之间相互独立，可以并行处理请求，提高了 Nginx 的性能和吞吐量。 1. [事件驱动模型]() ： Nginx 采用了事件驱动的模型，主要利用了操作系统提供的异步 I/O 机制。 当有新的连接建立或者数据可读写时，Nginx 不会阻塞等待，而是通过事件...

跨域问题是浏览器为了保护用户的信息安全，实施了同源策略（Same-Origin Policy），即只允许页面请求同源（相同协议、域名和端口）的资源，当 JavaScript 发起的请求跨越了同源策略，即请求的目标与当前页面的域名、端口、协议不一致时，浏览器会阻止请求的发送或接收。 解决跨域问题方案 跨域问题可以从以下方面解决： 1. 应用层面解决 ：例如 Spring Boot 项目中解决跨域问题。 2. 反向代理解决 ：例如 Nginx 中解决跨域问题。 3. 网关中解决 ：例如 [Spring Cloud Gateway]() 中解决跨域问题。 而这 3 类解决方案，总共包含了 8 种解决方案，一起来看。 1.Spring Boot 中解决跨域 在 Spring Boot 中跨域问题有以下 5 种解决方案： 1. 使用 @CrossOrigin 注解实现跨域【局域类跨域】 2. 通过配置文件实现跨域【全局跨域】 3. 通过 CorsFilter 对象实现跨域【全局跨域】 4. 通过 Response 对象实现跨域【局域方法跨域】 5. ...

引言 早期的业务都是基于单体节点部署，由于前期访问流量不大，因此单体结构也可满足需求，但随着业务增长，流量也越来越大，那么最终单台服务器受到的访问压力也会逐步增高。时间一长，单台服务器性能无法跟上业务增长，就会造成线上频繁宕机的现象发生，最终导致系统瘫痪无法继续处理用户的请求。 从上面的描述中，主要存在两个问题： ①单体结构的部署方式无法承载日益增长的业务流量。 ②当后端节点宕机后，整个系统会陷入瘫痪，导致整个项目不可用。 因此在这种背景下，引入负载均衡技术可带来的收益： 系统的高可用：当某个节点宕机后可以迅速将流量转移至其他节点。 系统的高性能：多台服务器共同对外提供服务，为整个系统提供了更高规模的吞吐。 系统的拓展性：当业务再次出现增长或萎靡时，可再加入/减少节点，灵活伸缩。 OK ，既然引入负载均衡技术可给我们带来如此巨大的好处，那么又有那些方案可供选择呢？主要有两种负载方案， 硬件层面与软件层面 ，比较常用的硬件负载器有 A10、F5 等，但这些机器动辄大几万乃至几十万的成本，因此一般大型企业会采用该方案，如银行、国企、央企等...

背景 最近有个项目需求： 来自同一客户端的所有请求都被发送到同一个后端服务器，以确保会话数据或状态在服务器之间保持一致。 会话粘性 根据上面的需求，其实就是如何实现会话粘性。 会话粘性（Session Affinity）：也称为会话持久性（Session Persistence）或会话坚持（Session Stickiness），是一种负载均衡策略，其中来自同一客户端的所有请求都被路由到相同的后端服务器。这样做的目的是确保在多个服务器之间保持用户的会话数据或状态的一致性。通常，会话粘性通过客户端的标识信息来实现，最常见的标识信息是客户端的 IP 地址或Cookie。 客户端和服务端之间的交互如下图所示： 实现方案 Nginx 可以根据客户端的 IP 地址，将请求路由到不同的后端服务器。如下图所示： ![图片](https://static.developers.pub/d3b4cca08407449da5...

基础配置 user root; worker_processes 1; events { worker_connections 10240; } http { log_format '$remote_addr $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"'; include mime.types; default_type application/octet-stream; sendfile on; autoindex on; autoindex_exact_size

引言 早期的业务都是基于单体节点部署，由于前期访问流量不大，因此单体结构也可满足需求，但随着业务增长，流量也越来越大，那么最终单台服务器受到的访问压力也会逐步增高。时间一长，单台服务器性能无法跟上业务增长，就会造成线上频繁宕机的现象发生，最终导致系统瘫痪无法继续处理用户的请求。 ❝从上面的描述中，主要存在两个问题：①单体结构的部署方式无法承载日益增长的业务流量。②当后端节点宕机后，整个系统会陷入瘫痪，导致整个项目不可用。 ❞ 因此在这种背景下，引入负载均衡技术可带来的收益： 「系统的高可用：」 当某个节点宕机后可以迅速将流量转移至其他节点。 「系统的高性能：」 多台服务器共同对外提供服务，为整个系统提供了更高规模的吞吐。 「系统的拓展性：」 当业务再次出现增长或萎靡时，可再加入/减少节点，灵活伸缩。 OK ，既然引入负载均衡技术可给我们带来如此巨大的好处，那么又有那些方案可供选择呢？主要有两种负载方案， 「「硬件层面与软件层面」」 ，比较常用的硬件负载器有 A10、F5 等，但这些机器动辄大几万乃至几十万的成本，...

背景 NGINX 是一个通用且流行的应用程序。也是最流行的 Web 服务器，它可用于提供静态文件内容，但也通常与其他服务一起用作分布式系统中的组件，在其中它用作反向代理、负载均衡 或 API 网关。 分布式追踪 distributed tracing 是一种可用于分析与监控应用程序的机制，将追踪在从源到目的的整个过程中的单个请求，这与仅通过单个应用程序域来追踪请求的形式不同。 换句话说，我们可以说分布式追踪是对跨多个系统的多个请求的拼接。拼接通常由一个或多个相关 ID 完成，并且跟踪通常是一组记录的、跨所有系统的结构化日志事件，存储在一个中心位置。 在这种背景的情况下， OpenTracing 应运而生。OpenTracing 是一个与应用供应商无关的 API，它可帮助开发人员轻松地跟踪单一请求的域。目前有多种开源产品都支持 OpenTracing（例如，Jaeger, skywalking 等），并将其作为一种检测分布式追踪的标准化方法。 本文将围绕，从 0 到 1 实现在 nginx 配置分布式追踪的架构的简单实例说明。本文实例使用的组件为 nginx[1]...

为什么要限流 日常生活中,有哪些需要限流的地方? 像我旁边有一个国家景区,平时可能根本没什么人前往,但是一到五一或者春节就人满为患,这时候景区管理人员就会实行一系列的政策来限制进入人流量, 为什么要限流呢?假如景区能容纳一万人,现在进去了三万人,势必摩肩接踵,整不好还会有事故发生,这样的结果就是所有人的体验都不好,如果发生了事故景区可能还要关闭,导致对外不可用,这样的后果就是所有人都觉得体验糟糕透了。 限流的思想就是,在保证可用的情况下尽可能多增加进入的人数,其余的人在外面排队等待,保证里面的一万人可以正常游玩。 回到网络上,同样也是这个道理,例如某某明星公布了恋情,访问从平时的50万增加到了500万,系统最多可以支撑200万访问,那么就要执行限流规则,保证是一个可用的状态,不至于服务器崩溃导致所有请求不可用。 限流思路 对系统服务进行限流，一般有如下几个模式： 熔断 系统在设计之初就把熔断措施考虑进去。当系统出现问题时，如果短时间内无法修复，系统要自动做出判断，开启熔断开关，拒绝流量访问，避免大流量对后端的过载请求。 系统也应该能够动态监测后端...