编程语言研究书库
DevOps 驱动开发

扩展微服务 — 从加机器到系统设计

扩展微服务 — 从加机器到系统设计

这一章讲什么: 流量涨了怎么办。答案分四层:单机加配置(纵向)、 多副本分担(横向)、让 K8s 自动管(三层自动扩缩)、把依赖一起拉上车 (数据库/缓存/队列/外部 API)。最后还有一道验收:不压测过的扩展策略等于盲飞。 本章的暗线是原书结账服务的四阶段演进——它几乎把每一种手段都走了一遍。

1. 主线例子:一个结账服务的四阶段扩展史

本章的主线例子,是原书案例:电商结账微服务的一天负载曲线怎么被一步步接住。

  背景:凌晨清闲,大促期间极端繁忙
    │
  第 1 阶段(纵向):Pod 限额 512Mi/0.5 CPU → 2Gi/2 CPU
    → 吞吐暂时改善,大促还是排队
    │ 教训:单机有「纵向墙」——贵、有单点、收益递减
    ▼
  第 2 阶段(横向 + HPA):多副本 + Service 负载均衡,
    HPA 盯 70% CPU,副本 2 → 12 自动伸缩
    → 应用层接住了;瓶颈挪走了
    ▼
  第 3 阶段(依赖扩展):瓶颈现在轮到 PostgreSQL
    → 加读副本分查询压力 + Redis 缓存商品查询
    ▼
  第 4 阶段(可观测与优化):Prometheus 看到更平滑的延迟曲线,
    成本监控确认大促结束后自动缩回去了

  图说:瓶颈是流动的——每接住一层,下一层瓶颈就显形。
  扩展能力 = 沿这条链逐层解锁的速度。资源数字沿原书案例。

下面按限制出现的顺序展开:§2 纵横向之争,§3 K8s 三层自动扩缩,§4 依赖扩展, §5 压测验收,§6 设计层的无状态与幂等。

2. 纵向 vs 横向:两种扩容的机器

纵向扩展(scale up):给一台机器更多 CPU/内存/IO。原书例子:发薪周的 payroll 服务从 t3.medium(2 vCPU/4GB)升到 t3.2xlarge(8 vCPU/32GB), 代码一行不改1。优势:简单、快、对遗留单体也管用、单机性能好调。 四条硬限制:成本非线性(高端机型的单价不成比例地贵)、 单点故障(机器挂=服务挂)、天花板(单机硬件有尽头)、收益递减 (CPU 翻倍吞吐不翻倍——IO 竞争、线程同步都在拖后腿)2。

横向扩展(scale out):加更多小机器,负载均衡分流量。 原书例子:同样那个 payroll 服务,改成 5 个小容器挂在负载均衡后面, 一个副本挂了其余继续服务3。优势:高可用、弹性、成本随用随付、可多地部署、 滚动更新友好。代价:要求无状态(副本间共享状态要外置)、协调开销 (负载均衡、缓存、同步机制)、写密集场景的数据一致性、跨节点网络延迟4。

一个简化的成本对比值得记住(原书数字):t3.large 约 $0.083/小时, 升到 t3.2xlarge 是 4 倍价买 4 倍资源;而用 4 台 t3.large 得到差不多的容量, 还白得冗余——一台挂了流量自动切走,纵向方案里这就是停机5。

选型五维度(原书):架构(单体偏纵向,微服务偏横向)、流量形态 (不可预测的尖峰→横向 + 自动扩缩)、成本模型(稳定流量大单机可能更便宜; 波动流量小机型更省)、韧性要求(使命关键必须横向)、数据形态 (状态与实例强耦合时纵向避免同步问题)6。

状态:扩展的真正瓶颈

无状态服务随便复制;有状态就难了。四种状态外置策略(原书): 会话放共享缓存(Redis/Memcached);数据库当唯一真相源; 粘性会话(sticky session,负载均衡把用户钉在同一副本)是最后手段,损弹性; 事件溯源(全部变更记成不可变事件,副本可从事件重建状态)7。

