简介：这份PDF面向云计算入门学习者、企业IT选型与售前咨询人员，系统梳理阿里云公有云的产品版图与业务脉络，可用于建立从市场格局到产品落地的整体认知。内容围绕云计算市场趋势、阿里云发展历程与关键实例展开，并延伸至全系列产品、专有云、物联网及行业解决方案，兼顾安全合规技术实力与生态资源介绍。资源包仅含1个PDF文件，大小约14.11MB，便于集中阅读和按章节检索。已有1741人学习，说明其对了解阿里云产品体系具有一定参考价值。读者可从中获取云市场数据与用户采纳情况、阿里云重要发展节点、计算存储数据库网络CDN中间件等产品分类，以及政务、企业等场景案例和安全合规要点，适合作为方案调研、培训提纲或产品选型的入门材料。

1. 公有云产品全景：200 多个服务其实是分五层挂上去的

拿到一份公有云全系列产品清单，大多数人的第一反应是“条目太多，从哪看起”。按字母顺序往下翻，翻到一半就失去耐心，关掉文档还是不知道自己的业务该从哪一层动手。真正有价值的其实不是那张平铺的服务表，而是它上面那张分层图：最底下是调度、存储和运维的底座，往上一层是弹性计算与网络，再往上是数据库、存储和中间件，最上面才是数据智能、物联网与安全。公有云全系列产品基本都挂在这五层上，先看懂自己落在哪一层，再去查具体条目，效率差好几倍。

这份材料适合三类人：要从自建机房往外迁的运维，可以拿它对着现状画一张能力差异表；做技术选型的架构，关心的是同一种能力有几种实现、边界在哪里；还有出方案和报价的售前，在意哪些能力能打包、哪些必须单独算钱。不太适合只想找某个具体开关位置的人——那得去翻单产品文档，全景图帮不上忙。

2. 计算与网络先定三处：实例规格、VPC 网段、SLB 后端

2.1 规格族先看 vCPU 与内存配比，再看主频和本地盘

弹性计算这一块在产品清单上往往占了十几行：通用型、计算型、内存型、本地盘型、GPU 型、裸金属、轻量应用服务器、高性能计算集群。名字看着杂，拆开看分类逻辑只有两条：vCPU 和内存的配比，以及有没有本地盘或加速卡。行业里最普遍的划分是通用型 1:4、计算型 1:2、内存型 1:8，本地盘型再额外挂上 NVMe，GPU 型按卡数和显存分档。

选之前先算一个比值：业务内存峰值除以 vCPU 峰值。低于 2 走计算型，2 到 4 走通用型，大于 6 走内存型。这个比值不要拍脑袋，从现有机器的监控里取 95 分位，取一周的数据，别取一天——很多业务周末和工作日的形态完全不同，只看工作日会低估内存。

算完配比还不够，得拿压测把机器的实际能力打出来。下面这两段是最小可用的基线脚本，跑完有具体数字，比看规格表上的理论值靠谱：

# CPU 基线：单核整数运算能力，用于横向对比不同规格族 sysbench cpu --cpu-max-prime=20000 --threads=4 --time=60 run # 内存带宽：--memory-total-size 要大于实例内存的 2 倍，否则全命中缓存 sysbench memory --memory-block-size=1M --memory-total-size=10G --num-threads=4 run

--cpu-max-prime控制质数计算上限，值越大单次计算耗时越长，20000 是个比较通用的档位；--threads对齐 vCPU 数，四核就填 4，填多了线程切换会拉低分数；--time固定 60 秒是为了让不同机器之间可比。内存测试的--memory-total-size必须大于实例内存的两倍，否则压出来的是缓存带宽而不是真实内存带宽，这个数值会虚高两三倍，拿去选型会直接选小一档。

磁盘别用 sysbench 的 fileio 模式，用 fio 更贴近生产：

fio -direct=1 -iodepth=32 -rw=randread -ioengine=libaio -bs=4k \ -size=2G -numjobs=4 -runtime=60 -group_reporting -name=randread_4k

-direct=1绕过 page cache，不然测的是内存；-iodepth=32模拟高并发随机读，对应数据库那种访问模式；-bs=4k对齐数据库页大小，如果是大文件顺序读写就改-bs=1M -rw=read；-numjobs=4与 vCPU 对齐。跑完别只看 IOPS，重点看clat的 p99，平均值好看但 p99 抖得厉害的盘，上了生产就是间歇性超时。

有个血泪经验：基准测试必须在同可用区、同镜像、同系统盘类型下跑，跨规格族和跨盘型混着比，结论很可能完全反过来。我见过有人拿 ESSD 盘的测试结果去论证某个计算型规格更强，实际上差的全在盘上，跟 CPU 一点关系没有。

