一、先别急着上微服务很多小伙伴学架构一上来就问[!chat-left] 读者微服务怎么搭注册中心选什么Spring Cloud 和 Dubbo 到底怎么选[!chat-right] 作者先别急。真正的架构演化不是从“我要上微服务”开始而是从“当前系统哪里扛不住”开始。说白了架构不是为了显得高级。架构演化的本质是当前系统哪里最痛就优先解决哪里。这篇文章我们借着“从单体架构到微服务架构”的路线把系统演化拆成 6 个阶段单体分层架构横向拆分阶段缓存加速阶段应用集群阶段数据与响应加速微服务高并发阶段二、第一段演化先把单体跑稳2.1 阶段 01单体分层架构业务早期最重要的不是架构多漂亮而是能不能快速把业务跑起来。所以一开始通常会采用单体架构前端、业务逻辑、数据访问、数据库都围绕一个应用展开。单体不是原罪。真正的问题是很多单体从第一天开始就没有分层、没有边界、没有模块意识。单体可以简单但不要混乱。 分层不是为了炫技而是为了以后能拆。一个比较健康的单体至少要有这些边界表现层处理页面、接口、请求响应。业务层承载业务规则。数据访问层负责数据库读写。基础设施层封装缓存、文件、消息、第三方服务。如果这一步没有做好后面想拆服务就会变成“拆墙的时候发现钢筋、水管、电线全缠在一起”。黑白手写讲解版彩色工程网格版2.2 阶段 02横向拆分当一台机器开始扛不住第一反应通常不是拆业务而是先把不同职责放到不同机器上。比如Web 服务器负责接入请求。应用服务器负责业务逻辑。数据库服务器负责结构化数据。文件服务器负责图片、附件、上传资源。这一步叫横向拆分也可以理解成“按层拆”。它解决的是资源不匹配的问题。Web 层更吃网络和连接数应用层更吃 CPU数据库更吃磁盘和内存文件服务更吃存储空间。放在一台机器上大家互相抢资源拆开之后至少可以各自优化。黑白手写讲解版彩色工程网格版三、第二段演化系统开始和流量正面交锋3.1 阶段 03缓存加速当数据库压力越来越大缓存就该上场了。缓存的核心思路很简单能不查数据库就不查数据库。 能在近处拿到数据就不要去远处拿。常见缓存包括本地缓存Redis 分布式缓存Nginx 缓存CDN 缓存数据库自身缓存但这里一定要注意缓存不是免费的。它会带来新的问题数据一致性怎么保证热点 Key 被打爆怎么办缓存穿透怎么办缓存击穿怎么办缓存雪崩怎么办缓存过期策略怎么设计所以缓存不是“加一个 Redis 就完事”而是把数据库压力转移到缓存体系之后继续治理缓存体系。黑白手写讲解版彩色工程网格版3.2 阶段 04应用集群和负载均衡缓存解决的是“数据库被频繁读取”的问题。但如果 Web 和应用服务器本身扛不住请求就要进入集群阶段。集群的核心流程是多台机器部署同一个应用。前面加负载均衡。请求被分发到不同节点。某台机器挂了可以自动摘除或切走。这里最关键的前提是应用尽量无状态。无状态服务天然适合集群。 有状态服务必须先把状态抽出去。最典型的问题就是 Session。如果 Session 保存在某一台应用服务器本地那用户下一次请求被负载到另一台机器时就可能变成“登录状态丢了”。所以常见做法是把 Session 放到 Redis 或独立 Session 服务里让所有应用节点共享。黑白手写讲解版彩色工程网格版3.3 阶段 05数据与响应加速系统继续变大后数据库和用户访问链路都会变成瓶颈。这一阶段通常会加入CDN加速静态资源访问。反向代理统一转发和接入。数据库读写分离写主库读从库。搜索引擎复杂检索交给 ES 等专门系统。这一步的本质是不要让一个系统承担所有压力。 把不同类型的压力拆给更适合的组件。读写分离解决的是数据库读压力。CDN 解决的是静态资源访问慢。搜索引擎解决的是复杂查询慢。反向代理解决的是统一入口、转发、接入控制和部分性能优化。你会发现架构每进化一步其实都不是“推倒重来”而是在当前瓶颈上加一层能力。黑白手写讲解版彩色工程网格版四、第三段演化从技术拆分走向业务拆分4.1 阶段 06微服务高并发前面的阶段大部分是在解决性能问题。但系统继续发展后真正麻烦的往往不是机器不够而是代码和团队协作扛不住。单体越来越大以后会出现这些问题代码耦合越来越重。改一个功能影响一大片。构建和发布越来越慢。团队边界不清晰。某个模块想单独扩容做不到。一个小 Bug 可能拖垮整个系统。这时才轮到垂直拆分和微服务登场。微服务可以这样理解按业务能力拆成多个小服务。 每个服务独立开发、独立部署、独立扩容。 服务之间通过 API、RPC 或消息队列协作。比如用户服务、订单服务、商品服务、支付服务、搜索服务各自有自己的代码、部署流程、扩容策略甚至可以有自己的数据库。黑白手写讲解版彩色工程网格版4.2 微服务不是只把代码拆开这里一定要注意微服务不是把一个项目拆成十个项目就完事了。它还需要一整套配套能力能力解决什么问题API 网关统一入口、鉴权、路由、限流注册中心服务在哪里怎么发现配置中心配置如何统一管理和动态更新消息队列异步解耦、削峰填谷限流熔断防止局部故障拖垮全局链路追踪一次请求跨多个服务后怎么排查监控告警服务出问题时怎么第一时间知道自动化发布多服务如何稳定上线幂等设计重试和重复请求如何不产生脏数据分布式事务跨服务数据一致性如何处理没有这些能力微服务很容易从“架构升级”变成“事故制造机”。4.3 微服务真正的门槛微服务的门槛不在“会不会写 Controller”。真正的门槛在这些地方服务拆分边界是否清楚。数据归属是否清楚。服务之间调用是否可控。出问题时能不能定位。发布时能不能回滚。高峰期能不能限流降级。团队是否具备 DevOps 能力。所以新手不要把微服务理解成“高级版单体”。它更像是把一个大问题拆成很多小问题然后再引入一套治理体系保证这些小问题不会互相引爆。五、两种架构图绘制风格5.1 黑白手写讲解版黑白手写讲解版更像课堂白板。它适合讲架构关系调用方向职责边界技术组件之间的配合一个系统为什么从 A 演化到 B这种图的优点是信息不花哨读者容易把注意力放在链路和逻辑上。5.2 彩色工程网格版彩色工程网格版更适合文章发布。它适合放在正文里做视觉锚点一眼知道这一节讲什么。色彩区分不同组件。阅读节奏更轻松。更像完整的图文内容。六、最后记住架构演化永远为业务服务架构演化不是技术清单。它更像一组连续选择业务刚起步先用单体快速交付。机器扛不住先按层拆。数据库扛不住引入缓存和读写分离。应用扛不住引入集群和负载均衡。检索和响应慢引入 CDN、反代、搜索引擎。团队和业务边界扛不住再考虑微服务。这里还有一个现实补充现在很多系统已经不需要完整复刻大厂当年的演进路线。因为云平台、托管数据库、对象存储、CDN、消息队列、容器平台、可观测性平台都已经很成熟了。小团队可以直接购买很多基础设施能力不一定要从零开始造一遍。但底层判断不变架构不是越复杂越高级而是越匹配当前业务越高级。不要为了微服务而微服务。也不要因为微服务复杂就否定微服务。真正好的架构决策是知道什么时候该简单什么时候必须复杂。