CAP 定理在此登场:分布式系统里一致性、可用性、分区容忍三者只能全取其二; 横向扩展天然偏向「分区容忍 + 可用」,强一致性通常是被让渡的那个—— 最终一致性要作为深思熟虑的妥协来设计,不是事故8。

而且一致性假设要验证,不能假设(原书给了三个手段):故障注入看系统能否收敛到 正确状态;压测里故意制造竞争、重复请求、乱序事件;一致性断言进指标 ——如「交易 ID 绝不重复、库存永不为负、事件处理延迟在 SLO 内」, 不变量破了测试就失败9。

3. Kubernetes 三层自动扩缩

K8s 的自动扩缩是一个指标驱动的控制环:metrics-server 收集 → 与目标比对 → 算差值 → 执行扩或缩,像恒温器一样持续纠偏10。三层各管一段:

层控制器管什么
Pod 数量HPA(水平 Pod 自动扩缩)副本数:CPU/内存/自定义指标触发
Pod 大小VPA(垂直 Pod 自动扩缩)每个 Pod 的 requests/limits
节点数量Cluster Autoscaler集群没地方调度就加节点,空闲就摘

3.1 HPA

声明式 YAML(照原书):minReplicas: 2, maxReplicas: 10、CPU 目标 70%; 控制环默认每 15 秒一轮;扩容决策是渐进的,防振荡(flapping)。 除了 CPU/内存,还能挂自定义指标——如 Prometheus 的每秒请求数 (http_requests_per_second 目标 200),或队列深度、并发会话11。

六条最佳实践(原书表 14.6):目标值温和些(60–75% CPU 通常最优); min/max 必须设(防尖峰时无限扩张);requests/limits 必须配(否则算不出利用率); 配就绪探针(别把流量发给还没起好的 Pod);冷却期(缩容前等一下防振荡); 盯扩缩事件本身(Prometheus 里看 kube_hpa_status_current_replicas)12。

3.2 VPA

适合不好复制的工作负载:有状态应用、批处理、ML 推理。 三组件:Recommender(分析历史用量给建议)、Updater(重启 Pod 应用新值)、 Admission controller(新建 Pod 时注入建议值)。 三模式:Off(只记录建议,测试用)、Initial(只在创建时应用)、 Auto(持续调整,会重启 Pod——生产慎用)13。

HPA 与 VPA 是互补不是竞争(数量 vs 容量);但两者同管一个工作负载会打架, 除非仔细配(常见组合:HPA 管弹性,VPA 管效率,再叠加 Cluster Autoscaler 管节点)14。

3.3 Cluster Autoscaler 与五大坑

典型链路(照原书):HPA 加了 5 个 Pod → 调度器无处可放 → CA 自动开新节点组 → 负载降了,冷却期后摘掉空闲节点15。端到端弹性,无人介入。

五个常见坑(原书)16:

坑症状解
没有 metrics-server扩缩静默失败kubectl get deployment metrics-server -n kube-system
振荡(flapping)阈值过激,上下横跳加大稳定窗口、设最小副本
Pod 卡 Pending集群满了而 CA 没开开 CA 或手动加节点
负载不均有的 Pod 闲有的忙查 Service selector 与就绪探针
指标失真没配 requestsDeployment 里必须写 CPU/内存 requests

案例(视频转码流水线,原书数字):HPA 盯队列长度 + VPA 调转码 Pod 的 CPU—— 平均排队时间降 82%,计算成本降 27%,吞吐 300 → 每集群 1100 并发转码17。

4. 依赖扩展:应用能扩,依赖也得跟上

K8s 把无状态 Pod 扩得再漂亮,整体吞吐由最弱的依赖决定:能扛 100 个并发连接的 数据库,面对扩出来的 500 个 Pod 就是饱和、慢查询、死锁18。

