编程与软件工程craigkerstiens.com
把我的单体架构还给我
Give Me Back My Monolith
2019 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 2019 年的文章以作者自身的工程经验反思微服务热潮，呼吁在合适场景回归单体架构。核心观点是：微服务并非默认更优的选择，对小团队和早期产品而言单体更简单高效；只有当组织规模和系统复杂度增长到单体成为瓶颈时，拆分才有意义。
为什么经久不衰：微服务与单体的争论每隔几年就随技术潮流重演，这篇文章代表了「先单体、按需拆分」的务实立场，对今天仍被过度工程困扰的团队是一剂清醒剂。
HN 评论精选
单体适合小团队起步，微服务应在组织和软件规模增长、单体成为瓶颈后再引入。
我不觉得这该怪作者。除非你就是想证明自己能构建微服务应用，否则我想不出为什么要从微服务开始。当你一开始说的是一个小服务时，单体搭建起来更快也更容易。只有当组织成长、软件成长，单体开始变得笨重难管时，转向微服务才说得通；也正是那时，微服务在工程和组织层面的优势才真正帮上忙。三个工程师编排 25 个微服务，在我看来简直疯了。三十人的团队把一个单体拆成 10 个微服务，再分成 10 个三人团队、各自负责维护一个服务，这才是微服务想要的场景。
padobson查看英文原文
I don't think I blame the author at all. I'm not sure why you would start with microservices, unless you wanted to show that you could build a microservices application. Monoliths are quicker and easier to setup when you're talking about a small service in the first place. It's when an organization grows and the software grows and the monolith starts to get unwieldy that it makes sense to go to microservices. It's then that the advantage of microservices both at the engineering and organizational level really helps. A team of three engineers orchestrating 25 microservices sounds insane to me. A team of of thirty turning one monolith into 10 microservices and splitting into 10 teams of three, each responsible for maintaining one service, is the scenario you want for microservices.
把单体拆成服务只是「分布式单体」；真正的微服务要能独立部署和变更，否则只增加复杂度和成本。
我在某种程度上同意作者。但关键在于，很多人以为把单体拆成服务，自己就有了微服务。不，你没有，你得到的是一个分布式单体。你能独立部署这些服务吗？不能？那你就没有微服务。你能改一个微服务的数据存储然后顺利部署吗？如果你改一个表结构现在就得部署多个服务，那它们就不是微服务。所以，你拿一个单体，把它拆开，加个消息代理、集中式日志，也许再部署到 K8s 上，然后你实现了……什么也没有。至少，没有任何能帮到业务的东西，只是更多复杂度和一大堆需要管理、可能出错的东西。而且占用很可能大得多：现在每个无聊的 hello world 应用都想要 8GB 内存和自己的数据库。所以你还增加了成本，而这一切，一条 CI/CD 流水线加上合理的开发和部署实践本来就能做到。
outworlder查看英文原文
I agree with the author to some extent. The main thing, however, is many people think that, by breaking up their monolith into services, that they now have microservices. No, you don't. You have a distributed monolith. Can you deploy services independently? No? You don't have microservices. Can you change one microservice data storage and deploy it just fine? If you are changing a table schema and you now have to deploy multiple services, they are not microservices. So, you take a monolith, break it up, add a message broker, centralized logging, maybe deploy them on K8s, and then you achieve... nothing at all. At least, nothing that will help the business. Just more complexity and a lot more stuff that need to be managed and can go wrong. And probably a much bigger footprint. Every stupid hello world app now wants 8GB of memory and its own DB for itself. So you added costs too. And accomplished nothing a CI/CD pipeline plus sane development and deployment practices wouldn't have achieved. It is also sometimes used in lieu of team collaboration. Now everyone can code their own thing in their own language without talking to anyone else. Except collaboration is still needed, so you are accruing tech debt that you know nothing about. You can break interfaces and assumptions, where your monolith wouldn't even compile. And now no-one understands how the system works anymore. Now, if you are designing a system using microservices properly, then it can be a dream to work on, and manage in production. But that requires good teamwork on each team and good collaboration between teams. You also need a different mindset.
微服务像当年的 OOP 狂热，只有组织分工和特殊硬件扩展两个合理理由，它不会带来性能提升，行业在盲目跟风、重复犯错。
我刚开始做职业编程时，是「面向对象设计将拯救我们所有人」的时代。我做过一个电商网站，为了在页面上渲染一个产品，类继承层次有 18 层深。没人知道那些层都是干什么的，但它确实又复杂又慢得要命。现在对微服务的痴迷在很多方面感觉是一样的。使用微服务似乎恰好只有两个理由：1. 你的公司需要 API 来界定对特定功能的职责，通常发生在团队变大时；2. 你有一组功能需要特定硬件来扩展，比如 GPU、大内存、高性能本地磁盘，那时作为单体来扩展可能就不合理了。有一件事你肯定得不到，那就是性能：你要把进程内共享内存的函数调用变成序列化的网络调用，然后它会更快？这话太疯狂了。那我们为什么还要做？1. 因为我们追随大科技公司的脚步，因为他们有伟大的工程师，但不幸的是他们面对的问题和我们非常不同。2. 这个行业的平均经验年限相当低，我已经见过两次这种周期了，我们就是不断重复同样的错误。
matt2000查看英文原文
When I started programming professionally it was the era of "Object Oriented Design" will save us all. I worked on an e-commerce site that had a class hierarchy 18 levels deep just to render a product on a page. No one knew what all those levels were for, but it sure was complicated and slow as hell. The current obsession with microservices feels the same in many ways. There appear to be exactly two reasons to use microservices: 1. Your company needs APIs to define responsibility over specific functionality. Usually happens when teams get big. 2. You have a set of functions that need specific hardware to scale. GPUs, huge memory, high performance local disk, etc. It might not make sense to scale as a monolith then. One thing you sure don't get is performance. You're going to take an in-process shared-memory function call and turn it into a serialized network call and it'll be _faster_? That's crazy talk. So why are we doing it? 1. Because we follow the lead of large tech companies because they have great engineers, but unfortunately they have very different problems then we do. 2. The average number of years of experience in the industry is pretty low. I've seen two of these kinds of cycles now and we just keep making the same mistakes over and over. Anyway, I'm not sure who I'm writing this comment for, I guess myself! And please don't take this as criticism, I've made these exact mistakes before too. I just wish we as an industry had a deeper understanding of what's been done before and why it didn't work.
微服务是解决组织规模问题的方案（康威定律），先做单体再沿边界拆分，比一开始就设计微服务更容易。
微服务一直是为了解决组织问题——让更多开发者同时在一个系统上工作。很多人同时在一个代码库上工作常常引发问题和归属权问题；解决方案是独立开发的服务，代价是一系列东西的复杂度增加。《人月神话》里有一篇讲康威定律，微服务很大程度上就是利用康威定律来实现开发规模扩展的方式。你可能直到规模大到单体真正成为痛点时才需要微服务。通过一些合理的设计努力，你大概能撑到 100 名开发者甚至更多，做大量隔离；但在超过 25 名开发者的某个点上，切换到多个部署单元、处理增加的系统复杂度和接口设计以及固有的版本问题，会变得更便宜也更容易。先做单体、找到正确的设计再沿着边界拆分，比一开始就做出正确的微服务要容易。
PaulKeeble查看英文原文
Microservices was always a solution to the organisational problem of getting more developers working on a system at once. A lot of people working on one code base over the top of each other often causes problems and issues with ownership. The solution was services independently developed with the trade off cost being increased complexity on a range of things. There is an essay in the mythical man month about Conways law and microservices are very much about a way to use Conways law to achieve scale of development. You likely don't need microservice until you hit a scale where the monolith is a real pain point. You can probably cope with a monolith especially with some reasonable design effort up to the 100 developers maybe more with a lot of separation but at some point in the >25 developers range it becomes cheaper and easier to switch to multiple deployed units of software and deal with the increased system complexity and interface designs and the inherent versioning issues it causes. It is easier to start with a monolith, find the right design and then split on the boundaries than it is to make the correct microservices to begin with.
历次讨论
同类还值得读
开源应用架构
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编辑精选