Nacos 3.0 架构全景解读,AI 时代服务注册中心的演进

作者:杨翊(席翁),柳遵飞(翼严),罗鑫(子葵)

Nacos/nɑ:kəʊs/是 Dynamic Naming and Configuration Service 的首字母简称,随着 Nacos 3.0 的发布,定位由“更易于构建云原生应用的动态服务发现、配置管理和服务管理平台”升级至“ 一个易于构建 AI Agent 应用的动态服务发现、配置管理和 AI 智能体管理平台”。

Nacos 从 2018 年 7 月宣布开源以来,已经走过了第六个年头,在这六年里,备受广大开源用户欢迎,收获许多社区大奖。Nacos 在社区共同的建设下不断成长,逐步开始帮助用户解决实际问题,助力企业数字化转型,目前已经广泛使用在国内的公司中,根据微服务领域调查问卷,Nacos 在注册配置中心领域已经成为国内首选,占有 50%+国内市场 份额,被各行各业的头部企业广泛使用。在此期间,Nacos 的部署包下载量突破 300w 次,官网每年访问用户数超过 90w 人,被国内各主流云厂商托管服务。

随着 AI 时代到来以及 Nacos 3.0 版本的正式发布,Nacos 未来的演进目标以及架构也会随之升级。本文会对比 Nacos 3.0 与 Nacos 2.0 的架构异同,对 Nacos 3.0 的主要功能原理进行介绍。

1. Nacos 2.0 架构回顾

Nacos 2.0 的架构主要聚焦对性能和可扩展性进行优化和提升。

对于性能升级,Nacos 2.0 通过将通信模型从 HTTP 升级至 gRPC,从短连接模型升级到长连接模型,使得 Nacos 的通信吞吐量中极大提升;同时配合数据存储和数据结构模型的升级,进一步减少核心操作所涉及的步骤和链路,最终实现性能的 10 倍提升。

关于可扩展性升级,Nacos 2.0 通过将一些具有个性化需求的通用能力进行抽象,进行插件化改造的方式,允许 Nacos 用户和运维人员能够开发自定义插件,适配个人或企业的个性化需求。

虽然 Nacos 2.0 在性能和可扩展性实现了一些突破,但仍然还存在一些挑战。

其中一个主要的挑战就是 Nacos 的安全风险。比如:Nacos 2.0 中所有的 HTTP API 均使用 8848 端口, 这其中及包含了 1.X 客户端使用的 API,也包含了运维人员以及控制台的 API。不同类型的 API, 对于权限的需求其实是不同的,对于网络访问的连通性要求也是不同的。使用单端口并且使用唯一的鉴权开关,导致了网络的访问控制,以及鉴权控制都不是很灵活。许多用户为了方便使用,将此端口暴露在办公网甚至公网环境,同时未开启鉴权,这就造成了安全风险。

另一个问题就是默认命名空间的使用,Nacos 最初的版本中定义了命名空间作为数据资源的强隔离属性,不同命名空间之间的服务和配置不能互相发现和获取;但在最初版本中因为历史原因,注册中心和配置中心对于默认命名空间的处理方式有一定的不统一,这导致了许多用户在使用默认命名空间时经常配置错误或者出现疑惑;并且在 Nacos 2.0 提供各种插件能力之后,许多插件实现时需要额外工作进行适配,严重阻碍了插件的开发以及插件的稳定性。

随着 AI 时代来临,AI Agent 应用的部署形态在之前云原生可弹性可伸缩的基础上,要求更加轻量,更加弹性,例如 FC 场景;在这种要求下,我们需要考虑 Nacos 之前的服务发现和配置管理的能力是否还能承载 AI Agent 的应用的部署。同时,随着越来越多的 AI Agent 的应用贯穿业务全线,Nacos 能否帮助更好地管理 AI Agent 的应用,是 Nacos 在当前的挑战,同时也是新的机遇。

为了应对这些挑战以及机遇,Nacos 3.0 架构也做了对应的升级。目标是在 AI 时代成为更安全的 Registry。设计理念也由之前的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台升级为一个易于构建 AI Agent 应用的动态服务发现、配置管理和 AI 智能体管理平台。

2. Nacos 3.0 架构

2.1 Nacos 3.0 整体架构解析

