go-zero-looklook 架构分析

go-zero-looklook 架构分析

• app目录下的每一个子目录都是一个微服务系统

• 

• 每一个子服务下，又有cmd目录，其中api是RESTfullAPI服务，rpc则是grpc服务

• api目录和rpc服务下都有一个 xxxcenter.go 表示的就是服务程序的入口文件

• rpc 目录内部结构说明：

  • 
  • 入口文件是 usercenter.go 主要就是初始化grpc服务，注册Service，
    • 
  • pb 是grpc自动生成的pb文件，grpc服务文件，还有proto自己定义的接口文件
  • internal/config 存放配置结构体的定义
    • 
  • internal/server 这个目录下其实是Service层接口的定义，service其实只是做了一层薄薄的转发，实际业务逻辑交给了logic层处理
    • rpc入口文件会初始化server对象
    • server 做的事情如下：
      • 会先初始化一个logic结构体对象
      • 调用结构体对象对应的方法处理业务逻辑。
      • 
  • internal/logic 才是实际业务逻辑书写的地方
    • logic层，其实更像是java中的Service层。 脏活累活都在这里面处理，如下：
    • 
    • logic 更多的时候适合model层做交互，比如数据库的CRUD就要依赖model层。

  • model层- looklook项目把model层提取到与cmd目录平级

    • 其实我也想不出这一层该放在哪里合适，适合于cmd平级也是可以的。
    • model 做的其实就是数据库的数据的CRUD操作，没啥好说的，非常简单。
    • model层的好多代码也是通过gotcl model来生成的，节省了大量时间👍🏻

  • 再来说说api目录结构

    • 入口文件需要单独定义 比如 usercenter.go 还是老样子，实例化Service结构体，注册路由，注册一系列的控制器
    • internal/handler 其实就是java中的controller层。 这一层其实也不做事情，就是个中间商，把繁杂的事情交给的 internal/logic 处理
    • internal/logic 处理实际的业务逻辑，但大多数情况下，是通过grpc client 请求grpc服务去了。 也不做事情。
    • 就是把对应的请求转发给grpc处理。只不过这个转发的代码是通过工具生成代码，不像grpc-gateway那样自动生成对应逻辑。 其实这种方式也还行。 还少不用写大量重复的代码。

  小结：总体而言go-zero的设计思路还是挺好的，让程序员从繁琐的拷贝黏贴工作中解脱出来，更加专注于处理具体的业务逻辑。

  goctl提供了api,rpc,model,docker,k8s等自动生成代码的功能。也算是针对约定编程了，这点和springboot异曲同工。当springboot多的更高级。而go-zero更加简单粗暴，我个人觉得既然用go的，就不要像java那样层层封装。go-zero这种浅层封装就挺好。