2.2 VPC 与子网：一份能直接抄的网段模板

网络这一层最容易在项目中期返工。开工前把网段规划定死，后面加子网、接专线、连容器都省事。下面这张表是我一般在项目启动会上就会拿出来过一遍的模板，按 10.10.0.0/16 起步，预留足够的扩容空间：

容器子网那一行是重点。一个 /24 只有 251 个可用地址，一个节点上跑 40 个 Pod，20 个节点就把地址吃光了，扩容直接失败。容器场景至少给 /20，也就是四千个地址起步，规划时按两年后的节点数算。

还有两条容易漏：一是 VPC 网段别和自建机房冲突，接专线之前一定要拿到机房的完整网段清单，包括那些“废弃但没删”的老网段；二是子网划分要跟着可用区走，同一个可用区内的实例互相访问走内网，跨可用区虽然也走内网但多一跳，对延迟敏感的服务（比如缓存和数据库）尽量保证同区部署。

2.3 SLB 健康检查与弹性伸缩：参数错一个就整片摘除

负载均衡的配置本身不复杂，翻车基本都翻在健康检查上。参数就四个：检查间隔、响应超时、健康阈值、不健康阈值。这里有个硬约束很多人第一次填就报错——响应超时必须小于检查间隔，超时设 5 秒、间隔设 2 秒，控制台会直接拒绝。常见的稳一点组合是间隔 2 秒、超时 5 秒不行，改成间隔 5 秒、超时 3 秒、健康阈值 3 次、不健康阈值 3 次，也就是最坏情况下 15 秒摘除一台。

健康检查接口本身也有讲究。别把/healthz写成会去查数据库连接和缓存的重量级接口，那样一次数据库抖动就会把所有后端同时判死，整片服务被摘光，这是最典型的雪崩路径。健康检查只查进程存活和端口监听，业务连通性用独立的监控去做。

后端异常时，先在同子网的另一台机器上复现，能快速区分是网络不通还是健康检查路径返回了非 200：

# 从同子网内的另一台实例验证后端端口与健康检查接口 nc -zv 10.10.1.15 8080 curl -s -o /dev/null -w '%{http_code} %{time_total}\n' http://10.10.1.15:8080/healthz

nc -zv只探端口，不通就说明安全组、网络 ACL 或进程没起来，跟应用逻辑无关；通了再看 curl 的返回码和耗时，time_total超过健康检查超时阈值同样会被摘除，所以这个数字要盯着看。我一般会把这条命令写进故障处理手册的第一页，比一上来就翻控制台日志快得多。

弹性伸缩这块，伸缩组本身好配，难的是两件事：镜像里不能写死 IP 和主机名，扩容出来的机器必须能自己注册到配置中心；缩容必须优雅下线，靠生命周期挂钩先摘流量再停实例，直接删实例会把正在处理的请求打断。冷却时间给 300 秒是常见值，太短会反复扩缩，账单和稳定性一起遭殃。

3. 存储与数据库分层：热温冷放错介质，账单能翻三倍

3.1 块存储、对象存储、文件存储的边界

三种存储在清单上各有十几行，很多人第一反应是“都差不多，随便挑一个能存就行”。实际差别很大，放错介质要么性能不够，要么账单爆炸。下面这张对比表基本能覆盖选型时的判断：

数据库和跑着状态服务的机器，只能用块存储，因为需要低延迟的随机读写。图片、视频、备份包、日志归档这类一次写入多次读取的数据走对象存储，成本能差一个数量级。多台机器要共享同一份文件（比如渲染集群、共享配置目录）才用文件存储，别拿它当数据库盘用，元数据锁会教你做人。

温冷分层是最容易被忽略的成本项。热数据放高性能云盘，温数据迁到低频对象存储，冷数据进归档。但归档有个硬性限制：读取之前要先解冻，解冻耗时按小时计，不是秒级。所以归档策略必须配套一个“什么情况下需要回读”的预案，否则真出事的时候干等几个小时。另一个隐性成本是对象存储的请求费：小文件海量读的场景，请求费经常超过存储费本身，做图片或日志处理时务必先把请求量估一遍。

3.2 数据库选型：先定 RPO 和 RTO，再挑引擎

选数据库的顺序经常被搞反——先比功能列表，最后才想起来问“挂了能丢多少数据、多久能恢复”。正确的顺序是先定 RPO（能容忍丢多少数据）和 RTO（能容忍停多久），再倒推架构：

