什么是蓝绿部署和金丝雀发布？
What are blue-green deployment and canary release?
蓝绿部署同时维护两套环境，流量一键切到新版本以便快速回滚；金丝雀发布先把少量流量导向新版本验证无误，再逐步放量，降低出错影响面。
Blue-green keeps two environments and switches traffic instantly for fast rollback; canary releases route a small slice to the new version first, then ramp up, limiting the blast radius of faults.
难度 进阶 · 适合 高中(15-18)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：此条未指向带版次的可引用著作（通识性内容、机构文件或未展开的英文书名），本库不提供独立书目出处；如需精确引用，需由编辑补全具体篇目与版次。
Martin Fowler
Martin Fowler
#云 #部署
无服务器（Serverless）计算是什么？
What is serverless computing?
Serverless 让开发者只写函数，平台按请求自动分配资源、扩缩容并按用量计费，无需管理服务器；冷启动和厂商锁定是其常见顾虑。
Serverless lets you write functions while the platform allocates, scales and bills by usage with no server management; cold starts and vendor lock-in are common concerns.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：此条未指向带版次的可引用著作（通识性内容、机构文件或未展开的英文书名），本库不提供独立书目出处；如需精确引用，需由编辑补全具体篇目与版次。
arXiv（Jonas 等, Cloud Programming Simplified: A Berkeley View on Serverless Computing, 2019）
arXiv (Jonas et al., Cloud Programming Simplified: A Berkeley View on Serverless Computing, 2019)
#云 #计算
微服务架构想解决什么问题？
What problem does microservices architecture solve?
微服务把单体应用拆成独立部署、围绕业务的小服务，通过 API 通信，提升团队自治、独立扩展与技术异构能力，代价是分布式复杂性增加。
Microservices split a monolith into independently deployable business-aligned services communicating via APIs, improving team autonomy, scaling and tech choice, at the cost of distributed complexity.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：此条未指向带版次的可引用著作（通识性内容、机构文件或未展开的英文书名），本库不提供独立书目出处；如需精确引用，需由编辑补全具体篇目与版次。
Martin Fowler
Martin Fowler
#云 #架构
容器（container）和虚拟机（VM）的隔离方式有什么不同？
How do containers and virtual machines isolate differently?
虚拟机靠 hypervisor 虚拟出一整套硬件，每个 VM 跑独立操作系统，隔离强但笨重；容器共享宿主内核，只隔离进程与文件系统，因此启动快、占用小，更适合微服务式的弹性部署。
A VM uses a hypervisor to virtualize full hardware with its own OS—strong isolation but heavy. Containers share the host kernel and isolate only processes and filesystems, so they start fast and stay light, suiting elastic microservices.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 已核验 · Verified 2026-08-23 · 2 条独立证据
来源 · Source
Tanenbaum & Bos,《Modern Operating Systems》第4版,Pearson,2014
A. S. Tanenbaum and H. Bos, Modern Operating Systems, 4th ed., Pearson, 2014
独立核验依据 · Independent verification: 核验依据 2 OPENLIBRARY 标识 /works/OL1970688W：Modern Operating System
#容器 #虚拟机
MQTT 定义了哪三种服务质量(QoS)等级?在弱网环境下以 QoS 1 投递消息时,为什么订阅端仍可能收到重复报文?
What three quality-of-service levels does MQTT define, and why can a subscriber still receive duplicated messages when publishing at QoS 1 over an unreliable network?
三个等级分别是至多一次(QoS 0)、至少一次(QoS 1)和恰好一次(QoS 2),保证越强所需的交互往返也越多。QoS 1 要求接收方回发 PUBACK;一旦确认包在网络中丢失,发送方会带 DUP 标志重传 PUBLISH,而首次报文其实已被处理,于是形成重复。业务侧通常需要配合消息 ID 去重或幂等写入来消除这种影响。
They are at-most-once (QoS 0), at-least-once (QoS 1), and exactly-once (QoS 2), with stronger guarantees costing more round trips. At QoS 1 the receiver must return PUBACK; when that acknowledgement gets lost, the sender retransmits PUBLISH with the DUP flag even though the first copy was already handled, producing duplicates. Applications typically add message-ID deduplication or idempotent writes to absorb them.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：著录仅给书名，无版次与年份；同一书名常对应多个版次，不臆测具体版本。
OASIS 标准《MQTT Version 3.1.1》第 4.3 节 Quality of Service levels 与第 4.4 节 Message delivery retry
OASIS MQTT Version 3.1.1 Standard, Section 4.3 Quality of Service levels and Section 4.4 Message delivery retry
#物联网协议 #消息可靠性
边缘计算为什么通常作为云计算的补充而非替代?以联网智能摄像头为例,说明视频数据应在哪几层被逐级过滤。
Why does edge computing usually complement rather than replace cloud computing? Using a networked smart camera as an example, explain at which tiers video data should be filtered step by step.
边缘计算把计算下沉到靠近数据源的网关或设备,主要服务于低时延、节省上行带宽与数据驻留合规三类需求,而云端仍保有全局模型训练、大规模存储与跨站点协调的优势,二者因此形成分工互补。以智能摄像头为例,帧级运动检测与人形识别通常在设备端完成,仅告警片段和低分辨率缩略图上传云端,原始视频流大多不出本地。这种分层过滤能把上行带宽需求降低几个数量级,并保证断网时本地功能仍然可用。
Edge computing pushes computation onto gateways or devices close to data sources, chiefly serving low-latency response, uplink bandwidth savings, and data-residency compliance, while the cloud keeps the advantages of global model training, massive storage, and cross-site coordination — hence the two form a complementary division of labor. On a smart camera, frame-level motion detection and person recognition typically run on the device, and only alert clips plus low-resolution thumbnails go to the cloud, so raw video streams mostly never leave the premises. This tiered filtering cuts uplink bandwidth demand by orders of magnitude and keeps local functions usable during network outages.
难度 进阶 · 适合 大众
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：本题原挂出处与答案内容不符，已撤回；具体书目待补，暂不展示来源。
本题原挂出处与答案内容不符，已撤回；具体书目待补。
Previous citation withdrawn as unsupported for this answer; a specific source is pending.
#边缘计算 #数据分级过滤
Kubernetes 为什么选择声明式API加控制循环，而不是提供一条条按序执行的部署命令？这种方式在大规模集群管理上优势何在？
Why does Kubernetes adopt declarative APIs with control loops instead of step-by-step imperative deployment commands, and what advantage does that bring to managing clusters at scale?
用户只提交期望状态，比如某个服务始终保持五个副本，控制器则负责让集群实际状态持续向期望值收敛，而不是逐条执行写死步骤的部署脚本。控制循环不停对比期望与实际，一旦出现偏差就执行一次幂等的调谐动作，进程崩溃或节点宕机后系统都会被自动拉回正轨，这正是自愈能力；期望状态集中存放并可纳入版本管理，变更可审计、可回滚，大规模集群的日常运维因此不必再靠人工记住操作顺序。
You declare a target state, say five replicas of a service, and controllers continuously steer the actual cluster toward it instead of running a deployment script whose every step is hard-coded. Beneath sits the reconciliation loop: it keeps diffing desired against actual state and applies one idempotent corrective action whenever they drift apart, so crashed processes or dead nodes get pulled back automatically — that is self-healing. Desired state lives centrally and can be version-controlled, keeping changes auditable and revertible, which frees large-scale operations from memorizing sequences of manual steps.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 已核验 · Verified 2026-11-03
来源 · Source
K. Hightower、B. Burns 与 J. Beda，《Kubernetes: Up and Running》，O'Reilly Media，2017年；B. Burns 等，Borg, Omega, and Kubernetes，Communications of the ACM 第59卷第5期，2016年
K. Hightower, B. Burns and J. Beda, Kubernetes: Up and Running, O'Reilly Media, 2017; B. Burns et al., Borg, Omega, and Kubernetes, Communications of the ACM 59(5), 2016
独立核验依据 · Independent verification: 核验依据 1 OPENLIBRARY 标识 /works/OL21364155W：Kubernetes - Up and Ru
#声明式API #控制循环 #自愈
什么是“微服务”？
What are 'microservices'?
微服务把一个大软件拆成许多小而独立的小服务，各管一摊（如登录、支付、搜索），彼此用网络沟通。这样哪块要改或要扩容，只需动那一块，不像“巨无霸”程序那样牵一发动全身。
Microservices split a big app into small independent services (login, payment, search…) that talk over the network. You can change or scale just one piece without disturbing the whole, unlike a monolithic program.
难度 入门 · 适合 小学低段(6-8)
CC BY 4.0 · 已核验 · Verified 2026-08-23 · 2 条独立证据
来源 · Source
Tanenbaum & Bos,《Modern Operating Systems》第4版,Pearson,2014
A. S. Tanenbaum and H. Bos, Modern Operating Systems, 4th ed., Pearson, 2014
独立核验依据 · Independent verification: 核验依据 2 OPENLIBRARY 标识 /works/OL1970688W：Modern Operating System
#微服务 #架构
弹性伸缩（Auto Scaling）如何工作？
How does auto scaling work?
弹性伸缩按 CPU、请求量等指标自动增减实例数量：超过阈值扩容保性能，低于阈值缩容省成本，通常配合健康检查剔除故障节点。
Auto scaling adds or removes instances based on metrics like CPU or request rate—scale out above threshold for performance, scale in below to save cost—often with health checks to drop bad nodes.
难度 入门 · 适合 大众
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：著录仅给书名，无版次与年份；同一书名常对应多个版次，不臆测具体版本。
Amazon Web Services,《Amazon EC2 Auto Scaling User Guide》(AWS 官方文档)
Amazon Web Services, Amazon EC2 Auto Scaling User Guide (AWS documentation)
#云 #扩展
云存储就是把文件存到很远处的电脑里吗？
Is cloud storage just keeping files on a far-away computer?
可以这么理解：你的照片和文件被保存到互联网另一端的数据中心，并通过账号随时取回，数据通常还会自动备份多份以防丢失。
Roughly yes: your photos and files are saved in a data center far away and retrieved anytime via your account, usually with automatic backups so they don't get lost.
难度 入门 · 适合 幼儿(3-6)
CC BY 4.0 · 已核验 · Verified 2026-11-04
来源 · Source
Mell, Grance,《The NIST definition of cloud computing》,NIST 特别出版物 800-145, 美国商务部,2011 (DOI: 10.6028/nist.sp.800-145)
Mell, Grance, 'The NIST definition of cloud computing', NIST Special Publication 800-145, U.S. Department of Commerce, 2011, DOI: 10.6028/nist.sp.800-145
独立核验依据 · Independent verification: 核验依据 1 Crossref DOI 10.6028/nist.sp.800-145
#云 #存储
网站发布新版本时，为什么不把所有服务器一口气换成新版，而是先让一小部分用户试用金丝雀实例，盯紧指标确认无误后再逐步放量？
When releasing a new version, why do websites avoid upgrading every server in one go and instead route a small share of users to canary instances, watching metrics carefully before gradually widening the rollout?
因为再充分的预发测试也覆盖不了真实生产环境的全部状况，小流量先行能把未知缺陷的影响面限制在一小批用户身上。新版上线先承接百分之几的请求，与旧版并行运行；平台持续对比错误率、延迟、转化率等关键指标，一旦偏离历史基线就自动切回旧版，绝大多数用户毫无察觉；指标平稳则逐级放大流量直至全量。发布由此从一锤子买卖变成可观测、可随时逆转的常规操作，配合灰度路由还能顺带完成A/B对照实验。
However thorough pre-production testing is, it never covers everything a live environment will throw at the software; sending a trickle first confines any unknown defect to a handful of users. The new build starts by serving a few percent of requests alongside the old one; the platform keeps comparing error rates, latency and conversion against historical baselines, and rolls back automatically the moment numbers drift, leaving most users untouched. Steady metrics earn progressively larger traffic shares until full rollout. Releases stop being all-or-nothing gambles and become observable, reversible routines — and gray routing doubles as an A/B experiment for free.
难度 入门 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-10-04
来源 · Source
J. Humble 与 D. Farley，《Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation》，Addison-Wesley，2010年；B. Beyer 等，《Site Reliability Engineering: How Google Runs Production Systems》，O'Reilly Media，2016年
J. Humble and D. Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley, 2010; B. Beyer et al., Site Reliability Engineering: How Google Runs Production Systems, O'Reilly Media, 2016
独立核验依据 · Independent verification: 核验依据 1 ISBN 9780321670229 (2010)
#金丝雀发布 #灰度放量 #自动回滚