1 api/

API 协议定义目录，services.proto文件，以及生成的 go 文件。
我们通常把 api 文档直接在 proto 文件中描述。

2 app/服务名/

(1) cmd main程序

负责程序的: 启动, 关闭, 配置初始化
cmd下根据业务类型的不同, 又分为如下文件夹:

  • interface: 对外的BFF服务(API层), 接收来自用户的请求, 比如暴露了HTTP/grpc接口
  • service: 对内的微服务(SRV层), 仅接受来自内部其他服务或网关的请求, 比如暴露了gRPC接口只对内服务
  • admin: 区别于service, 是面向运维侧的服务
  • job: 流式任务处理的服务, 如订阅kafka的消息

  • task: 定时任务, 如cronjob, 部署到task托管平台

    (2) configs 配置文件

    分为如下文件:

  • registry.yaml: 用于服务注册与发现

    1. consul:
    2. address: 127.0.0.1:8500
    3. scheme: http

  • config.yaml: 监听端口, 链路追踪, 消息队列等

    1. trace:
    2. endpoint: http://127.0.0.1:14268/api/traces
    3. server:
    4. http:
    5.   addr: 0.0.0.0:0
    6.   timeout: 1s
    7. grpc:
    8.   addr: 0.0.0.0:0
    9.   timeout: 1s
    10. data:
    11. kafka:
    12.   addrs:
    13.     - 127.0.0.1:9092

    (3) internal 私有目录

    只有本微服务才能调用的代码放在本目录
    image.png

    1) biz

    业务逻辑的组装层，类似 DDD 的 domain 层，data 类似 DDD 的 repo，repo 接口在这里定义，使用依赖倒置的原则。
    业务逻辑的增删改查接口, 复杂逻辑在此实现

    2) conf

    conf.proto: 用proto文件来定义配置

    3) data

    业务数据访问，包含 cache、db 等封装，实现了 biz 的 repo 接口。
    data层一般要导入conf来创建db连接

    4) pkg

    本微服务内程序共用的基础库

    5) server

    为http和grpc实例的创建和配置，以及注册对应的 service 。

    6) service

    服务的srv层具体实现, 调用biz, 完成接收请求, 处理请求, 返回响应的逻辑

    实现了 api 定义的服务层，类似 DDD 的 application 层，处理 DTO 到 biz 领域实体的转换（DTO -> DO），同时协同各类 biz 交互，但是不应处理复杂逻辑。

3 pkg 基础库

所有项目可以共用的基础库目录
image.png