4.1 数据库:最难扩的组件

五种策略(原书表 14.10)19:

策略干什么工具/例子
纵向主库升级RDS 换大实例
读副本读走副本,写走主库PostgreSQL 流复制、RDS 读副本
分片按键范围拆到多节点按 customer_id 分:1–10 万在分片 1……
连接池限制活跃连接数共享复用PgBouncer、ProxySQL
缓存热点数据内存直出Redis、Memcached

分片的代价要讲透:查询路由要感知分片拓扑、跨分片 join 昂贵、 再平衡(某个分片长得快)不自动化就会停机20。

4.2 缓存:第一道防线,四种模式

读穿透(缓存未命中回源并回填)、写穿透(同时写缓存与库)、 写后置(先写缓存异步落库)、旁路缓存(应用自己管)。 红线:必须有 TTL 和失效策略——没有逐出策略,脏数据会赖着不走21。

4.3 消息队列:削峰与扩消费者

Kafka/RabbitMQ/Pub/Sub 解耦生产与消费。扩法四件(原书表 14.12): topic 分区、消费组、按队列深度自动扩消费者(KEDA) 、死信队列收尸。盯两个指标:队列深度与消费者滞后(lag)22。

4.4 外部 API:别人的限速是你的天花板

这是最容易被忽略的一条:你的集群可以无限扩,但第三方 API 的配额不会。 失控扩 Pod 只会招来 HTTP 429(Too Many Requests)。四个自适应手段: 限流(令牌桶/漏桶)、熔断、请求合并、降级走缓存。 原书给了 Python 令牌桶实现(照抄结构):按速率匀速补充令牌,有令牌才放行23。

4.5 依赖可观测

四类依赖各盯一组数(原书):数据库——查询延迟/活跃连接/复制滞后; 缓存——命中率/逐出数/内存;队列——消费者滞后/未确认消息; 外部 API——响应时间/失败率/配额使用率。依赖指标与应用指标同屏, 瓶颈在哪一眼可见24。

判断(我们的,不是书里的): 本章最有价值的一句话是「瓶颈是流动的」: 应用扩完轮到数据库,数据库加完副本轮到网络,全扩完可能轮到第三方 API 的配额。 实践中团队常犯的错是「为上一阶段的瓶颈过度优化」——大促后还留着 12 副本的配置。 因此扩展策略必须和缩容验证绑定:每个扩展动作都要回答「流量退潮后它怎么退回去」, 缩不回去的弹性不是弹性,是账单(第 13 章)。 如果错,会错在: 预留容量按长期基线供给、弹性只用于真尖峰的系统里, 「缩容验证」的优先级会下降——但即便在那里,缩容能力仍是灾备的一部分 (故障时需要快速让出资源),不会完全失效。

5. 压测:扩展策略的验收考试

不验证的扩展是盲飞。压测在 DevOps 里是 shift-left 的一部分,进 CI/CD25。

六种测试各问一个问题(原书表 14.13)26:

类型干什么例子
负载测试预期流量下稳不稳500 用户同时下单
压力测试压到崩,看断点1 万并发连接
尖峰测试突发流量,验弹性闪购 3 倍流量突袭
浸泡测试长时间持续,抓泄漏8 小时连续负载
扩展性测试渐加负载,验自动扩缩100 → 1000 req/s

工具五选(原书表 14.14):JMeter(企业级多协议)、k6(JavaScript 脚本, CI 友好,Grafana 一家)、Locust(Python)、Gatling(Scala,CI 环境)、 Artillery(Node,YAML 定义)27。

设计压测五要素:目标负载定义;爬坡/下坡曲线;数据多样性(别拿同一请求刷屏); 依赖侧插桩(压测时同时盯数据库/缓存/队列);成功标准挂在 SLO 上 (如 95% 请求 < 300ms)。k6 例子(照抄):100 并发 1 分钟, p(95)<300 阈值,挂进 GitHub Actions 一步搞定28。

