微服务架构热度已过：从狂热到理性的架构选型之路

微服务架构热度已过：从狂热到理性的架构选型之路

更多问题讨论和资料获取，请关注文章最后的微信公众号

引言

还记得几年前吗？微服务简直是技术圈的"当红炸子鸡"。不管什么项目，上来就先选微服务架构，好像不用就显得自己技术栈落后、不够专业。

但最近这两年，风向变了。越来越多的团队开始重新审视单体架构的价值。这不是技术倒退，而是大家终于想明白了------架构选型不能跟风，得看实际需求。

ThoughtWorks 在 2020 年的技术雷达里就明确提出：不要从微服务开始[23]。这个建议，现在看来真是说到点子上了。

微服务热潮的兴起与现状

曾经的狂热

2015 年到 2019 年那会儿，微服务真的是火得一塌糊涂。Spring Cloud、Dubbo 这些框架大行其道，Netflix、阿里巴巴的成功案例被到处传播。一时间，微服务仿佛成了包治百病的神药：

• 业务解耦，每个服务独立开发部署
• 技术栈随便选，想用什么用什么
• 弹性扩展，哪里不够扩哪里
• 团队自治，各管各的

在这种氛围下，连很多小项目、个人项目都跃跃欲试，觉得不用微服务就 out 了。

Martin Fowler 在 2014 年发表的文章《Microservices》[1]算是奠基之作。他当时就提醒过：微服务不是银弹，它带来了分布式系统的所有复杂性。可惜那时候大家都在追热度，这话没多少人听进去。

看看 Netflix，人家确实把微服务做成功了。但你得想想，人家有多少用户？全球数亿用户啊！而且 Netflix 的 DevOps 能力也是顶级的。Netflix 的技术博客[2]详细记录了这一过程，成为业界学习的标杆。这种成功案例，对大多数团队来说，看看就好，真要学，得先问问自己有没有那个条件。

当前的冷静

等到真正落地实践了，很多团队才发现事情没那么简单：

• 分布式系统的复杂性，不是说着玩的
• 运维压力陡增，得搭一套完整的基础设施
• 服务之间调用，网络开销不小
• 调试起来特别费劲，调用链路追踪是个麻烦事
• 分布式事务？那更是个坑

这些问题暴露出来后，大家开始反思：我们真的需要微服务吗？

有篇论文专门研究了这个问题，《To Microservices or Not to Microservices?》[3]，结论挺有意思：微服务带来的好处，在很多场景下被它引发的问题抵消了。建议团队在决定前，先好好做个成本收益分析。

有个概念叫"分布式单体"（Distributed Monolith），由前 Google 工程师 Steve Yegge 在 2017 年提出[4]，说的是那种盲目拆分微服务的结果------既没有真正解耦，又摊上了分布式系统的所有麻烦。这可不是危言耸听，真有不少项目踩了这个坑。

回归单体架构的原因

1. 大多数项目规模有限

现实很骨感------绝大多数项目，根本不需要微服务：

• 日活几千到几万，这已经是大多数项目的水平了
• 团队规模？3-10 个人的团队最常见
• 业务复杂度？大部分场景用模块化单体就能搞定
• 发布频率？两周一次就够呛了

根据 Stack Overflow 2023 年开发者调查报告[5]，超过 70% 的开发者在 50 人以下的团队，80% 的项目用户规模在 10 万以下。这些数据说明什么？大多数项目压根不需要微服务的分布式能力。

Martin Fowler 在《MonolithFirst》[6]文章中早就说过：几乎任何从零开始构建系统的项目，都应该从单体架构开始。只有当系统真的够复杂、团队真的够大了，再考虑拆分。这话现在看来，真是太对了。

2. 微服务的隐藏成本被低估

当时大家只看到了好处，没看到背后的一堆成本。

基础设施成本

得搭这些东西：

• 服务注册与发现（比如 Nacos、Consul）
• 配置中心
• API 网关
• 链路追踪系统
• 日志聚合平台
• 监控告警系统

