简介这份PDF面向云计算入门学习者、企业IT选型与售前咨询人员系统梳理阿里云公有云的产品版图与业务脉络可用于建立从市场格局到产品落地的整体认知。内容围绕云计算市场趋势、阿里云发展历程与关键实例展开并延伸至全系列产品、专有云、物联网及行业解决方案兼顾安全合规技术实力与生态资源介绍。资源包仅含1个PDF文件大小约14.11MB便于集中阅读和按章节检索。已有1741人学习说明其对了解阿里云产品体系具有一定参考价值。读者可从中获取云市场数据与用户采纳情况、阿里云重要发展节点、计算存储数据库网络CDN中间件等产品分类以及政务、企业等场景案例和安全合规要点适合作为方案调研、培训提纲或产品选型的入门材料。1. 公有云产品全景200 多个服务其实是分五层挂上去的拿到一份公有云全系列产品清单大多数人的第一反应是“条目太多从哪看起”。按字母顺序往下翻翻到一半就失去耐心关掉文档还是不知道自己的业务该从哪一层动手。真正有价值的其实不是那张平铺的服务表而是它上面那张分层图最底下是调度、存储和运维的底座往上一层是弹性计算与网络再往上是数据库、存储和中间件最上面才是数据智能、物联网与安全。公有云全系列产品基本都挂在这五层上先看懂自己落在哪一层再去查具体条目效率差好几倍。这份材料适合三类人要从自建机房往外迁的运维可以拿它对着现状画一张能力差异表做技术选型的架构关心的是同一种能力有几种实现、边界在哪里还有出方案和报价的售前在意哪些能力能打包、哪些必须单独算钱。不太适合只想找某个具体开关位置的人——那得去翻单产品文档全景图帮不上忙。2. 计算与网络先定三处实例规格、VPC 网段、SLB 后端2.1 规格族先看 vCPU 与内存配比再看主频和本地盘弹性计算这一块在产品清单上往往占了十几行通用型、计算型、内存型、本地盘型、GPU 型、裸金属、轻量应用服务器、高性能计算集群。名字看着杂拆开看分类逻辑只有两条vCPU 和内存的配比以及有没有本地盘或加速卡。行业里最普遍的划分是通用型 1:4、计算型 1:2、内存型 1:8本地盘型再额外挂上 NVMeGPU 型按卡数和显存分档。选之前先算一个比值业务内存峰值除以 vCPU 峰值。低于 2 走计算型2 到 4 走通用型大于 6 走内存型。这个比值不要拍脑袋从现有机器的监控里取 95 分位取一周的数据别取一天——很多业务周末和工作日的形态完全不同只看工作日会低估内存。算完配比还不够得拿压测把机器的实际能力打出来。下面这两段是最小可用的基线脚本跑完有具体数字比看规格表上的理论值靠谱# CPU 基线单核整数运算能力用于横向对比不同规格族 sysbench cpu --cpu-max-prime20000 --threads4 --time60 run # 内存带宽--memory-total-size 要大于实例内存的 2 倍否则全命中缓存 sysbench memory --memory-block-size1M --memory-total-size10G --num-threads4 run--cpu-max-prime控制质数计算上限值越大单次计算耗时越长20000 是个比较通用的档位--threads对齐 vCPU 数四核就填 4填多了线程切换会拉低分数--time固定 60 秒是为了让不同机器之间可比。内存测试的--memory-total-size必须大于实例内存的两倍否则压出来的是缓存带宽而不是真实内存带宽这个数值会虚高两三倍拿去选型会直接选小一档。磁盘别用 sysbench 的 fileio 模式用 fio 更贴近生产fio -direct1 -iodepth32 -rwrandread -ioenginelibaio -bs4k \ -size2G -numjobs4 -runtime60 -group_reporting -namerandread_4k-direct1绕过 page cache不然测的是内存-iodepth32模拟高并发随机读对应数据库那种访问模式-bs4k对齐数据库页大小如果是大文件顺序读写就改-bs1M -rwread-numjobs4与 vCPU 对齐。跑完别只看 IOPS重点看clat的 p99平均值好看但 p99 抖得厉害的盘上了生产就是间歇性超时。有个血泪经验基准测试必须在同可用区、同镜像、同系统盘类型下跑跨规格族和跨盘型混着比结论很可能完全反过来。我见过有人拿 ESSD 盘的测试结果去论证某个计算型规格更强实际上差的全在盘上跟 CPU 一点关系没有。2.2 VPC 与子网一份能直接抄的网段模板网络这一层最容易在项目中期返工。开工前把网段规划定死后面加子网、接专线、连容器都省事。下面这张表是我一般在项目启动会上就会拿出来过一遍的模板按 10.10.0.0/16 起步预留足够的扩容空间用途网段说明VPC 主网段10.10.0.0/16后续扩容靠加子网不改主网段可用区 A 业务子网10.10.1.0/24应用服务器可用区 B 业务子网10.10.2.0/24与 A 区对称做跨区高可用数据库子网10.10.10.0/24单独网络 ACL只允许业务子网访问容器与 Serverless 子网10.10.20.0/20必须放大见下面的坑跳板机子网10.10.250.0/24只挂弹性公网 IP其余实例不出网容器子网那一行是重点。一个 /24 只有 251 个可用地址一个节点上跑 40 个 Pod20 个节点就把地址吃光了扩容直接失败。容器场景至少给 /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/healthznc -zv只探端口不通就说明安全组、网络 ACL 或进程没起来跟应用逻辑无关通了再看 curl 的返回码和耗时time_total超过健康检查超时阈值同样会被摘除所以这个数字要盯着看。我一般会把这条命令写进故障处理手册的第一页比一上来就翻控制台日志快得多。弹性伸缩这块伸缩组本身好配难的是两件事镜像里不能写死 IP 和主机名扩容出来的机器必须能自己注册到配置中心缩容必须优雅下线靠生命周期挂钩先摘流量再停实例直接删实例会把正在处理的请求打断。冷却时间给 300 秒是常见值太短会反复扩缩账单和稳定性一起遭殃。3. 存储与数据库分层热温冷放错介质账单能翻三倍3.1 块存储、对象存储、文件存储的边界三种存储在清单上各有十几行很多人第一反应是“都差不多随便挑一个能存就行”。实际差别很大放错介质要么性能不够要么账单爆炸。下面这张对比表基本能覆盖选型时的判断维度块存储云盘对象存储文件存储访问协议挂载为块设备HTTP REST APINFS / SMB共享方式单实例为主少数支持共享块全局共享天然多端多实例同时挂载容量上限单盘 TB 级近乎无限PB 级随机小 IO高 IOPS适合数据库不适合按对象整读整写中等元数据操作偏慢计费构成容量加性能等级存储量、请求次数、下行流量容量加协议类型数据库和跑着状态服务的机器只能用块存储因为需要低延迟的随机读写。图片、视频、备份包、日志归档这类一次写入多次读取的数据走对象存储成本能差一个数量级。多台机器要共享同一份文件比如渲染集群、共享配置目录才用文件存储别拿它当数据库盘用元数据锁会教你做人。温冷分层是最容易被忽略的成本项。热数据放高性能云盘温数据迁到低频对象存储冷数据进归档。但归档有个硬性限制读取之前要先解冻解冻耗时按小时计不是秒级。所以归档策略必须配套一个“什么情况下需要回读”的预案否则真出事的时候干等几个小时。另一个隐性成本是对象存储的请求费小文件海量读的场景请求费经常超过存储费本身做图片或日志处理时务必先把请求量估一遍。3.2 数据库选型先定 RPO 和 RTO再挑引擎选数据库的顺序经常被搞反——先比功能列表最后才想起来问“挂了能丢多少数据、多久能恢复”。正确的顺序是先定 RPO能容忍丢多少数据和 RTO能容忍停多久再倒推架构方案RPORTO相对成本单机加定时备份小时级小时级低主备高可用同城双可用区秒级分钟级中多副本强一致接近零分钟级高跨地域容灾秒到分钟分钟到小时很高大部分业务系统落在第二档就够主备跨可用区自动切换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 工具本身接数据源五分钟就能搞定真正花时间的是指标口径对齐。同一个“日活”运营按登录算、产品按打开页面算、技术按设备上报算三个部门三个数做出来的看板没人信。所以在连数据源之前先把核心指标的口径定下来落成一张表指标口径定义取数层订单量支付成功且未全额退款DWS交易额支付金额含运费扣除退款DWS活跃用户按设备标识去重当日有上报DWD转化率下单用户数除以访问用户数ADS有了这张表后面不管是换 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.csvvmstat的 1 2 表示每秒采一次共两次tail -1取第二次的稳定值前四个数字分别是用户态、系统态、空闲和等待 IO 的 CPU 占比。等待 IO 那列如果一直很高说明瓶颈在磁盘不在 CPU这时候加规格是白花钱。第二张是成本单元核算表。把每个服务按“固定成本、随流量变动成本、存储成本”三栏拆开算出单次请求或单笔订单的云成本。很多项目上线三个月后才发现对象存储的请求费比存储费还高这时候改架构已经来不及只能在应用层加缓存。第三张是 SLA 对照表。把业务能接受的可用性、延迟、数据丢失容忍度写成一列再把所选产品的承诺值写成一列两边对不上就得加高可用方案或者换形态。这张表在出故障的时候特别有用能快速判断是“在承诺范围内”还是“需要对外解释”。从那以后我每次做云上选型都会强制走一遍这三张表哪怕项目再小。因为翻车从来不是因为功能选错了而是因为没人把数字摆到桌面上。希望帮到你。本文还有配套的精品资源点击获取