简介这是一份面向信创云平台规划与建设人员的完整方案文档针对国内信息技术自主创新云平台发展中核心技术受制、安全能力不足、适配环境缺乏等痛点提供了从入驻基地、搭建信创云到功能展示的系统化解决路径。资源包内含1个docx文档大小约29.58MB文档结构完整涵盖项目改造意义、发展现状、问题分析、需求分析及云平台基础设施区设计等章节适合作为项目申报、方案编写和汇报展示的参考模板。目前已有1446人学习下载尤其适合信息化主管部门、云平台架构师及信创项目管理人员使用。读者可依据文档中的需求分析方法与设计思路快速搭建自身项目的信创云框架同时规避核心技术风险、完善安全体系提升方案的专业性与可落地性。1. 信创云平台建设方案为什么你拿到的 docx 只是张入场券做过信创迁移的同行都有体会真正卡进度的从来不是 CPU 换成了鲲鹏或飞腾也不是操作系统从 CentOS 换成了麒麟或统信而是你发现“替换”这两个字背后站着一整条软件生态链——数据库、中间件、虚拟化、容器编排、运维监控每一层都要重新选型、适配、调优。所谓“信创云平台建设方案.docx”它通常是一份包含现状调研、总体架构、分阶段实施路径、迁移策略与风险应对的完整规划文档它解决的是“从现有 IT 架构平滑迁移到信创体系”这个系统工程问题而不是简单回答“装哪个系统”。这套方案真正适合三类读者一是企业里负责基础设施的技术负责人需要向上汇报和向下落地二是做迁移实施的一线工程师需要把方案变成可执行的部署步骤三是政务、金融、能源等对合规有硬性要求的行业从业者。对这些人来说方案的意义在于把“国产化替代”从一个口号拆解成架构选型、资源规划、业务迁移、安全等保、应急回退五个可落地的动作。本文偏重真实可用的环节架构怎么立、部署怎么走、参数怎么调、业务怎么迁、坑在哪里。2. 信创云平台的技术栈拆解从芯片到 PaaS 的完整替代路径2.1 全栈信创的分层模型为什么“能用”不等于“适配”做信创云平台第一件事是建立分层思维。一个完整的信创云平台从下往上至少分五层基础设施层是国产 CPU鲲鹏、飞腾、海光、龙芯、兆芯和国产服务器虚拟化层是云平台的核心常见的选择包括基于 OpenStack 的定制发行版、华为 FusionSphere、或者更轻量的 ZStack 信创版操作系统层是麒麟Kylin、统信 UOS 这类国产 Linux 发行版中间件与数据库层是东方通 TongWeb、金蝶天燕 APUSIC、达梦 DM8、人大金仓 KingbaseES、OceanBase开源兼容 MySQL 协议最上层则是业务应用与开发平台。每一层都存在选型问题而且各层之间不是简单拼装——你必须提前确认硬件兼容矩阵。比如鲲鹏 920 是 ARM 架构OpenStack 的 Nova 调度需要提前做好 CPU 型号过滤规则否则虚拟机可能漂移到异构节点海光 CPU 虽然兼容 x86 指令集但当你在上面跑 KVM 虚拟化时某些内核参数和 CentOS 时代不一样io 调度器默认值可能让数据库性能直接打个七折。我一般建议在写方案之前先拉一张兼容性清单维度包括 CPU 架构、操作系统版本、虚拟化软件、数据库、中间件、监控工具、备份工具。这张表就是云平台建设的“宪法”后面所有部署步骤都要基于它展开。忽略这个步骤的直接后果是——部署中期发现存储驱动不兼容整个环境推倒重来。2.2 计算虚拟化选型KVM 路线为什么是当前最稳的底座信创云平台的计算虚拟化当前最主流、也最稳妥的路线是 KVM。原因并不复杂KVM 是 Linux 内核原生模块国产操作系统麒麟、统信本身就是 Linux天然支持 KVMOpenStack 所有发行版对 KVM 的适配也最完善而且 KVM 的嵌套虚拟化能力对测试云平台本身非常有价值。如果你用的是 OpenStack 加 KVM 的组合安装完虚拟化软件之后必改的参数之一是 Nova 的 cpu_model 配置。在/etc/nova/nova.conf里默认的cpu_mode none会让虚拟机失去 CPU 特性的透传能力部分依赖 AVX 指令集的业务应用会直接启动失败或运行报错。实际环境中我会这样设置[libvirt] cpu_mode host-model cpu_model qemu64 virt_type kvm这段配置的意思是让 libvirt 以宿主机 CPU 型号为基础生成一个适度兼容的 CPU 模型给虚拟机。host-model 在信创环境里比 host-passthrough 安全因为鲲鹏的某些 CPU 特性透传后嵌套虚拟化场景下可能触发内核 panic而qemu64作为兜底模型保证了跨节点迁移时的兼容性——OpenStack 冷迁移时会校验 CPU 模型匹配度设置不一致直接迁移失败。还有 VM 的内存大页配置。数据库类业务在信创云平台上最容易遇到性能瓶颈开启透明大页是不行的需要显式配置大页池。在宿主机/etc/default/grub的内核启动参数里加上default_hugepagesz2M hugepagesz2M hugepages16384同时在 Nova 的 flavor 里设置为内存页面大小为 2MB。这样配置后跑达梦数据库的云主机内存分配效率提升明显实测 TPS 比默认小页模式高出 15% 到 20%。2.3 分布式存储选型Ceph 与信创硬件的适配边界存储选型是信创云平台最容易踩雷的地方。因为信创硬件尤其是鲲鹏 ARM 架构与存储软件之间的兼容问题往往要到你真正压测时才暴露出来。当前最常见的组合是 Ceph 分布式存储加 SSD/NVMe 混闪。Ceph 版本建议选 16.2 及以上因为对 ARM 架构的编译支持和内存管理更友好。安装时要注意Ceph 的 OSD 进程依赖librbd的 RDMA 支持但信创网卡比如华为 Hi1822的驱动在某些老内核版本上根本不识别导致 Ceph 的 public_network 无法正常通信。部署 Ceph 时OSD 的蓝鲸设备管理BlueStore参数建议显式指定否则默认参数在 NVMe 上表现不佳ceph orch apply osd --all-available-devices --device-class nvme ceph config set osd osd_max_backfills 4 ceph config set osd osd_deep_scrub_interval 604800第一行把 NVMe 设备加入 OSD 池第二行把回填并发数限定为 4避免新 OSD 加入集群时瞬时 IO 暴涨第三行把深度清理间隔设为 7 天一次在生产环境减少不必要的性能损耗。这三个参数是信创存储环境最常见的调优入口尤其数据规模过百 TB 之后默认值会直接拖垮业务 IO。块存储协议方面RBD 是 OpenStack 的标准接法Cinder 配置后端时rbd_pool建议独立池子对应不同业务等级。不建议把数据库业务和文件业务混在同一个存储池因为两者的 IO 特征差异太大数据库是延迟敏感型文件业务是吞吐型。混池的唯一结果就是数据库性能抖动。3. 从零搭建信创云平台控制节点与计算节点的落地部署3.1 物理资源规划至少需要几台机器才能建起最小集群先给出一套可复制的参考配置。信创云平台的最小集群至少需要 3 台物理机其中 2 台控制节点高可用、3 台计算节点可以共用但如果你是第一次搭建资源受限时也压到 1 台控制加 2 台计算。这里给出常规配置建议角色CPU内存磁盘数量控制节点鲲鹏 920 (32C)128GB2 x 480GB SSD系统镜像数据库2计算节点鲲鹏 920 (64C)256GB2 x 960GB SSD系统本地缓存3存储节点鲲鹏 920 (32C)128GB8 x 4TB NVMe3控制节点上要跑 MariaDB、RabbitMQ、Keystone、Glance、Nova API、Neutron 服务内存 128GB 只能算及格如果你还要跑 Horizon 面板和计量服务建议直接加到 256GB。计算节点上 OpenStack 的 nova-compute 进程虽然吃内存不多但虚拟机内存是宿主机内存直接切分出去的256GB 起步是最低底线。网络规划同样关键。管理网络、存储网络、租户网络必须三网分离。在信创环境里存储网络建议使用独立的物理网卡至少万兆或以上否则 Ceph 的副本同步流量会把管理网打爆表现为控制节点 API 响应超时、虚拟机创建卡在 scheduling 状态。3.2 控制节点部署OpenStack 服务安装与配置的最小步骤这里给出一个简化的控制节点部署路径使用 Kolla-Ansible 方式因为它是当前信创环境中最不容易翻车的 OpenStack 容器化部署方案。# 1. 安装基础依赖 yum install -y python3-pip python3-devel gcc git ansible pip3 install kolla-ansible # 2. 生成配置文件 kolla-genpwd cp -r /usr/share/kolla-ansible/etc/kolla /etc/kolla/ # 3. 修改全局配置 vim /etc/kolla/globals.yml # 关键配置 # kolla_base_distro: centos # openstack_release: zed # network_interface: eth0 # neutron_external_interface: eth1 # enable_cinder: yes # enable_cinder_backend_lvm: no # enable_ceph: yes # enable_haproxy: yes # enable_mariadb: yes配置完成后的逻辑说明network_interface指定的是 OpenStack 管理网络的物理网卡neutron_external_interface指定的是外部网络接口用于创建浮动 IPenable_ceph比 LVM 存储更适合信创环境因为 Ceph 天然支持副本和扩展而 LVM 在国产化存储驱动上问题不断。enable_haproxy必须打开否则控制节点高可用就是空话——VIP 由 HAProxy 加 Keepalived 承担。然后执行部署# 4. 安装部署 kolla-ansible -i /etc/kolla/multinode bootstrap-servers kolla-ansible -i /etc/kolla/multinode prechecks kolla-ansible -i /etc/kolla/multinode deploy # 5. 生成 openrc 文件 kolla-ansible post-deployprechecks这一步一定要仔细看输出。它检查所有节点的连通性、磁盘空间、Docker 可用性。我遇到过的情况是计算节点磁盘满了prechecks 直接中断但日志不够醒目排查了很久才发现是/var/lib/docker目录空间不足。在信创环境下尤其注意/boot分区空间麒麟系统默认给的 /boot 只有 512MB多装几个内核版本就会把这个分区塞满。3.3 计算节点加入集群网络代理与虚拟化配置的配合计算节点加入集群的常见方式是修改multinode文件后重新执行 kolla-ansible 的 deploy 命令把计算节点角色加进去。但更精细的做法是手动配置 nova-compute 和 neutron-agent。# /etc/nova/nova.conf [DEFAULT] transport_url rabbit://openstack:密码控制节点IP:5672 my_ip 计算节点IP use_neutron True firewall_driver nova.virt.firewall.NoopFirewallDriver [libvirt] virt_type kvm cpu_mode host-model# /etc/neutron/neutron.conf [DEFAULT] core_plugin ml2 service_plugins router allow_overlapping_ips True这两段配置中transport_url必须与控制节点的 RabbitMQ 用户保持一致firewall_driver设为 Noop 的原因是安全组规则交给 Neutron 的 openvswitch 处理Nova 不再干预cpu_mode host-model已在前文解释过。Neutron 侧的core_plugin和service_plugins是标准配置但要注意如果计算节点使用的是 ARM 架构openvswitch 模块需要单独编译 OVS 的 DPDK 支持时会失败——建议直接用内核自带 openvswitch 模块性能差距在多数业务场景可以接受。4. 信创云平台上的业务迁移从传统架构迁到信创环境的四种路径4.1 迁移评估先行如何判断一套业务适不适合直接迁迁移评估是信创云平台建设方案里最容易走过场、也最影响成败的环节。很多团队在风险评估表上勾选“兼容”之后实际上根本没跑过验证结果到上线时才发现中间件不兼容 ARM 指令集——这种事在国产化项目里非常多见。我的判断标准分为三层第一层是操作系统兼容性业务是否依赖特定的 Linux 发行版或内核版本第二层是中间件与数据库兼容性Java 应用是否跑在东方通、Tomcat 是否换成了 TongWeb、Oracle 是否要迁到达梦或金仓第三层是硬件指令集兼容性最常见的坑是 C 语言的动态库中有 x86 优化的汇编代码在 ARM 上直接段错误。评估之后迁移路径就好选了。常见做法是四类一、全新部署代码不变操作系统和中间件换成信创版本这是最理想的情况二、数据迁移加应用迁移适用于数据库需要从 Oracle 迁到达梦的情况三、双轨并行平滑割接一套老环境一套信创环境数据实时同步最后切换流量四、重构与适配适用于老系统深度绑定 x86 指令集或专有中间件的情况这需要业务侧配合改代码。4.2 数据库迁移Oracle 到达梦的 DTS 工具实操与常见失败点政务和金融行业最常见的场景是把 Oracle 迁到达梦 DM8。达梦自带 DTS数据迁移工具图形界面操作比较多但在命令行环境里用 dminit 配合 dmfldr 批量导入反而更适合自动化运维。# 1. 初始化数据库实例 dminit PATH/dm/data DB_NAMEDMDB INSTANCE_NAMEDMSERVER PORT_NUM5236 # 2. 启动数据库服务 dmserver /dm/data/DMDB/dm.ini # 3. 使用 disql 创建用户和表空间 disql SYSDBA/SYSDBA CREATE TABLESPACE app_ts DATAFILE /dm/data/DMDB/app_ts.dbf SIZE 2048; CREATE USER app IDENTIFIED BY app_password DEFAULT TABLESPACE app_ts; GRANT DBA TO app;DTS 迁移执行时最常翻车的点有三个一是 Oracle 的 NUMBER 类型到达梦后默认映射成 NUMERIC如果源表里有 NUMBER(38) 的超大精度字段达梦会报精度超出限制解决办法是在 DTS 的对象映射中单独指定目标字段类型二是 Oracle 的 VARCHAR2 按字节计算长度达梦默认按字符计算中文字段从 VARCHAR2(20) 迁过来之后变成 VARCHAR(20) 字符容量无形中翻了三倍——索引大小超出预期性能下降明显三是空表不迁移DTS 默认跳过空表但业务表里有些就是结构空表比如配置表、临时表必须手动勾选“包含空表”。4.3 中间件替换Java 应用从 Tomcat 到东方通 TongWeb 的适配要点Java 应用的信创改造通常集中在三处Servlet 容器、JDK 版本、以及国密算法支持。Tomcat 换到东方通 TongWeb 后大多数应用不需要改代码因为 TongWeb 实现了 Web 容器规范Servlet API 兼容性没有问题。但有几个细节必须注意。第一TongWeb 的默认线程池参数偏保守依据官方建议在conf/server.xml里可以把 maxThreads 从默认 200 调高到 500但不要超过参与 HT 的 CPU 核心数的两倍第二TongWeb 对 session 序列化要求更严格如果你的应用里有自定义对象存入 session必须实现 Serializable 接口否则在开启 session 持久化时直接抛 NotSerializableException第三国密算法的引入在 JDK 层面要安装 BouncyCastle 的国密 Provider在 TongWeb 的bin/setenv.sh中加载-Djava.security.properties/path/to/java.security并在文件里追加security.provider.Norg.bouncycastle.jce.provider.BouncyCastleProvider。中间件替换的最佳实践是“双跑验证”先在测试环境把老容器和新容器同时跑同一套代码对比 session 处理和 JNDI 数据源连接确认无差异后再切生产。信创项目里不能信“API 兼容”这几个字必须实测。5. 信创云平台安全加固与性能调优从等保合规到压测报告5.1 等保三级视角下的必备加固项SSH 策略、账号管理与日志审计信创云平台上线前安全等保评测几乎是必过的一关。从实操角度我会优先把以下四项做扎实——因为它们既是等保检查项也是日常运维最容易暴露问题的点。第一SSH 安全加固。修改/etc/ssh/sshd_config中的PermitRootLogin为noPasswordAuthentication改为no只保留密钥登录同时把 SSH 端口从默认 22 改掉减少扫描攻击面。第二账号与权限分离。给不同角色创建独立账号使用sudo粒度授权而不是共享 root所有管理操作必须通过auditd记录。第三日志远程存储。将系统日志和操作日志实时转存到独立的日志服务器防止攻击者删除本地日志灭迹——等保测评员会检查日志留存时间是否超过 6 个月本地磁盘留 6 个月不现实远程集中存储是过审的关键。第四身份鉴别机制。双因子认证不是硬性要求但测评时加分运维端可以部署基于 TOTP 的认证方式比如 Google Authenticator 的 PAM 模块。5.2 性能压测方法论用 sysbench 和 fio 验证信创硬件没被“白换”信创硬件性能到底能不能打必须用压测数据说话。我常用的组合是 sysbench 压 CPU 和数据库fio 压磁盘iperf 压网络。# CPU 性能测试16 线程单线程跑素数计算 sysbench cpu --threads16 --time60 --cpu-max-prime20000 run # 内存压测 sysbench memory --threads16 --memory-block-size1M --memory-total-size10G run # 磁盘顺序写/读测试与理论值对比 fio --nameseqwrite --filename/dev/nvme0n1 --rwwrite --bs64k --size20G --numjobs4 --ioenginelibaio --iodepth16 # 数据库场景随机读写混合 fio --namerandrw --filename/dev/nvme0n1 --rwrandrw --rwmixread70 --bs16k --size20G --numjobs4 --ioenginelibaio --iodepth16sysbench 跑多轮取平均值才有参考意义至少要跑三遍剔除最高和最低。fio 测试时要注意比较基准是“达到该硬件的标称性能的 80% 就算合格”不用追求极限。因为信创云平台上的虚拟机性能损失本来就存在——每多一层虚拟化就多一层开销全虚拟化环境下 NVMe 随机读能跑到裸机 70% 到 80%已经是比较理想的数据。网络压测用 iperf3 验证存储网络与租户网络互通性# 服务端 iperf3 -s -p 5001 # 客户端 iperf3 -c 存储节点IP -p 5001 -t 60目标值是在万兆网络下至少跑到 7Gbps 以上才算正常。如果低于这个数优先排查网卡驱动、多队列配置和中断绑核irqbalance 是否生效。信创网卡的驱动往往不是内核自带最优版本要用厂商提供的新驱动重新编译安装。5.3 信创云平台常见问题排查5 个高频坑与处理记录仅凭一次搭建经历远远不够信创环境的坑往往在长期运维中逐渐暴露。下面整理 5 个我实际遇到过的、能直接参考的高频问题。现象 1虚拟机创建后一直处于 BUILD 状态最终报 error。原因是 Glance 镜像上传时格式不完整或计算节点无法访问镜像存储。解决方案检查 Glance 服务日志/var/log/glance/api.log和计算节点 nova-compute 日志。最常见的原因是 Glance 配置的后端存储类型与实际不一致——比如你配置了 Ceph RBD但 Ceph 的 keyring 权限不足导致计算节点拉取镜像失败。解决方法是验证 Ceph 的 auth 配置确保 nova 用户对镜像池有读权限同时用 qemu-img 手动验证镜像文件完整性。现象 2虚拟机网络不通但状态正常。原因多半是 Neutron 的 DHCP agent 或 L3 agent 挂了。执行openstack network agent list查看 agent 状态如果显示 dead重启对应容器如果是在 Kolla 环境执行docker restart neutron_dhcp_agent。还有一种不太明显的可能计算节点的时间与控制器节点偏差过大导致 OVS 流表同步失败。信创环境的解决方法是配置 NTP 同步确保整个集群时间偏差不超过 1 秒。现象 3Ceph 集群数据分布不均个别 OSD 磁盘使用率远高于其他。这是权重配置或新增 OSD 后未做再平衡导致的。用ceph osd reweight-by-utilization调整或手动降低高利用率 OSD 的权重但如果集群数据量太大应该先在低峰期执行ceph osd rebalance。建议不要随意修改 weight容易引发数据迁移风暴导致集群性能雪崩。现象 4业务应用在信创环境启动极慢比之前的 x86 环境慢好几倍。排查后发现是 JDK 版本问题。老应用自带 JDK 8在 ARM 架构上 JIT 编译效率本来就偏低而且没有开启-XX:UseAarch64Intrinsics。解决方法是升级到支持 ARM 性能优化的 JDK 版本如毕昇 JDK并显式开启这个 JIT 优化开关启动速度恢复接近原环境水平。现象 5桌面云或远程桌面场景下3D 渲染性能极差。信创环境里的云桌面产品如深信服 aDesk 信创版在 GPU 直通支持上不如 KVM 加 vGPU 的方案完善。最直接的解决路径是开启 vGPU 或直通 GPU 显卡如果硬件不支持就只能接受软件渲染。信创实时云渲染在现在仍是一个正在快速演进的领域选型时要确认 GPU 厂商是否提供国产 OS 驱动否则买了卡也白搭。5.4 让云平台更可用的小型自动化健康检查脚本与告警阈值云平台建设完成后运维不能靠人肉盯屏。建议写一个轻量健康检查脚本每 30 秒轮询一次将状态输出到日志文件并接入告警#!/bin/bash # 检查控制节点 API 可用性 API_STATUS$(curl -s -o /dev/null -w %{http_code} http://127.0.0.1:5000/v3) if [ $API_STATUS ! 200 ]; then echo $(date) Keystone API 异常状态码: $API_STATUS /var/log/cloud_check.log fi # 检查计算节点负载 LOAD$(cat /proc/loadavg | awk {print $1}) if [ $(echo $LOAD 16 | bc) -eq 1 ]; then echo $(date) 计算节点负载过高: $LOAD /var/log/cloud_check.log fi # 检查 Ceph 健康状态 CEPH_STAT$(ceph health 2/dev/null | awk {print $1}) if [ $CEPH_STAT ! HEALTH_OK ]; then echo $(date) Ceph 不健康: $(ceph health) /var/log/cloud_check.log fi这段脚本逻辑直白三个关键检查点覆盖了云平台最核心的三块。实际生产环境我还会增加磁盘使用率检查和关键服务进程数检查。阈值要按环境调整负载阈值 16 适用于 64 核计算节点32 核节点改成 8 更合理。6. 从方案到落地编制一份可执行的信创云平台项目建设方案6.1 建设方案的章节结构决策层和落地层各看什么当你真正动笔写或者评审“信创云平台建设方案.docx”时要清楚读者有两种决策层看的是投资规模、建设周期、业务风险技术层看的是资源规划、部署步骤、回退方案。文档结构上我会使用六大章节现状分析与需求调研、总体架构设计、分阶段建设计划、迁移与验证方案、安全与运维体系、风险应对与应急预案。每一章都不能写成虚的。比如总体架构设计必须给出服务器数量表、网络拓扑图三级互联管理、存储、租户、软件选型清单含版本号分阶段建设计划要精确到周明确每个阶段的验收标准迁移与验证方案要列出业务清单和迁移顺序先迁非核心再迁核心每一步都要有回退计划。一份好的建设方案真正的价值不在华丽架构图。评审通过的关键在于资源估算有依据CPU、内存、磁盘按业务类型算出来不是拍脑袋迁移清单覆盖所有业务系统不能漏掉边缘系统安全等保的整改项列出明确负责人和时间点预算和周期在一页纸就能讲清楚方便向上汇报。6.2 信创云平台建设的最短可行路径两周小规模试点如果你在组织中的角色是推动者而不是决策者可以用“两周小规模试点”来破局。这个策略的目的是控制风险拿到真实数据向决策层证明可行性。第一周做基础环境搭建准备 3 台信创物理机部署三节点 OpenStack Ceph 最小集群第二周做业务验证选一个非核心业务系统最好是 Java 技术的完成迁移、压测、数据对比输出一份《迁移试运行报告》附上性能对比数据和问题清单。这份报告最重要要让决策层看到真实数据和风险项而不是拍胸脯保证。如果试点顺利再扩成完整方案如果不顺利也拿到了一手踩坑数据后续建设方案会更靠谱。信创云平台的核心逻辑是“小步快跑快速验证”不要一开始就搞 50 节点大集群——翻车成本太高而且你会被卡在硬件交付环节动弹不得。6.3 我踩过最痛的一个坑最后分享一个真实教训早期我负责的一个信创项目在选型评审时没有认真核实存储网络交换机的国产化兼容性结果到货后发现交换机的光模块与信创服务器的万兆网卡不兼容协商速率失败存储网络始终只有千兆速率Ceph 性能完全跑不起来。这个坑从发现到解决花了整整三周——换光模块、换驱动、甚至换了两台交换机才搞定。从那以后我在每份建设方案的“设备兼容性验证”章节都加一条强制要求所有硬件到货后第一周先做交叉连通性测试和链路协商测试包括光纤模块型号、网卡驱动版本、交换机固件版本三者的交叉验证。信创项目里的硬件兼容矩阵千万别只依赖厂商的纸面认证必须实测。这套方法论也适用于你下载的任何一份信创云平台建设方案先看它有没有覆盖兼容性验证再看有没有回退方案最后看性能压测是不是有具体数值。三点都有才是可以照着做的方案。希望这篇拆解对你自己的信创云平台建设有所帮助。本文还有配套的精品资源点击获取