动态负载均衡

已于 2022-08-24 18:35:20 修改
阅读量2.2k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： Openresty 文章标签： 负载均衡 lua 运维
于 2022-08-24 18:30:29 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/math_chao/article/details/126510327
本文介绍了如何针对特定需求开发一个轻量级的动态负载均衡项目，重点讨论了技术选型，包括openresty+go的组合、多协议支持、动态加载、协议解析规则和资源预分配。文章详细阐述了管理接口、服务配置、多实例管理和高可用性的实现策略。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

文章目录


最近组内有个动态负载均衡的项目，虽然目前开源的网关项目可以满足项目的需求，但是因为网关项目太大，有太多不需要的功能，而这个项目仅仅需要动态负载均衡功能，所以就尝试进行自己开发。

项目功能概述

本项目的定位的是动态负载均衡，主要的功能设计如下

  1. 动态加载
    在不重启的服务（reload）的情况下，能够动态添加 upstream 服务组，动态添加请求到 upstream 服务组的解析规则
  2. 多协议支持
    要能够支持 7 层、4 层负载均衡，7 层要能够支持 http、grpc 协议，4 层要能够支持 tcp、udp 协议
  3. 灵活 upstream 服务组解析规则
    要能够支持通过请求port、 host、uri、header 等规则确定 upstream 服务组

技术选型和可行性论证

技术选型

因为本项目需求应该算是网关项目需求的子集，而目前常用的网关项目，比如 kong、apisix 等都是基于 openresty + go 这样的一个技术栈。

openresty 基于 nginx 的架构，提供非阻塞 + 同步的编程方式来支持丰富的功能开发需求，而 nginx 的架构和性能也是经过无数大型成熟项目的验证，并且本身定位也是作为反向代理来来使用

go 作为云原生时代的热门语言，特别适合这类中间件服务的开发，目前我们项目也考虑 openresty + go 这样一个技术选型

可行性论证

  1. 多协议支持
    openresty 的 lua-nginx-module 模块提供了 7 层负载均衡的编程功能，stream-lua-nginx-module 模块提供了针对 4 层负载均衡的编程功能

  2. 动态加载
    openresty 的 lua-nginx-module 模块和stream-lua-nginx-module 模块均提供了 balancer_by_lua_block 命令，给我们开放了针对负载均衡 server 选择的编程能力

    balancer_by_lua_block

    syntax: balancer_by_lua_block { lua-script }

    context: upstream

    This directive runs Lua code as an upstream balancer for any upstream entities defined by the upstream {} configuration block.

 upstream foo {
     server 127.0.0.1;
     balancer_by_lua_block {
         -- use Lua to do something interesting here
         -- as a dynamic balancer
         local balancer = require “ngx.balancer”
         balancer.set_more_tries(1)
         #设置处理请求的 server
         local ok, err = balancer.set_current_peer(host, port)
         if not ok then
             ngx.log(ngx.ERR, “failed to set the current peer: ”, err)
             return ngx.exit(500)
         end
     }
 }

 server {
     location / {
         proxy_pass http://foo;
     }
 }
  1. 灵活 upstream 服务组解析规则
    openresty 提供了丰富的 api （Lua_Nginx_API）使我们可以获取请求 host、port、uri、header，这样我们就可以根据这些信息确定请求upstream 服务组
  2. 无 reload 运行时动态解析
    reload 实现 nginx 在不停止服务的情况下重新加载配置的能力。我们先来看下 nginx 的 reload 过程
    • master 进程接收到 reload 信号
    • master 进程验证配置文件是否正确，如果配置文件正确，添加配置文件里面对新的端口资源的监听
    • master 进程启动新的 worker 进程，这些 worker 也拥有 master 新监听的端口 socket 资源，然后开始处理新的请求
    • master 进程向旧的 worker 进程发送优雅关闭信息，旧的 worker 优雅关闭

在这里插入图片描述

通过以上过程分析，我们知道 reload 过程中很重要的一件事情就是进行新的端口监听，并通过启动新的 worker 进程，来使 worker 进程拥有新的端口 socket 资源。我们很难在不 reload 的情况下进行新的端口监听。

