编程与软件工程blog.bradfieldcs.com编辑精选
你不是 Google（2017）
You Are Not Google (2017)
2017 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章提醒开发者：不要盲目照搬 Google 等大公司的技术栈。绝大多数网站的流量远低于 Stack Exchange（每天 2 亿次请求仅靠四台 SQL 服务器支撑），简单方案往往足够，选型前应真正思考问题本身，而不是追逐时髦的分布式系统。
为什么经久不衰：它戳中了行业长期存在的'过度工程'痛点，用 Stack Exchange、Wikipedia 等实例证明简单架构能扛住巨大流量，对今天做技术选型依然是一剂清醒剂。
HN 评论精选
Stack Exchange 的实例证明绝大多数网站的负载远低于想象，简单数据库足够。
文章里最有启发的一段：截至 2016 年，Stack Exchange 每天处理 2 亿次请求，背后只有四台 SQL 服务器——一个主库服务 Stack Overflow，一个主库服务其余站点，外加两个副本。它今天的 Alexa 排名是全球第 48，所以无论你的网站是什么，负载大概率没它高。
chadash查看英文原文
> As of 2016, Stack Exchange served 200 million requests per day, backed by just four SQL servers: a primary for Stack Overflow, a primary for everything else, and two replicas. This was the most enlightening piece of the article for me. Their alexa rank today is 48 (globally, 38 in U.S.), so whatever your site is, you are probably not dealing with as heavy a load as them. What techniques do you have to employ to serve this many requests from a single database server?
容错架构是为大规模设计的，小规模使用反而增加故障风险。
值得注意的一点：在大规模下最小化故障概率的系统，往往不是在小规模下最小化故障的系统。大规模（成百上千万节点）时最常见的故障是单节点失效，需要复杂的容错系统；小规模（一两台服务器能搞定）时故障主要来自系统本身，引入复杂系统反而会推高故障率，尤其是在没有大团队维护的情况下。
ummonk查看英文原文
Good example for which I’d highlight a particular thing to note: The kinds of systems that minimize failure probability at a large scale are often not the kinds of systems that minimize failure at a small scale. At a large scale (e.g. hundreds or especially millions of hardware nodes) the most common faults will be due to individual nodes / services / whatever failing, so you want a complex fault tolerant system to deal with those faults. At a small scale (e.g. stuff that can fit on one or several servers) the most common faults are from the system itself, not from individual nodes. Here, using a complex system will drive up the likelihood of failures, especially when you don’t have a large team to manage the system.
托管/无服务器服务的真正价值在于免除运维负担，而非规模。
人们说'为什么用 Dynamo 不用 SQL''为什么用 Hadoop，bash 脚本更快'时忽略了一个关键问题：前者是全托管的！这对团队扩展意义重大。SQL 也可以用 RDS 托管，但托管程度不如 Dynamo 或 Firebase，仍需维护调优。我的目标是让支撑应用的一切都完全无法 SSH 进去——不是因为不想，而是物理上做不到。这就是无服务器的未来：不是因为能支撑海量规模，而是因为受够了运维、受够了担心 OpenSSL 漏洞，我付钱给 Amazon，只管做产品。
013a查看英文原文
The big issue I think we miss when people say "why are you using Dynamo, just use SQL" or "why are you using hadoop, a bash shell would be faster" or "why are you using containers and kubernetes, just host a raspberry pi in your closet": The former examples are all managed! That's amazing for scaling teams. (SQL can be managed with, say, RDS. Sure. But it's not the same level of managed as Dynamo (or Firebase or something like that). It still requires maintenance and tuning and upkeep. Maybe that's fine for you (remember: the point of this article was to tell you to THINK, not to just ignore any big tech products that come out). But don't discount the advantage of true serverless.) My goal is to be totally unable to SSH into everything that powers my app. I'm not saying that I want a stack where I don't have to. I'm saying that I literally cannot, even if I wanted to real bad. That's why serverless is the future; not because of the massive scale it enables, but because fuck maintenance, fuck operations, fuck worrying about buffer overflow bugs in OpenSSL, I'll pay Amazon $N/month to do that for me, all that matters is the product.
简历驱动的开发是技术过度采用的重要推手。
这篇文章和评论都漏掉了一点：开发者选择这些技术是因为它们时髦、能帮自己找到下一份工作。'用 Hadoop、MapReduce 和 GCP 做欺诈检测'和'用 MySQL 加一些简单的统计方法做欺诈检测'，哪个开发者明年更可能拿到六位数薪水？这是这些东西出现在不该出现的地方的重要原因。作为一个总是先选最简单方案、40 岁还没挣到 10 万美元的开发者，我现在晚上都在琢磨怎么把最新技术部署到完全不需要的地方。
thaumaturgy查看英文原文
What this article, and the comments on it at the moment, are missing is that developers choose many of these technologies because they are sexy and will help the developer get their next job. Which of the following two developers has the better chance of breaking six figures next year: "Used Hadoop, MapReduce, and GCP for fraud detection on..." ...or... "Used MySQL and some straightforward statistics for fraud detection on..." This is a big part of why all these things exist in places where they shouldn't. As a dev that always goes for the simplest solution first and has yet to break a hundred k at 40 ... I'm spending my evenings now trying to figure out how to deploy the latest technologies where they're totally not needed.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选