物联网平台别按设备数配机器：连接数、上报频率、规则链放大和留存天数，这四个乘起来才是规格

把设备数量当成配置依据，是物联网平台选型里最普遍的一个错。一万台设备这个数字，其实只决定了一件事——长连接的常驻内存。

真正把机器压垮的东西，藏在这个数字后面：每台设备多久上报一次、一条上报进平台之后要被处理几遍、这些处理结果要留多少天。这三个问题里没有任何一个的答案，能靠"一万台"这三个字推出来。

所以自建物联网平台（本文以 ThingsBoard 这类开源物联网平台为例）的规格，不是设备数的函数，是四个量的乘积：设备连接数 × 上报频率 × 规则链放大倍数 × 留存天数。设备数只决定长连接的常驻内存与句柄，真正扛压力的是每秒数据点数和它的留存时间。

顺序也很要紧，颠倒了就一定算错：先算每秒数据点，再乘留存天数，得到存储量；再看规则链对每条消息的处理次数，得到 CPU 和写次数的放大倍数。很多人的做法是反过来的——先凭设备数挑一台机器，跑起来发现不够，再加。这样加出来的机器，加的往往是错的那一项。

先声明一句：下文讲的是典型部署思路，并非特指某一真实客户。文中不出现任何吞吐量或性能基准数字，所有算式都是结构性算式，量级示例一律标为"假设"，请拿自己的数往里填。

一万台设备这个数字，只回答了头一个问题

有人来问"我们有一万台设备，该配什么机器"，这个问题本身没法回答，因为它只回答了四个问题里的头一个。

"一万台设备"能推出的是：平台要同时维持一万条左右的长连接，每条连接都要在内存里留一份会话状态、鉴权信息和缓冲区。这一股开销是确定的、可估的，而且和上报频率基本无关——设备就算一小时不上报一个点，那条连接照样挂在那里占内存。

推不出来的是另外三件事。其一，这些设备每秒一共产生多少个数据点？一万台设备每台每分钟上报一次，和每台每秒上报一次，中间差着六十倍，而这两种情况在"设备数"这个字段上完全相同。其二，每个数据点进平台之后要被写几次？这一项取决于规则链怎么搭，跟设备数没关系。其三，写进去的东西要留多久？留三十天和留一年，存储账差一个数量级，设备数却一个字没变。

说白了，"一万台"这个数字回答的是"我要同时应付多少个对象"，而不是"我要同时应付多少工作量"。前者决定内存，后者决定 CPU 和磁盘。把这两件事用同一个数字去估，是头一层错。

物联网平台上跑着几股不同的负载：连接、遥测、规则、查询、告警

物联网平台不是单一负载的程序，它身上同时跑着几股性质完全不同的负载。这几股负载吃的东西不一样、由不同的变量决定、到顶的信号也不一样，混在一起估必然出错。

连接那一股吃内存和句柄，跟上报频率无关。遥测写入那一股吃磁盘写 IOPS 和容量，跟每秒数据点数成正比。规则链那一股吃 CPU，跟"消息数 × 每条消息经过的节点数"成正比，同时它还会派生出额外的写。查询和仪表盘那一股吃读 IOPS 和聚合计算，跟查询的时间跨度和并发人数有关，跟写入量关系不大。告警判定那一股吃的是判定次数和告警状态的读写，跟参与判定的遥测条数有关。

这五股负载的一个共同特点是：它们的峰值时间往往不重合。写入是全天候均匀的，查询集中在有人看的时候，告警判定集中在异常发生的时候，连接在早晚的设备上电时段有波峰。既然峰值不重合，就该分开估、分开看，而不是取一个"总负载"去配一台机器。

把这五股负载并排放一张表，各自的资源属性就一目了然：

头一股：长连接。它吃的是内存、句柄和端口，不是 CPU

设备连上来之后，平台要为每个连接保留一份状态：连接本身、会话信息、鉴权凭据、订阅关系、未确认的消息、还有读写缓冲区。这些东西都住在内存里，而且只要设备在线就一直住着。

除了内存，一条连接还要吃掉一个文件描述符和一个 socket。这里有个容易被忽略的点：句柄上限不是"内存够就不成问题"，它是内核层面的一个独立上限；可用端口范围同理，短连接的场景下端口回收速度也会成为约束。所以连接数这一股的账要同时看三样东西——内存、文件句柄上限、端口与回收参数——少看一样就可能在自以为很宽裕的地方翻车。

