duanli9569 2019-05-09 20:27 采纳率: 100%
浏览 753




var userConn *grpc.ClientConn
var userServiceName string

func init() {
    userServiceName := os.Getenv("USER_SERVICE_URL")
    if userServiceName == "" {
        userServiceName = "localhost"
    logging.LogDebug("userClient:  Connecting to: "+userServiceName, "")
    tempConn, err := grpc.Dial(userServiceName, grpc.WithInsecure())
    if err != nil {
        logging.LogEmergency("account_user_client.Init()  Could not get the connection.  "+err.Error(), "")
    userConn = tempConn


c := user.NewUserClient(userConn)
// Contact the server and print out its response.
ctx, cancel := context.WithTimeout(context.Background(), time.Second)
defer cancel()
r, err := c.GetUserFromTokenID(ctx, &user.GetUserFromTokenRequest{TransactionID: transactionID, OathToken: *oathToken})
//Handle Error and Response



  • 写回答

2条回答 默认 最新

  • douqiang4501 2019-05-09 22:48

    Yes, it's fine to have single GRPC client connection per service. Moreover, I don't see any other options here. GRPC does all the heavy lifting under the hood: for example, you don't need to write your own client connection pool (as you would do for a typical RDBMS), because it won't provide better results than a single GRPC connection.

    However I would suggest you to avoid using global variables and init functions, especially for networking setup. Also you don't need to create GRPC client (c := user.NewUserClient(userConn)) every time you post a request to the GRPC service: this is just an extra work for garbage collector, you can create the only instance of client at the time of application startup.


    Assuming that you're writing server application (because it can be seen from the method you call on the remote GRPC service), you can simply define a type that will contain all the objects that have the same lifetime as the whole application itself. According to the tradition, these types are usually called "server context", though it's a little bit confusing because Go has very important concept of context in its standard library.

       // this type contains state of the server
       type serverContext struct {
           // client to GRPC service
           userClient user.UserClient
           // default timeout
           timeout time.Duration
           // some other useful objects, like config 
           // or logger (to replace global logging)
           // (...)       
       // constructor for server context
       func newServerContext(endpoint string) (*serverContext, error) {
           userConn, err := grpc.Dial(endpoint, grpc.WithInsecure())
           if err != nil {
               return nil, err
           ctx := &serverContext{
              userClient: user.NewUserClient(userConn),
              timeout: time.Second,
           return ctx, nil
       type server struct {
           context *serverContext
       func (s *server) Handler(ctx context.Context, request *Request) (*Response, error) {
           clientCtx, cancel := context.WithTimeout(ctx, time.Second)
           defer cancel()
           response, err := c.GetUserFromTokenID(
                  TransactionID: transactionID,
                  OathToken: *oathToken,
           if err != nil {
                return nil, err
           // ...
       func main() {
           serverCtx, err := newServerContext(os.Getenv("USER_SERVICE_URL"))
           if err != nil {
           s := &server{serverCtx}
           // listen and serve etc...

    Details may change depending on what you're actually working on, but I just wanted to show that it's much more better to encapsulate state of your application in an instance of distinct type instead of infecting global namespace.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?



  • ¥15 CST2023安装报错
  • ¥15 使用diffusionbert生成文字 结果是PAD和UNK怎么办
  • ¥15 有人懂怎么做大模型的客服系统吗?卡住了卡住了
  • ¥20 firefly-rk3399上启动卡住了
  • ¥15 如何删除这个虚拟音频
  • ¥50 hyper默认的default switch
  • ¥15 网站打不开,提示502 Bad Gateway
  • ¥20 基于MATLAB的绝热压缩空气储能系统代码咨询
  • ¥15 R语言建立随机森林模型出现的问题
  • ¥15 中级微观经济学,生产可能性边界问题