Go mod 好菜系列 - 0x14 kratos 这锅微服务脚手架不是只会搭架子

很多人第一次看到 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 分层是为了职责边界，不是为了看起来专业
• 适合长期维护、多人协作、微服务倾向的项目
• 小项目不一定非上，但复杂项目里它确实能减少混乱