CPU 在这一股上几乎不出力。心跳报文很小，协议解析的成本可以忽略，一万条连接安静地挂着和一千条连接安静地挂着，CPU 曲线可能看不出差别。这就导致一个很常见的误判：看着监控里 CPU 常年空着，就觉得这台机器"还有很大余量"，于是往上继续加设备，直到某天在内存或句柄上突然顶住。CPU 空不等于机器有余量，这是物联网平台和普通 Web 服务在资源直觉上最大的一个不同。

这一股的算法很直接：连接数 × 单条连接的常驻开销，再加上句柄与端口上的约束检查。具体开销是多少，取决于平台实现、会话持久化的方式和协议类型，本文不给出具体数值——它需要你拿自己的平台版本和实际连接形态去核。

第二股：遥测写入。它是持续写，而且几乎不删

遥测写入这股负载，跟做业务系统的经验是冲突的，所以特别容易被低估。

业务系统里的写是事务性的：有增删改，有缓存挡在前面，热点数据可以合并，一天里也有明显的忙闲。遥测写入不是这样。它是追加式的——每个数据点带一个时间戳写进去，之后基本不改、不删，一直到留存期到了才整批清理。它没有"热点"可以优化，也没有"闲时"可以借力：夜里三点，设备照样在上报。

这意味着写入压力跟"有多少人在用系统"完全无关，只跟"有多少台设备在按什么频率上报"有关。一个没人打开的仪表盘，不会让写入减轻一丝一毫；反过来，一个被二十个人同时打开的仪表盘，写入量也不增加。这是第二条容易错的资源直觉：物联网平台的写入负载曲线是平的，它的高度由设备侧决定，不由人侧决定。

还有一层：遥测写入的删除几乎不发生，所以磁盘上的存量是单调增长的。容量规划在这里不是一个"够不够"的问题，是一个"多久到顶"的问题——到顶的时间点，等于容量除以每天的增量。这个天数如果比你的扩容周期短，那从一开始就该改留存策略，而不是等到告警。

每秒数据点数怎么算：设备数乘上报频率，再除以批量

所有后续估算的源头就是这个数：每秒数据点数。算式结构是这样的——

每秒数据点数 = 在线设备数 × 每台每秒上报次数 × 单条报文携带的键数

举个由你自己填数的示意。假设一千台设备，每台每 10 秒上报一次，每次报文里只有一个键，那么每秒数据点数约为 1000 × 0.1 × 1 = 每秒约 100 个数据点。如果每次报文带 5 个键，就变成每秒约 500 个数据点。注意"键数"这个乘数经常被漏掉：一台温湿度传感器上报温度和湿度，它是两个数据点不是一个；一台电表上报电压电流功率电能，它是四个。设备数没变，账翻了几倍。

再说批量。如果边缘网关把十台设备的数据打成一个报文上送，那么落到平台上的报文数变成十分之一，但数据点数一个没少。这里必须把两条线分开算：报文数决定连接占用与协议解析开销，数据点数决定写入量与存储量。合包能省前者，省不了后者。很多"我们做了合包所以压力小了"的判断，错就错在用报文数的下降去推断写入量的下降。

算完之后还要加余量，理由有三条。设备侧的对时会让大批设备在整分整秒附近同时上报，形成周期性的小尖峰；设备重连后会补传缓存数据，那一批数据往往集中在同一时刻到达；事件触发型上报（阈值越限、状态跳变）本身就是突发的。所以拿标称频率算出来的是均值，容量要按峰值配。峰值系数取多少，取决于你的设备形态和网络环境，本文不给出具体数值。

第三股：规则链。一条上报会被放大成几次写

这是整篇文章最要紧的一段，也是最容易被完全忽略的一段。

一条遥测消息进入平台之后，不是写一次就结束了。它会进入规则链，沿着链路上的节点走一遍。每经过一个"会写东西"的节点，就多产生一次写操作。也就是说：平台实际承受的写次数 = 进入的消息数 × 每条消息触发的写次数。后面这个"每条消息触发的写次数"，就是放大倍数。