Nacos 3.0 升级后的整体架构仍然以一致性协议、通信模块、其他模块等通用功能模块为基座,承载出注册中心、配置中心、AI Registry、协议增强等功能;同时通过各类多语言 SDK,桥接各个生态组件。架构的左右两侧,分别是 Nacos 的插件以及 Nacos 的一些拓展组件,它们一起构成了 Nacos 3.0 的整体架构。

我们来重点关注 Nacos 3.0 的新增能力,即图中绿色和棕色的部分。

这其中既包括对原本注册配置中心的增强功能,即模糊订阅,也包括了对 AI 相关能力的实现和规划,如 MCP 和管理,MCP Router,动态 Prompt 及 A2A 协议支持;同时也通过支持 xDS 协议及 Nacos Controller 继续加强和探索 Mesh 生态。

2.2 Nacos 3.0 AI Registry 架构

了解完 Nacos 3.0 的整体架构,接下来我们来看 Nacos AI 中心(AI Registry)的架构设计。作为 Nacos 3.0 规划中最重要的能力,Nacos AI Registry 的架构被分为 3 个层次,分别是模型层、``工具层和应用层。

在模型层中,主要通过对 AI 模型中一些常用的动态参数,比如 Prompt、学习率、联网参数等进行管理,采取复用在云原生应用中配置动态管理和分发能力的方式,帮助 AI 智能体在模型层进行快速调整及试错。

模型层之上是工具层,工具层主要帮助 LLM 模型和提供数据的 MCP 工具之间进行自动的发现、注册以及检索等能力,复用在云原生应用中服务的动态注册、管理、发现的能力,帮助 AI 智能体应用快速及便捷地发现 MCP 工具,同时快速过滤无关工具,减少 Token 损耗。

最顶层是 Agent 的应用层,实现 AI 应用与 AI 应用之间的发现与协作。目前规划是通过支持 A2A 等社区标准协议,同时配合 Spring AI Alibaba 等 AIAgent 应用框架,帮助 AIAgent 应用便捷的自动注册自身 AI 应用,同时发现其他 AI 应用,并能够像云原生应用一样,进行任务的分发以及结论的构成。

如果从功能视角出发,Nacos AI Registry 又可被分为针对大模型 LLM 的模型动态配置调优,针对 AI 应用平台的应用开发管理以及针对 AI Agent 应用的运行时能力增强。Nacos 希望通过不同的功能点,帮助 AI 应用像微服务云原生应用一样,能动态的调整 Prompt,学习率等参数,无需重新发布,从而帮助 AI 应用简化开发,调试过程中的繁琐操作,提高 AI 应用的开发和运行效率。

2.3 Nacos 3.0 安全架构

Nacos 2.0 中面临的一个主要的风险就是 Nacos 所有的 HTTP OpenAPI 均通过统一的端口进行暴露,同时使用了统一的鉴权开关,这使得使用者必须在便捷性和安全性中作出取舍,导致在许多部署的环境中可能存在安全风险。

Nacos 3.0 为了解决这个问题,从 Nacos 的部署架构上作出演进,独立控制台部署,拆分鉴权开关,分类 API 并默认开启控制台及管控类 API 的鉴权。

同时配合配置加密插件,``TLS 传输,来实现 Nacos 3.0 的零信任安全架构。

除了针对 Nacos 自身的安全零信任架构外,Nacos 3.0 还将与 Druid,Spring AI Alibaba/Spring Cloud Alibaba 等开源社区,及 KMS 等安全云产品合作,提供面向应用侧的数据源运行期动态轮转方案。

在这套解决方案中,数据源的凭据始终由 KMS 等凭据托管平台和系统保存,全程无人工传递和配置的过程。用户可以设置定期进行凭据的自动轮转,或在怀疑密钥泄漏时手动触发凭据轮转;触发后会通过 Nacos 动态无损的将新的加密凭据通知到 Druid 或 Spring AI Alibaba/Spring Cloud Alibaba,进行凭据的动态刷新和无损替换。这种方式极大降低了凭据泄漏的可能性,同时显著提高了安全性及出现安全风险时的收敛恢复速度。

3. Nacos MCP Registry

3.1 Nacos MCP Registry 架构

