定位

Kratos 是 B 站开源的微服务框架。和 go-zero 同属「微服务全家桶」，但路线不同：Kratos 以 gRPC 和 proto 为核心，HTTP 是附属；go-zero 以 .api 文件生成 HTTP 服务为主。

分层上，Kratos 更接近传统 DDD（api / biz / data / service），约束更清晰。

安装

# 安装脚手架工具
go install github.com/go-kratos/kratos/cmd/kratos/v2@latest

1. 安装 protoc 插件
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
go install github.com/go-kratos/kratos/cmd/protoc-gen-go-http/v2@latest

创建项目

kratos new helloworld
cd helloworld
kratos run

生成的结构：

helloworld/
├── api/helloworld/v1/          # proto 定义 + 生成的 pb 代码
├── internal/
│   ├── biz/                    # 业务逻辑（类似 DDD 的 domain）
│   ├── data/                   # 数据访问（repo 实现）
│   ├── service/                # 服务层，对接 api
│   ├── server/                 # HTTP / gRPC server 装配
│   └── conf/                   # 配置结构体
├── configs/                    # 配置文件
└── cmd/helloworld/main.go      # 入口

proto 优先

1. 定义接口

api/helloworld/v1/greeter.proto：

syntax = "proto3";
package helloworld.v1;
option go_package = "helloworld/api/helloworld/v1;v1";

import "google/api/annotations.proto";

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {
    option (google.api.http) = {
      get: "/helloworld/{name}"
    };
  }
}

message HelloRequest { string name = 1; }
message HelloReply  { string message = 1; }

关键在 option (google.api.http)：一份 proto 同时生成 gRPC 和 HTTP 两个入口。对外 HTTP，对内 gRPC，同一套业务逻辑。

2. 生成代码

kratos proto client api/helloworld/v1/greeter.proto
kratos proto server api/helloworld/v1/greeter.proto -t internal/service

3. 实现业务

业务代码写在 internal/biz 和 internal/data，service 层只做协议转换：

// internal/service/greeter.go
func (s *GreeterService) SayHello(ctx context.Context, req *pb.HelloRequest) (*pb.HelloReply, error) {
    return s.uc.SayHello(ctx, req.Name)
}

uc 是 biz 层的 usecase。依赖方向是 service → biz → data，data 层实现 biz 定义的接口（依赖倒置）。

核心概念

1. 强弱约束：依赖倒置

biz 层定义 repo 接口，data 层实现：

// internal/biz/user.go
type UserRepo interface {
    FindByID(ctx context.Context, id int64) (*User, error)
}

这样 biz 不依赖具体数据库，测试时可以注入 mock。这是 Kratos 比 go-zero 更「正统」的地方——go-zero 的 model 是生成的，直接耦合数据库。

2. 一个进程两个 server

// internal/server 里同时装配
httpSrv := http.NewServer(...)
grpcSrv := grpc.NewServer(...)
app := kratos.New(
    kratos.Server(httpSrv, grpcSrv),   // 同时跑
)

同一个服务既提供 HTTP（对外）又提供 gRPC（对内），共享业务逻辑。

3. 内置治理

限流、熔断、链路追踪、注册中心（etcd / consul / nacos）、配置中心，都是中间件形式，按需装配。

常见坑

① protoc 插件链容易装错

protoc-gen-go、protoc-gen-go-grpc、protoc-gen-go-http 三个都要装，版本不匹配会生成失败。建议用 kratos upgrade 或看官方 Makefile。

② 分层不是强制的，容易写乱

Kratos 的目录结构是建议，不是强制。团队不遵守的话，很容易变成「全都堆在 service 里」。

③ 比 go-zero 陡

go-zero 的 .api 语法简单，Kratos 要会写 proto、理解 gRPC。团队没 gRPC 经验的话，上手时间要按周算。

什么时候选它

• 服务间通信以 gRPC 为主
• 团队接受 DDD 分层、愿意维护接口抽象
• 需要同时对外 HTTP、对内 gRPC

不选它的场景：纯 HTTP 项目（用 Gin/Echo 更轻）、团队没有 gRPC 经验、单体应用。

和 go-zero 怎么选

简单判断：如果团队已经在用 protobuf 和 gRPC，选 Kratos；如果只是想快速搭微服务，选 go-zero。