这个倍数在设备数里完全看不出来。两个部署，设备数都是一万、上报频率都是每分钟一次、留存天数都一样，但一个的规则链只有两个节点、另一个有八个节点，前者的写次数可能只是后者的几分之一。同样的"一万台设备"，规则链的差别能让磁盘 IOPS 的需求差出好几倍。这就是本文标题里"别按设备数配机器"最直接的理由。

放大倍数的算法不需要任何工具：把规则链画出来，沿着链路数一遍写型节点的个数，就是它。这一步是纸面工作，几张图的事，但它决定的是 CPU 和写 IOPS 这两个最贵的资源。跳过这一步直接去挑机器，等于闭着眼睛填一个数。

放大倍数从哪来：最新值、告警判定、属性更新、队列消息

把放大倍数拆开看，它主要由四类操作贡献。

其一，最新值。为了让仪表盘打开就显示当前状态，平台会把每个键的"最后一次值"单独存一份。这意味着每来一个数据点，除了时序本身那次写，还多一次最新值的写入或更新。这是最基础的一层放大，几乎所有部署都有。

其二，告警判定。每条进入判定的遥测都要先读出阈值和设备配置，判断之后如果命中，还要写告警记录、更新告警状态、可能再触发一次通知。请注意这里既有写也有读——判定用的配置读、告警状态的读写，都算在 IOPS 账里。如果判定是逐条做的（每来一个点判一次），那这一层的开销就和数据点数成正比。

其三，属性更新。设备状态、服务端属性、以及派生字段（比如"最近上报时间""是否在线""累计运行时长"）往往在每次上报时被顺带更新一次。这些更新看起来不起眼，但它们是真正的写操作，一条上报带上三四个派生字段，就多三四次写。

其四，队列消息。规则链里节点之间的消息传递、失败重试、向外部系统的投递，都会在队列里产生入队、出队和确认。队列是平台用来削峰的，但队列本身也要落盘或驻留内存，它同样是资源账的一部分。

把这四类加起来，就能得到一个属于你自己的放大倍数。这个数字一旦算出来，回头看"一万台设备该配什么机器"这个问题，会发现它根本没答到点子上——因为真正的分母不是设备数，是"每秒数据点数 × 放大倍数"。

第四股：留存。存储量等于数据点数乘时间，时间是最贵的那个乘数

存储量这笔账的算式结构是这样的：

存储量 ≈ 每秒数据点数 × 每天的秒数 × 留存天数 × 单个点的存储开销（含索引与副本）

四个乘数里，时间是最贵的那个。道理很简单：把上报频率降一半，存储账乘 0.5；把留存从 30 天改成 180 天，存储账乘 6。两者都是线性的，但天数这个乘数的基数大得多，动一动就是成倍的变化。在物联网平台的容量预算里，最该被反复审视的参数不是设备数，是留存天数。

还有一个常被漏算的部分：索引和副本。时序数据通常要建时间索引和设备维度索引，索引本身占空间；如果做了多副本，副本份数也是一个乘数。只算裸数据体积，算出来的容量一定会偏小，而且偏小的比例不固定——它取决于你建了几个索引、怎么分区、副本几份。

再提醒一个隐藏项：降采样之后的历史聚合表，是额外的一份存储，不是对原始表的替换。也就是说，在原始表清理之前的那段时间里，两份数据同时存在，容量账要按两份算。这一条在做降采样规划的时候最容易忘。

最后把结论摆清楚：留存天数是这四个乘数里唯一一个"纯粹花钱买习惯"的量。设备数由业务决定，上报频率由产品决定，放大倍数由架构决定，只有留存天数经常是"别人都留这么久"或者"先留着吧"定下来的。改它，几乎不需要动任何代码。

降采样与过期策略：这两个开关比加机器便宜

容量不够的时候，多数人的头一个反应是加盘、加机器。但在物联网平台上，通常有两个更便宜的开关可以先动。

降采样。原始点按较短的保留期存着，超过之后只保留聚合值——比如分钟级均值、小时级最大最小值。聚合之后点数大幅下降，存储账按聚合后的点数重算。代价是原始精度没了：你能看出那一小时的峰值，但看不出峰值发生在哪一秒。所以降采样能不能用，取决于业务要不要回溯到秒级，这是业务决策。

过期（TTL）。给时序数据设保留期，到期自动清理。它和降采样通常配合着用：原始层短一些，聚合层长一些，用两个不同的保留期拼出"近期能看细节、远期能看趋势"的效果。

