Kit 基础库
将 Kit 项目作为公司的标准库，因此应该只有一个。并且 Kit 基础库也应该具备以下这些特点：
- 简单：不过度设计，代码平实简单；
- 通用：通用业务开发所需要的基础库的功能；
- 高效：提高业务迭代的效率；
- 稳定：基础库可测试性高，覆盖率高，有线上实践安全可靠；
- 健壮：通过良好的基础库设计，减少错用；
- 高性能：性能高，但不特定为了性能做 hack 优化，引入 unsafe ；
- 扩展性：良好的接口设计，来扩展实现，或者通过新增基础库目录来扩展功能；
- 容错性：为失败设计，大量引入对 SRE 的理解，鲁棒性高；
- 工具链：包含大量工具链，比如辅助代码生成，lint 工具等等； 微服务中的 app 服务类型主要分为4类：interface、service、job、admin，应用 cmd 目录负责程序的：启动、关闭、配置初始化等。
# 创建项目模板
kratos new helloworld
cd helloworld
# 拉取项目依赖
go mod download
# 生成proto模板
kratos proto add api/helloworld/helloworld.proto
# 生成client源码
kratos proto client api/helloworld/helloworld.proto
# 生成server模板
kratos proto server api/helloworld/helloworld.proto -t internal/service
- interface: 对外的 BFF 服务，接受来自用户的请求，比如暴露了 HTTP/gRPC 接口。
- service: 对内的微服务，仅接受来自内部其他服务或者网关的请求，比如暴露了gRPC 接口只对内服务。
- admin：区别于 service，更多是面向运营测的服务，通常数据权限更高，隔离带来更好的代码级别安全。
- job: 流式任务处理的服务，上游一般依赖 message broker。
- task: 定时任务，类似 cronjob，部署到 task 托管平台中。 总的来说，Go语言的强大的并发性和静态编辑使得Go语言的编辑效率和开发效率很高。
服务内部目录
Application 目录下有 api、cmd、configs、internal、pkg 目录，目录里一般还会放置 README、CHANGELOG、OWNERS。
internal 是为了避免有同业务下有人跨目录引用了内部的 data、biz、service、server 等内部 struct。
data
业务数据访问，包含 cache、db 等封装，实现了 biz 的 repo 接口。我们可能会把 data 与 dao 混淆在一起，data 偏重业务的含义，它所要做的是将领域对象重新拿出来，我们去掉了 DDD 的 infra层。
biz
业务逻辑的组装层，类似 DDD 的 domain 层，data 类似 DDD 的 repo，repo 接口在这里定义，使用依赖倒置的原则。
service
实现了 api 定义的服务层，类似 DDD 的 application 层，处理 DTO 到 biz 领域实体的转换（DTO -> DO），同时协同各类 biz 交互，但是不应处理复杂逻辑。
server
为http和grpc实例的创建和配置，以及注册对应的 service 。
不建议的目录
src/
src 目录在 java 开发语言的项目中是一个常用的模式，但是在 go 开发项目中，尽量不要使用 src 目录。
model/
在其他语言开发中一个非常通用的模块叫 model，把所有类型都放在 model 里。但是在 go 里不建议的，因为 go 的包设计是根据功能职责划分的。比如一个 User 模型，应该声明在他被用的功能模块里。
xxs/
带复数的目录或包。虽然 go 源码中有 strings 包，但更多都是用单数形式。
总结
在实际 go 项目开发中，一定要灵活运用，当然也可以完全不按照这样架构分层、包设计的规则，一切以项目的大小、业务的复杂度、个人专业技能认知的广度和深度、时间的紧迫度为准。 并且，一定要按实际情况，选择合适自己团队的 Kit 基础库，进行充分的调研以及是否可满足插件定制化，需要维护好属于团队的 Kit 基础库 和 代码规范 ，带动开发者进行积极参与贡献。