Nacos 3.0 最主要的能力升级就是作为 MCP Registry,支持了 MCP 服务的管理能力。

Nacos MCP Registry 支持三类 MCP 服务的注册方式:

第一类是将存量 HTTP 或 RPC 的服务,通过声明自动转化为 MCP 服务,配合 Higress 的协议转换能力,实现 0 代码改造成 MCP 服务协议,如何将存量 API 转化为 MCP 服务,详情可参见文档【1】。

第二类就是新构建的 MCP 服务注册, 配合 Spring AI 等 AI Agent 应用框架和 Nacos-MCP 的 sdk,能够做到像微服务一样自动注册到 Nacos 中进行统一的管理和维护,如何通过 Spring AI 或 Nacos-MCP 的 sdk 进行 MCP 服务的自动注册与发现,请参见文档【2】。

第三类就是已经构建好的或其他供应商提供的 MCP 服务,可以导入到 Nacos 中,进行其描述、工具列表、工具 Schema 等内容的动态修改和维护,让调试 MCP 服务变得更加简单。

3.2 Nacos MCP Router

Nacos 3.0 支持用户通过 3 种方式发布 MCP 服务,并对 MCP 服务的元数据和版本进行管理,但如果最终不能将这些元数据和版本信息进行实际的使用,这些信息就没有意义。

因此 Nacos 3.0 提供 Nacos MCP Router 帮助终端使用者无需实际感知 MCP 服务列表,即可自动发现和使用需要的 MCP 服务。

Nacos MCP Router 提供两种工作模式,动态路由和动态代理。

动态路由模式将会根据 LLM 所提供的关键字信息,对注册在 Nacos 中的 MCP 服务进行相关性过滤和筛选,选择出与关键字相关的 MCP 服务进行实际的使用,从而减少对 LLM 上下文的消耗,实现路由 MCP 服务的能力。

而代理模式能够进行 MCP 协议的转换,将 stdio 和 sse 类型的 MCP 服务,代理成 streamable 类型的 MCP 服务。代理模式下的 Nacos MCP Router 不根据关键字进行筛选,仅是将注册在 Nacos 中的 stdio 和 sse 类型的 MCP 服务,转化成 streamable 类型,同时应用用户在 Nacos 上修改和编辑的 Tool 描述信息,将转化后的 MCP 服务列表,返回给 LLM 供其使用。

4. Nacos 3.0 RoadMap

Nacos 3.0 的目标是成为全面拥抱 AI 时代的服务、配置、AI Registry 平台,因此 Nacos3.0 的 RoadMap 将会逐步实现 AI Registry 的能力,从当前的 MCP 管理,拓展到 Prompt 管理,Agent 的自动注册发现,再到 LLM 模型的参数管理和托管;同时进一步加强注册配置中心的能力和更多相关领域协议的支持(如 DNS,Mesh)。

Nacos 也希望有更多的社区贡献者加入进 Nacos 社区,帮助 Nacos 更快更好的完善和实现 Nacos3.0。

5. 欢迎加入 Nacos 社区

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及 AI 管理。

Nacos 帮助用户更敏捷和容易地构建、交付和管理云原生 AI 应用的平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式、AI 原生范式) 的服务基础设施。

Nacos 3.0 还有很多待完成的功能及大量待探索和开发的领域,欢迎大家扫码加入 Nacos 社区群及 Nacos MCP 社区讨论群,参与 Nacos 社区的贡献和讨论,在 Nacos 社区一起搭把手,让你的代码和能力有机会能在各行各业领域内进行释放能量,期待认识你和你一起共建 Nacos 社区;

“Nacos 相信一切都是服务,每个服务节点被构想为一个星球,每个服务都是一个星系;Nacos 致力于帮助这些服务建立连接赋予智能,助力每个有面向星辰的梦想能够透过云层,飞在云上,更好的链接整片星空。”

Nacos 官网:

https://nacos.io/

Nacos 仓库地址:

https://github.com/alibaba/nacos

“Nacos社区群5”群的钉钉群号:

120960003144

“Nacos MCP 社区讨论群”群的钉钉群号:

97760026913

6. 更多了解 Nacos 3.0