这两个开关和加机器的本质区别在于：它们减少的是存量，加机器抬升的是上限。存量不减，上限永远在追，而且追的速度是每天的增量乘以天数。所以顺序应该是先动开关、再谈扩容，而不是反过来。

有一点要注意：清理不是免费的。删除、归并、整理这些动作本身也是写负载，而且往往比较重。把清理窗口安排在写入高峰上，等于自己给自己制造一次尖峰。清理窗口该放在业务的低写入时段，这一点在规划的时候就要排进去，不要等上线之后发现夜里定时卡。

查询和仪表盘是另一条负载曲线，不能和写入共用一份估算

写入和查询，在物联网平台上是两条形状完全不同的曲线，用同一份估算去罩，必然有一边是浪费的、另一边是不够的。

写入是持续、均匀、可预测的，它跟着设备走。查询是突发、集中、难以预测的，它跟着人走：早上上班打开一眼看板、月底拉一份跨月对比、出了问题去翻历史。这几件事发生的时候，写入量一个字节都没变，但机器可能当场被打爆。

单次查询的代价大致是这几个量的乘积：查询的时间跨度 × 涉及的设备数与键数 × 聚合粒度 × 并发查询人数。其中时间跨度最狠——跨度翻倍，要扫的数据翻倍，中间的临时结果集也跟着涨，代价往往不止翻倍。所以"查最近一小时很流畅"完全不能推出"查最近一年也流畅"。

仪表盘还有个特殊之处：自动刷新会把一次性查询变成常驻查询流。一个设了十秒刷新的看板，等于在平台上挂了一个永不停止的查询；如果上面有五个人同时开着，就是五条。这类开销在容量估算里经常被整块漏掉，因为它不体现在任何"设备"相关的数字上。

所以这两股要分开给资源，至少要在监控上分开看。写入指标正常而用户抱怨卡的时候，别去动写入那一侧的配置，去看查询那一侧：谁在查、查多久的跨度、有没有自动刷新、并发多少。

内存账：写缓存、批量提交、队列堆积各占一份

内存这一项在物联网平台上不是"一个进程占多少"的问题，它至少要分成几份来算。

头一份是连接的常驻开销。前面已经讲过，它等于连接数乘以单条连接的常驻量，跟上报频率无关。

第二份是写缓存与批量缓冲。攒够一批再落盘，是降低写次数、改善写模式的常用手法。但缓存是拿内存换 IOPS：攒得越大，单次写越顺，内存占得越多，机器异常时丢掉的未落盘数据也越多。这是一个明确的取舍，不是白来的好处——把批量开大之前，先想清楚能接受丢多少。

第三份是批量提交过程中的临时对象。序列化、压缩、组装批次的时候会有中间态，这部分内存随着批量大小和并发提交数上升，峰值出现在写入最猛的那一刻，平时的监控曲线上看不出来。

第四份是队列堆积。下游处理慢了，消息就在队列里堆着。这里有个很好用的理解方式：队列长度就是积压的秒数。队列里躺着多少条，大致就等于处理延迟了多少秒。所以队列长度不该只看"会不会溢出"，它同时是延迟的具象化指标。给队列留多少内存，取决于你允许它积压多久。

还有一份容易被忘掉的：查询的临时结果集。一个大跨度的聚合查询会在内存里撑开一块结果区域，多个这样的查询并发，就叠成一份不小的内存压力。这一份归在查询那一股负载头上，但落在同一台机器的内存账里。

磁盘账：IOPS 看写入模式，容量看留存天数，两者要分开算

磁盘这一项最常见的错，是只算了其中一个维度。容量算得很细、IOPS 完全没算，或者反过来，都会翻车。

先看 IOPS 侧。每秒的写次数大致等于：（每秒数据点数 × 放大倍数）÷ 每批的条数。所以批量是 IOPS 的分母——批量开大，写次数下降，但上一节说过，内存占用和丢失风险上升。这不是一个可以单向拉满的旋钮，它是一个交换。

再看写模式。时序数据按时间推进，看起来像顺序写；但上报来自成千上万台设备，不同设备交替到达，落到存储上就变成了按设备维度分散的写。设备越多、上报越分散，写模式越接近随机。这就是为什么"每秒数据点数一样"的两个部署，磁盘表现可以完全不同——点数一样只说明量一样，不代表落盘的形态一样。设备维度如何组织、分区怎么划、批量怎么合，共同决定了这个形态。