而我们的项目要求在不进行 reload 的情况下，动态配置服务。在这种情况下，我们使用资源预分配来实现在无 reload 情况下动态配置服务，我们会先预分配一批端口资源，在运行过程中动态添加针对端口的解析

技术实现方案

预分配端口资源

通过上面分析，我们采用端口资源预分配的方案，来实现无 reload 动态配置服务，我们会预分配一批端口资源，在运行过程中动态添加针对端口的解析。

我们现将端口资源进行划分，不同的协议（不同层次的负载均衡）分别占用不同的端口范围。我们的端口资源划分如下

  • http 协议：80, 10000 - 10999
  • grpc 协议：11000 - 11999
  • tcp 协议：12000 - 12999
  • udp 协议：13000 - 13999
  • 管理接口：19000 - 19099

说明

  1. 每个协议占用 1000 个端口范围，每个 Openresty 实例每种协议监听 100 个端口
  2. Openresty 提供 http、grpc、tcp、udp 的协议支持
  3. 我们还为管理接口分配 100 个端口，每个 Openresty 监听一个管理端口，通过管理端口提供动态配置 Openresty 的接口

这样，我们提供如下的 Openresty 配置：

# 7 层负载均衡配置
http {
    # 配置 http upstream
    upstream http_backend {
        server 127.0.0.1;
        keepalive 2000;
    }
    # 配置 http upstream
    upstream grpc_backend {
        server 127.0.0.1;
        keepalive 2000; 
    }

    # 为 http 服务预分配资源
    server {
        listen 80; #http 服务默认端口，公共 web 服务使用, 根据 host, header, uri 来分配 backend,
        listen 10000; # http 服务预分配资源，根据 port 分配给申请方使用，分配方可以根据根据 host, header, uri 来分配 backend
        listen 10001;
        # ...
        listen 10099;
        location / {
            proxy_pass http://http_backend;
        }
    }
    # 为 grpc 服务预分配资源
    server {
        listen 11000 http2; # grpc 服务预分配资源，根据 port 分配给申请方使用
        listen 11001 http2;
        # ...
        listen 11099 http2;
        location / {
            grpc_pass http://grpc_backend;
        }
    }
}

# 4 层负载均衡配置
stream {
    upstream tcp_backend {
        server 127.0.0.1;
    }

    upstream udp_backend {
        server 127.0.0.1;
    }

    # tcp 负载均衡预分配资源
    server {
        # 不指定协议默认是TCP协议
        listen 12000 so_keepalive=on;
        listen 12001 so_keepalive=on;
        #...
        listen 12091 so_keepalive=on;
        proxy_pass tcp_backend;
    }

    # udp 负载均衡预分配资源
    server {
        listen 13000 udp;
        listen 13001 udp;
        #...
        listen 13099 udp;
        proxy_pass udp_backend;
    }
}
共享配置数据

Nginx 采用 master + worker 的进程模型，由多个 worker 来共同处理请求，所以多个 worker 进程之间需要共享 upstream 配置数据。我们通过共享内存来在worker 进程之间共享 upstream 配置数据

共享内存配置如下

lua_shared_dict upstream_dict 1m; # 配置共享内存，在不同 work进程之间共享 upstream 信息
init_by_lua_block {               # master 进程初始化过程中调用，进行初始化工作，一般进行 lua 模块载入、初始化共享内存
    # 初始化 upstream_dict 共享内存，可以从 redis 等存储初始化数据
    local upstreamTable = ngx.shared[upstream_dict]
    for _, upstreamInfo in pairs(httpUptreams) do
        local key = "http_" .. upstreamInfo.port
        upstreamTable[key] = upstreamInfo
    end

    for _, upstreamInfo in pairs(grpcUptreams) do
        local key = "grpc_" .. upstreamInfo.port
        upstreamTable[key] = upstreamInfo
    end

    for _, upstreamInfo in pairs(tcpUptreams) do
        local key = "tcp_" .. upstreamInfo.port
        upstreamTable[key] = upstreamInfo
    end

    for _, upstreamInfo in pairs(udp_Uptreams) do
        local key = "udp_" .. upstreamInfo.port
        upstreamTable[key] = upstreamInfo
    end
}