6 月 6 日,Nacos 在上海举办了开源开发者沙龙 MeetUp 活动,此次是 Nacos 社区成员今年首次线下分享最新的能力和实践,并邀请了 Spring AI Alibaba 和 Higress 一起分享一站式的开源解决方案。

有需要 MeetUp 的 PPT 或希望回看 MeetUp 活动视频的同学,欢迎加入本文末尾的群中获取。

同时如果对 Nacos 3.0 的架构,运行原理,最佳实践等内容感兴趣的同学,欢迎阅读 Nacos 3.0 更多相关文章:

《0 代码改造实现应用运行时数据库密码无损轮转》

《Nacos MCP Router 新版发布:支持 Docker 远程部署,MCP的多协议stido、SSE、Streamable互相转换》

《企业生产环境中,实现 MCP 服务的统一管理和智能路由的实践》

《Nacos 3.0 正式发布:MCP Registry、安全零信任、链接更多生态》

【1】存量 API 转换 MCP 手册

https://nacos.io/docs/latest/manual/user/ai/api-to-mcp/?spm=5238cd80.2ef5001f.0.0.3f613b7ciRMNL5

【2】MCP Server 自动注册手册

https://nacos.io/docs/latest/manual/user/ai/mcp-auto-register/?spm=5238cd80.2ef5001f.0.0.3f613b7ciRMNL5

相关推荐

推荐一款好用的刷题工具

为了帮助正在准备求职季的开发者提升备战效率,阿里云特别推出“通义灵码陪你备战求职季”活动,精心挑选百道历史校招技术面试/笔试题,借助通义灵码智能问答、代码智能生成、代码优化等核心功能,帮助开发者更加准确地了解程序员职业所需的核心技能,加强对问题解决思维和解题能力的练习。

阿里巴巴云原生的博客 1383

通义灵码 Visual Studio 下载安装指南(附安装包)

本安装步骤适用于 Windows 10 及以上操作系统中安装和使用通义灵码。

阿里巴巴云原生的博客 4436

生产更可信,订阅更耐用丨Higress 社区进展报告

阿里巴巴云原生的博客 115

让 Agent 成为企业生产力丨Alibaba Cloud AgentCore 企业智能体构建与治理沙龙·杭州站精彩回顾 & PPT 下载

近日,让 Agent 成为企业生产力丨Alibaba Cloud AgentCore 企业智能体构建与治理沙龙·杭州站圆满落幕。本场活动吸引了 100+ 名技术从业者深度参与,深度分享了企业 Agent 趋势、AgentCore 构建与治理、Agent 观测与优化、STAROps 智能运维及 AI 网关等相关议题,并设置了动手实操环节。

阿里巴巴云原生的博客 58

如何用 STAROps Elasticsearch 智能助手看穿“搜索变慢”

某电商平台的商品搜索服务使用一台 6 个数据节点的 Elasticsearch 实例。周五北京时间 20:00 起,业务陆续反馈搜索变慢。业务监控中的搜索接口 P99 从平时约 200 ms 升到 2s 以上,部分请求超时。值班工程师打开控制台:集群状态为 Green,没有未分配分片,集群平均 CPU 约 40%,乍看不像资源已经吃紧。

阿里巴巴云原生的博客 304

满帮基于阿里云 AgentCore 打造生产级 SRE 稳定性数字人

满帮基于阿里云 AgentCore 构建“稳定性数字人”:满帮提供业务知识、专业工具与处置流程,AgentCore 提供智能体运行、协作和治理支撑。数字人已在核心链路的巡检与根因分析中得到应用,受控处置能力也在持续建设,让满帮积累的稳定性能力能够在具体任务中得到复用。

阿里巴巴云原生的博客 112

稳定复现超 70% 的缺陷,报警到自动修复的 Agent 流水线实践

本文将分享我们在 PolarDB-X 团队做的一些工程实践:让 Agent 从一条报警或工单出发,自主完成排查、复现、修复和验证,再把结果交给研发评审。

阿里巴巴云原生的博客 294

从“自证清白”到“因果链条”:智能体如何重塑运维排障效率

STAROps 做全域关联分析,把范围从「五个团队依次自证清白」收拢到一条具体链路;证据指向对象存储后,OSS Agent 接手,基于真实配置、访问日志和用量数据往下挖,给出根因和支撑它的证据链。你面对的始终是一个对话框:路由归它管,说清现象、拍板方案归你。