开发维护成本

这些事也跑不了：

• 服务间通信协议怎么设计？
• 接口版本怎么管理？
• 分布式事务怎么处理？
• 服务降级、熔断怎么搞？
• 数据一致性怎么保障？

这些成本，在小型项目里往往得不偿失。

Google 工程师 Jeffrey Dean 和 Luiz André Barroso 在论文《The Tail at Scale》[7]中专门分析了分布式系统的尾延迟问题。他们指出：在分布式系统里，一个慢请求会拖慢整个系统。这在微服务架构里尤其明显。

Uber 在其技术博客[8]中也分享过他们的经验------管理数千个微服务需要投入大量工程资源。他们达到那个规模，投入才值得。规模不够的团队，这笔账算不过来。

还有篇论文《Microservices: Yesterday, Today, and Tomorrow》[9]说得更直白：微服务架构想成功，得有三个前提------快速部署基础设施、完善的监控体系、成熟的团队组织。缺一个，微服务都可能变成负担。

3. 单体架构的演进

现在的单体架构可不是以前那种"大泥球"了，已经进化了不少：

• 模块化设计，边界清晰
• 分层架构，职责分明
• 用 DDD 思想做领域划分
• 插件化扩展
• Docker 容器化部署

这种"模块化单体"，既简单又好维护。很多人可能不知道，DDD（领域驱动设计）最早就是用来解决单体架构的复杂度问题的。Eric Evans 在《领域驱动设计》[10]一书中提出，通过限界上下文（Bounded Context）划分，单体应用内部也能保持清晰的业务边界，未来真要拆分服务也容易。

《Building Microservices》[11]这本书的作者 Sam Newman 说过：微服务架构不应该成为默认选择。他建议用"绞杀者模式"（Strangler Pattern），渐进式地从单体演进到微服务。也就是说，别上来就拆，等项目真的需要了再拆。

微服务架构并未过时

得说明白一点：微服务热度下降不等于它过时了。正好相反，这说明大家对微服务的认识更成熟了。

微服务的适用场景

微服务依然有它的价值，但得用在合适的地方。

超大规模系统

• 用户量百万、千万级别
• 业务领域复杂，模块边界清晰
• 团队规模庞大（50+开发人员）
• 业务模块需要独立迭代

典型场景

• 电商平台（用户、商品、订单、支付等服务）
• 社交应用（用户、消息、动态、推荐等服务）
• 金融系统（账户、交易、风控、清算等服务）

像淘宝、支付宝、微信这些，用微服务是合适的。但问题是，你做的项目，真有这个规模吗？

技术演进的必然规律

任何技术都会经历"Gartner技术成熟度曲线"：

1. 技术萌芽期：新技术出现，引发关注
2. 期望膨胀期：过度宣传，期望过高
3. 泡沫破裂低谷期：问题暴露，热度下降
4. 稳步爬升恢复期：理性认识，逐步成熟
5. 生产成熟期：广泛应用，成为主流

微服务正在从第2阶段走向第4阶段，这是技术走向成熟的标志，不是过时的征兆。

根据场景选择架构

架构选型的原则

1. 简单优先

能用简单方案解决的问题，绝不使用复杂方案。架构设计的首要目标是解决问题，不是炫技。

Robert C. Martin 在《架构整洁之道》[12]这本书里说得好：软件架构的首要目标是降低构建和维护系统的成本。过度复杂的架构，恰恰相反。

还有个 KISS 原则（Keep It Simple, Stupid），简单的设计往往比复杂的设计更可靠、更好维护。这个原则虽然听着简单，但真做起来不容易，尤其是当你手头有一堆新技术想尝试的时候。

2. 演进式架构

架构应该随着业务发展而演进，别想着一步到位。不要试图预测未来的所有需求。今天的架构解决今天的问题，同时给明天留点空间就行。