init_worker_by_lua_block {       # work 进程初始化调用

}

说明

  1. 如果存在以协议+端口为 key 存储数据，当存在某个端口的解析数据，说明此端口被使用，可以解析；否在端口未被使用，不能解析和访问
  2. upstreamInfo 为解析配置信息，里面包括了这组解析的信息，包括 upstreams 的 services、负载均衡算法等
动态负载均衡

我们通过 openresty 的提供的 balancer_by_lua_block 指令，来为请求动态选择 server，以实现动态负载均衡功能。我们先从共享内存里面取出来此端口的 upstream 配置信息，然后根据请求的信息和配置信息来为请求选择 server

我们以 http 服务为例，动态负载均衡配置如下

# 7 层负载均衡配置
http {
    # 配置 http upstream
    upstream http_backend {
        server 127.0.0.1;
        keepalive 2000;   # 需要配置 keepalive https://xiaorui.cc/archives/5970
        balancer_by_lua_block {
            local balancer = require "ngx.balancer"
            local upstreamTable = ngx.shared[upstream_dict]
            local port = ngx.var.server_port
            local key = "http_" .. port
            local uptreamInfo = upstreamTable[key]
            if upstreamInfo == nil{
                ngx.say("not allow")
                ngx.log(ngx.ERR, "port not allow")
                return ngx.exit(403)
            }

            # 根据 host, uri, host 确定 server
            local headers = ngx.req.get_headers() # 获取 header 信息，也可以获取其他请求信息，作为选择 uptream 的依据
            local uri = ngx.var.request_uri
            # 从 upstreamInfo 中选出处理请求的 service
            local server
            
            balancer.set_more_tries(1)
            #设置处理请求的 server
            local ok, err = balancer.set_current_peer(server.host, server.port)
            if not ok then
                ngx.log(ngx.ERR, “failed to set the current peer: ”, err)
                return ngx.exit(500)
            end
        }
    }

    # 为 http 服务预分配资源
    server {
        listen 80; #http 服务默认端口，公共 web 服务使用, 根据 host, header, uri 来分配 backend,
        listen 10000; # http 服务预分配资源，根据 port 分配给申请方使用，分配方可以根据根据 host, header, uri 来分配 backend
        listen 10001;
        # ...
        listen 10099;
        location / {
            proxy_pass http://http_backend;
        }
    }
}
服务管理接口

我们还需要提供管理接口，来管理端口资源的 upstream 配置数据

http {
    # openresty 管理接口
    server {
        listen 19000;
        location =/v1/upstream {
            # method = post 新建或者更新 upstream 服务组
            # method = delete 删除 upstream 服务组
        }

        location =/v1/parse {
            # method = post 新建或者更新 upstream 的流量解析 规则
            # method = delete 删除 upstream 的流量解析规则
        }
    }
}
服务总体配置信息

根据以上分析，我们的服务配置数据如下所示

lua_shared_dict upstream_dict 1m; # 配置共享内存，在不同 work进程之间共享 upstream 信息
init_by_lua_block {               # master 进程初始化过程中调用，进行初始化工作，一般进行 lua 模块载入、初始化共享内存
    # 初始化 upstream_dict 共享内存，可以从 redis 等存储初始化数据
    local upstreamTable = ngx.shared[upstream_dict]
    for _, upstreamInfo in pairs(httpUptreams) do
        local key = "http_" .. upstreamInfo.port
        upstreamTable[key] = upstreamInfo
    end

    for _, upstreamInfo in pairs(grpcUptreams) do
        local key = "grpc_" .. upstreamInfo.port
        upstreamTable[key] = upstreamInfo
    end

    for _, upstreamInfo in pairs(tcpUptreams) do
        local key = "tcp_" .. upstreamInfo.port
        upstreamTable[key] = upstreamInfo
    end

    for _, upstreamInfo in pairs(udp_Uptreams) do
        local key = "udp_" .. upstreamInfo.port
        upstreamTable[key] = upstreamInfo
    end
}

init_worker_by_lua_block {       # work 进程初始化调用

}

