不看懂这些词，看任何一家公司的产品都会迷路
把「买服务器」变成「租服务器」，用多少付多少。
在云计算之前，做一个网站必须自己买机器、找机房托管、装系统、配网络。前期要投一大笔钱，而且流量小时机器闲着，流量暴涨时又扛不住。
云计算把硬件变成了一种可以随时购买的服务：你在网页上点几下，几分钟后就得到一台能用的服务器；不要了随时退掉。这就是「按需付费」和「弹性」的来源。
理解这一点之后，几乎所有云产品的分类都会变得自然：卖算力的（虚拟机、容器、函数）、卖存储的（对象存储、数据库）、卖网络的（CDN、专线）、卖能力的（AI、音视频、地图）。
常见误解：常见误解：云就是「别人的电脑」。更准确的说法是「别人把成千上万台电脑切分后按配额租给你，并附带一整套自动化管理系统」。
把计算搬到离用户最近的那个机房，让数据少跑路。
光速是有限的。你的服务器在美国，中国用户访问至少要绕太平洋一圈，物理延迟就是一百多毫秒，代码写得再好也消不掉。
边缘计算的做法是：把一部分代码和数据复制到全球几百个机房，让用户就近执行。只有必须集中的操作（比如写入数据库）才回到中心。
CDN 是边缘计算的静态版本（缓存文件），边缘函数是它的动态版本（执行代码）。这是过去十年网络架构最重要的一个变化方向。
都为了让多个程序互不干扰地共用一台机器，但「隔离的层次」不同。
虚拟机会虚拟出一整套硬件，每台虚拟机里跑一个完整的操作系统，隔离最彻底，但启动慢、占用大（每台都要跑一份系统）。
容器只隔离进程，所有容器共享宿主机同一个操作系统内核，因此启动只要毫秒级、体积小得多。代价是隔离没虚拟机那么强。
实践中的组合是：在云服务器（虚拟机）里跑容器，再用 Kubernetes 来编排管理这些容器。三层各管各的事。
常见误解：常见误解：容器不是「轻量虚拟机」。它本质上只是被限制过的普通进程。
没有请求就没有实例，你不为「闲置的服务器」付钱。
传统模式你要为「一直开着的服务器」付费，哪怕凌晨三点没人访问。Serverless 把计费单位改成了「调用次数 + 执行时长」。
代价是你要接受更严格的约束：单次执行有超时上限、不能保存本地状态、冷启动可能带来延迟。因此它适合事件驱动、短小、可水平切分的任务。
它真正的价值是「不用再考虑容量规划」——大促来了自动扩到一万个实例，大促结束自动归零。
所有请求的唯一入口，鉴权、限流、路由、日志都在这里统一做。
系统拆成几十个服务之后，如果让客户端自己去记「哪个接口在哪个服务」，客户端会变得极其难维护，安全策略也会散落各处。
网关把所有内部服务藏在后面，对外只暴露一个地址。它统一处理那些「每个服务都要做一遍」的事情：验证身份、限制频率、记录日志、灰度分流。
这类「横切关注点」上移是架构演进的一条主线：逻辑只写一遍，所有服务受益。
把涌进来的流量分给多台服务器，如同超市多开收银台。
一台服务器的处理能力有上限，负载均衡器站在前面把请求分发给后面一组服务器，任何一台挂了就把它从名单里摘掉。
它同时解决三个问题：容量（多台一起扛）、可用性（坏了一台不致命）、运维（可以滚动升级，逐台重启而不中断服务）。
在云上，负载均衡通常和健康检查、证书管理、WAF 打包在一起，是「可用架构」的第一块积木。
三种存放数据的方式：放照片的仓库、可以随机读写的硬盘、多人共用的共享文件夹。
对象存储（S3、OSS、COS）适合「写一次、读很多次」的内容：图片、视频、备份、静态文件。它用 HTTP 接口读写，几乎可以无限扩容，但不支持像硬盘那样随机修改。
块存储就是我们熟悉的云盘：可以格式化、装系统、跑数据库，性能高但只能挂在一台机器上。
文件存储是可以被很多台机器同时挂载的共享目录，适合需要共享读写的中小规模场景，成本通常最高。
常见误解：常见误解：对象存储便宜，就什么都往里放。它不能当数据库用——你要查「所有价格大于 100 的商品」时，它只能把全部数据读一遍再筛。
关系型像 Excel 表格并保证一致性；NoSQL 牺牲一部分规则换取可扩展性。
关系型数据库（MySQL、PostgreSQL、SQL Server）用表来组织数据，支持事务与复杂查询，保证「要么全成功、要么全失败」，是绝大多数业务的首选。
NoSQL（键值、文档、宽列、图）放弃了一部分灵活查询能力，换取超大并发下的稳定与横向扩展能力。例如 DynamoDB 在亿级数据量下依然保持稳定延迟。
现实中的选择往往是「两者都用」：核心交易数据放关系库，海量日志、会话、推荐特征放 NoSQL。
数据库服务「某个用户此刻的订单」，数据仓库回答「过去一年全国各类目卖了多少」。
业务数据库的特点是「大量小的读写」，而且是按行存取。当你要统计全公司数据、跨几十张表做关联分析时，直接查业务库会把线上服务拖垮。
数据仓库专门为分析设计：按列存储（只读需要的字段）、批量导入、支持巨大的聚合查询，能忍受几秒到几分钟的响应时间。
两者之间靠「同步」连接起来：定时或实时把业务数据搬到数仓，在数仓里加工成指标。这就是 ETL 与数据分层的由来。
把最常被访问的数据放在最快的地方，避免每次都去问慢的那一层。
磁盘比内存慢几万倍，跨城网络比本机慢几百倍。缓存的原则很简单：把热点数据复制到更近、更快的位置。
浏览器缓存、CDN 缓存、应用内存缓存、数据库查询缓存，本质上都是这一件事在不同层级上重复发生。
缓存最难的不是「怎么变快」，而是「数据更新时怎么不返回过期内容」。这也是为什么几乎所有缓存方案都要讨论一致性、穿透、雪崩。
把任务先塞进排队区，需要的人按自己的速度取走。
下单时要发短信、加积分、通知仓库、更新报表。如果这些都同步做完再给用户返回，用户要等很久，且任何一步失败都会导致下单失败。
消息队列把「接收请求」和「处理后续」拆开：下单成功立刻返回，其余动作变成一条条消息，由各个后台服务慢慢消费。
它同时带来四个好处：解耦（双方互不认识）、削峰（突发流量先排队）、异步（用户体验更快）、可靠（失败可重试、可人工兜底）。
一个巨大的「下一个词概率机」，参数是它记住的规律量，token 是它读写的单位。
模型内部是一堆数字（参数），训练就是不断调整这些数字，让它在给定上文时预测下一个词越来越准。参数量大致对应「能装下多少规律」，但不直接等于聪明程度。
Token 是它处理文本的最小单位，大约一个英文单词或半个汉字。计费按 token 算，所以「输入越长、输出越长越贵」。
上下文窗口是它一次能「看见」的 token 上限。超出部分模型看不到，这也是为什么长文档要做切片与检索（RAG）。
常见误解：常见误解：模型不是数据库，它不「存储」你的资料。它记住的是语言模式，具体事实很容易记错（幻觉）。
三种「让模型懂你业务」的手段，成本与效果差别很大。
提示词（Prompt）成本最低：把要求、格式、示例写进对话里。适合规则明确、不需要额外知识的任务，改一次立刻见效。
检索增强（RAG）适合「模型不知道的私有事实」：把公司文档切块入库，提问时先检索再拼进提示词。它让答案可核查、随时更新，且不用重新训练。
微调（Fine-tune）适合「风格与格式的稳定要求」或「垂直领域语感」。它要花算力与数据，且知识更新需要重新训练，因此不要用它来塞事实。
把文字变成一串数字，让「意思相近」变成「距离相近」。
计算机不认识「退款政策」和「退货规则」是同一件事。嵌入模型把文本映射到一个高维坐标系里，语义越接近，坐标距离越近。
于是「找相似内容」就变成了「找最近的坐标点」——这是向量数据库（以及 pgvector、FAISS 这类方案）的核心工作。
它是 RAG、语义搜索、推荐系统、去重、聚类的共同基础设施。理解它，就理解了现代 AI 应用的检索层。
让模型不只「回答」，还能「动手」：查数据库、发请求、改文件、再根据结果继续。
普通对话是一问一答。智能体则是一个循环：模型决定下一步用什么工具 → 系统执行 → 把结果喂回去 → 模型再决定下一步，直到任务完成。
它需要两个基础：模型能可靠地输出结构化的调用请求（函数调用能力），以及一套标准的工具接入方式（协议，如 MCP）。
能力越强、权限越大，风险也越大。因此生产环境的智能体必须做权限隔离、操作审计与人工确认点。
训练是「上学」，推理是「上班」。成本结构完全不同。
训练要处理海量数据、反复前向与反向计算，需要成千上万张加速卡连续跑数周，是极少数大公司的游戏。
推理是「用模型」，不需要反向传播，但对延迟很敏感。为了让推理更便宜更快，业界会做量化、蒸馏、批处理、缓存等优化。
理解这条分界线，就能理解为什么有的产品卖算力（训练平台），有的产品按 token 卖结果（模型 API），有的产品卖优化工具（推理引擎）。
密码只交给一个「身份提供商」，其他系统拿令牌放行。
如果一个员工要在 30 个系统里各存一套密码，结果一定是到处复用弱密码，离职后也没人能确认权限是否全部收回。
单点登录把验证集中到一处（Entra ID、Okta、Google Workspace 等），业务系统不再保存密码，只接收一个短期有效的令牌。
这也是零信任的基础：身份、设备、权限三者结合，每次访问都重新判断，而不是「进了内网就都信」。
只有你和对方能看懂，连服务器本身也解不开。
普通加密（HTTPS）保护的是「传输途中」：数据在服务器上是明文，服务器能读到。
端到端加密把密钥只放在通信双方的设备上，服务器收到的永远是密文，只能负责转发。这从根本上改变了「服务商能否看到你的内容」这个问题的答案。
代价是功能受限：服务器看不懂内容，就无法做云端搜索、内容审核、跨设备恢复；丢失设备也可能丢失历史记录。
可用区是「同一个城市里相互独立的机房楼」，多放一个就多一层保险。
「三个九」是 99.9% 可用，一年最多停 8.76 小时；「四个九」是 52 分钟。差一个九，成本可能翻倍。
可用区（AZ）指同一区域内电力与网络相互独立的机房，把服务同时部署在两个可用区，单栋楼停电也不影响业务。跨区域的容灾则用来应对整座城市级别的故障。
读 SLA 时要看两件事：可用性承诺是多少、没达到时赔什么。绝大多数 SLA 只赔服务费，不赔你的业务损失。
云账单最大的风险不是单价贵，而是「没人看着的流量与闲置资源」。
常见的账单爆炸来源有三个：出网流量（把数据读出去）、忘记关闭的测试实例与快照、以及日志与存储的无上限增长。
几条实用纪律：给所有资源打上「项目/负责人」标签便于归集；对 AI 调用设预算告警；定期清理无主资源；能开自动伸缩就别长期买大配置。
理解计费单位比理解产品功能更能省钱：是按带宽还是按流量、是按调用次数还是按并发、是按存储量还是按请求数，差异往往是数量级。