Neal Ford 等人在《演进式架构》[13]一书中提出：架构应该是可演进的，应该为未来的变化做好准备，而非试图预测未来。极限编程（XP）创始人 Kent Beck 也说过："先让它工作，再让它正确，最后让它快速。"这话用在架构选型上也合适：先用简单的架构让业务跑起来，再根据实际需求优化和演进。

3. 成本收益平衡

架构选型要权衡收益与成本，选性价比最高的方案。

多项研究表明，微服务架构的开发和维护成本平均比单体架构高出 30%-50%。只有在用户规模、团队规模、业务复杂度达到一定程度时，这些额外成本才能被收益抵消。

Google 在《Software Engineering at Google》[14]这本书里强调：最简单的架构往往是最好的架构，因为它更容易理解和修改。

不同规模的架构选择

给你个简单的参考表：

项目规模	团队人数	用户规模	推荐架构
小型项目	1-5人	<10万	模块化单体
中型项目	5-20人	10-100万	模块化单体或服务化单体
大型项目	20-50人	100-1000万	部分核心业务拆分
超大型项目	50+人	>1000万	微服务架构

架构选型的决策流程

说到底，架构选型就是问自己几个问题：

1. 当前业务规模和复杂度如何？
2. 未来 1-2 年业务会怎么增长？
3. 团队规模和技术能力够不够？
4. 基础设施和运维能力跟得上吗？
5. 成本和收益算过账吗？

这些问题想清楚了，架构选择其实不难。难的是克服"我想用新技术"的冲动。

架构演进之路

从单体到微服务的演进

架构不是一成不变的，应该随着业务发展而演进。一般会经历这几个阶段：

阶段一：单体架构

• 快速验证业务想法
• 团队规模小，沟通成本低
• 部署简单，调试方便
• 专注业务功能开发

阶段二：模块化单体

• 业务模块边界清晰
• 模块间通过接口通信
• 为未来拆分做准备
• 团队规模增长

阶段三：服务化单体

• 核心业务模块独立部署
• 部分服务拆分出去
• 引入基础的服务治理能力
• 团队分工明确

阶段四：微服务架构

• 业务模块全面拆分
• 完善的微服务基础设施
• 团队规模大，独立交付
• 业务复杂度高

演进的时机

什么时候该拆分了？看这几个信号：

• 部署冲突频繁，不同模块需要独立发布
• 扩展瓶颈明显，部分模块需要独立扩展
• 团队协作困难，团队规模大，协调成本高
• 业务边界清晰，领域边界已经明确

过早拆分的风险

• 增加系统复杂度
• 引入不必要的分布式问题
• 增加运维负担
• 降低开发效率

所以，别着急拆，等真有需要了再拆。

案例分析

成功的单体架构案例

Shopify

日处理数十亿请求，起初就是单体架构。后来通过 Ruby on Rails 模块化设计，逐步演进，核心服务还是单体。Shopify 工程团队在《Deconstructing the Monolith》[15]一文中详细描述了这个过程。他们的哲学很简单："能不拆就不拆，必须要拆才拆"。最终也只有少数核心服务被拆分出去。

Stack Overflow

你可能想不到，Stack Overflow 也是单体架构。支撑了每秒数百次请求、每月数十亿 PV 的流量。Stack Overflow 在《Why Stack Overflow Doesn't Use Microservices》[16]一文中明确表示，他们的架构师 Nick Craver 说过："微服务不是性能问题的解决方案，良好的数据库设计、缓存策略和代码优化才是。"

Basecamp

Basecamp 用单体 Rails 应用服务了数百万用户，证明了单体架构完全可行。创始人 DHH（David Heinemeier Hansson）在《重来》[17]这本书里反复强调：简单的架构优于复杂的架构。

从微服务回归单体的案例

Ingenious

这个团队经历了从微服务回归单体的过程。Ingenious 的技术团队在《Goodbye Microservices: From 100s of problem children to 1 superstar》[18]一文中详细记录了这个过程。原因很简单：复杂度过高，团队规模小，撑不住。回归单体后，开发效率提升了 3 倍，部署时间从几小时缩短到几分钟。