# 7 层负载均衡配置
http {
    # 配置 http upstream
    upstream http_backend {
        server 127.0.0.1;
        keepalive 2000;   # 需要配置 keepalive https://xiaorui.cc/archives/5970
        balancer_by_lua_block {
            local balancer = require "ngx.balancer"
            local upstreamTable = ngx.shared[upstream_dict]
            local port = ngx.var.server_port
            local key = "http_" .. port
            local uptreamInfo = upstreamTable[key]
            if upstreamInfo == nil{
                ngx.say("not allow")
                ngx.log(ngx.ERR, "port not allow")
                return ngx.exit(403)
            }

            local headers = ngx.req.get_headers() # 获取 header 信息，也可以获取其他请求信息，作为选择 uptream 的依据
            local uri = ngx.var.request_uri

            # 根据 host, uri, host 确定 server
            balancer.set_more_tries(1)
            #设置处理请求的 server
            local ok, err = balancer.set_current_peer(host, port)
            if not ok then
                ngx.log(ngx.ERR, “failed to set the current peer: ”, err)
                return ngx.exit(500)
            end
        }
    }
    # 配置 http upstream
    upstream grpc_backend {
        server 127.0.0.1;
        keepalive 2000;   # 需要配置 keepalive https://xiaorui.cc/archives/5970
        balancer_by_lua_block {
            # 此处会根据请求 host, port, header, uri 等信息和初始化共享变量的配置，设置处理请求的 server
            # use Lua to do something interesting here
            # as a dynamic balancer
        }
    }

    # 为 http 服务预分配资源
    server {
        listen 80; #http 服务默认端口，公共 web 服务使用, 根据 host, header, uri 来分配 backend,
        listen 10000; # http 服务预分配资源，根据 port 分配给申请方使用，分配方可以根据根据 host, header, uri 来分配 backend
        listen 10001;
        # ...
        listen 10099;
        location / {
            proxy_pass http://http_backend;
        }
    }
    # 为 grpc 服务预分配资源
    server {
        listen 11000 http2; # grpc 服务预分配资源，根据 port 分配给申请方使用
        listen 11001 http2;
        # ...
        listen 11099 http2;
        location / {
            grpc_pass http://grpc_backend;
        }
    }

    # openresty 管理接口
    server {
        listen 19000;
        location =/v1/upstream {
            # method = post 新建或者更新 upstream 服务组
            # method = delete 删除 upstream 服务组
        }

        location =/v1/parse {
            # method = post 新建或者更新 upstream 的流量解析 规则
            # method = delete 删除 upstream 的流量解析规则
        }
    }
}

# 4 层负载均衡配置
stream {
    upstream tcp_backend {
        server 127.0.0.1;
        balancer_by_lua_block{
            # use Lua to do something interesting here
            # as a dynamic balancer
        }
    }

    upstream udp_backend {
        server 127.0.0.1;
        balancer_by_lua_block{
            # use Lua to do something interesting here
            # as a dynamic balancer
        }
    }

    # tcp 负载均衡预分配资源
    server {
        # 不指定协议默认是TCP协议
        listen 12000 so_keepalive=on;
        listen 12001 so_keepalive=on;
        #...
        listen 12091 so_keepalive=on;
        proxy_pass tcp_backend;
    }

    # udp 负载均衡预分配资源
    server {
        listen 13000 udp;
        listen 13001 udp;
        #...
        listen 13099 udp;
        proxy_pass udp_backend;
    }
}

服务多实例管理

因为我们的端口资源预分配的，既然是预分配，那么就会用耗尽的情况，针对这种情况，我们采用多实例来解决这个问题。当服务资源将要耗尽的时候，我们通过创建新的实例来申请更多的资源

既然是多实例，那我们就需要一个代理服务来管理这些实例，这个代理服务主要提供一下功能

  • 代理 openresty 的管理接口
  • 管理已经分配和未分配的端口信息
  • 新建、删除 openresty 实例

这样，我们的服务架构，将变成如下所示
在这里插入图片描述

服务高可用管理

作为一个负载均衡服务，提供高可用功能是非常重要的，所以我们的服务还需提供集群管理功能，并将 Openresty 实例进行备份，然后对 Openresty 实例及其备份实例进行调度，将其均匀分配到集群不同机器上