容量侧就是留存那一节的公式，这里不再重复。要强调的是两者的独立性：容量和 IOPS 是两件不同的商品。盘还有空间，不代表写还能更快；加盘能把容量撑大，但单块盘的写能力不会因为容量变大而线性提升。用"盘还很空"去推断"写入没问题"，是这类部署里非常典型的一个判断错误。

什么时候必须把数据库分出去

小规模部署把平台和存储放在同一台机器上，是合理的起点，没有错。真正的问题是什么时候该分。

判据不是"数据有多少 G"，而是有没有出现这几种互相抢的迹象。

迹象一，写入和查询抢同一份 IOPS。表现为写入峰值的时候查询超时，或者有人拉大跨度查询的时候写入延迟抬起来。两边的资源是同一块盘，这种互抢靠调参缓解不了，只能分开。

迹象二，内存出现竞争。存储层的缓存、平台进程、消息队列都在同一台机器上分内存。存储层希望缓存越大越好，平台进程也需要自己的堆，两边都想要，结果是某一方被挤压甚至被系统回收。这时候加内存能缓一时，但两边的增长曲线不一样，迟早再撞。

迹象三，维护动作影响在线。备份、整理、过期清理这类动作都是重负载，它们和在线写入在同一台机器上必然冲突。分开之后，这些动作可以安排在自己的机器和自己的时间窗里。

但分出去也有代价：多一跳网络、多一层延迟、多一套要维护的东西。所以这个动作应该在"确实抢上了"之后做，而不是一开始就做。分的时候通常先分时序存储那一层，规则和会话部分可以之后再动。以上均为典型部署思路，并非特指某一真实客户。

边缘侧与中心侧的分工：断线缓存能解决什么、解决不了什么

讲到容量，总会有人问：能不能在网关侧做点什么，让中心少扛一点。可以，但要先分清"削峰"和"减量"。

边缘侧能解决的有这几样。断网期间在网关本地缓存数据，恢复之后补传，中心侧的写入曲线不会被断网切开；多台设备的数据在网关合包上送，减少报文数和连接压力；在网关做一点预处理，过滤掉明显无意义的上报（比如值没变化的重复上报）；断网期间需要本地联动的逻辑放在网关执行，不等中心。

解决不了的是这几样。留存总账不变——数据最终还是要到中心落库，补传上来之后该占的空间一分不少，天数也没变。放大倍数不变——规则链跑在中心侧的规则引擎上，网关合包只降低了报文数，既没减少数据点数，也没减少每条消息在规则链里被处理的次数。历史查询不变——查询要的是跨设备的完整历史，网关只有自己这一小段的本地片段，顶不了这件事。

所以结论是：边缘侧的主要价值是削峰和平滑，不是减量。它把尖峰摊平、把断网那段时间的曲线补完整，让中心不用按最坏情况去预留，但它不改变总量。如果指望靠网关把中心的容量账降下来，会失望。

只有一个例外情况确实能减量：网关侧做了真正的聚合，比如只在本地算五分钟均值再上送。这时候数据点数确实下降，中心侧的写入、放大、存储三笔账一起下降。代价是丢掉了原始精度，而这属于业务决策不是技术决策——先问业务要不要回溯到秒级，再决定能不能这么干。

上物联网平台之前，容量这笔账最常被问的七个问题

设备数涨十倍，机器要不要跟着涨十倍？不一定，而且四股负载的答案各不相同。连接那一股近似线性，涨十倍大致就是十倍的常驻内存与句柄，这一股躲不掉。写入那一股看的是每秒数据点数，如果新增设备上报频率低、或者走了网关合包，写入涨不到十倍。留存那一股是存量账：数据点数涨十倍、天数不变，存储大致涨十倍，但它是容量扩张不是性能扩张，加盘就能解决。真正可能涨得比十倍还多的是规则链那一股——消息数涨十倍，CPU 大致也涨十倍，如果链上有脚本节点，涨得更多。所以"涨十倍"这个问法本身就问错了，要分股问。