Segment

Segment 最初为了解决扩展问题转向微服务，结果发现分布式事务、服务间通信、调试等问题严重影响了开发效率。Segment 的工程团队在《Goodbye Microservices》[19]一文中详细描述了这一历程。最后重构回单体架构，运维负担减少了 90%，工程师终于可以专心写业务逻辑了，不用整天折腾基础设施。

Eventuate

Chris Richardson 是微服务布道者，但他后来也反思：分布式数据管理是微服务架构最大的挑战之一，很多团队低估了这个问题[20]。在业务边界不清晰、数据一致性要求高的场景下，单体架构反而更务实。

个人实践案例：医疗项目的架构选型反思

说个我自己的亲身经历，可能更能说明问题。

项目背景

• 技术栈：基于 pigx 微服务框架开发
• 业务领域：医疗管理系统
• 架构选择：微服务架构（用户服务、权限服务、医疗业务服务等）
• 团队规模：5-8 人

实际问题

上线后几年内，实际使用用户量很少，根本不需要分布式架构。但微服务架构需要部署注册中心、配置中心、网关、多个业务服务等组件，资源占用大。

为了节省云服务器成本，我们将所有微服务组件都部署到了同一台服务器上。

矛盾与代价

这种"伪微服务"架构带来的问题很严重：

1. 违背了微服务的初衷------微服务强调独立部署、独立扩展，但所有服务挤在一台服务器上，完全丧失了这些优势

2. 维护成本增加：

   • 要维护 Nacos 注册中心、Sentinel 熔断器、Gateway 网关等基础设施
   • 服务间调用要经过网络通信，排查问题更难了
   • 日志分散在多个服务里，调试时得在多个服务间跳转

3. 资源占用依然高------即使部署在一台服务器上，多个 JVM 实例、数据库连接池、基础设施组件依然占用大量内存

4. 开发效率低------每次启动要等好几个服务依次启动，本地开发调试特别耗时

反思与改进

项目后期，我们深刻认识到：

• 架构选型失误：医疗项目的用户规模、业务复杂度完全不需要微服务架构
• 过度设计：为了"技术先进"而选择了微服务，但实际收益为零
• 成本倒挂：维护成本远超单体架构，却没获得任何收益

最终，我们计划将项目重构为单体架构，预计可以：

• 减少 60% 以上的服务器资源占用
• 降低 70% 的维护成本
• 提升 50% 以上的开发调试效率
• 部署流程从"部署 10+ 个服务"变为"部署 1 个应用"

这次经历让我深刻认识到：架构选型必须基于实际需求，不能跟风。一个日活几百用户的系统，用单体架构完全够用。为了"微服务"而微服务，只会给自己找麻烦。

最佳实践建议

对于新项目

1. 从单体开始，别想太多
2. 模块化设计，按领域边界组织
3. 保持架构层次清晰
4. 为未来拆分预留接口抽象
5. 持续重构，保持代码质量

对于已有项目

1. 理性评估当前架构的问题
2. 找出真正的痛点
3. 渐进式改进，别搞大规模重构
4. 适时拆分，识别需要独立的服务
5. 完善基础设施，为拆分做好准备

团队能力建设

基础能力

• 代码设计与重构
• 数据库设计与优化
• 测试与持续集成

进阶能力

• 领域驱动设计（DDD）
• 分布式系统设计
• 服务治理与监控

决策能力

• 架构评估
• 技术选型
• 演进规划

说到底，架构能力不是一天两天能练出来的，需要在实践中不断积累。

总结

微服务架构热度下降，反映的是行业认知的成熟。大家不再盲目追风，而是理性地认识到：

1. 架构选型没有银弹------每种架构都有其适用场景
2. 简单是最高级的复杂------能用简单方案解决的问题，就不需要复杂方案
3. 架构应该服务于业务------而不是业务迁就架构
4. 演进式架构才是正道------根据业务发展逐步演进

