Context指的是标准库的context.Context,是一个接口对象,常用于异步IO控制以及上下文流程变量的传递。本文将要介绍的,是如何使用Context传递流程间共享变量。

Go的执行流程中,特别是HTTP/RPC执行流程中,不存在”全局变量”获取请求参数的方式,只有将上下文Context变量传递到后续流程的方法中,而Context上下文变量即包含了所有需要传递的共享变量。并且该Context中的共享变量应当是事先约定的,并且往往存储为对象指针形式。

通过Context上下文共享变量非常简单,以下我们通过一个项目中的示例来展示如何在实战化项目中传递和使用通用的共享变量。

一、结构定义

上下文对象中往往存储一些需要共享的变量,这些变量通常使用结构化的对象来存储,以方便维护。例如,我们在model定义一个上下文中的共享变量:

const (
	// 上下文变量存储键名,前后端系统共享
	ContextKey = "ContextKey"
)

// 请求上下文结构
type Context struct {
	Session *ghttp.Session // 当前Session管理对象
	User    *ContextUser   // 上下文用户信息
	Data    g.Map          // 自定KV变量,业务模块根据需要设置,不固定
}

// 请求上下文中的用户信息
type ContextUser struct {
	Id       uint   // 用户ID
	Passport string // 用户账号
	Nickname string // 用户名称
	Avatar   string // 用户头像
}

其中:

  1. model.ContextKey常量表示存储在context.Context上下文变量中的键名,该键名用于从传递的context.Context变量中存储/获取业务自定义的共享变量。
  2. model.Context结构体中的Session表示当前请求的Session对象,在GoFrame框架中每个HTTP请求对象中都会有一个空的Session对象,该对象采用了懒初始化设计,只有在真正执行读写操作时才会初始化。
  3. model.Context结构体中的User表示当前登录的用户基本信息,只有在用户登录后才有数据,否则是nil
  4. model.Context结构体中的Data属性用于存储自定义的KV变量,因此一般来说开发者无需再往context.Context上下文变量中增加自定义的键值对,而是直接使用model.Context对象的这个Data属性即可。详见后续介绍。

二、逻辑封装

由于该上下文对象也是和业务逻辑相关的,因此我们需要通过service对象将上下文变量封装起来以方便其他模块使用。

// 上下文管理服务
var Context = new(contextService)

type contextService struct{}

// 初始化上下文对象指针到上下文对象中,以便后续的请求流程中可以修改。
func (s *contextService) Init(r *ghttp.Request, customCtx *model.Context) {
	r.SetCtxVar(model.ContextKey, customCtx)
}

// 获得上下文变量,如果没有设置,那么返回nil
func (s *contextService) Get(ctx context.Context) *model.Context {
	value := ctx.Value(model.ContextKey)
	if value == nil {
		return nil
	}
	if localCtx, ok := value.(*model.Context); ok {
		return localCtx
	}
	return nil
}

// 将上下文信息设置到上下文请求中,注意是完整覆盖
func (s *contextService) SetUser(ctx context.Context, ctxUser *model.ContextUser) {
	s.Get(ctx).User = ctxUser
}

三、上下文变量注入

上下文的变量必须在请求一开始便注入到请求流程中,以便于其他方法调用。在HTTP请求中我们可以使用GoFrame的中间件来实现。在GRPC请求中我们也可以使用拦截器来实现。在service层的middleware管理对象中,我们可以这样来定义:

// 自定义上下文对象
func (s *middlewareService) Ctx(r *ghttp.Request) {
	// 初始化,务必最开始执行
	customCtx := &model.Context{
		Session: r.Session,
		Data:    make(g.Map),
	}
	service.Context.Init(r, customCtx)
	if userEntity := Session.GetUser(r.Context()); userEntity != nil {
		customCtx.User = &model.ContextUser{
			Id:       userEntity.Id,
			Passport: userEntity.Passport,
			Nickname: userEntity.Nickname,
			Avatar:   userEntity.Avatar,
		}
	}
	// 将自定义的上下文对象传递到模板变量中使用
	r.Assigns(g.Map{
		"Context": customCtx,
	})
	// 执行下一步请求逻辑
	r.Middleware.Next()
}

该中间件初始化了用户执行流程共享的对象,并且存储到context.Context变量中的对象是指针类型*model.Context。这样任何一个地方获取到这个指针,既可以获取到里面的数据,也能够直接修改里面的数据。

其中,如果Session中存在用户登录后的存储信息,那么也会将需要共享的用户基本信息写入到*model.Context中。

四、上下文变量使用

方法定义

约定俗成的,方法定义的第一个输入参数往往预留给context.Context类型参数使用,以便接受上下文变量,特别是service层的方法。例如:

// 执行用户登录
func (s *userService) Login(ctx context.Context, loginReq *define.UserServiceLoginReq) error {
    ...
}

// 查询内容列表
func (s *contentService) GetList(ctx context.Context, r *define.ContentServiceGetListReq) (*define.ContentServiceGetListRes, error) {
    ...
}

