go 服务端开发总结报告

服务端开发一般是指业务的接口编写，对大部分系统来说，接口中CURD的操作占了绝大部分。然而，网络上总有调侃“CURD工程师”的梗，以说明此类开发技术并不复杂。但我个人认为，如果仅仅为了找个框架填充点代码完成任务，确实是简单，但是人类贵在是一根“会思考的芦苇”，如果深入的思考下去，在开发过程中还是会碰到很多通用的问题的。我们就用go的开发框架举例子，它有两种分化形式： 一种以beego为代表的，goframe继续发扬广大的框架类型，它们的特点就是大而全，提供各种各样的功能，你甚至不需要做多少选择，反正按照文档使用就是了。它们的问题也就在于此，很多时候因为封装的太好了，很多问题都已经被无形地解决了（但不一定是最适合的解决方式）。 另一种则以gin、go-mirco等框架为代表，它们只解决特定一部分问题，使用它们虽然还有很多额外的工作要做，但是在之中也能学到更多的东西。 接下来，详细地看看go的服务端开发可能会碰到哪些问题：

1. 项目结构

无论是大项目还是小管理系统，万里长征第一步，都是如何组织自己的项目结构。在项目结构这方面，go其实没有一个固定的准则，因此可以根据实际情况，灵活的组织。但我觉得，还是需要知道一些需要注意的点：

1. 包名简单，但要注意见名知意

fmtstrconvpkgcmdmdwmiddleware

2. 使用 internal

使用 internal 有助于强制人思考，什么应该放在公共包，什么应该放在私有包，从而是项目结构更加清晰。而且go本身提供的包访问权限没有java那么详细，只有公开和私有这两种状态，更应该用internal来补充一下。

3. 不要随便使用 init

说实话，我对为什么没有对init做任何限制还是有些疑虑的，这也就是说，你依赖的某些库可以先于你的程序代码运行，你也不知道它会做什么事（任何代码都可以在init中执行）。这在那种依赖非常多，又有很多间接依赖的大型项目中体现的很明显。尽管go官方要求不要在init中执行任何复杂的逻辑，但是这没有任何约束力。 最简单的例子就是单元测试，我有时候跑单元测试经常会碰到panic跑不起来，究其原因就是某些依赖库init中做了一些骚操作。但问题是：我是依赖的依赖（间接依赖）了这个库，我也没法控制它的代码（没有修改权限）。碰到这种情况，也只能在单元测试中完成它的要求才能继续运行。 所以把代码放在init中，一定要三思。就我来看，很多用init的代码确实在做初始化，但它们内部隐式依赖了文件、路径、资源等。这种情况要想一想，是不是可以用 NewXX() \ InitXX() 这种函数来替代。

4. 慎用 util \ common 这种包名

util.NewTimeHelper()time_helper.New()

2. 代码结构

代码结构上能说道的东西就更多了，这可能是见软件设计功底的地方，我在这方面也是初学者，所以总结出来的可能对，可能不对，仅供参考。

1. c \ s \ d 层的划分

controllerhandlerservicesvcdaorepositorycontrollervalidatorserviceserviceservicedao

2. 依赖的传递

controllerservicedaocontrollerserviceservicedaocontrollerNewService

var XX *XXService = &XXService{}

type XXService struct{
}

func (x *XXService) XX() {
}

NewXX()

type XXService struct{
	xRepo XXRepo
}

func NewXXService(r *XXRepo) *XXService {
	
}

然后通过依赖注入框架管理这些构造函数

// wire.Build(repo.NewGoodsRepo, svc.NewGoodsSvc, controller.NewGoodsController)
// wire 框架自动生成
func initControllers() (*Controllers, error) {
	goodsRepo := repo.NewGoodsRepo()
	goodsSvc := svc.NewGoodsSvc( goodsRepo)
	goodsController := controller.NewGoodsController(goodsSvc)
	return goodsController, nil
}

这里，wire框架远没有java中的依赖注入框架那么牛逼，实际上，就是帮我们省了自己编写的麻烦。 这样Controller就持有了Service对象，Service就持有了Repo对象。而且，只有注册过的才能持有，避免了管理混乱的问题。

3. 尽量避免全局变量

if err != nilzapgorm.DB

3. 可观察性的处理

