<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Aliyun-Fullstack on Chen Kai Blog</title><link>https://www.chenk.top/zh/series/aliyun-fullstack/</link><description>Recent content in Aliyun-Fullstack on Chen Kai Blog</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Sat, 09 May 2026 09:00:00 +0000</lastBuildDate><atom:link href="https://www.chenk.top/zh/series/aliyun-fullstack/index.xml" rel="self" type="application/rss+xml"/><item><title>阿里云全栈实战（十二）：Terraform 全栈统一交付</title><link>https://www.chenk.top/zh/aliyun-fullstack/12-terraform-e2e/</link><pubDate>Sat, 09 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/12-terraform-e2e/</guid><description>&lt;p>十一篇文章。几十条 CLI 命令。上百个手动步骤。现在我们把它们全部扔掉，只用一条 &lt;code>terraform apply&lt;/code> 重建整个栈。这正是基础设施即代码（IaC）的核心价值。&lt;/p>
&lt;p>在这个系列的过去十一部分里，我们点击过控制台，敲过 &lt;code>aliyun&lt;/code> CLI 命令，手动配置了从 VPC 到 Function Compute 触发器的一切。这种方式可行：亲手搭建每个资源，熟悉所有细节。但在新地域重建整套栈——三层双可用区 VPC、带 cloud-init 的 ECS 实例、RDS MySQL HA、带生命周期规则和 CORS 配置的 OSS bucket、RAM 策略、SLS 日志管道、Function Compute 事件触发器——至少需要一整天的精细操作。难免会遗漏安全组规则、备份策略或 CORS 配置。&lt;/p></description></item><item><title>阿里云全栈实战（十一）：PAI 打造机器学习平台</title><link>https://www.chenk.top/zh/aliyun-fullstack/11-pai-ml-platform/</link><pubDate>Fri, 08 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/11-pai-ml-platform/</guid><description>&lt;p>单卡跑模型很有趣，但要稳定支撑每秒 1000 个请求，才是从实验迈向产品的关键一步。PAI 正好覆盖了这两个阶段。&lt;/p>
&lt;p>PAI（Platform for AI）是阿里云的托管式机器学习平台。严格来说，它并非单一产品，而是五个独立子产品共享同一控制台的集合：Notebook 用于交互式探索，分布式训练服务支撑规模化训练，模型服务平台承载生产部署，可视化流水线面向偏好拖拽操作的用户，模型库则提供开源模型的一键部署能力。经过十八个月的真实 LLM 负载验证，各组件表现不一——EAS 表现优秀，Designer 基本够用；但一旦理清它们之间的协同机制，整体效能远超各部分之和。&lt;/p></description></item><item><title>阿里云全栈实战（十）：DashScope 与大模型层</title><link>https://www.chenk.top/zh/aliyun-fullstack/10-bailian-llm/</link><pubDate>Thu, 07 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/10-bailian-llm/</guid><description>&lt;p>早年在国内开发生产级 LLM 应用时，可选方案极少且成本高昂：国际大厂要么未在中国内地部署服务端点（endpoint），要么计费需绑定境外信用卡；若调用其美国 API，首 token 延迟普遍超过 800ms。后来 Qwen 接入 DashScope 并提供 OpenAI 兼容接口，国内开发 AI 产品的体验因此与海外接轨——SDK 一样，请求结构一样，流式协议也一样，只需改个 &lt;code>base_url&lt;/code>，再从百炼控制台拿个 Key 就行。该方案已在生产环境稳定运行一年以上。本文系统梳理了我初上手时最急需的实战经验。&lt;/p></description></item><item><title>阿里云全栈实战（九）：OpenSearch 与 AI 搜索</title><link>https://www.chenk.top/zh/aliyun-fullstack/09-opensearch/</link><pubDate>Wed, 06 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/09-opensearch/</guid><description>&lt;p>我做的第一个搜索引擎是用 Elasticsearch 搭建的，配了一堆同义词表。花了六个月才达到基本可用水平，随后陷入重复循环：用户反馈搜不到结果，就加同义词；结果引发其他查询误匹配，又得补例外规则，如此反复。相关性调优配置膨胀到 400 行，包括三种语言的自定义 analyzer 和高度复杂的 boosting 逻辑，早已超出可维护边界；重建索引则需耗时四小时。后来在一个侧边项目中尝试了混合向量和关键词搜索，首日效果即超越此前所有调优成果，首次实现用户零投诉的搜索体验。这一实践经历重塑了我对搜索系统设计的理解，催生了本文。&lt;/p></description></item><item><title>阿里云全栈实战（八）：Serverless 与事件驱动</title><link>https://www.chenk.top/zh/aliyun-fullstack/08-serverless/</link><pubDate>Tue, 05 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/08-serverless/</guid><description>&lt;p>第一次看到函数计算的账单——处理 1 万次请求仅需 0.03 元时，我彻底重构了原有架构。此前，为了支撑一个每小时仅约 200 次请求的 API，我常年运行一台 2 核 ECS 实例，每月花费约 490 元；而同样的工作负载迁移到函数计算后，月成本不到 5 元——不是每天 5 元，而是整月不到 5 元。成本差距如此悬殊，以至于那个周末我把所有无需常驻进程的服务都从 ECS 迁移到了函数。&lt;/p></description></item><item><title>阿里云全栈实战（七）：SLS 打造可观测性体系</title><link>https://www.chenk.top/zh/aliyun-fullstack/07-observability/</link><pubDate>Mon, 04 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/07-observability/</guid><description>&lt;p>我职业生涯中最严重的一次生产事故，排查整整花了三个小时。当时一个 Node.js 服务间歇性返回 502 错误，大约 5% 的请求受影响，而我手头几乎没有任何工具：没有集中式日志（每台 ECS 实例都有自己的 &lt;code>/var/log/&lt;/code>，我只能一台台 SSH 登录查看）；没有监控大盘（只能在终端里反复执行 &lt;code>top&lt;/code> 和 &lt;code>df -h&lt;/code>）；也没有链路追踪（只能靠手动添加 &lt;code>console.log&lt;/code> 时间戳，试图定位哪个下游调用卡住了）。三小时后，问题终于浮出水面：一个被遗忘的定时任务占着数据库连接不释放，导致 RDS 连接池在高负载下耗尽。修复只需两行代码，但诊断过程却耗费了整整三小时——只因系统毫无可观测性可言。&lt;/p></description></item><item><title>阿里云全栈实战（六）：RAM、KMS 筑牢云安全</title><link>https://www.chenk.top/zh/aliyun-fullstack/06-ram-security/</link><pubDate>Sun, 03 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/06-ram-security/</guid><description>&lt;p>有一次，我在一个公开的 GitHub 仓库里发现了自己的 DashScope API Key——有人 fork 了我几个月前上传的一个 Demo，而这个 API Key 明文存放在未被 .gitignore 排除的配置文件中。等我发现时，这个 Key 已在一个周末内被用于发起 14,000 次 Qwen API 调用，所幸账单未超支，这得益于 DashScope 按 token 计费的弹性计费机制，但教训极为深刻。我曾以为云安全可以“以后再做”，结果这个“以后”变成了凌晨两点触发的账单告警。&lt;/p></description></item><item><title>阿里云全栈实战（五）：RDS 与 PolarDB 数据基石</title><link>https://www.chenk.top/zh/aliyun-fullstack/05-rds-database/</link><pubDate>Sat, 02 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/05-rds-database/</guid><description>&lt;p>我在 ECS 上自建的 MySQL 只撑了四个月。流量高峰期的一次磁盘 I/O 飙升直接让整个服务宕机：InnoDB buffer pool 和 OS page cache 争抢内存，binary log 写满系统盘的速度远超 cron 任务的清理能力，而那台所谓“备份”实例的单线程复制竟已落后九小时。凌晨三点，我只能靠扩容磁盘勉强救火；结果两周后，同样的故障再次上演。那一刻我才真正明白托管数据库存在的意义——不是因为我不会部署或运维 MySQL，而是我不想在凌晨三点被报警叫醒，只因 MySQL 判定 relay log 损坏，而唯一的修复方式竟是依赖一份一致性无法保证的冷备份来重建副本。&lt;/p></description></item><item><title>阿里云全栈实战（四）：OSS——对象存储最佳实践</title><link>https://www.chenk.top/zh/aliyun-fullstack/04-oss-storage/</link><pubDate>Fri, 01 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/04-oss-storage/</guid><description>&lt;p>以前我把用户上传的文件直接塞进 ECS 磁盘里。头像、PDF 发票、CSV 导出文件——统统丢在一台跑着 Flask 应用的 &lt;code>ecs.g7.large&lt;/code> 实例的 &lt;code>/var/data/uploads/&lt;/code> 目录下。我还写了个 cron 任务，每六小时把整个目录 rsync 到另一台 ECS 上，美其名曰“备份”。直到某个周五凌晨三点，一个批处理任务生成了 40GB 没人下载的报表，系统盘瞬间飙到 100%，实例进入只读状态，应用彻底宕机——而上一次 rsync 还是前一天晚上跑的。我丢了整整六小时的用户上传数据，整个周末都在向客户道歉。正是这次事故让我明白：对象存储不是可有可无的附加项，而是云上架构的基石。你的应用服务器是临时的，但数据必须持久。&lt;/p></description></item><item><title>阿里云全栈实战（三）：VPC、SLB 构建网络基石</title><link>https://www.chenk.top/zh/aliyun-fullstack/03-vpc-networking/</link><pubDate>Thu, 30 Apr 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/03-vpc-networking/</guid><description>&lt;p>我在云上排查过的每一次故障，追根溯源最后都指向了网络。要么是 CIDR 规划没做好，半年后 IP 不够用了；要么是路由缺失，流量在层级间静默丢弃；要么是安全组配置极端——要么对 &lt;code>0.0.0.0/0&lt;/code> 开放了 22 端口（哈喽，黑客朋友），要么锁得太死导致健康检查失败，负载均衡不停剔除健康实例。网络层是所有部署的前提，必须最先规划和落地；但一旦需要调整，补救成本极高——修改 VPC 的 CIDR 段意味着要重建其下的所有资源。&lt;/p></description></item><item><title>阿里云全栈实战（二）：ECS——让计算回归本质</title><link>https://www.chenk.top/zh/aliyun-fullstack/02-ecs-compute/</link><pubDate>Wed, 29 Apr 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/02-ecs-compute/</guid><description>&lt;p>记得我第一次启动 ECS 实例时，配置选得离谱地高：挑了个能找到的最大规格——&lt;code>ecs.r6.8xlarge&lt;/code>，32 vCPU 配 256 GiB 内存，就为了跑一个每分钟大概 20 个请求的 Flask 应用。结果一周内就耗尽了账号额度。紧急学习在线降配操作后，我把实例规格降至 2 vCPU——实际性能未受影响，但成本降低了 94%。选对实例规格，远比盲目堆砌算力更重要；而深入理解计算层，才是掌握任一云平台的关键。&lt;/p></description></item><item><title>阿里云全栈实战（一）：生态全景图——阿里云到底是什么</title><link>https://www.chenk.top/zh/aliyun-fullstack/01-ecosystem-map/</link><pubDate>Tue, 28 Apr 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/zh/aliyun-fullstack/01-ecosystem-map/</guid><description>&lt;p>刚接触阿里云的第一周，我彻底迷失在产品名称的海洋里：ECS、SLB、SLS、RDS、OSS、NAS、PAI、ARMS、ACK、FC、CDN、WAF、RAM、KMS、ROS、CloudMonitor、EventBridge、PolarDB、Lindorm、AnalyticDB、MaxCompute、DataWorks、Flink、DashScope、Bailian、OpenSearch……每个控制台页面都链接到三四个我没听过的产品，文档默认你已经了解一切，英文翻译有时直译、有时意译，偶尔干脆缺失。这正是我当初最需要的指南——不用浪费整个周末点击控制台、硬啃那些只教你怎么开关功能却从不解释产品本质的翻译文档。&lt;/p></description></item></channel></rss>