Martin Fowler 说过："You must be this tall to use microservices."（你必须达到这个高度才能使用微服务）

这句话的意思很明确：使用微服务需要相应的团队规模、技术能力和基础设施支持。条件不成熟时，单体架构往往是更明智的选择。

Martin Abbott 和 Michael Fisher 在《扩展的艺术》[21]这本书里提出了"扩展立方体"（Scaling Cube）模型，说系统扩展有多种维度，微服务只是其中一种方式。选择架构时，应该根据业务需求和团队能力，选择最合适的方式，而非盲目追求最先进的技术。

论文《Microservices: A Systematic Mapping Study》[22]对 2014-2017 年间发表的 103 篇微服务相关论文做了系统性综述。研究发现，微服务架构的主要挑战包括：数据一致性（占 36%）、服务发现与通信（占 28%）、测试与部署（占 22%）。论文建议团队在采用微服务前，必须确保具备应对这些挑战的能力。

微服务没有过时，它依然是一种重要的架构模式。只是我们现在更清楚：架构的本质是权衡，是在特定约束条件下做出最优选择，而非盲目追求所谓的"先进技术"。

让我们回归理性，根据实际场景选择最适合的架构。这才是成熟技术团队应有的态度。

---

参考文献

1\] Martin Fowler \& James Lewis. "Microservices: a definition of this new architectural term". martinfowler.com, 2014. \[2\] Netflix Technology Blog. Netflix 微服务架构实践系列文章. medium.com/netflix-techblog \[3\] Amirhossein Vakilzadeh et al. "To Microservices or Not to Microservices?". IEEE International Conference on Software Architecture, 2018. \[4\] Steve Yegge. "Platforms". steve-yegge.blogspot.com, 2017. \[5\] Stack Overflow. "Developer Survey Results 2023". survey.stackoverflow.co, 2023. \[6\] Martin Fowler. "MonolithFirst". martinfowler.com, 2015. \[7\] Jeffrey Dean, Luiz André Barroso. "The Tail at Scale". Communications of the ACM, 2013. \[8\] Uber Engineering. "Why We Switched from Mesos to Kubernetes". eng.uber.com \[9\] Nicola Dragoni et al. "Microservices: Yesterday, Today, and Tomorrow". Springer, 2019. \[10\] Eric Evans. 《领域驱动设计：软件核心复杂性应对之道》. Addison-Wesley, 2003. \[11\] Sam Newman. 《Building Microservices: Designing Fine-Grained Systems》. O'Reilly Media, 2014. \[12\] Robert C. Martin. 《架构整洁之道》. Prentice Hall, 2017. \[13\] Neal Ford, Rebecca Parsons, Patrick Kua. 《Building Evolutionary Architectures》. O'Reilly Media, 2017. \[14\] Titus Winters, Tom Manshreck, Hyrum Wright. 《Software Engineering at Google》. O'Reilly Media, 2020. \[15\] Shopify Engineering. "Deconstructing the Monolith: How We Broke Down Our Massive Rails App". shopify.engineering, 2019. \[16\] Stack Overflow Blog. "Why Stack Overflow Doesn't Use Microservices". stackoverflow.blog, 2015. \[17\] David Heinemeier Hansson. 《重来：更为简单有效的商业思维》. 中信出版社, 2010. \[18\] Ingenious. "Goodbye Microservices: From 100s of problem children to 1 superstar". ingenious.net, 2018. \[19\] Segment Blog. "Goodbye Microservices". segment.com, 2020. \[20\] Chris Richardson. Eventuate 关于微服务数据一致性的系列文章. eventuate.io \[21\] Martin Abbott, Michael Fisher. 《The Art of Scalability》. Addison-Wesley, 2009. \[22\] Paulo Pereira et al. "Microservices: A Systematic Mapping Study". Journal of Systems and Software, 2017. \[23\] ThoughtWorks. "Technology Radar Vol. 21". thoughtworks.com, 2020. *** ** * ** ***