编程与软件工程martinfowler.com编辑精选
单体优先
Monolith First (2015)
2015 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Martin Fowler 的这篇短文提出“单体优先”策略：新项目先从一个单体应用开始，等模块边界稳定后再拆分出微服务。他基于观察认为，微服务更适合作为从成功单体中逐步演化的产物，而非新项目的起点。
为什么经久不衰：在微服务热潮中冷静反思架构选择，多年后仍是团队讨论“该不该上微服务”时被反复引用的经典。
HN 评论精选
先修好单体再考虑拆分，重写救不了烂架构
更常见的情形是：单体积累了大量概念债，团队渴望改变，于是有人用微服务的美好愿景说服大家重写。结果团队面临一堆新问题：概念债并没有消失，还要重新发现旧系统里没文档的正确逻辑、承担 POC 阶段看不出来的微服务开销，同时保证业务连续。我的建议是先修好你的单体——如果连单体都重写不好，换架构重写的成功率又能有多少？之后按康威定律，把一块职责交给专门团队，再拆成微服务或独立服务。
ser0查看英文原文
A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team. A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of microservices. The team buys into the pitch and looks forwards to a happily-ever-after ending. The reality though is that the team now has multiple problems, which include: - Addressing conceptual debt that hasn't gone away. - Discovering and migrating what the legacy system got right, which is often not documented and not obvious. - Dealing with the overheads of microservices that were not advertised and not prominent at a proof-of-concept scale. - Ensuring business continuity while this piece of work goes on. I would propose alternative is to fix your monolith first. If the team can't rewrite their ball of mud as a new monolith, then what are the chances of successfully rewriting and changing architecture? Once there is a good, well functioning monolith, shift a subset of responsibility that can be delegated to a dedicated team - the key point is to respect Conway's law - and either create a microservice from it or build a new independent monolith service, which aligns more to service oriented architecture than microservices.
真实案例：140 个微服务合并成单体后效率与可靠性大幅提升
我帮一家大银行把 140 个服务合并成一个单体：团队缩到三分之一但效率大增，可靠性显著改善。我加入时目睹连续 6 次失败部署，每次要一周准备、整个周末执行（40 人电话会议）；离开时是连续 50 次成功部署，1 小时准备、1 名工程师 2 小时完成。拆分必然带来管理多个东西的低效，你的员工在管理应用而不是写业务逻辑。想上微服务，必须清楚收益能否超过成本，否则就是在坑项目。
lmilcin查看英文原文
Hahaha. I have been saying the same for years but have either been punished by my managers or mercilessly downvoted on HN. Somehow mentioning that microservices might not be perfect solution in every case triggers a lot of people. I have actually helped save at least one project in a huge bank which got rolled from 140 services into one. The team got also scaled down to third of its size but was able to work on this monolithic application way more efficiently. Also reliability, which was huge issue before the change, improved dramatically. When I joined, I have observed 6 consecutive failed deployments. Each took entire week to prepare and entire weekend to execute (with something like 40 people on bridge call). When I left I have observed 50 consecutive successful deployments, each requiring 1h to prepare (basically meeting to discuss and approve the change) and 2h of a single engineer to prepare and execute using automation. Most projects absolutely don't need microservices. Breaking anything apart brings inefficiencies of having to manage multiple things. Your people now spend time managing applications rather than writing actual business logic. You have to have really mature process to bring those inefficiencies down. If you want to "do microservices" you have to precisely know what kind of benefits you are after. Because the benefits better be higher than the costs or you are just sabotaging your project. There are actually ways to manage huge monolithic application that don't require each team to have their own repository, ci/cd, binary, etc. How do you think things like Excel or PhotoShop have been developed? It is certainly too large for a single team to handle.
单体/微服务的二分法过于宽泛，按用例设计而非贴标签
“单体 vs 微服务”的二分法本身没意义。你描述你的“微服务”，我会证明它其实就是单体：分开部署？那是分布式单体。各自管数据库？那就是两个单体。这些术语太宽泛，“单体”通常描述代码依赖，“微服务”描述数据依赖，两者大量重叠。按你的实际用例设计和实现系统，别纠结标签。
kingdomcome50查看英文原文
The problem with creating a dichotomy between "monolith" and "microservices" is that... well... it doesn't make any sense. You describe your "microservices" and I'll explain how it's really just a monolith. "So let me get this straight, you have a Billing package and an Ordering package. How are these organized again?" -> "We have a distributed system." "So you you compile them together and deploy them horizontally across many machines? Like a distributed monolith?" -> "No we use microservices. The two packages are compiled and deployed separately so there is no code dependencies between them." "Okay. So if I understand this right, you develop each package separately but they both access the same database?" -> "No no no no! Microservices are not just about code dependency management, they are also about data ownership. Each package is developed and deployed separately and also manages it own database." "Ah, so you have two monoliths?" -> "..." You see the problem is that the above terms are too broad to describe anything meaningful about a system. And usually "monolith" is used to described the dependencies between code whereas "microservices" is used to describe dependencies about data. It turns out there is a lot of overlap. Design and implement your systems according to your use-case and stop worrying about how to label them.
亲历案例：微服务改单体后性能、可靠性、可维护性全面胜出
2003/2004 年我在 BBC 把一个“微服务”架构改成了单体，结果快了约 100-1000 倍，代码量只剩零头，从十几台机器降到 1 台，更易维护，几年内几乎零故障（原来每天故障数次），部署简单到复制一个 jar 就行。
mpweiher查看英文原文
I had great success converting a "microservices" architecture to a monolith at the BBC back in 2003/2004. The result was ~100-1000 times faster (speed was an issue with the original), had a fraction of the code, used 1 machine instead of a dozen, was more maintainable, had effectively zero failures over several years versus several a day, was trivial to install (copy this jar over here) etc.
历次讨论
同类还值得读
开源应用架构
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编辑精选