读结果看三指标:延迟、吞吐、错误率;健康系统的样子—— 负载渐加时延迟稳定、吞吐线性增长直到触顶、过顶后优雅退化而不是陡崖29。

五个反模式:只压单个服务不带上依赖;没有基线对比;不测冷启动 (serverless 的冷启动会扭曲真实表现);并发参数脱离真实用户行为; 不与可观测数据关联30。

案例(金融科技 API,原书数字):k6 按真实流量模拟 5000 并发/秒,发现两件事—— 数据库连接在 300 并发以上饱和;HPA 阈值配错(85% 才触发,扩得太晚)。 改连接池 + 阈值降到 70% 后,平均响应 620 → 210ms31。

6. 设计层:无状态、幂等与可扩模式

基础设施再先进,也救不了设计上抱死状态的服务32。

无状态的准确含义:不是不要状态,而是状态外置、每次请求独立。 对照例子:有状态的认证服务把会话存内存,机器挂会话全丢; 无状态设计会话放 Redis 或编码进 JWT,任何副本能服务任何请求33。 五条设计指引:会话外置(Redis/DynamoDB)、文件用对象存储(S3/GCS)、 配置外置(ConfigMap/环境变量)、事务外置(队列/数据库)、 API 无状态(JWT 而非服务端会话)。原书给了 Flask + Redis 会话的例子(照抄结构)34。

反模式清单(原书点名):日志/上传写 /tmp、用内存 map 当会话表、 用户偏好存本地 JSON、依赖本地文件路径——每一条都把实例钉死在自己的运行时里, K8s 没法自由重排35。

幂等(idempotency):同一操作执行多次与执行一次效果相同——重试密集的环境里的 保命属性。支付重试不能双扣款,通知重发不能双投递。四种手段(原书表 14.15): 唯一请求 ID 记事务日志;条件更新(UPDATE ... WHERE status='pending'); upsert;无状态重试(429 + 重试头)36。

可扩架构五模式(原书表 14.16):CQRS(读写分离,读多写少的系统单独扩读侧)、 事件驱动(Kafka 异步解耦)、舱壁(按域隔离故障)、熔断(Hystrix/Resilience4j)、 Saga(跨服务的长事务拆成一串本地事务 + 补偿)37。

API 设计四要求:可预期无副作用、可缓存(ETag/Cache-Control)、 分页/流式(防大载荷)、幂等可重试。分页例子照原书:page/per_page/total_pages/data38。

案例(无状态图片处理,原书数字):原来临时文件写本地盘,Pod 重启就丢活; 重构为直传 S3 + Redis 队列记状态 + 异步 worker + 任务幂等(文件绑唯一 ID)—— 20 → 200 Pod 零配置改动,处理时间降 40%,Pod 挂了不丢工作39。

7. 边界与局限

  1. 「瓶颈是流动的」没给检测方法:怎么主动发现下一层瓶颈(排队论?压测?) 靠读者自己悟;依赖可观测一节给了一半答案。
  2. 分片讲得比读副本浅——再平衡与跨分片事务是生产里最大的坑,各一句带过。
  3. KEDA 只在表里出现一次名字,事件驱动扩消费者这种关键能力没有展开。
  4. CAP 定理的表述是通俗版(「三者只能取二」),严格的学术表述与 「分区发生时必须在 C/A 间选」的 nuanced 版本有距离。
  5. 所有案例数字(82%、27%、620→210ms)无出处。