阿里巴巴云原生的博客 125

TechTalk丨从能买奶茶到能进企业,Agent 绕不开同一组问题

史明伟所在的 Alibaba Cloud AgentCore 是企业级 Agent 构建和治理平台,为 Agent 在业务场景下的规模化落地提供基础设施,所以这场对话,他和 Datawhale 主持人从个人助理一路聊到企业 Agent:权限该怎么一步步放开?进了企业,账号打通、数据权限、沙箱隔离又会带来哪些新问题?没有强技术团队的企业,该从哪里起步?

阿里巴巴云原生的博客 208

AgentCore + Codex 构建生产级 Agent 的原理与实践

本文章演示 AgentCore[1]的自定义代码/镜像能力,目的是展示如何基于自定义的 Harness 框架(Codex) 结合 AgentCore 提供的身份、模型、工具、技能、凭证 、观测评估等能力实现一个端到端的 Agent 应用,内容包含两个部分,技术方案和实践教程,文末附相关源码和本次的测试数据,可以根据需要自行查阅。

阿里巴巴云原生的博客 187

让复杂任务由团队完成:阿里云 AgentCore 多 Agent 协作架构及实践

Alibaba Cloud AgentCore 以身份、通信、团队和任务为基础,让专业 Agent 与人类成员共同参与业务协作。企业可以按职责组合知识、工具、Skill 和模型,用任务系统持续追踪工作,再结合 AgentLoop 评估效果、优化配置。

阿里巴巴云原生的博客 335

易点天下:AI 驱动 IT 运维组织提效的实践

易点天下作为一家专注品牌全球化的营销科技公司,由智能营销、全域增长、智能变现三大引擎驱动。公司旗下拥有“整合营销服务”与“广告平台业务”两大业务线。

阿里巴巴云原生的博客 300

阿里云可观测 2026 年 10 月产品动态

阿里云可观测 2026 年 10 月产品动态

阿里巴巴云原生的博客 199

用 Nacos 3.3.0 ARD 让 Agent 按任务发现工具和 Skill

如今,工作中用 Agent 帮忙已经越来越常见。研发同学用 Coding Agent 写代码、补测试、排查问题,业务同学用 Work Agent 整理资料、分析表格、制作演示文稿。不少过去需要自己一步步操作的事情,现在可以把需求交给 Agent,让它协助完成。

阿里巴巴云原生的博客 314

HiRoute 新版本发布:结合自己的真实工作选择最佳模型

HiRoute[1]是一个开源、运行在本地的 Agent 智能路由引擎。你继续用 Codex、Claude Code、Qoder、Pi、OpenCode、Hermes、DeepSeek Harness 等熟悉的 Agent,由 HiRoute 判断每一步交给哪个模型。

阿里巴巴云原生的博客 388

用户说 App“下不了单”:用 Session Replay 看清流程卡在哪一步

Session Replay(会话回放)将采集到的页面变化重建为可回看的过程。研发可以沿着这次会话,查看操作前后的界面变化,先确认流程停在了哪里,再结合当时的事件、日志和代码检查原因。

阿里巴巴云原生的博客 55

欢迎报名丨Alibaba Cloud AgentCore 企业智能体构建与治理八城巡回沙龙 · 杭州站开启

欢迎报名丨Alibaba Cloud AgentCore 企业智能体构建与治理八城巡回沙龙 · 杭州站开启

阿里巴巴云原生的博客 144

运维走出控制台:阿里云 AgentCore AI Native 运维实践

UModel 让现场能够被关联,运维数字员工让经验能够被调用,AgentCore Team 让分析能够协作,AgentLoop 让质量能够被检验。这些建设共同服务于一件事:让团队对系统的理解,成为每个人处理问题时都能接上的能力。

阿里巴巴云原生的博客 301

从长程 Agent 到 Super-agent,解锁更多场景

Deepseek Harness 提升了架构的透明度,但也带来了工程上的复杂度。这次开源的dsh-superagent-prototype,是对 Agent “连续实体”能力的工程拆解。

阿里巴巴云原生的博客 237

排查提效 50%:淘大集新核心系统的观测护航之路