对 Openresty 进行主备管理，那么主备管理将是一件非常重要的事情。我们采用 keepalived 进行服务实例主备管理。

keepalived基于VRRP协议来实现高可用，主要用作realserver的健康检查以及负载均衡主机和backup主机之间的故障漂移。它主要工作在 ip 层，通过虚拟 ip 和 mac 地址来虚拟出对外提供服务的 ip ，当发证故障需要转移，通过 arp 协议，来通知主机更新各个主机 arp 信息（ip 和 mac 地址对应关系）

既然要提供集群管理功能，所以我们还需要一个 guilder 服务，来对集群进行管理，并提供服务的对外管理接口

到目前为止，服务架构图如下
在这里插入图片描述
Guilder 服务主要提供一下功能

  1. 管理主机信息，将主机加入集群，或者从集群中删除主机
  2. 协调管理 openresty 实例，通过调用 agent 接口，保证 openresty 实例均匀分布到不同机器上
  3. 管理 openresty 的 upstream 和 upstream 对应的解析等信息
  4. 管理端口分配、分布信息，openresty 实例分布信息
SPDK动态负载均衡
weixin_37097605的博客
09-29 1336
背景在SPDK中，每个CPU core将对应一个reactor，创建的线程将在reactor上执行。Figure 1 core – reactor - thread 对应关系默认情况下，...
网络动态负载均衡算法分析
07-24 2218
网络动态负载均衡算法分析陈登伟，鲁智勇（中国人民解放军63880部队　河南洛阳　471003）    摘　要：在阐述网络负载基本概念的基础上，分析了基本的网络负载均衡算法并对动态反馈负载均衡进行了探讨。    关键词：计算机网络；负载均衡；网络过载；算法　　随着Internet的日益普及，无论在企业网、园区网还是在广域网如Internet上，用户与业务量
OpenResty动态负载均衡
Fouy_风度玉门。
07-16 6159
Consul Consul+Consul-templete方式 Consul-Server 注册服务 Consul-template 上游服务器 测试验证 Consul+Lua方式 OpenResty配置 在之前提到的OpenResty/Nginx的负载均衡当中，当服务器启动之后，upstream中的上游服务器就是固定死的了，做不到动态的变更。这里面说到的变更，其实更多指...
负载均衡和动态负载均衡
qq_22978533的博客
10-13 2817
Nginx一般作为反向代理服务器来实现反向代理来转发处理请求，同时也可以作为静态资源服务器来加快静态资源的获取和处理。 1.正向代理与反向代理 正向代理： 正向代理 是一个位于客户端和原始服务器之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。 作用：访问原来无法访问的资源；可以做缓存，加速访问资源；对客户端访问授权，上网进行认证；代理...
Http动态负载均衡
lzh253985690的博客
01-06 675
Http动态负载均衡 什么是动态负载均衡 传统的负载均衡，如果Upstream参数发生变化，每次都需要重新加载nginx.conf文件, 因此扩展性不是很高，所以我们可以采用动态负载均衡，实现Upstream可配置化、动态化，无需人工重新加载nginx.conf。 这类似分布式的配置中心 动态负载均衡实现方案 Consul+Consul-template 每次发现配置更改需要raload ngi...
动态负载均衡的实施及适用场景
最新发布
用低代码构建未来——勤研科技低代码开发新视角，助力企业数字化转型
08-09 538
在现代多租户环境中，随着用户需求的不断变化和流量的波动，传统的静态负载均衡方法往往难以满足高效资源利用和服务质量的要求。动态负载均衡应运而生，它能够根据实时的流量和资源使用情况，灵活地调整请求的分配，确保系统的高效运行和用户体验的优化。
基于排队论综合指标评估的动态负载均衡算法.pdf
02-16
"基于排队论综合指标评估的动态负载均衡算法" 这个动态负载均衡算法基于排队论综合指标评估，旨在解决互联网通信、计算机集群和云环境中的负载失衡问题。该算法的提出是为了解决传统负载均衡策略的缺陷，即以 CPU、...
基于排队论综合指标评估的动态负载均衡算法
01-19
针对该问题，提出了一种基于排队论综合指标评估的动态负载均衡算法，首先引入排队论模型评估各服务器的实时负载情况，然后根据各服务器的负载综合指标，将输入队列中的任务逐一分配给各服务器。实验结果表明，该方法...
基于负载感知的数据流动态负载均衡策略
02-07
### 基于负载感知的数据流动态负载均衡策略 #### 摘要解析与扩展 在当前的大数据处理环境中，特别是在流式计算平台中，如何有效地进行资源管理和任务调度是提高系统性能的关键因素之一。传统的负载均衡策略往往...
基于动态负载均衡的分布式任务调度算法研究.pdf
08-10
本文研究了基于动态负载均衡的分布式任务调度算法，旨在解决传统分布式任务调度中节点负载不均衡问题，从而提高系统性能。 动态负载均衡是指在任务调度过程中，根据系统内各节点的实时性能指标，如CPU利用率、内存...
利用遗传算法的网络GIS集群服务器动态负载均衡算法 (2011年)
05-27
### 利用遗传算法的网络GIS集群服务器动态负载均衡算法 #### 一、研究背景与意义 随着互联网技术的发展和地理信息系统（GIS）的应用日益广泛，网络GIS面临着大量的并发访问请求，这对服务器端的数据处理能力提出了...
spring_cloud_gateway负载均衡，动态路由
12-11
spring cloud gateway的负载均衡和动态路由的实现 demo_01,demo_02,demo_03 这三个服务相当于是集群的微服务 gateway这个服务是 springcloude gateway + ribbon 做的负载均衡 gateway_01 这个服务 是动态路由的实现 其中redis部分，有一个jar是自己封装的，可以自己手写redis工具类替换掉
Nginx动态负载均衡
热门推荐
大魔王
11-17 2万+
Nginx一般作为反向代理服务器来实现反向代理来转发处理请求，同时也可以作为静态资源服务器来加快静态资源的获取和处理。 1.正向代理与反向代理 正向代理：        正向代理 是一个位于客户端和原始服务器之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才...
Nginx实现动态负载均衡
xungen的博客
05-24 2577
为什么用nginx nginx是经过实践证明的、安全稳定的反向代理服务器，淘宝、新浪等大型互联网公司都有nginx的身影。nginx经过线上各种网络环境验证，能够帮你隔离各种复杂的网络环境，轻松支持10000+的同时在线连接数，同时拥有多种成熟的负载均衡策略，能够方便横向拓展后端服务。今天我们说一说nginx负载均衡策略。 nginx有以下几种负载均衡策略 1、基于轮询方式 轮询是最基本的配...
nginx-17 动态负载均衡
yt_php的博客
02-14 735
负载均衡请参考nginx-16 负载均衡 前言 通常如果要增加、删除一台上游服务器的步骤是，编辑nginx.conf，再执行nginx -s reload重载配置。 这样的做法，一个是相对麻烦，第二个问题是nginx -s reload对于nginx是有压力的，它会去重启进程去加载配置，消耗系统的cpu资源。 upstream backend { server 49.233.70.27:9502...
静态负载均衡和动态负载均衡_动态负载平衡
cumtb2002的博客
07-30 2607
静态负载均衡和动态负载均衡 动态负载平衡 (Dynamic Load Balancing) The algorithm monitors changes on the system workload and redistributes the work accordingly. 该算法监视系统工作负载的变化并相应地重新分配工作。 This algorithm works on three st...
负载均衡算法
XiaoCai
12-26 1518
负载均衡（Load Balance），指由多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，都可以单独对外提供服务而无须其他服务器的辅助。通过某种负载分担技术，将外部发送来的请求均匀分配到对称结构中的某一台服务器上，而接收到请求的服务器独立地回应客户的请求。负载均衡能够平均分配客户请求到服务器阵列，借此提供快速获取重要数据，解决大量并发访问服务问题，这种集群技术可以用最少的投资获得接近于大型主机的性能。
动态网络负载均衡平衡算法
weixin_33749242的博客
10-18 1460
2019独角兽企业重金招聘Python工程师标准>>> ...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值