8. 可带走的

  1. 纵向简单有单点有天花板;横向弹性但要求无状态;真实系统混合用;
  2. 简化账:4 台小机 ≈ 1 台大机的价格,但白得冗余;
  3. 状态外置四法:共享缓存、数据库为真相源、粘性会话(最后手段)、事件溯源;
  4. 三层自动扩缩:HPA 管数量(60–75% 目标、必须设 max)、VPA 管大小 (Auto 会重启)、CA 管节点;
  5. 五大坑:无 metrics-server、振荡、Pending、负载不均、没配 requests;
  6. 依赖是天花板:数据库(读副本/分片/连接池/缓存)、队列(分区/消费组/KEDA)、 外部 API(令牌桶限流);
  7. 压测六类型问六个问题;k6 挂 CI,阈值挂 SLO;健康曲线=延迟稳+吞吐线性+过顶优雅;
  8. 无状态=状态外置;幂等四手段(请求 ID/条件更新/upsert/无状态重试);
  9. 五模式:CQRS、事件驱动、舱壁、熔断、Saga;
  10. 每个扩展动作都要回答「流量退潮后怎么缩回去」。

9. 原文地图

主题原书章原文位置
纵横向定义与工资服务例子Horizontal and vertical scalingtext/45-fm-horizontal-and-vertical-scaling.txt:13(搜「payroll」) · text/45-fm-horizontal-and-vertical-scaling.txt:30(搜「single point of failure」)
成本对比与选型五维度同上text/45-fm-horizontal-and-vertical-scaling.txt:551(搜「0.083」) · text/45-fm-horizontal-and-vertical-scaling.txt:402(搜「Application architecture」)
状态外置与 CAP同上text/45-fm-horizontal-and-vertical-scaling.txt:574(搜「Redis or Memcached」) · text/45-fm-horizontal-and-vertical-scaling.txt:587(搜「CAP」)
一致性验证三手段同上text/45-fm-horizontal-and-vertical-scaling.txt:593(搜「consistency expectations」)
结账四阶段演进同上text/45-fm-horizontal-and-vertical-scaling.txt:620(搜「Phase 1」) · text/45-fm-horizontal-and-vertical-scaling.txt:629(搜「Phase 4」)
自动扩缩控制环Kubernetes autoscalingtext/46-fm-kubernetes-autoscaling.txt:27(搜「thermostat」)
HPA 配置与自定义指标同上text/46-fm-kubernetes-autoscaling.txt:87(搜「webapp-hpa」) · text/46-fm-kubernetes-autoscaling.txt:147(搜「http_requests_per_second」)
HPA 六最佳实践同上text/46-fm-kubernetes-autoscaling.txt:197(搜「60 to 75%」)
VPA 三组件三模式同上text/46-fm-kubernetes-autoscaling.txt:295(搜「Recommender」) · text/46-fm-kubernetes-autoscaling.txt:371(搜「Off」)
Cluster Autoscaler 链路与五大坑同上text/46-fm-kubernetes-autoscaling.txt:582(搜「adds five new pods」) · text/46-fm-kubernetes-autoscaling.txt:720(搜「metrics-server」)
转码案例(82%/27%)同上text/46-fm-kubernetes-autoscaling.txt:782(搜「82%」)
数据库五策略与分片代价Scaling with third-party dependenciestext/47-fm-scaling-with-third-party-dependencies.txt:50(搜「Strategy」) · text/47-fm-scaling-with-third-party-dependencies.txt:183(搜「shard topology」)
缓存四模式与 TTL 红线同上text/47-fm-scaling-with-third-party-dependencies.txt:243(搜「Read-through」) · text/47-fm-scaling-with-third-party-dependencies.txt:318(搜「TTL」)
队列扩法与外部 API 四手段同上text/47-fm-scaling-with-third-party-dependencies.txt:357(搜「Topic partitioning」) · text/47-fm-scaling-with-third-party-dependencies.txt:451(搜「token buckets」)
依赖可观测四组指标同上text/47-fm-scaling-with-third-party-dependencies.txt:528(搜「Query latency」)
压测六类型与工具五选Performance testing for scale readinesstext/48-fm-performance-testing-for-scale-readiness.txt:88(搜「Load testing」) · text/48-fm-performance-testing-for-scale-readiness.txt:248(搜「JMeter」)
k6 例子与健康曲线同上text/48-fm-performance-testing-for-scale-readiness.txt:414(搜「p(95)<300」) · text/48-fm-performance-testing-for-scale-readiness.txt:468(搜「Stable latency」)
五反模式与金融案例同上text/48-fm-performance-testing-for-scale-readiness.txt:540(搜「Testing in isolation」) · text/48-fm-performance-testing-for-scale-readiness.txt:602(搜「620 ms」)
无状态/幂等与 Flask+Redis 例子Designing stateless and scalable servicestext/49-fm-designing-stateless-and-scalable-services.txt:26(搜「JWT」) · text/49-fm-designing-stateless-and-scalable-services.txt:207(搜「SESSION_TYPE」) · text/49-fm-designing-stateless-and-scalable-services.txt:91(搜「Request identifiers」)
本地状态反模式清单同上text/49-fm-designing-stateless-and-scalable-services.txt:255(搜「/tmp」)
架构五模式与 API 四要求同上text/49-fm-designing-stateless-and-scalable-services.txt:304(搜「CQRS」) · text/49-fm-designing-stateless-and-scalable-services.txt:410(搜「Cacheable」)
图片处理案例(20→200 Pod)同上text/49-fm-designing-stateless-and-scalable-services.txt:503(搜「200 pods」)