供应链运维,缺的不是更多机器,是“一条能把指标、日志、链路串起来的线”。阿里云 ARMS+SLS+云监控2.0+STAROps 重构观测底座。

阿里巴巴云原生的博客 148

概率、插座与 5000 个爱因斯坦:专访阿里云研发副总裁周琦

这次访谈发生在 2026 年云栖大会之后。大会期间,阿里云发布了智能体构建和治理平台 AgentCore,将企业级 Agent 基础设施进一步标准化和托管化。

阿里巴巴云原生的博客 154

Agent 数据飞轮平台的选型和实践

用统一标准判断修改效果,积累覆盖不同路径的测试样本,沿执行记录排查失败,并将典型问题纳入后续回归。而这也是宙斯接入 AgentLoop 要解决的问题。

阿里巴巴云原生的博客 29

Durable Agent 详解:如何让 Agent 在云端长期稳定运行

本文使用一个具体的用户任务示例“向五位客户发送通知邮件”,解释为什么保存聊天记录还不够,再以 AgentScope 构建的 Agent 为例,展开任务状态、持久提交和故障恢复的通用设计,最后结合 Alibaba Cloud AgentCore 已有的 Harness 托管与节点恢复能力,讨论共享状态、可靠调度及 Brain / Hands 分离如何支撑更完整的长期托管服务。

阿里巴巴云原生的博客 335

Qoder × AgentLoop:智能体规模化应用,敏感数据保护如何跟上?

智能体观测与优化平台 AgentLoop 持续分析已采集的 Qoder 审计日志,将发现的风险线索关联到具体会话、工具调用、成员和环境,帮助安全团队回查任务过程、明确需要整改的环节,并复查处理效果。

阿里巴巴云原生的博客 291

完整还原已经服务千家企业的 AIOps Agent 的评测和调优实践

阿里云 STAROps 是一个生产运维 Agent,通过连接多域数据、运维工具与专家经验,从被动响应走向智能自治,7×24 保障业务连续、稳定运行。本文将分享 STAROps 的评测和调优实践。

阿里巴巴云原生的博客 199

阿里云云原生四项 AI 应用工程化实荣获“鼎新杯”优秀案例

第五届“鼎新杯”由中国通信标准化协会主办、中国信息通信研究院承办,自2026年05月正式启动,历时近 5 个月,聚焦国内政企数智化转型领域的创新成果,旨在为行业提供可复制、可推广的实践参考。

阿里巴巴云原生的博客 323

交付周期从 51 天缩短到 14 天,多 Agent 协作产品⾃进化背后的组织重构

本⽂结合这段实践,介绍评测如何驱动产品持续进化、⼈机协作的边界如何设定,以及团队如何通过统⼀⽬标、结果标准和责任分⼯,减少跨岗位交接,降低沟通损耗,把技术能⼒转化为实际交付效果。

阿里巴巴云原生的博客 328

从部署上线到运维优化:STAROps 与 ROS Agent 的资源运维自动化实践

STAROps 数字员工提供统一的运维对话入口,结合日志、指标、告警等信息理解问题,并通过 alibabacloud-ros-agent 技能,将基础设施规划和变更任务委派给 ROS Agent。

阿里巴巴云原生的博客 131

车企数据隐私保护必修课:如何用 SLS mask 守住日志中的敏感信息

阿里云日志服务 SLS 的 mask 函数可在采集或写入阶段替换匹配的敏感值,同时保留业务状态与调用链,并结合访问控制和保留期限管理减少暴露。下文通过车辆与车主服务、海外联网订阅、智能座舱交互三类业务中的四组日志,介绍规则选择与脱敏效果。

阿里巴巴云原生的博客 113

切换模型会损失缓存,智能路由还省钱吗?

智能路由会把不同的工作交给不同的模型。很多人随之会问:模型一换,之前积累的缓存就用不上了,这笔损失会不会把省下的钱又花回去?

阿里巴巴云原生的博客 209
上一篇: 编程智能体+MCP:让 AI 提取和总结微信聊天记录,再也不怕错过重要信息
下一篇: 打通数据孤岛:基于对象存储的多云可观测融合实战
阿里云云原生
阿里云云原生 企业官方账号 企业官方账号
博客等级 码龄8年 1万+粉丝 3151原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值