上报频率能不能先按低的算，后面不够再调？不建议这么赌。三个理由：频率是产品决策，后期因为业务需要调高是很常见的动作，而机器已经按低频率配好了；设备侧的对时和批量重连会造成短时间的同步上报，峰值天然高于标称频率；最关键的是，频率降下来省下的那部分数据，是补不回来的——当时没采就是没了。合理的做法是：按标称频率算基准，再乘一个峰值系数留余量，同时在平台侧准备好限流、批量、降采样这几个后手。算不准的地方，宁可在留存天数和降采样上留弹性，也不要在频率上赌。

历史数据到底该留多久？没有通用答案，它取决于三类用途各自要求多少天：运维排障需要回溯多久的原始精度数据、业务报表需要多久的聚合值、以及合规或审计要求保留多久。把这三个天数取最大者，再回头检查一件事——能不能用"原始数据留短期、聚合数据留长期"的组合，替代"原始数据留长期"。多数情况下这个组合能把容量账压下来一大截，而业务上几乎无感。至于落到具体机器上要多大盘、什么价位，以官网实时展示为准，需实时询价。

规则链写得复杂，会不会拖垮写入？会，而且这是这类平台特有的风险。规则链的处理发生在写入路径上，节点越多、脚本越重，单条消息从进来到落库的时间越长，队列越容易堆积，堆积又会反过来占内存。判断方法很简单：数一遍链路上的写型节点，估算单条消息触发几次写；然后把脚本节点单独拎出来看，脚本是那个超线性的部分。缓解的顺序也有讲究：先精简节点、再做批量合并、最后才考虑加机器。跳过前两步直接加机器，等于用钱买一个本来可以免费解决的问题。

数据库要不要单独放一台？小规模不用。写入和查询都轻、监控上也没有互相抢的迹象时，同机部署省掉网络跳数和一整套运维复杂度，是正确的选择。出现三种信号就要分：写入峰值时查询开始超时、内存出现竞争、备份与清理影响了在线写入。分的时候通常先分时序存储这一层，会话与规则部分可以之后再动。另外提醒一句，分开之后要盯的东西多了一个——跨机网络的延迟和稳定性，它本身也会成为新的瓶颈。

设备大面积断网又重连，会不会冲垮平台？会，这是物联网场景里非常典型的一次性冲击。大批设备在同一时刻重连，连接建立、鉴权、会话恢复这几件事同时发生，紧接着断网期间缓存在设备侧的数据集中补传，形成一股远高于日常的上报量。应对手段有几种：在设备侧做重连退避，让每台设备的重试时间随机错开，别整齐划一地去挤；限制补传速率，把补传拉长成一段时间而不是一次灌完；会话恢复走轻量路径。监控上也要注意，这时候该看的指标不是"当前连接数"，而是"连接建立速率"——前者看起来正常，后者已经爆了。还有一点：补传的数据往往带着旧时间戳，写入的是历史时间点，这会让写落到不同的时间分区上，也会额外消耗 IOPS，要算进账里。

什么规模该考虑分片或者上集群？判据不是设备数，是那几条曲线里有没有一条顶到了单机能承受的上限：连接数顶到内存或句柄、每秒写次数顶到磁盘 IOPS、规则链处理顶到 CPU。只要有一条到顶，并且降采样、批量合并、过期清理这几个便宜的开关已经用尽，就该考虑横向拆分了。拆分的切法通常优先按设备维度，因为遥测查询几乎都带设备条件，按设备分片能让查询落在一个分片上而不是广播到全部。至于具体的分片数和节点数，取决于你前面算出来的那几个量，没有通用档位可抄。

本文关于物联网平台负载结构的公开依据在哪里

本文关于设备连接、遥测时序、属性、告警与规则引擎结构的说明，公开依据是 ThingsBoard 官方文档 https://thingsboard.io/docs/ 及其开源仓库 https://github.com/thingsboard/thingsboard ，涉及的概念名称按文档中的公开表述使用。文中所有算式均为结构性算式，量级示例统一标注为"假设"，供读者填入自己的数值使用；本文不涉及任何吞吐量或性能基准数字，也未做过任何性能对比。

一万网络深耕 IDC 19 年（成立于 2007 年），在物联网平台落地这件事上承担的是机器规格参考的角色——把上面这四个乘数算出来之后，再去看对应的 CPU、内存、磁盘与出网该怎么配。具体的配置档位与价格以官网 https://www.idc10000.net/ 实时展示为准，需实时询价。