1、微服务概述：从单体架构到微服务架构的演进
说实话，我入行那会儿，大家聊的都是「单体架构」。一个项目，一个代码仓库，一个部署包。简单、直接、好理解。但后来项目越做越大，问题就来了——改一行代码要重新部署整个系统，一个模块出问题可能拖垮全部服务。嗯，这就是我们今天要聊的起点。
从单体架构到微服务架构的演进
先说说单体架构。说白了，就是把所有功能都塞进一个进程里。比如一个电商系统，用户管理、商品管理、订单处理、支付逻辑，全写在一个项目里。开发初期确实爽，本地跑起来快，调试也方便。
但项目到了中期，我开始头疼了。我记得有一次，团队里一个同事改了个支付模块的日志打印，结果把用户登录的接口搞崩了。为什么？因为代码耦合太深，一个全局变量的改动影响到了其他地方。这就是单体架构的典型痛点——牵一发而动全身。
后来大家开始尝试「垂直拆分」。把电商系统拆成用户服务、商品服务、订单服务等几个独立应用。每个应用独立部署，通过 API 通信。这其实就是微服务的雏形。但当时还没有「微服务」这个说法，我们管这叫「面向服务架构（SOA）」。
真正让微服务火起来的，是 2014 年 Martin Fowler 和 James Lewis 那篇经典文章。他们定义了微服务的核心思想：将单一应用程序划分为一组小服务，每个服务独立运行在自己的进程中，并通过轻量级通信机制（通常是 HTTP/REST）协作。
核心区别一句话总结：
- 单体架构：一个进程，一个数据库，一个部署单元
- 微服务架构：多个进程，多个数据库（或共享数据库），多个独立部署单元
微服务的核心特征
我根据自己多年的实践经验，把微服务的核心特征归纳为以下五点。你想想看，是不是这个理？
1. 单一职责
每个服务只负责一个业务功能。比如订单服务只管订单，商品服务只管商品。我在项目中遇到过有人把「用户积分」和「用户登录」放在同一个服务里，结果积分规则一改，登录也受影响。这就是没遵守单一职责。
2. 独立部署
每个服务可以独立开发、测试、部署、升级。你改你的订单服务，我改我的支付服务，互不干扰。我曾经见过一个团队，因为部署耦合，每次上线都要协调 5 个服务一起发版，光排期就花了两天。独立部署之后，这个时间缩短到了 10 分钟。
3. 去中心化治理
每个服务可以选自己最合适的技术栈。订单服务用 Python + PostgreSQL，推荐服务用 Go + Redis，前端展示用 Node.js。只要接口约定好，内部怎么折腾都行。我建议新手团队先统一技术栈，等成熟了再考虑异构。
4. 轻量级通信
服务之间通过 RESTful API、gRPC 或消息队列通信。通信协议要简单、高效。我个人习惯用 HTTP/REST 做同步调用，用 RabbitMQ 或 Kafka 做异步解耦。注意，别搞成「分布式单体」——服务之间直接共享数据库，那就失去微服务的意义了。
5. 容错与弹性设计
微服务架构下，网络是不可靠的。一个服务挂了，不能拖垮整个系统。需要引入熔断器（如 Hystrix）、重试机制、超时控制、限流等策略。我记得有一次线上事故，支付服务响应变慢，结果订单服务一直在等它返回，最终导致所有线程池耗尽，整个系统瘫痪。这就是没有做容错设计的后果。
避坑指南： 我曾经在项目初期就引入了服务网格（Service Mesh），结果团队学习成本太高，反而拖慢了进度。建议先做好基础的服务拆分和通信，等规模大了再考虑 Service Mesh。
微服务的优缺点
任何架构都不是银弹。微服务有它的优势，也有它的问题。我直接给你列个表，一目了然。
| 维度 | 优点 | 缺点 |
|---|---|---|
| 开发效率 | 小团队独立开发，互不干扰 | 服务数量多，开发环境搭建复杂 |
| 部署频率 | 可以频繁独立部署，快速迭代 | 部署流程复杂，需要 CI/CD 和容器化支持 |
| 技术选型 | 每个服务可以选最合适的语言和数据库 | 技术栈碎片化，维护成本高 |
| 故障隔离 | 一个服务挂了，不影响其他服务 | 分布式系统调试困难，问题定位耗时 |
| 扩展性 | 可以针对热点服务单独扩容 | 网络延迟增加，数据一致性难保证 |
| 团队规模 | 适合 10 人以下的小团队 | 团队人数少时，运维负担反而更重 |
优点展开说
- 独立扩展：双十一来了，订单服务压力大，我只需要给订单服务加机器就行。商品服务、用户服务完全不用动。这在单体架构下是不可能的——你只能给整个系统加机器，浪费资源。
- 技术多样性：我见过一个项目，推荐算法用 Python（因为机器学习库多），核心交易用 Java（因为稳定），前端展示用 Go（因为并发高）。各取所长，互不干扰。
- 故障隔离：支付服务挂了，用户还能浏览商品、加购物车。只是不能付款而已。这在单体架构下，支付模块一崩，整个网站都打不开。
缺点也得说清楚
- 分布式复杂性：服务间通信、数据一致性、分布式事务、服务发现、负载均衡……这些在单体架构下根本不用操心。我刚开始做微服务时，光搭建服务注册中心就折腾了一周。
- 运维成本高：以前一个应用，一台服务器就够了。现在 10 个服务，至少需要 10 个实例。还要考虑监控、日志收集、链路追踪、容器编排……没有 DevOps 团队，小公司真玩不转。
- 数据一致性难题：单体架构下，一个事务就能搞定的事情，微服务里要拆成多个服务调用。要么用分布式事务（性能差），要么用最终一致性（业务复杂）。我建议非核心业务优先考虑最终一致性，别一上来就上分布式事务。
重要提醒： 不要为了微服务而微服务。如果你的团队只有 3 个人，业务逻辑也不复杂，老老实实用单体架构。等业务规模上来了，再考虑拆分。我见过太多团队，项目还没上线，先搞了 20 个微服务，结果光维护就累死了。
什么时候该用微服务？
我个人总结了一个简单的判断标准：
- 团队规模超过 10 人，且分工明确
- 业务模块之间耦合度低，可以清晰划分边界
- 需要频繁独立部署，迭代速度要求高
- 有专门的 DevOps 或基础设施团队
如果以上四点满足三点以上，可以考虑微服务。否则，我建议你先用单体架构，把业务跑起来再说。
好了，这一章就聊到这里。下一章我们会深入微服务的通信机制，聊聊 REST 和 gRPC 到底怎么选。到时候我会分享一个我在项目中踩过的坑——用错了通信协议，导致线上延迟飙升。敬请期待。