面试题：Go语言中context如何在微服务间传递请求上下文

Question

在Go语言开发微服务场景下，描述一下如何通过context在不同微服务之间传递请求上下文，列举至少两种常见的传递方式，并说明它们的优缺点。

Answer 1

传递方式及优缺点

1. HTTP 头传递

   • 实现方式：在发送 HTTP 请求时，将 context 中的关键信息（如 trace ID、用户认证信息等）放在 HTTP 头中。接收方微服务从 HTTP 头中提取这些信息，重新构建 context。
   • 优点：
     • 简单直接，HTTP 协议本身支持头信息传递，不需要额外复杂的机制。
     • 跨语言兼容性好，只要不同微服务能够解析 HTTP 头，就可以实现 context 传递，便于与非 Go 语言开发的微服务交互。
   • 缺点：
     • 增加了 HTTP 请求的大小，如果传递的信息较多，可能影响性能。
     • 安全性问题，如果头信息未加密传输，可能导致敏感信息泄露。

2. RPC 框架传递

   • 实现方式：使用 gRPC 等 RPC 框架，在 RPC 调用时，将 context 作为参数传递给服务端。gRPC 本身支持 context 传递，在客户端发起调用时可以传入 context，服务端可以直接获取。
   • 优点：
     • 性能高，相比于 HTTP 头传递，RPC 框架在性能上更有优势，尤其适合内部微服务之间的高频调用。
     • 类型安全，在 RPC 定义中可以明确 context 相关参数的类型，减少错误。
   • 缺点：
     • 耦合度高，依赖特定的 RPC 框架，与其他框架或语言的集成相对复杂。
     • 学习成本较高，需要掌握 RPC 框架的使用，如 gRPC 的 protobuf 定义等。

3. 消息队列传递

   • 实现方式：当通过消息队列进行微服务间通信时，将 context 信息作为消息的一部分发送。接收方从消息中提取 context 信息，创建相应的 context。
   • 优点：
     • 异步解耦，适合异步处理场景，不影响消息的正常流转。
     • 灵活性高，可以根据业务需求灵活地在消息中添加或修改 context 信息。
   • 缺点：
     • 一致性问题，由于消息队列的异步特性，可能导致 context 信息与业务处理的一致性难以保证。
     • 可能增加消息的大小，影响消息队列的性能和吞吐量。