分久必合，合久必分，这句老话在软件开发领域同样适用。微服务架构的设计初衷，本是为了应对用户量巨大（例如百万级以上）、流量极高的极端场景，其架构本身也更加复杂。不仅如此，微服务在带来解耦与独立部署等优势的同时，也伴随着一系列棘手的缺点。
最初的应用程序大多是“monolith application”，国内常称为单体架构。
所谓单体架构，是指整个代码库都打包在一个独立的应用程序中。对于早期的小型项目而言，这非常自然——代码量本身就不大，全部放在一个程序里，开发、测试和部署都相对简单直接。
但随着项目的持续迭代和功能膨胀，即便采用了模块化设计，代码依然容易变得混乱。一个难以避免的问题是，任何一个微小的 Bug 都可能导致“牵一发而动全身”，影响整个系统的稳定性。
于是，微服务架构应运而生。它将一个庞杂的多功能应用，拆分为多个独立部署、各司其职的小型服务。这其中最显著的优点便是故障隔离：一个服务出现 Bug 或宕机，理论上不会导致整个系统崩溃。其次，各个服务可以采用不同的技术栈，进行针对性的优化。在业务增长需要扩容时，也能按需扩展特定的服务模块，显得非常灵活。
大厂的“回归”浪潮
然而，最近一两年出现了一个有趣的现象。从国外的 Basecamp、亚马逊、谷歌，到国内的腾讯，不少大厂开始重新审视甚至回归单体架构的怀抱。这背后的原因是什么？
最初采用微服务的愿景很美好：每个功能独立，修改一处不会波及其他，就像管理源代码文件一样清晰。团队也能明确分工，前端、后端、数据库等各司其职，界限分明。
但现实往往没有设想中那么美好。首先，源代码间的调用几乎是瞬间完成的，而运行时的服务间调用则涉及网络通信、消息队列、复杂的 RPC 或 RESTful 协议，延迟和不确定性大大增加。
其次，微服务系统不像源代码那样，整齐地躺在清晰的目录结构里。它更像一个错综复杂的“大沙盘”，服务间存在隐性的耦合与依赖。新成员加入团队，光是熟悉这些零散的服务和它们之间的关系，可能就需要耗费数周时间。
运维的挑战则更为突出。分布式追踪、链路监控、日志收集的复杂度呈指数级上升，排查一个跨服务的 Bug 犹如大海捞针。整个系统呈现出一种“去中心化的无力感”，让人难以掌控全局。
虽然降低复杂性的一个基本方法是将复杂性隔离——如果能把复杂性局限在一个模块内，不与其他模块交互，就相当于消除了系统的复杂性——但就目前的实践来看，我们对微服务架构的探索还远未成熟到能“优雅地”消除复杂性的程度。
一个具体的场景
让我们设想一个场景：你需要开发一个类似 Notion 的在线协作平台。
核心功能模块可能包括：【身份认证网关】、【实时协同编辑】、【权限解析服务】、【文件存储服务】以及【日志服务】。如果采用微服务架构，你会为每一个模块都独立部署一个服务。
一旦开始实施，挑战接踵而至：你需要设计一套复杂的服务间通信协议，可能是基于 gRPC 的接口，或是引入类似 Nats 这样的消息队列。此外，像“文档保存”这类操作，可能涉及多个服务的数据更新，实现分布式事务将是一个巨大的难题。
更令人头疼的是日常的功能迭代。假设你只想增加一个按钮，点击后显示用户头像。这个看似简单的需求，可能就需要前端、用户服务、权限服务、界面组件四个团队的协同改动与联调。而在单体架构中，这个改动可能一次提交就能完成。
部署流程的差异同样巨大。单体应用部署通常快速直接，而微服务架构的 CI/CD 流水线则需要为众多服务分别构建、测试和部署，整个过程动辄十几分钟甚至更长。同时，每一个独立运行的服务实例都会消耗额外的计算、内存资源，云平台的账单压力不容小觑。
核心矛盾：复杂性并未消失
问题的核心在于，复杂性并没有消失，它只是被转移了。从代码内部的复杂性，转移到了服务编排、网络通信、数据一致性和运维监控上。
相比之下，结构清晰、新人友好的单体架构，对于绝大多数应用场景来说，可能反而是更务实的选择。需要明确的是，单体架构本身并非为了追求极致的“简单”，而微服务架构诞生的核心驱动力，是为了解决超大规模应用（如数百万并发）的高可用与弹性伸缩问题。
当下，像 Rust 和 Go 这类现代编程语言，已经能够支撑起性能极高、资源占用更少的单体应用。对于 99% 的初创公司而言，真正的风险是“没有用户和流量”，而非“流量太大冲垮服务器”。
因此，对于创业团队，一个中肯的建议是：初期应避免过度设计，采用清晰的前后端分离单体架构，专注于业务验证和产品打磨。当用户规模真正达到百万级别，且团队相对稳定时，再根据实际瓶颈，考虑是否有必要将系统中的特定高负载模块拆分为微服务。
技术的选择没有银弹，架构演进始终是为业务目标服务的。盲目追逐技术潮流，可能会让团队过早陷入复杂性的泥潭。如果你正在为技术选型而纠结，不妨来 云栈社区 的后端架构板块，看看其他开发者是如何权衡与决策的。
发表于 3 小时前
|
查看: 3|
回复: 0
