微服务是什么
微服务把系统按业务能力拆成一组可独立部署的小服务，每个服务拥有自己的数据存储，通过轻量协议（HTTP/JSON、gRPC、消息）通信，并可由独立团队端到端负责。它换来独立发布、按需伸缩与技术异构的自由度，代价是把进程内调用换成网络调用，一致性问题、运维复杂度和调试难度随之上升。评价一个系统是否“微服务”，看的是能否独立部署与独立演进，而不是服务数量多少。
基本信息
| 划分依据 | 业务能力与限界上下文，而非技术分层 |
|---|
| 通信方式 | 同步 REST/gRPC 与异步消息并存，按场景选择 |
|---|
| 数据归属 | 服务自管数据，禁止跨服务直接读写他人库表 |
|---|
| 部署单元 | 一个服务一个可独立发布的制品，通常跑在容器编排平台上 |
|---|
| 前提条件 | 成熟的 CI/CD、集中日志与链路追踪、自动化测试与灰度能力 |
|---|
典型使用场景
- 团队规模增长后发布互相阻塞：把高频变更的业务域拆出独立发布链路
- 资源画像差异大：订单写入重、报表查询重，分开后可各自伸缩
- 技术异构需求：推荐模块用 Python 生态，交易模块保持 Java
- 故障隔离诉求：非核心模块异常不应拖垮主交易链路
- 多端多区域部署：把需要就近部署的能力独立成服务
- 外部集成频繁：为每个第三方对接建立独立边界，避免污染核心模型
关键特征
| 特征 | 说明 |
|---|
| 独立部署 | 每个服务可单独发布与回滚，发布节奏由团队自定 |
| 业务能力划分 | 边界对齐业务域，避免按技术层切分带来的跨域改动 |
| 数据去中心化 | 服务自管数据，避免共享库造成的事实耦合 |
| 基础设施自动化 | 依赖流水线、监控告警、弹性调度，靠人肉运维不可持续 |
| 面向失败设计 | 超时、重试、熔断、降级是默认配置而不是事后补丁 |
代价与对策
| 代价 | 表现 | 常见对策 |
|---|
| 分布式事务 | 跨服务写操作无法用本地事务保证 | Saga、事件驱动最终一致、对账与补偿 |
| 运维复杂度 | 服务数量与实例数量成倍增长 | 容器编排、统一日志、指标与追踪三件套 |
| 调试困难 | 一次请求跨多个进程，本地断点失效 | 关联 ID 贯穿全链路，集中式链路追踪 |
| 契约演进 | 一个接口多个消费者，改字段就出事 | 接口版本化、消费者驱动契约测试 |
| 组织成本 | 团队边界与业务边界错位导致反复协调 | 先对齐团队与业务域，再定服务边界 |
服务边界往往与团队沟通结构互相塑造，先想清楚谁负责哪个业务域，再决定切几刀，比先画架构图更有效。
多个服务共用一套库表时，schema 变更会同时影响所有服务，这种系统通常只是“分布式单体”，拆分的收益拿不到，复杂度却全部承担。
拆分前的检查
| 检查项 | 判断标准 | 不通过时的建议 |
|---|
| 发布独立性 | 单个服务能否独立构建、发布与回滚 | 先补流水线与环境隔离 |
| 数据边界 | 每个服务的表能否自成一簇、少联表 | 先完成表归属梳理再谈拆分 |
| 观测能力 | 能否按请求追踪跨服务的调用链 | 先建关联 ID 与链路追踪 |
| 运维承载 | 故障时是否有人能在分钟级定位 | 先建监控告警与值班机制 |
| 团队边界 | 每个服务是否有明确负责的团队 | 先调整组织与职责再造服务 |