// 创建回复内容
func (s *replyService) Create(ctx context.Context, r *define.ReplyServiceCreateReq) error {
    ...
}

此外,约定俗成的,方法的最后一个返回参数往往是error类型。如果您确定此方法内部永不会产生error,那么可以忽略。

Context对象获取

通过service中封装的以下方法,将context.Context上下文变量传递进去即可。context.Context上下文变量在GoFrame框架的HTTP请求中可以通过r.Context()方法获取,在GRPC请求中,编译生成的pb文件中执行方法的第一个参数即固定是context.Context

service.Context.Get(ctx)

自定义Key-Value

通过以下方式设置/获取自定义的key-value键值对

// 设置自定义键值对
service.Context.Get(ctx).Data[key] = value

...

// 获取自定义键值对
service.Context.Get(ctx).Data[key]

五、注意事项

  1. 上下文变量只传递必须的链路参数数据,不要什么参数都往里面塞。特别是一些方法参数传参的数据,别往里面塞,而应当显示传递方法参数。
  2. 上下文变量仅用作运行时临时使用,不可持久化存储长期使用。例如将ctx序列化后存储到数据库,并再下一次请求中读取出来反序列化使用是错误做法。






Content Menu



  • No labels

34 Comments

  1. 如何不用session解决呢?

    1. context可用于流程变量的传递,session的使用场景不一样哦。

      1. 你好,为什么不使用golang自带的context包实现?

        1. 不就是用的标准库的context.Context吗?

      2. 感觉上面内容中的context就是起了个session的作用!!不懂


        1. 文中的context其实就是golang标准库中的context库,可参考context标准库说明及源码。context本身是用于流程中多个协程间共享变量的,这里是利用context的特性来充当session,但两者不是同一个东西

    2. session一般存放每个链接私有的数据,如每个登录账户的个性设置、账户信息等等。

      context一般存放所有链接公有的数据,如本系统所有链接都要用到的各种公有数据。

      应用场景不同,如果用session存放公有数据,那么会大量浪费内存;如果用context存放私有数据,那么会存在数据泄密风险。

      1. 感觉context更像是临时储存, 本次连接链路结束释放. 

  2. kkk

    上下文的变量必须在请求一开始便注入到请求流程中,以便于其他方法调用。

    这句话的意思是不是只能用中间件在一开始初始化上下文??

    1. 这句话的意思是你需要在流程中共享的数据结构(如自定义的Context对象),需要一开始就注入进去,不然后面取不到,最好的方式是使用中间件/拦截器。如果你在中间流程中再执行注入,可能会让其他人踩坑。

      1. 最好的方式是使用中间件/拦截器;你在中间注入进去可能会让其他人踩坑。

        这句话有点不理解了。不是在中间件中进行注入的吗?

        我一直以为是中间件中就注入的。难道我的理解错误了。

        1. 意思是你要在最早的地方注入值, 不要到处理一半半了还在注入. 你的同事会懵逼.

  3. kkk

    我试了一下 

    场景1 : 在一个api里设置context,在另一个 api获取不到context (无拦截器初始化context)

    场景2 : 在拦截里设置context,在一个API里可以获取并修改 

    这两个场景是对的?



    1. 你的问题不太严谨。context是流程间共享的,你需要把上下文变量传播给所有的方法,这个流程叫做propagate,上下文变量往往是方法的第一个参数。

  4. 我不喜欢每在控制器的每个方法都有 context参数,而是把它放到结构体里,如上面的 

    func (s *userService) Login(ctx context.Context, loginReq *define.UserServiceLoginReq) error {
        ...
    }

    我会写成

    func (s *userService) Login() error {
        ...}

    把 context跟req都丢到 userService中去,看起来就整结好多。


    1. 哈哈,放在第一个参数是为了形成规范约束,这样在传递上下文共享数据的时候肯定不会断掉链路。

      1. 恩,我看到google一些库也是这样,在很多函数都会有个context形参

      2. 我也喜欢放到对象中去。这样开发效率要高些。不用在不需要ctx的地方也强行声明一个ctx。只需要在用得上的地方直接使用就可以。不过按现在的单例模式来说,不好实现。要实现,在api层就得多实例才行。这个其实就是与之前我提出的事务问题是一类问题,也是一类解决方案。其实事务也可以用携带ctx的方式来解决。只是所有方法都声明一个ctx开参,真心很多地方有些冗余。很多地方用不到ctx。我们框架是否可以考虑采用多实例的方式来实现?而不是现在的这种单实例。不过多实例的话,应该要实现一个对象池才行。不然一直分配、释放内存,还是会影响性能。


        ctx传参,是传统的C语言的习惯。个人还是比较喜欢OOP的方式。一路跟着对象走。

        1. 在官方文档中同样建议ctx永远作为第一个参数传递给各个函数,而不是一开始使用一个struct的字段来保存ctx

  5. 我感觉我目前的项目用不太上,我只需要在中间件作权限验证后共享一下用户ID,用一下r.SetCtxVar和r.GetCtxVar足以。

  6. 是否可总结为如下:

    1. model包含数据定义

    2. service包含操作数据的接口/方法

    3. middlewear里通过service来操作model以达到共享上下文的结果

  7. 我用全局变量的方式进行传递会不会有问题

    type global struct {
        User  gdb.Record
        Token string
        CxtID string
    }
    var Global = global{}

    其它方法中调用

    config.Global.User 
    1. 想全局随时使用,可以试试通过获取GoroutineID来处理,以GoroutineID来做map的key,将变量进行存储。只是这样性能可能会低一些。因为每次使用时都要获取当前GoroutineID

      func getGoroutineID() uint64 {
          b := make([]byte, 32)
          runtime.Stack(b, false)
          //fmt.Println(string(b))
          b = bytes.TrimPrefix(b, []byte("goroutine "))
          b = b[:bytes.IndexByte(b, ' ')]
          n, _ := strconv.ParseUint(string(b), 10, 64)
      
          return n
      }
      1. 如果是HTTP请求,由于每个请求都是单独创建goroutine来处理,因此使用goroutine id存储goroutine级别的"全局变量"是可实现的,通过gdebug.GoroutineId()可以获取到当前goroutineid。但是,我个人不推荐这么做。我推荐的做法还是将需要共享的变量通过ctx传递下去。

        1. 找了半天的goroutine id原来在 gdebug里。。。^_^。我现在改造router多实例化中,这样就可以直接把这类“全局”的存储在当前实例中了,当然为了方便,也只是传递了ctx下去。获取与设置时,还是利用ctx来的。只是相对方便些。可以隐藏ctx传递

          1. 不推荐使用goroutine id来实现local storage的设计,效率太低了,通过堆栈访问方式获取gooutine id至少是微秒级别一次(我测试了下本机是3微秒以上)。并且这种设计会在异步编程时降低变量获取效率,并且需要关注更多的"全局"变量并发安全控制。

            1. 所以,我才想法设法的把api调用多实例化,通过实例来携带数据进行隐式传参,会比使用goroutine id方式高许多。现在单实例,如果想携带数据,除了ctx显式传参,取巧的方式就是goroutine id了。最近多实例化的方式都改造好了,从api到service到dao层,现在都是隐式传递ctx。然后在ctx里如你所说的,加了个map指针作为全局变量在座用。不过这个就个人用用,没写测试用例,不能保证全是OK的。嘿嘿~

              只是,为了想使用自动化补全,很多东东就没办法封到库中去了。只有写在项目了,不然不提醒我。比如在api中调用service,我现在是 

              type Api truct {

                    api.Base

              }


              func (api *Api) a(r *Request) {

                      api.Service.AuthService().auth()

              }

              由于api.Base中实现过Init方法,所以实例化时,会调用Base中的Init进行初始化(这里我给改造了下router注册,反射用得不熟,测试好像反射里的method好像取不到父类的Init吧?所以我给改成了使用接口来取Init方法),反正现在可以调用到父类中的Init与Shut就对了。


              在Api Init中,我会将 r 的ctx传给service保存起来。然后当在service中调用时,会使用 s.Dao.AuthDao()的方式来取Dao对象,同时在AuthDao中也会将service中的ctx传给它。这样全程就都可以使用ctx了。然后在其上再封装个SetData与GetData,就相当于可以随时随时使用全局变量了。


              同时,由于ctx一直可以传递,所以事务处理时,也可以很方便,封装下后不用再显式地传递ctx了。这样,不管之前的Dao调用时有没有传递ctx,在外层发起事务时,它都会被包含在事务之内。


              不过我没测试过性能如何。相较单实例的性能损失主要是在对象创建上,所以对象创建我是依靠gpool来做的。给设置成5分钟过期。应该性能还是能保障的。


              现在觉得能封装的代码,我给封了下,放在了joy999/gf-boost at develop (github.com) 里。给指导指导^_^。回头我再把项目里的部分整理出来写个demo。不然整体上不全

      2. 多层go function(){}()时失效。

      3. 当我在协程里面再开几个协程时,在这些新开出来的协程中调用gdebug.GoroutineId()估计会出问题,拿不到http那条协程的ID,只拿到当前协程的ID

  8. GF里能增加注解模块就好了,可以注解方式注入

  9. 单元测试时如果业务代码中需要获取ctx中的数据,就会报异常.需要有大佬指教一下

  10. 现在有的资料都是在service中获取和设置.我的问题是如何在控制器中如何设置和获取上下文信息呢.虽然控制器中有个ctx参数.

  11. Fed

    func (s *modelService) anyFunction(ctx context.Context, req *ghttp.Request) res *ghttp.Response, error {
        ...
    }

    其实你这样的ctx参数布局很像node中的Koa,但我觉得上面才是“规范标准式”。但如果是这样就会显得代码很冗长,但不影响可读性。