Go mod 好菜系列 - 0x14 kratos 这锅微服务脚手架不是只会搭架子
详细聊 kratos 的定位、transport/service/data 分层怎么理解、它适合什么团队，以及为什么它更像工程约束工具而不只是生成目录的脚手架。
很多人第一次看到 kratos，第一反应通常是：这不就是个脚手架吗？能生成目录、能起个服务、能跑个 gRPC 和 HTTP，看起来像是“搭完骨架就没了”。但真到了团队项目里，它真正有价值的地方，反而不是“帮你少敲几十行命令”，而是它在悄悄帮你把工程结构往一个更稳的方向收。
kratos 在解决什么问题
它主要解决的是 Go 服务项目怎么组织 这件事。很多项目一开始都能跑，但跑着跑着就会开始乱：
- handler 里直接查数据库
- service 里顺手拼 SQL
- 日志、配置、超时、错误码到处散落
- HTTP 和 gRPC 两套入口越来越像两棵野生分支
kratos 并不是魔法，它做的事情更像是：先替你把这些边界画出来，再逼着你别轻易把它们写穿。
它为什么常见
因为国内 Go 团队里，尤其是做 API 服务和内部平台服务的，很多时候真正缺的不是“某个库”，而是一套大家都能看懂、也愿意按着写的项目组织方式。kratos 恰好卡在这个位置上：
- 比从零自建框架轻松
- 比毫无约束的自由发挥更稳
- 对 gRPC / HTTP / 配置 / 日志 / 中间件这些常见要素有现成组合
最常见的目录分层怎么理解
cmd/
internal/
service/
biz/
data/
server/
这个分层如果只背名字，很快就会觉得空。真正要理解的是职责：
service：接口层，接住 transport 进来的请求，做参数翻译和响应组织biz：业务层，放真正的业务规则和领域逻辑data：数据层，和 DB、缓存、第三方系统打交道server：把 HTTP、gRPC 服务启动起来
你会发现它想传达的不是“目录长这样”，而是“别把 transport、业务、存储搅成一锅”。
看一眼 kratos 风格的 service/biz/data 怎么接
type UserRepo interface {
Save(ctx context.Context, user *User) error
}
type UserUsecase struct {
repo UserRepo
}
func (uc *UserUsecase) Create(ctx context.Context, name string) error {
return uc.repo.Save(ctx, &User{Name: name})
}
type UserService struct {
pb.UnimplementedUserServer
uc *UserUsecase
}
func (s *UserService) CreateUser(ctx context.Context, req *pb.CreateUserRequest) (*pb.CreateUserReply, error) {
if err := s.uc.Create(ctx, req.Name); err != nil {
return nil, err
}
return &pb.CreateUserReply{Message: "ok"}, nil
}这段代码的重点不是语法，而是依赖方向。service 不直连数据库，biz 不关心 transport 细节，data 去实现 repo 接口，这样边界会清楚很多。
kratos 不是只给你一个生成器
很多人用完 kratos new 就觉得差不多了。其实真正进入日常开发后，你会更常碰到这些东西：
- 配置加载
- 日志接入
- 中间件链路
- 错误码和错误包装
- 服务注册发现
- proto 驱动的接口定义
这些才是 kratos 更常被提起的原因。它不只是“把目录搭出来”，而是给了你一套偏工程化的默认组合。
什么时候它特别适合
- 团队里不止一个人维护服务
- 项目有 HTTP 和 gRPC 双入口需求
- 你希望服务结构尽量统一
- 后面可能要接注册发现、链路追踪、配置中心
这类场景里，kratos 能帮你少走很多“每个项目都重新吵一次目录结构”的弯路。
什么时候它反而可能有点重
如果你只是写一个很小的单体 API，或者只是想快速验证一个想法，那 kratos 也可能显得有点“正经过头”。因为它默认带来的，是工程约束，而不是最短启动路径。
所以它并不是所有项目都该上，而是更适合那些你已经知道自己会长期维护、会继续扩张的服务。
一个简单的理解方式
如果说 Gin 更像是“给你一把快刀，你自己决定怎么切”，那 kratos 更像是“给你一套后厨分区和配菜流程”。它不是为了让第一道菜炒得最快，而是为了让后面几十道菜别全乱套。
小结
kratos 这锅菜不在于炫技，而在于稳定：
- 它的核心价值是工程组织，不只是代码生成
- service / biz / data 分层是为了职责边界，不是为了看起来专业
- 适合长期维护、多人协作、微服务倾向的项目
- 小项目不一定非上，但复杂项目里它确实能减少混乱