Micro In Action：项目结构与启动过程

项目结构

在上篇文章中我们创建了一个简单的项目， 并过将它运行起来。本篇将继续这个旅程，先介绍项目结构及其中每个文件的用途。

项目结构如下：

.
├── main.go
├── generate.go
├── plugin.go
├── proto/hello
│   └── hello.proto
│   └── hello.pb.go
│   └── hello.pb.micro.go
├── handler
│   └── hello.go
├── subscriber
│   └── hello.go
├── Dockerfile
├── go.mod
├── go.sum
├── Makefile
└── README.md

每个文件的说明为：

• main.go ，项目主文件，后面会详细说明
• generate.go ，只包含一行 //go:generate make proto ，实现与 go generate 命令的集成。在运行 go generate 命令时自动调用 make proto
• plugins.go，目前是空文件， 根据 Micro 的约定[2]， 建议在这里管理所需 plugin 的导入， 后续会用到。
• proto/hello/hello.proto，gRPC 服务定义[3]文件， 定义了 rpc 服务Hello，服务中提供 3 种典型 gRPC 调用：单向 RPC，单向 Stream 和双向 Stream
  **proto/hello/hello.pb.go，**根据上述 proto 文件， 由protoc 生成 gRPC 相关代码
• proto/hello/hello.pb.micro.go，由前文提到的 protoc-gen-micro 生成的， 进一步简化开发者的工作。其中定义了HelloSerivce 接口， 以及 HelloHandler 接口。后者是我们需要去实现、完成业务逻辑的接口
• handler/hello.go ，实现 gRPC 业务逻辑的地方。其中定义了 Hello 对象， 此对象实现了前面提到 HelloHandler 接口。
• subscriber/hello.go，实现异步消息接收并处理的地方。其中展示了用两种不同方式处理消息，一是以对象方法处理， 二是以一个函数来处理。
• Dockerfile，定义如何构建 Docker 镜像
• go.mod / go.sum ， Go Module 相关文件
• Makefile，包含了几个常用任务定义， 编译、测试、生在 Docker 镜像等
• README.md，记录了生成项目的基本信息，以及基本运行指南

注：文件夹 proto有特殊含义。虽然在技术上没有限制， 但在 Micro 的约定中，每个项目根目录下的proto文件夹专门用来存放“接口”文件。这既包含本项目需要对外暴露的接口， 也包含本项目所依赖其它接口。举例来说， 假如我们实现业务逻辑时需要依赖另外一个服务 foo。那么我们会建立proto/foo 文件夹，并在其中放置 foo.proto, foo.pb.go, foo.pb.micro.go 三个文件，供业务代码调用。

启动过程解析

接下来看一看启动代码，main.go:

package main

import (
   "github.com/micro/go-micro/util/log"
   "github.com/micro/go-micro"
   "hello/handler"
   "hello/subscriber"

   hello "hello/proto/hello"
)

func main() {
   
   // New Service
   service := micro.NewService(
      micro.Name("com.foo.srv.hello"),
      micro.Version("latest"),
   )

   // Initialise service
   service.Init()

   // Register Handler
   hello.RegisterHelloHandler(service.Server()