大部分业务系统落在第二档就够，主备跨可用区，自动切换，RTO 控制在分钟级。金融级或者订单强一致场景才需要往上走，成本也会明显上去。

引擎选择上，MySQL 兼容的最普遍，生态和运维人才都多；PostgreSQL 在复杂查询和 GIS 上有优势；分析型负载别硬塞进关系库，走列存或数仓。表设计阶段就该把分区想好，等单表过亿再改就得上在线 DDL 工具了：

-- 按时间做范围分区，避免单表过亿后 DDL 锁表 CREATE TABLE order_detail ( id BIGINT NOT NULL, order_time DATETIME NOT NULL, amount DECIMAL(12,2) DEFAULT 0.00, PRIMARY KEY (id, order_time) ) PARTITION BY RANGE (TO_DAYS(order_time)) ( PARTITION p202401 VALUES LESS THAN (TO_DAYS('2024-02-01')), PARTITION p202402 VALUES LESS THAN (TO_DAYS('2024-03-01')), PARTITION pmax VALUES LESS THAN MAXVALUE );

MySQL 的分区表要求分区键包含在主键里，所以主键写成(id, order_time)这个组合，而不是单独的 id。TO_DAYS把日期转成整数便于范围比较，比直接用字符串快。pmax是兜底分区，必须有，否则超出范围的插入会直接报错；但也不能一直放着不管，要配定期任务把 pmax 拆出去重建，不然所有新数据都堆在一个分区里，分区就白做了。

3.3 缓存与消息队列：削峰的三个参数

缓存这块，最容易出事的是 key 设计没规范。前缀混乱导致没法批量清理，TTL 不设导致内存打满后开始随机淘汰热数据，value 直接序列化整个对象导致每次更新都要全量读写。我一般会先定一份 key 规范再动手：

{ "key_pattern": "biz:module:entity:{id}", "example": "order:detail:item:8823017", "ttl_seconds": 1800, "value_type": "hash", "eviction_policy": "allkeys-lru" }

三段式前缀是为了按业务和模块批量扫描与清理，{id}放在最后便于用通配符定位单条。ttl_seconds必须显式设置，没有 TTL 的 key 是缓存雪崩的第一嫌疑人，而且这类问题往往在流量高峰才暴露。value_type定成 hash 而不是把对象整体序列化成 string，是为了后续改单个字段时不用整存整取，减少网络往返。

消息队列在削峰场景下有三个参数决定成败：消费并发度、单次拉取条数、不可见时间与重试间隔。消费并发度受分区数约束，分区数少于消费者数，多出来的消费者就是白开；单次拉取条数太大，一次处理失败就要重投一大批；不可见时间设短了，业务还没处理完消息就被重新投递，设长了故障恢复慢。

必须接受一个事实：绝大多数消息队列提供的是“至少一次”投递语义，重复消费一定会发生，不是概率问题而是时间问题。所以消费端从第一行代码起就要幂等，用业务唯一键落一张去重表，或者在数据库层用唯一索引兜住。等到线上出现重复扣款再回来补，成本是现在的十倍。

4. 数据智能与物联网接入：先修数仓再连 BI，安全链路最后补

4.1 离线数仓的分层与数据同步

数据这部分在产品清单上条目最多，从数据集成、离线计算、流计算、数据开发、数据质量一路到可视化，看着像一堆独立产品，实际是一条流水线。分层还是经典的 ODS、DWD、DWS、ADS 四层，别图省事把清洗逻辑写在 ADS 里，后面每加一个报表就要复制一遍。

数据同步通常用两种方式：批量同步按天或按小时把业务库的增量拉到 ODS，实时同步走变更日志订阅。批量同步要注意别直接读生产库的全表，走只读实例并且在低峰期跑，否则会把线上拖慢。

DWD 层的清洗是最考验耐心的一步，也是最容易糊弄过去的一步：

-- DWD 层：把 ODS 原始表清洗成明细宽表，保留业务发生时间 INSERT OVERWRITE TABLE dwd_order_detail PARTITION (dt='${bizdate}') SELECT order_id, user_id, CAST(amount AS DECIMAL(12,2)) AS amount, FROM_UNIXTIME(create_ts) AS create_time FROM ods_order_raw WHERE dt = '${bizdate}' AND order_id IS NOT NULL;

${bizdate}是调度系统传入的日期参数，分区写在 INSERT 子句里比写在 SELECT 后面更直观，也便于补数据时直接改参数重跑。清洗阶段至少要干两件事：类型收敛和空主键过滤。金额从字符串转成定点小数，时间戳转成可读时间，主键为空的脏数据直接挡在 DWD 外面。这两步漏掉，到 DWS 层聚合时会出现各种对不上的数，排查起来非常痛苦。