Footnotes

  1. 出处:「Horizontal and vertical scaling」第 13 段(text/45-fm-horizontal-and-vertical-scaling.txt:13,搜「payroll」)。 ↩

  2. 出处:「Horizontal and vertical scaling」第 30–33 段(text/45-fm-horizontal-and-vertical-scaling.txt:30,搜「single point of failure」;text/45-fm-horizontal-and-vertical-scaling.txt:145,搜「non-linearly」)。 ↩

  3. 出处:「Horizontal and vertical scaling」第 209 段(text/45-fm-horizontal-and-vertical-scaling.txt:209,搜「five smaller containers」)。 ↩

  4. 出处:「Horizontal and vertical scaling」第 337–381 段(text/45-fm-horizontal-and-vertical-scaling.txt:337,搜「Requires stateless design」;text/45-fm-horizontal-and-vertical-scaling.txt:363,搜「Data consistency」)。 ↩

  5. 出处:「Horizontal and vertical scaling」第 551–561 段(text/45-fm-horizontal-and-vertical-scaling.txt:551,搜「0.083」)。 ↩

  6. 出处:「Horizontal and vertical scaling」第 402–414 段(text/45-fm-horizontal-and-vertical-scaling.txt:402,搜「Application architecture」)。 ↩

  7. 出处:「Horizontal and vertical scaling」第 572–583 段(text/45-fm-horizontal-and-vertical-scaling.txt:574,搜「Redis or Memcached」;text/45-fm-horizontal-and-vertical-scaling.txt:580,搜「Sticky sessions」)。 ↩

  8. 出处:「Horizontal and vertical scaling」第 587 段(text/45-fm-horizontal-and-vertical-scaling.txt:587,搜「CAP」)。 ↩

  9. 出处:「Horizontal and vertical scaling」第 590–610 段(text/45-fm-horizontal-and-vertical-scaling.txt:593,搜「consistency expectations」;text/45-fm-horizontal-and-vertical-scaling.txt:606,搜「invariants」)。 ↩

  10. 出处:「Kubernetes autoscaling」第 27 段(text/46-fm-kubernetes-autoscaling.txt:27,搜「thermostat」)。 ↩

  11. 出处:「Kubernetes autoscaling」第 58–159 段(text/46-fm-kubernetes-autoscaling.txt:87,搜「webapp-hpa」;text/46-fm-kubernetes-autoscaling.txt:129,搜「averageUtilization」;text/46-fm-kubernetes-autoscaling.txt:147,搜「http_requests_per_second」)。 ↩

  12. 出处:「Kubernetes autoscaling」第 192–262 段(text/46-fm-kubernetes-autoscaling.txt:197,搜「60 to 75%」;text/46-fm-kubernetes-autoscaling.txt:210,搜「runaway scaling」)。 ↩

  13. 出处:「Kubernetes autoscaling」第 285–410 段(text/46-fm-kubernetes-autoscaling.txt:295,搜「Recommender」;text/46-fm-kubernetes-autoscaling.txt:371,搜「Off」)。 ↩

  14. 出处:「Kubernetes autoscaling」第 416–563 段(text/46-fm-kubernetes-autoscaling.txt:563,搜「Table 14.8」)。 ↩

  15. 出处:「Kubernetes autoscaling」第 569–591 段(text/46-fm-kubernetes-autoscaling.txt:582,搜「adds five new pods」)。 ↩

  16. 出处:「Kubernetes autoscaling」第 713–740 段(text/46-fm-kubernetes-autoscaling.txt:720,搜「metrics-server」;text/46-fm-kubernetes-autoscaling.txt:725,搜「flapping」)。 ↩

  17. 出处:「Kubernetes autoscaling」第 769–792 段(text/46-fm-kubernetes-autoscaling.txt:782,搜「82%」;text/46-fm-kubernetes-autoscaling.txt:788,搜「1,100」)。 ↩

  18. 出处:「Scaling with third-party dependencies」第 13–19 段(text/47-fm-scaling-with-third-party-dependencies.txt:13,搜「100 concurrent connections」;text/47-fm-scaling-with-third-party-dependencies.txt:19,搜「cascading failures」)。 ↩

  19. 出处:「Scaling with third-party dependencies」第 50–158 段(text/47-fm-scaling-with-third-party-dependencies.txt:50,搜「Strategy」;text/47-fm-scaling-with-third-party-dependencies.txt:158,搜「Table 14.10」)。 ↩

  20. 出处:「Scaling with third-party dependencies」第 170–190 段(text/47-fm-scaling-with-third-party-dependencies.txt:176,搜「customer_id」;text/47-fm-scaling-with-third-party-dependencies.txt:189,搜「Rebalancing」)。 ↩

  21. 出处:「Scaling with third-party dependencies」第 225–318 段(text/47-fm-scaling-with-third-party-dependencies.txt:243,搜「Read-through」;text/47-fm-scaling-with-third-party-dependencies.txt:318,搜「TTL」)。 ↩

  22. 出处:「Scaling with third-party dependencies」第 321–432 段(text/47-fm-scaling-with-third-party-dependencies.txt:357,搜「Topic partitioning」;text/47-fm-scaling-with-third-party-dependencies.txt:432,搜「KEDA」)。 ↩

  23. 出处:「Scaling with third-party dependencies」第 435–515 段(text/47-fm-scaling-with-third-party-dependencies.txt:444,搜「429」;text/47-fm-scaling-with-third-party-dependencies.txt:470,搜「TokenBucket」)。 ↩

  24. 出处:「Scaling with third-party dependencies」第 518–540 段(text/47-fm-scaling-with-third-party-dependencies.txt:528,搜「Query latency」)。 ↩

  25. 出处:「Performance testing for scale readiness」第 4–10 段(text/48-fm-performance-testing-for-scale-readiness.txt:10,搜「shift-left」)。 ↩

  26. 出处:「Performance testing for scale readiness」第 52–203 段(text/48-fm-performance-testing-for-scale-readiness.txt:88,搜「Load testing」;text/48-fm-performance-testing-for-scale-readiness.txt:157,搜「Endurance」)。 ↩

  27. 出处:「Performance testing for scale readiness」第 212–363 段(text/48-fm-performance-testing-for-scale-readiness.txt:248,搜「JMeter」;text/48-fm-performance-testing-for-scale-readiness.txt:271,搜「k6」)。 ↩

  28. 出处:「Performance testing for scale readiness」第 366–530 段(text/48-fm-performance-testing-for-scale-readiness.txt:414,搜「p(95)<300」;text/48-fm-performance-testing-for-scale-readiness.txt:521,搜「k6-action」)。 ↩

  29. 出处:「Performance testing for scale readiness」第 444–483 段(text/48-fm-performance-testing-for-scale-readiness.txt:468,搜「Stable latency」)。 ↩

  30. 出处:「Performance testing for scale readiness」第 533–556 段(text/48-fm-performance-testing-for-scale-readiness.txt:540,搜「Testing in isolation」;text/48-fm-performance-testing-for-scale-readiness.txt:546,搜「cold starts」)。 ↩

  31. 出处:「Performance testing for scale readiness」第 588–604 段(text/48-fm-performance-testing-for-scale-readiness.txt:591,搜「5,000 concurrent」;text/48-fm-performance-testing-for-scale-readiness.txt:602,搜「620 ms」)。 ↩

  32. 出处:「Designing stateless and scalable services」第 4–7 段(text/49-fm-designing-stateless-and-scalable-services.txt:4,搜「poorly designed service」)。 ↩

  33. 出处:「Designing stateless and scalable services」第 23–27 段(text/49-fm-designing-stateless-and-scalable-services.txt:26,搜「JWT」)。 ↩

  34. 出处:「Designing stateless and scalable services」第 176–225 段(text/49-fm-designing-stateless-and-scalable-services.txt:207,搜「SESSION_TYPE」;text/49-fm-designing-stateless-and-scalable-services.txt:210,搜「redis-service」)。 ↩

  35. 出处:「Designing stateless and scalable services」第 255–268 段(text/49-fm-designing-stateless-and-scalable-services.txt:255,搜「/tmp」)。 ↩

  36. 出处:「Designing stateless and scalable services」第 33–163 段(text/49-fm-designing-stateless-and-scalable-services.txt:40,搜「double-charge」;text/49-fm-designing-stateless-and-scalable-services.txt:91,搜「Request identifiers」)。 ↩

  37. 出处:「Designing stateless and scalable services」第 274–397 段(text/49-fm-designing-stateless-and-scalable-services.txt:304,搜「CQRS」;text/49-fm-designing-stateless-and-scalable-services.txt:376,搜「Saga」)。 ↩

  38. 出处:「Designing stateless and scalable services」第 400–450 段(text/49-fm-designing-stateless-and-scalable-services.txt:410,搜「Cacheable」;text/49-fm-designing-stateless-and-scalable-services.txt:429,搜「per_page」)。 ↩

  39. 出处:「Designing stateless and scalable services」第 476–512 段(text/49-fm-designing-stateless-and-scalable-services.txt:503,搜「200 pods」;text/49-fm-designing-stateless-and-scalable-services.txt:506,搜「40%」)。 ↩

成本优化与开发者主导的 FinOps — 把账单当成技术指标

Previous Page

AI 时代的 DevOps 与 NoOps — 从辅助到自治的路线图

Next Page

On this page

扩展微服务 — 从加机器到系统设计1. 主线例子:一个结账服务的四阶段扩展史2. 纵向 vs 横向:两种扩容的机器状态:扩展的真正瓶颈3. Kubernetes 三层自动扩缩3.1 HPA3.2 VPA3.3 Cluster Autoscaler 与五大坑4. 依赖扩展:应用能扩,依赖也得跟上4.1 数据库:最难扩的组件4.2 缓存:第一道防线,四种模式4.3 消息队列:削峰与扩消费者4.4 外部 API:别人的限速是你的天花板4.5 依赖可观测5. 压测:扩展策略的验收考试6. 设计层:无状态、幂等与可扩模式7. 边界与局限8. 可带走的9. 原文地图Footnotes