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




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.

duadpnld426905 对! 非常感谢你。 那是一种更清洁的方法。 非常感谢您的帮助。
一年多之前 回复
dongzhun6952 我提供了一些小例子...
一年多之前 回复
doucan8246326 非常感谢,这非常有帮助。 如果您不介意,请跟进问题。 如果不是全局的,您如何建议建立连接? 我将拥有使用同一连接的所有功能。 那是我在您的建议中不理解的部分。 再次感谢。
一年多之前 回复


Csdn user default icon