调度配置上，依赖关系比节点本身重要。上游没跑完下游就启动，跑出来的结果空表还不报错，第二天业务方找上门才发现。基线时间也要设，关键报表链路延迟超过阈值要告警，别等到早上开会才看见。

4.2 可视化与 BI：先定指标口径，再连数据源

BI 工具本身接数据源五分钟就能搞定，真正花时间的是指标口径对齐。同一个“日活”，运营按登录算、产品按打开页面算、技术按设备上报算，三个部门三个数，做出来的看板没人信。所以在连数据源之前，先把核心指标的口径定下来，落成一张表：

有了这张表，后面不管是换 BI 工具还是加新看板，口径都不会漂。另外一条纪律：BI 只读 ADS 和 DWS 层，不要直连生产库做实时查询。一个复杂的拖拽查询打到主库上，慢查询能把整站拖垮，这类事故每年都在发生。

4.3 IoT 设备接入与边缘节点

设备接入的核心是三要素：产品标识、设备名、设备密钥，三个组合起来唯一确定一台设备。接入协议以 MQTT 为主，主题按“产品/设备/上行或下行”的层级设计，别把所有设备塞进一个主题，后面做权限隔离和规则路由都没法做。

上报报文建议统一成下面这个结构，字段不多但都能派上用场：

{ "id": "1723456789001", "version": "1.0", "params": { "temp": 23.5, "humidity": 61, "status": 1 }, "ts": 1723456789000 }

id用于请求与响应的匹配，同一设备并发上报时必须保证唯一，否则响应回来不知道对应哪条；version是给协议升级留的口子，第一版就要有，后期加字段不会把老固件搞崩；ts用毫秒时间戳，处理乱序和断网补传时全靠它；params里只放会变化的量，设备型号、安装位置这类静态属性走设备标签，每次上报都带着纯属浪费流量。

边缘节点解决的是两个问题：断网期间的数据不丢，以及本地实时响应。常见的做法是边缘侧先做协议转换和简单规则判断，本地缓存最近若干条数据，网络恢复后按时间戳顺序补传。补传逻辑一定要做幂等，否则重连风暴时云上会收到大量重复数据。

4.4 安全与合规：账号、密钥、边界防护的最小链路

安全产品在这份清单里能列出一长串：访问控制、密钥管理、Web 应用防火墙、抗 DDoS、主机防护、数据库审计、堡垒机、操作审计、证书服务。逐个开当然最省心，但成本和维护量都上去了。实际落地时先串一条最小链路出来，能覆盖八成风险。

第一环是账号。主账号只用来做计费和授权，日常运维全部走子账号或角色，任何人手里不长期持有长期访问密钥。子账号策略要精确到资源：

