先来感受下用 kratos 快速创建项目
一、环境准备#
1.1 安装依赖软件
安装 protoc：
- 到 protobuf release 页面，选择适合自己操作系统的文件包。
或者文档 - 也可以看 grpc.io 官方安装文档： https://grpc.io/docs/protoc-installation/
安装 protoc-gen-go：
- 简单点可以直接用 go install 安装 ：
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
或者看文档 - https://developers.google.com/protocol-buffers/docs/reference/go-generated
建议开启 GO111MODULE
一些相关文档：
- https://developers.google.com/protocol-buffers
- https://github.com/protocolbuffers/protobuf
- https://grpc.io
- https://github.com/grpc/grpc-go
1.2 安装 kratos cli
go install github.com/go-kratos/kratos/cmd/kratos/v2@latest
CLI 工具使用说明：CLI工具使用
go-kratos 和 Go 版本：
go 1.17
go-kratos v2.2.1
二、创建和运行项目#
2.1 通过 kratos new 命令创建项目模板
使用 kratos new 命令创建 quickstart 项目：
kratos new quickstart
使用该命令创建项目：
$ kratos new quickstart
🚀 Creating service quickstart, layout repo is https://github.com/go-kratos/kratos-layout.git, please wait a moment.
From https://github.com/go-kratos/kratos-layout
cf30efc..cc5192f main -> origin/main
* [new tag] v2.2.1 -> v2.2.1
* [new tag] v2.1.3 -> v2.1.3
* [new tag] v2.1.4 -> v2.1.4
* [new tag] v2.1.5 -> v2.1.5
* [new tag] v2.2.0 -> v2.2.0
Updating cf30efc..cc5192f
Fast-forward
.github/workflows/gitee-sync.yml | 27 +
Makefile | 35 +-
README.md | 2 +-
api/helloworld/v1/error_reason.pb.go | 100 ++--
api/helloworld/v1/error_reason.proto | 11 +-
api/helloworld/v1/error_reason_errors.pb.go | 30 -
api/helloworld/v1/greeter.pb.go | 114 ++--
... ...
🍺 Project creation succeeded quickstart
💻 Use the following command to start the project 👇:
$ cd quickstart
$ go generate ./...
$ go build -o ./bin/ ./...
$ ./bin/quickstart -conf ./configs
🤝 Thanks for using Kratos
📚 Tutorial: https://go-kratos.dev/docs/getting-started/start
如果拉取 github 上的项目模板失败，可以使用 -r 参数指定拉取项目模板地址.
比如拉取 gitee 上的模板：
kratos new quickstart -r https://gitee.com/go-kratos/kratos-layout.git
更多命令的使用：kratos 命令使用
2.2 使用 go generate 命令生成相应代码
生成 proto 源码、wire 等等：
$ go generate ./...
go: downloading github.com/go-kratos/kratos/v2 v2.2.1
go: downloading google.golang.org/genproto v0.0.0-20220222213610-43724f9ea8cf
go: downloading github.com/go-logr/logr v1.2.1
go: downloading github.com/go-logr/stdr v1.2.0
... ...
2.3 运行项目
使用 kratos run 命令运行项目
$ kratos run
INFO msg=config loaded: config.yaml format: yaml
INFO msg=[gRPC] server listening on: [::]:9000
INFO msg=[HTTP] server listening on: [::]:8000
2.4 测试接口
我使用的 go 写的 curlie：https://github.com/rs/curlie 测试：
$ curlie http://localhost:8000/helloworld/kratos
HTTP/1.1 200 OK
{
"message": "Hello kratos"
}
三、kratos 项目布局#
基于 kratos-layout 创建的项目，使用的 kratos new 命令：
kratos new
生成的目录结构图如下：
.
├── Dockerfile
├── LICENSE
├── Makefile
├── README.md
├── api // 下面维护了微服务使用的proto文件以及根据它们所生成的go文件
│ └── helloworld
│ └── v1
│ ├── error_reason.pb.go
│ ├── error_reason.proto
│ ├── error_reason.swagger.json
│ ├── greeter.pb.go
│ ├── greeter.proto
│ ├── greeter.swagger.json
│ ├── greeter_grpc.pb.go
│ └── greeter_http.pb.go
├── cmd // 整个项目启动的入口文件
│ └── server
│ ├── main.go
│ ├── wire.go // 我们使用wire来维护依赖注入
│ └── wire_gen.go
├── configs // 这里通常维护一些本地调试用的样例配置文件
│ └── config.yaml
├── generate.go
├── go.mod
├── go.sum
├── internal // 该服务所有不对外暴露的代码，通常的业务逻辑都在这下面，使用internal避免错误引用
│ ├── biz // 业务逻辑的组装层，类似 DDD 的 domain 层，data 类似 DDD 的 repo，而 repo 接口在这里定义，使用依赖倒置的原则。
│ │ ├── README.md
│ │ ├── biz.go
│ │ └── greeter.go
│ ├── conf // 内部使用的config的结构定义，使用proto格式生成
│ │ ├── conf.pb.go
│ │ └── conf.proto
│ ├── data // 业务数据访问，包含 cache、db 等封装，实现了 biz 的 repo 接口。我们可能会把 data 与 dao 混淆在一起，data 偏重业务的含义，它所要做的是将领域对象重新拿出来，我们去掉了 DDD 的 infra层。
│ │ ├── README.md
│ │ ├── data.go
│ │ └── greeter.go
│ ├── server // http和grpc实例的创建和配置
│ │ ├── grpc.go
│ │ ├── http.go
│ │ └── server.go
│ └── service // 实现了 api 定义的服务层，类似 DDD 的 application 层，处理 DTO 到 biz 领域实体的转换(DTO -> DO)，同时协同各类 biz 交互，但是不应处理复杂逻辑
│ ├── README.md
│ ├── greeter.go
│ └── service.go
└── third_party // api 依赖的第三方proto
├── README.md
├── google
│ └── api
│ ├── annotations.proto
│ ├── http.proto
│ └── httpbody.proto
└── validate
├── README.md
└── validate.proto
整个项目架构流程图，官方的一个架构图：
上面虽然对代码结构做了文字说明，但是在 internal 里，有 DDD 这个概念，相信很多人看了后，不是很明白。
先来看看 DDD 的分层架构，架构图如下：
再来对比看看 internal 目录里的 biz、data、service、server、conf 这 5 个目录。
- biz：文档里说了类似 DDD 的 domain 层，也就是 DDD 架构中的领域层。这里还定义了对业务操作的接口。业务逻辑组装。
- data：对数据库 db，缓存 cache 的封装，并且实现 biz 中定义的接口。它将领域对象重新拿出来，这里去掉了 DDD 的基础层。
- service：实现 api 定义的服务层，类似 DDD 的应用层。处理数据传输对象到 biz(领域实体)的转换。同时协同各类 biz 交互，不应处理复杂逻辑。
- server：http 和 grpc 实例的创建和配置，以及注册对应的 service。
service -> biz -> data