可观察性是指日志、链路追踪、监控这三者的有机结合，具体的知识可以见附录的一些参考资料。可观察性其实也是在jaeger、prometheus流行后为大众所知，虽然历史不太久远，但是其重要性是不言而喻的。有效的解决了当线上服务出现问题时，快速的发现和定位具体位置，无论是大项目、小项目，微服务架构或者单体架构，都是非常必要的一环。 具体的配合上来说，首先可以通过prometheus这样的监控服务，及时发现服务存在异常，然后通过jaeger+log配合，寻找问题发生时的上下文，从而快速定位。 以前我未用过链路追踪、监控这些技术时，只靠打log，很多线上错误不能及时发现或者不能复现，其实是比较可惜的。但是要实现可观察性，多多少少都要改造一些代码，完全无侵入的改造是不可能的，所以在项目设计阶段，就可以考虑这方面的事情。从侵入性来说，监控<链路追踪<日志。 监控的侵入性最小，如接入prometheus，只要运行一个 sidecar 线程，处理prometheus的拉取请求即可，但是程序也要预先写好收集监控指标的代码；链路追踪更多的是要深入项目的各个层，比如：controller->service->dao->db，这样才能跟踪到整条请求链路；日志的侵入性肯定最大了，都是在业务代码中打印的。

1. db\redis\log 链路追踪处理

链路追踪的核心就是 context 了，在请求的开头生成一个追踪的上下文，各层来处理和传递这个context，如果是项目内部的代码，可以从context中解析出span，然后打印数据到span中。但是对于项目依赖的一些库(gorm\zap\redis等)，如果想把链路追踪到这些库的内部，这里就有两种处理方式：

1. 库本身就支持传递context 比如：gorm就可以传递context进去，它虽然不能帮你解析这个上下文，但是提供了hook能力，可以自己编写一个plugin拿到这个上下文，自己处理即可。或者是go-micro这种框架，自动就处理了context的解析工作。

// gorm示例
	// 使用插件
	err = db.Use(NewPlugin(WithDBName(dbName)))
	if err != nil {
		return nil, err
	}
	
	// 查询
	DB.WithContext(ctx).Find()

2. 库不支持传递context 或者是库支持传递context，但是没提供hook能力。这种由于我们不能修改库的代码，又不能hook它内部的关键操作，就需要通过代理模式来接管对库的访问，比如：go-redis

type Repo interface {
	Set(ctx context.Context, key, value string, ttl time.Duration, options ...Option) error
	Get(ctx context.Context, key string, options ...Option) (string, error)
	TTL(ctx context.Context, key string) (time.Duration, error)
	Expire(ctx context.Context, key string, ttl time.Duration) bool
	ExpireAt(ctx context.Context, key string, ttl time.Time) bool
	Del(ctx context.Context, key string, options ...Option) bool
	Exists(ctx context.Context, keys ...string) bool
	Incr(ctx context.Context, key string, options ...Option) int64
	Close() error
}

type cacheRepo struct {
	client *redis.Client
}

SetGetGet

func (c *cacheRepo) Get(ctx context.Context, key string, options ...Option) (string, error) {
	var err error
	ts := time.Now()
	opt := newOption()
	defer func() {
		if opt.TraceRedis != nil {
			opt.TraceRedis.Timestamp = time_parse.CSTLayoutString()
			opt.TraceRedis.Handle = "get"
			opt.TraceRedis.Key = key
			opt.TraceRedis.CostSeconds = time.Since(ts).Seconds()
			opt.TraceRedis.Err = err

			addTracing(ctx, opt.TraceRedis)
		}
	}()

	for _, f := range options {
		f(opt)
	}

	value, err := c.client.Get(ctx, key).Result()
	if err != nil {
		err = werror.Wrapf(err, "redis get key: %s err", key)
	}
	return value, err
}

2. 中间件

这里的中间件指的是扩展go原生的http框架，从而支持请求方法链的三方框架，比如：gin、negroni等，这样我们就可以在一个请求的前后插入处理逻辑，比如：panic-recover、鉴权等。前面说到需要在请求的开头生成追踪的上下文，这个功能就可以在中间件来完成（如果是微服务架构，就应该在入口网关处就生成好）。 生成的追踪上下文，可以直接传到log中，这样后续请求链路中打印的log，就全部带上了TraceID，方便追踪。同时，请求的监控指标（QPS、响应时长等）也可以放在这个中间件中一起完成。