{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": ["oss:GetObject", "oss:PutObject"], "Resource": "acs:oss:*:*:app-static/upload/*" } ] }

Resource精确到桶和前缀，不要图省事写星号；Action按最小集合给，给了GetObject不等于给了列举权限，需要列举再单独加。生产账号上再叠一条显式拒绝，把删库、改网络这类高危操作挡住，双保险。

第二环是密钥。敏感数据落盘前用信封加密：主密钥放在密钥管理服务里永不导出，每次加密数据时生成一个数据密钥，用主密钥加密后跟密文一起存。这样即使数据库被拖走，没有主密钥也解不开。

第三环是边界。Web 应用防火墙挡应用层攻击，抗 DDoS 挡流量层，安全组管实例层，三层各管一段，别指望一层全包。安全组只放行必要端口，管理端口不要对公网开放，走跳板机。

最后一环是审计。所有 API 调用都记进操作审计，日志集中收到日志服务里，保留半年起步。合规证书那一页要特别留意覆盖范围——同一个云厂商，不同地域、不同产品线拿到的认证可能不一样，看证书名字不如看覆盖清单，这一条比功能参数更容易翻车，而且往往在投标或审计阶段才被发现。

5. 避坑清单：产品文档看三遍仍会翻车的 5 个地方

5.1 计费与资源释放类

现象：按量付费的实例在控制台点了停止，第二天账单照旧。

原因：停止分两种模式。普通停止只关操作系统，vCPU、内存、系统盘、公网 IP 继续计费；只有开启节省停机模式，计算资源（vCPU 和内存）才会释放并停止计费，但磁盘和公网 IP 仍然收费。

解决：确认实例是否支持节省停机模式，长期不用的实例直接转成更低成本的存储形态或做成镜像后释放；公网 IP 单独看，绑定了弹性公网 IP 的实例关机也照样收 IP 保留费，不用就解绑。

现象：月度账单里出现一笔不小的“快照存储费”，但没人记得建过快照。

原因：自动快照策略在创建实例或数据库时可能被默认挂上，保留周期设得很长；镜像本身也占存储，很多人做完自定义镜像就忘了删。

解决：定时排查快照策略和镜像列表，把保留周期压到 7 到 15 天，历史镜像按版本保留最新的两三个，其余清理。这一项在项目结束后的资源回收清单里必须有。

5.2 网络与权限类

现象：安全组已经放行 0.0.0.0/0，外面还是连不上。

原因：安全组只是第一层。子网可能挂了网络 ACL，或者路由表里没有指向网关的条目，公网 IP 没绑定，实例也没有出网的路由。放行安全组只是允许，能不能通还得看路由。

解决：按“安全组、网络 ACL、路由表、公网 IP 绑定”四步顺序查，一步不通就停下。同一子网内起一台机器用nc -zv探端口，能快速定位是网络层还是应用层。

现象：给子账号配了策略，调用接口还是返回 403。

原因：一是策略里的 Resource 写成了通配但 Action 拼错；二是操作的是另一个账号下的资源，跨账号必须走角色扮演而不是直接授权；三是策略生效有延迟，改完立刻验证会误判。

解决：用策略模拟器先验证再上线，改完等几分钟再测。跨账号场景统一用角色加临时凭证，别把长期密钥发给对方。

5.3 存储与数据库类

现象：归档存储里的历史日志要查，读取请求直接报错。

原因：归档类型的对象在读取前必须先解冻，解冻是异步的，标准解冻按小时计。很多人把“归档便宜”当成普通存储用，真要用的时候才发现取不出来。

解决：归档策略必须配套解冻预案，明确哪些数据可能要回读、能等多久。对可能被临时查询的数据用低频而不是归档，差价不大但可用性差很多。

现象：读写分离后，刚写入的数据在只读实例上查不到，页面显示“下单成功但订单列表为空”。

原因：主备复制有延迟，大事务、无主键表的批量更新、DDL 都会把延迟拉大。业务侧没做读写分离的延迟兜底。

解决：写入后立即要读的场景强制走主库，或者用会话粘滞；表必须建主键，批量更新拆成小批次；监控复制延迟指标，超过阈值自动把读流量切回主库。

现象：消息队列消费端日志里出现大量重复处理记录。

原因：至少一次投递语义下，消费确认超时、消费端重启、网络抖动都会触发重投，这是设计预期而不是故障。

解决：消费逻辑按业务唯一键做幂等，落去重表或用数据库唯一索引兜底，把重复消费当成必然事件处理，而不是当成异常去追查。

6. 上线前验收：把选型表变成三张能核对的表

选型做完不等于落地，中间还差一次能拿数据说话的验收。我一般会逼着项目组在上线前把三张表填满，填不满就不签字。

第一张是压测基线表。每个规格族至少跑一轮，记录 vCPU 得分、内存带宽、4K 随机读写的 IOPS 和 p99 延迟，同一份脚本同一套参数，跨规格的结果才有可比性。压测期间在本机挂一个轻量采集脚本，把 CPU、内存、磁盘的瞬时值留下来，事后能对上号：

# 压测期间每 2 秒采一次系统指标，输出到 CSV 便于和压测结果对齐 while true; do ts=$(date +%s) vmstat 1 2 | tail -1 | awk -v t="$ts" '{print t","$13","$14","$15","$16}' sleep 2 done >> /tmp/bench_metrics.csv

vmstat的 1 2 表示每秒采一次共两次，tail -1取第二次的稳定值，前四个数字分别是用户态、系统态、空闲和等待 IO 的 CPU 占比。等待 IO 那列如果一直很高，说明瓶颈在磁盘不在 CPU，这时候加规格是白花钱。

第二张是成本单元核算表。把每个服务按“固定成本、随流量变动成本、存储成本”三栏拆开，算出单次请求或单笔订单的云成本。很多项目上线三个月后才发现对象存储的请求费比存储费还高，这时候改架构已经来不及，只能在应用层加缓存。

第三张是 SLA 对照表。把业务能接受的可用性、延迟、数据丢失容忍度写成一列，再把所选产品的承诺值写成一列，两边对不上就得加高可用方案或者换形态。这张表在出故障的时候特别有用，能快速判断是“在承诺范围内”还是“需要对外解释”。

从那以后我每次做云上选型，都会强制走一遍这三张表，哪怕项目再小。因为翻车从来不是因为功能选错了，而是因为没人把数字摆到桌面上。希望帮到你。

本文还有配套的精品资源，点击获取