补充一个在 Debian 12 上可直接照抄的做法（nftables + 固定容器 IP），重点是把“转发链路”一次配全： 1. 固定容器 IP。在 /var/lib/lxc/web/config 里加：   lxc.net.0.ipv4.address = 10.0.3.100/24   lxc.net.0.ipv4.gateway = 10.0.3.1   避免容器重启后 IP 变化导致 DNAT 失效。 2. 宿主机开启转发。/etc/sysctl.d/99-lxc.conf 写入 net.ipv4.ip_forward=1，执行 sysctl --system 生效。 3. 配 nftables（/etc/nftables.conf）：   table ip nat {     chain prerouting {       type nat hook prerouting priority dstnat;       iifname "eth0" tcp dport 8080 dnat to 10.0.3.100:80     }   }   table ip filter {     chain forward {       type filter hook forward priority 0;       ct state established,related accept       iifname "lxcbr0" oifname "eth0" accept       iifname "eth0" oifname "lxcbr0" ct state new accept     }   }   然后 systemctl enable --now nftables，保证重启后规则还在。 4. 华为云安全组放行 8080/TCP，只开业务端口，不要图省事全开。 5. 验证顺序：ss -lntp | grep 8080 看宿主机监听；curl -I http://127.0.0.1:8080 看本机转发；再从外部 curl http://EIP:8080 验证公网链路。 常见坑：只写了 DNAT 没放行 forward；安全组没开端口；容器里的服务只监听 127.0.0.1（要改成 0.0.0.0）；容器重启后 IP 变了。

补充一个可落地的五步法，把“规格”拆成 CPU、内存、磁盘、带宽四个维度分别定量： 1. 先定规格族，不要只比核数。Web/中间件常用 1:2~1:4 的通用型；编译、转码、游戏服偏 CPU，选 1:2 计算型；Redis、ES 等选 1:8 内存型；日志、大数据除了核数还要看 EVS 的 IOPS/吞吐。规格族选错，同价位性能可能差一大截。 2. 用真实数据定档。先按需开 2 核 4G 跑 7 天，用云监控 CES 看 CPU 的 95 分位（不要只看均值）、内存使用率、磁盘 IOPS/吞吐和出网带宽峰值。CPU 95 分位长期低于 40% 就降一档，高于 70% 再升一档，留 20%~30% 余量即可。 3. 能横向扩展就不要一味纵向升配。无状态服务用 2 台 2 核 4G + ELB，通常比 1 台 4 核 8G 更稳，还能配合弹性伸缩扛高峰；规格价格是非线性的，翻倍规格往往不止翻倍价格。 4. 计费方式组合使用。稳定基线用包年包月，波峰用按需 + 弹性伸缩；开发测试环境设置定时开关机。注意按需 ECS 关机后不再收计算费，但云硬盘和 EIP 仍会继续计费。 5. 定期做资源治理。每季度结合 CES 的闲置分析合并低负载实例，及时释放闲置 EIP、快照和旧镜像。长期看，治理浪费往往比选型时抠参数省得更多。 一句话：先按负载画像选对规格族，再用 95 分位监控数据定档，能横向不纵向，最后用计费组合和定期治理收尾。

嵌入式系统抓住三个本质特征即可： 1. 专用性：面向特定功能或被控对象设计，不是通用计算机；软件通常固化在 Flash 里，开机直接进入业务循环，用户不会去安装软件。2. 资源受限：CPU 主频、内存、存储、功耗、成本都有硬约束，软硬件需要一起裁剪，很多芯片甚至没有 MMU。3. 实时性与可靠性：大量场景要求在确定时间内响应（硬实时/软实时），并支持长期无人值守、掉电恢复、看门狗复位。 典型组成：MCU/SoC + 传感器/执行器 + 实时操作系统（FreeRTOS、RT-Thread、LiteOS 等）+ 应用固件。常见例子有家电控制板、汽车 ECU、工业 PLC、可穿戴设备、路由器。 与通用 PC 的区别在于设计目标：通用机追求什么都能跑，嵌入式追求在给定资源下稳定完成这一件事。