4. 错误处理

1. Response Error 处理

一般来说，我们的接口返回都习惯返回一个错误码，用来处理一些业务逻辑错误。这个错误码有别于HTTP状态码，一般都是自己定义的一个错误码表，但是从标准性来考虑，我们在返回时还是要兼容一些常用的HTTP状态码的（400、404、500）等等。 这样，我们的 Response Error 就需要以下这些能力：

1. 隐藏程序错误，尤其是panic 程序错误，尤其是panic，一旦抛出，容易让人分析出系统内部的实现细节，所以要注意隐藏。尤其是很多web框架会自动recover panic，然后打印出去。
2. 可以方便的定义HTTP状态码、错误码 这里的方便指的是可以在service层指定返回的状态码、错误码，因为只有service层可以掌控全局。

实现起来很简单，只需实现以下五个方法：

// 根据状态码、错误码、错误描述创建一个Error
func NewError(httpCode, businessCode int, msg string) Error {}
// 状态码默认200，根据错误码、错误描述创建一个Error
func NewErrorWithStatusOk(businessCode int, msg string) Error {}
// 状态码默认200，根据错误码创建一个Error（错误描述从 错误码表 中获取）
func NewErrorWithStatusOkAutoMsg(businessCode int) Error {}
// 根据状态码、错误码创建一个Error
func NewErrorAutoMsg(httpCode, businessCode int) Error {}
// 把内部的err放到 Error 中
func (e *err) WithErr(err error) Error {}

这个Error结构，就封装了状态码、错误码、错误描述和真正的error。使用时，示例代码如下：

func (s *GoodsSvc) AddGoods(sctx core.SvcContext, param *model.GoodsAdd) error {
...
	if err != nil{
		return response.NewErrorAutoMsg(
			http.StatusInternalServerError,
			response.ServerError,
		).WithErr(err)
	}

2. Go 的错误处理

既然写到了错误码，就不得不提一下Go中的错误处理，错误处理一直是Go中争议比较大的地方，就我们的日常开发而言，最常碰到的问题有三个，而Go的官方，也只是在1.13版本解决了其中一个。

func Set(key string, value string) error{
	...
	return err 
}

func DoSomething(key string, value string) error{
	...
	err := io.Read()
	if err != nil{
		return fmt.Errors("Read: %w",err)
	}
	...  
	err = io.Read()
	if err != nil{
		return fmt.Errors("Read2: %w",err)
	}
}

	func StartPull(){
		var errMulti error
		for i := range systems{
			if err := Pull(systems[i]); err != nil{
				errMulti = multierror.Append(errMulti, err)
			}
		}
	}

github.com/hashicorp/go-multierror

5. dao层的处理

上面提到了 c / s / d 层的划分，以及各层的作用，这里想详细的讲下dao层。

1. 自动生成代码

gormt

2. 字段的隐藏

gormtgopoGORM V2

func FindBy(id int, columns ...string){
    db.Select(colums).Find(&SomeTable{},id)
}
// 只取 ID Name 字段
bean := FindBy(1,dao.Colums.ID, dao.Colums.Name)
// 只取 Status 字段
bean := FindBy(2,dao.Colums.Status)

FindByCreateUpdate

3. 更新字段

由于go的零值规定（0\false””），字段的更新是一个容易出现问题的点。（我就经常在这上面写出bug）按道理说，我们提供的更新功能，应该满足一下几点：

// PUT /score
{
	"id": 1,
	"name": "张三",
	"score": 100,
	"create_time": "2021-12-12"
}

// POST /score
{	
	"id": 1,
	"name": "不对，我叫李四",
	"score": 0,
	"create_time": ""
}

// POST /score
{
	"id": 1,
	"name": "我叫李四"
}

type UpdateScore struct{
	Id int 
	Name *string
	Score *int
	CreateTime *string
}

// POST /score
{	
	"id": 1,
	"name": "不对，我叫李四",
	"score": 100,
	"create_time": "2021-12-12"
}

6. 附录

虽然总结了5点事项，但我觉得，还有很多小知识点，其它的方面，可能不是一篇文章能写的尽的。若后期遇到或者碰到，也会继续总结出来。毕竟古人云，“学而时习之，不亦说乎”。没有总结，就看不到问题的全貌。 附上一些参考资料：