微单体
理解微单体的模块边界、部署边界及其与微服务的关系。
1分钟内可阅读完
什么是微单体
“微单体”没有统一、严格的行业定义。本文用它描述一种应用组织方式：在应用内部划分边界清晰的业务模块，以一个应用作为主要构建和部署单位，并按需引入接口规范、认证鉴权、可观测性等工程能力。
“单体”主要描述部署边界，并不意味着代码必须集中在一起；“微”强调应用职责克制、模块组织清晰，也不代表某个固定的代码量或服务数量。
一个微单体可以运行多个副本。是否高可用取决于实例部署、负载均衡、状态管理等设计，而不是“单体”这个名称。
与微服务有什么关系
以用户、订单、支付三个业务模块为例，微单体可以把它们组织在一个应用中；微服务则可以把它们拆成独立服务。
| 对比项 | 微单体 | 微服务 |
|---|---|---|
| 代码组织 | 一个应用内划分多个业务模块 | 按服务划分代码与职责 |
| 构建和部署 | 通常一起构建、部署 | 各服务可独立构建、部署 |
| 内部调用 | 通常通过进程内函数或接口 | 通常通过 RPC、HTTP 或消息 |
| 扩容方式 | 通常扩容整个应用 | 可按服务分别扩容 |
| 故障边界 | 同一进程内的模块共享进程级风险 | 可建立服务级隔离，但仍可能级联故障 |
| 数据与事务 | 可以共用数据库；仍应明确数据归属 | 常需处理跨服务数据一致性与事务 |
| 交付与运维 | 部署单位较少，协调成本通常较低 | 需要管理服务通信、版本及分布式故障 |
微服务的关键是服务边界和独立部署能力。使用 gRPC、运行在 Kubernetes 上，或引入注册中心，都不能单独证明一个系统采用了微服务架构。
反过来，一个大型微服务系统中的某个服务，也可以在内部采用微单体的模块组织方式。这两个概念分别描述不同层面的边界。
gRPC Kit 的定位
gRPC Kit 面向 Go 微单体应用，为服务开发提供脚手架、接口约定、组件配置和运行治理能力。可以从以下三个层面理解：
- **应用内部：**通过业务模块和 Go 接口组织职责，明确模块依赖。
- **应用对外：**通过 Protobuf、gRPC 和 HTTP API 提供接口契约。
- **应用运行：**按需配置监听、认证鉴权、缓存、对象存储和可观测性等能力。
模块划分、依赖方向和数据归属仍需要由应用开发者设计。框架提供的接口与治理能力能为后续拆分提供工程基础，但不自动保证模块隔离，也不自动完成服务拆分。
配置字段与使用示例见配置参考，接口命名和错误处理约定见接口规范。
什么时候考虑拆成微服务
微单体可以是长期架构选择，不必以拆分为最终目标。可以先检查某个模块是否存在明确需求：
| 需求 | 需要评估的问题 |
|---|---|
| 独立发布 | 是否经常因其他模块的发布节奏而受阻 |
| 独立扩容 | 是否只有少数模块持续消耗大量资源 |
| 故障隔离 | 是否需要减少某个模块故障对其他业务的影响 |
| 独立团队维护 | 是否已经具有清晰的职责、接口和交付边界 |
| 独立运行环境 | 是否有不同的资源、技术栈或部署要求 |
拆分前还应明确数据库归属、接口兼容性、跨服务事务、重试与超时、监控和故障处理。代码目录已经分开，并不意味着这些问题已经解决。
设计建议
- 按业务职责划分模块，避免模块直接操作其他模块的内部实现。
- 明确数据归属，减少跨模块直接读写表带来的耦合。
- 通过明确的接口组织依赖，不必为了“像微服务”而强制增加网络调用。
- 从开始就做好错误处理、指标、日志与链路观测。
- 当独立部署带来的收益能够覆盖分布式复杂度时，再按业务边界拆分。
首次使用 gRPC Kit，请继续阅读快速入门；了解通信机制，请阅读RPC 简介。