FunctionGraph 冷启动优化可以按收益从高到低做： 1. 预留实例/预置并发：热实例常驻，对延迟敏感的接口按基线 QPS 预留，突发部分再走按量实例，这是最直接的手段。2. 缩小代码包：依赖按需打包，别把 numpy/pandas、完整 SDK 全塞进去；公共依赖抽成 Layer 复用，包越小下载解压越快。3. 选对运行时：冷启动大致是 Java/.NET > Node/Python > Go/自定义运行时；Java 可以考虑 GraalVM native image，或换轻量 HTTP 框架。4. 初始化逻辑外移：DB 连接、客户端 SDK 初始化放到 handler 外，利用初始化阶段只执行一次；不要在每次调用里 new client。5. 谨慎用 VPC 访问：挂 ENI 会明显拉长冷启动，只有必须访问 VPC 内资源时才配置，能走私网网关/终端节点的优先替代。6. 定时预热：定时触发器每 5~10 分钟打一次，配合少量预留实例，成本可控。7. 先定位再优化：看冷启动次数、初始化耗时、包下载耗时，确认瓶颈在拉包、依赖加载还是 VPC 挂载。

FunctionGraph 的冷启动优化，按收益从高到低可以这么做： 1. 预留实例/预置并发。把热实例常驻，是最直接的手段；对延迟敏感的接口按基线 QPS 预留，突发部分再走按量实例。2. 缩小代码包。依赖按需打包，别把 numpy/pandas、完整 SDK 一股脑塞进去；公共依赖抽成层（Layer）复用。包越小，下载和解压越快。3. 选对运行时。冷启动耗时大致是 Java/.NET > Node/Python > Go/自定义运行时；Java 可以考虑 GraalVM native image，或者把重框架换成轻量 HTTP 框架。4. 初始化逻辑外移。把数据库连接、客户端 SDK 初始化放到 handler 外的初始化阶段，利用"初始化只执行一次"的特性；不要在每次调用里 new client。5. 谨慎使用 VPC 访问。挂 ENI 会明显拉长冷启动，只有必须访问 VPC 内资源时才配置；能用私网网关/终端节点替代的优先替代。6. 定时预热。用定时触发器每 5~10 分钟打一次，配合少量预留实例，成本可控。7. 先定位再优化。看冷启动次数、初始化耗时、镜像/包下载耗时，确认瓶颈在拉包、依赖加载还是 VPC 挂载，避免盲目调参。

嵌入式系统可以抓住三个本质特征来定义： 1. 专用性：面向特定功能/被控对象设计，不是通用计算机。软件通常固化在 Flash 中，开机直接进入业务循环，用户不会去"安装软件"。2. 资源受限：CPU 主频、内存、存储、功耗、成本都有硬约束，软硬件需要一起裁剪，很多芯片连 MMU 都没有。3. 实时性与可靠性：大量场景要求在确定时间内响应（硬实时/软实时），并支持长期无人值守运行、掉电恢复、看门狗复位等机制。 典型组成是：MCU/SoC + 传感器/执行器 + 实时操作系统（FreeRTOS、RT-Thread、LiteOS 等）+ 应用固件。常见例子有家电控制板、汽车 ECU、工业 PLC、可穿戴设备、路由器。 和通用 PC 最大的区别在于设计目标：通用机追求"什么都能跑"，嵌入式追求"在给定资源下稳定完成这一件事"。

列几个新手最容易踩的 OBS 坑： 1. 桶策略与 IAM 策略不一致。桶 ACL 公共读写改成了"所有人"，或 IAM 授权配了 obs:bucket:*:ListBucket 全桶列举，这两种都是真实事故来源。最小权限原则：桶策略只对特定前缀/操作授权。 2. 跨区流量费被忽略。同区域 ECS 访问 OBS 走内网免流量费；跨区域、公网下载都按流量计费，一次大批量导出账单会很惊人。批量同步用跨区复制或 CDN 回源，比直接拉便宜。 3. 误把 OBS 当文件系统用。它不是 POSIX，不支持原子 rename/append，语义是 PUT 覆盖写 + LIST 强最终一致（新桶 LIST 是强一致，老桶是最终一致）。拿它当日志 append 端会把彼此覆盖。 4. 生命周期规则一上就删数据。配置过期删除时先在测试桶验证，尤其是"分段上传未完成清理"规则——上传中断的碎片默认 7 天清理，配错会把还在续传的分段删掉。 5. 桶名、Endpoint 用错。桶名全局唯一且创建后不可改名；客户端连的 Endpoint 必须和桶所在区域一致，否则拿到的 SignatureDoesNotMatch 类报错会误导排查方向。 6. 大对象上传不用分段。SDK 默认阈值以上会自动分段，但自己裸写 PUT 上传 5GB+ 文件必然超时；单次 PUT 上限是 5GB。 排查工具建议：开 OBS 的访问日志 + 云审计，先把"谁在什么时候删的"这个问题变成可回答的。

选型思路按四步走，别一上来就挑具体规格： 1. 先画像再选型。把业务拆成 CPU 密集（编译、转码）、内存密集（缓存、大 JVM 堆）、IO 密集（数据库、消息队列）三类。CPU 密集选 c 系列，内存型选 m/kylin M 系列，通用 web/微服务用 s/Flexus 就够，数据库类用鲲鹏 kc1 或 x86 的 c 系列 + 高 IO 云硬盘。 2. 用"按需试跑 + 包周期"组合。新业务先按需（按小时计费）压测 1~2 周拿到真实 P95 负载画像，再转包周期，比拍脑袋买包年包月便宜 30% 以上。中途还能用"规格变更"在线升配，不用重装。 3. 性能下限看两个指标：vCPU 与内存配比（1:1 通用 / 1:2~1:4 均衡 / 1:8+ 内存型），以及内网带宽与 PPS（很多卡顿其实是网络打满而不是 CPU）。磁盘选高 IO 型，SSD 买容量送 IO 的不如按 IO 付费的场景要算清楚。 4. 成本控制三板斧：闲时业务用竞价实例（能容忍中断的批处理/worker）、包周期 + 预留券、低峰期做定时关机（Flexus/函数工作流定时关 ECS）。同时留意"共享配额型"和"独享型"的差别——性能抖动的锅常在超卖型规格上。 一句话总结：先用按需摸清画像，再按画像定系列，最后用计费策略省钱。

补充几点华为云 APIG 限流调优的实操思路： 1. 选对流控对象。按 API 限流只适合单接口保护；对调用方维度（比如不同 AppCode/租户）要用"流控策略绑定应用"或插件市场里的流控插件，否则一个调用方打满配额会拖死所有人。 2. 阈值不要拍脑袋。先在 APIG 自带的调用统计（或对接 AOM/CES 看板）里观察 P95 峰值，按"峰值 × 1.2~1.5"设默认阈值，再逐步收紧。突然设一个很小的值，最先报错的是正常的批处理任务。 3. 突发流量用突发上限（burst）兜底，而不是把长期阈值调高。桶容量给到 2~3 倍 QPS 即可，避免限流器长期放水。 4. 返回行为可以自定义：默认 429 带上 Retry-After 头，客户端退避重试比直接 5xx 友好得多；前端可以配置错误响应模板。 5. 注意流控插件与后端自身的限流是叠加的。APIG 放过去了，后端网关（如 Nginx limit_req）还会再拦一层，压测时容易误判"限流没生效"，实际是命中了下游。 排查顺序建议：APIG 调用日志看 429 命中率 → 流控策略绑定的对象范围 → 阈值与实际峰值对比 → 客户端重试策略是否放大了流量（重试风暴往往是限流问题的真凶）。