Як зупинити http.ListenAndServe ()

Я використовую бібліотеку Mux від Gorilla Web Toolkit разом із серверним сервером Go http.

Проблема полягає в тому, що в моїй програмі сервер HTTP є лише одним компонентом, і його потрібно зупиняти та запускати на мій розсуд.

Коли я називаю http.ListenAndServe(fmt.Sprintf(":%d", service.Port()), service.router)це блоками, і я не можу зупинити роботу сервера.

Я усвідомлюю, що це була проблема в минулому, чи все ще так? Чи є якісь нові рішення?

Щодо витонченого вимкнення (представленого в Go 1.8), трохи конкретніший приклад:

package main

import (
    "context"
    "io"
    "log"
    "net/http"
    "sync"
    "time"
)

func startHttpServer(wg *sync.WaitGroup) *http.Server {
    srv := &http.Server{Addr: ":8080"}

    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        io.WriteString(w, "hello world\n")
    })

    go func() {
        defer wg.Done() // let main know we are done cleaning up

        // always returns error. ErrServerClosed on graceful close
        if err := srv.ListenAndServe(); err != http.ErrServerClosed {
            // unexpected error. port in use?
            log.Fatalf("ListenAndServe(): %v", err)
        }
    }()

    // returning reference so caller can call Shutdown()
    return srv
}

func main() {
    log.Printf("main: starting HTTP server")

    httpServerExitDone := &sync.WaitGroup{}

    httpServerExitDone.Add(1)
    srv := startHttpServer(httpServerExitDone)

    log.Printf("main: serving for 10 seconds")

    time.Sleep(10 * time.Second)

    log.Printf("main: stopping HTTP server")

    // now close the server gracefully ("shutdown")
    // timeout could be given with a proper context
    // (in real world you shouldn't use TODO()).
    if err := srv.Shutdown(context.TODO()); err != nil {
        panic(err) // failure/timeout shutting down the server gracefully
    }

    // wait for goroutine started in startHttpServer() to stop
    httpServerExitDone.Wait()

    log.Printf("main: done. exiting")
}

Як зазначено у yo.ian.gвідповіді. Go 1.8 включив цю функцію у стандартну бібліотеку.

Мінімальний приклад для Go 1.8+:

    server := &http.Server{Addr: ":8080", Handler: handler}

    go func() {
        if err := server.ListenAndServe(); err != nil {
            // handle err
        }
    }()

    // Setting up signal capturing
    stop := make(chan os.Signal, 1)
    signal.Notify(stop, os.Interrupt)

    // Waiting for SIGINT (pkill -2)
    <-stop

    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()
    if err := server.Shutdown(ctx); err != nil {
        // handle err
    }

    // Wait for ListenAndServe goroutine to close.

Оригінальна відповідь - Pre Go 1.8:

Спираючись на відповідь Увеличителя .

Ви можете створити власну версію, ListenAndServeяка повертає io.Closerі не блокує.

func ListenAndServeWithClose(addr string, handler http.Handler) (io.Closer,error) {

    var (
        listener  net.Listener
        srvCloser io.Closer
        err       error
    )

    srv := &http.Server{Addr: addr, Handler: handler}

    if addr == "" {
        addr = ":http"
    }

    listener, err = net.Listen("tcp", addr)
    if err != nil {
        return nil, err
    }

    go func() {
        err := srv.Serve(tcpKeepAliveListener{listener.(*net.TCPListener)})
        if err != nil {
            log.Println("HTTP Server Error - ", err)
        }
    }()

    srvCloser = listener
    return srvCloser, nil
}

Повний код доступний тут .

Сервер HTTP закриється з помилкою accept tcp [::]:8080: use of closed network connection

Go 1.8 включатиме витончене та примусове вимкнення, доступне через Server::Shutdown(context.Context)та Server::Close()відповідно.

go func() {
    httpError := srv.ListenAndServe(address, handler)
    if httpError != nil {
        log.Println("While serving HTTP: ", httpError)
    }
}()

srv.Shutdown(context)

Відповідний коміт можна знайти тут

Ви можете побудувати net.Listener

l, err := net.Listen("tcp", fmt.Sprintf(":%d", service.Port()))
if err != nil {
    log.Fatal(err)
}

які ви можете Close()

go func(){
    //...
    l.Close()
}()

і http.Serve()на ньому

http.Serve(l, service.router)

Оскільки жодна з попередніх відповідей не говорить, чому ви не можете цього зробити, якщо використовуєте http.ListenAndServe (), я зайшов у вихідний код http v1.8, і ось що там сказано:

func ListenAndServe(addr string, handler Handler) error {
    server := &Server{Addr: addr, Handler: handler}
    return server.ListenAndServe()
}

Як бачите, функція http.ListenAndServe не повертає змінну сервера. Це означає, що ви не можете потрапити на "сервер", щоб скористатися командою вимкнення. Тому вам потрібно створити власний екземпляр "сервера" замість того, щоб використовувати цю функцію для витонченого вимкнення.

Ви можете закрити сервер, закривши його контекст.

type ServeReqs func(ctx context.Context, cfg Config, deps ReqHandlersDependencies) error

var ServeReqsImpl = func(ctx context.Context, cfg Config, deps ReqHandlersDependencies) error {
    http.Handle(pingRoute, decorateHttpRes(pingHandlerImpl(deps.pingRouteResponseMessage), addJsonHeader()))

    server := &http.Server{Addr: fmt.Sprintf(":%d", cfg.port), Handler: nil}

    go func() {
        <-ctx.Done()
        fmt.Println("Shutting down the HTTP server...")
        server.Shutdown(ctx)
    }()

    err := server.ListenAndServeTLS(
        cfg.certificatePemFilePath,
        cfg.certificatePemPrivKeyFilePath,
    )

    // Shutting down the server is not something bad ffs Go...
    if err == http.ErrServerClosed {
        return nil
    }

    return err
}

І щоразу, коли ви готові його закрити, телефонуйте:

ctx, closeServer := context.WithCancel(context.Background())
err := ServeReqs(ctx, etc)
closeServer()

Це можна вирішити за context.Contextдопомогою a net.ListenConfig. У моєму випадку, я не хочу використовувати sync.WaitGroupабо http.Server«s Shutdown()виклик, і замість того, щоб покладатися на context.Context(який був закритий з сигналом).

import (
  "context"
  "http"
  "net"
  "net/http/pprof"
)

func myListen(ctx context.Context, cancel context.CancelFunc) error {
  lc := net.ListenConfig{}
  ln, err := lc.Listen(ctx, "tcp4", "127.0.0.1:6060")
  if err != nil {
    // wrap the err or log why the listen failed
    return err
  }

  mux := http.NewServeMux()
  mux.Handle("/debug/pprof/", pprof.Index)
  mux.Handle("/debug/pprof/cmdline", pprof.CmdLine)
  mux.Handle("/debug/pprof/profile", pprof.Profile)
  mux.Handle("/debug/pprof/symbol", pprof.Symbol)
  mux.Handle("/debug/pprof/trace", pprof.Trace)

  go func() {
    if err := http.Serve(l, mux); err != nil {
      cancel()
      // log why we shut down the context
      return err
    }
  }()

  // If you want something semi-synchronous, sleep here for a fraction of a second

  return nil
}

Те, що я робив для таких випадків, коли програма є лише сервером і не виконує жодної іншої функції, - це встановити http.HandleFuncдля такого шаблону, як /shutdown. Щось на зразок

http.HandleFunc("/shutdown", func(w http.ResponseWriter, r *http.Request) {
    if <credentials check passes> {
        // - Turn on mechanism to reject incoming requests.
        // - Block until "in-flight" requests complete.
        // - Release resources, both internal and external.
        // - Perform all other cleanup procedures thought necessary
        //   for this to be called a "graceful shutdown".
        fmt.Fprint(w, "Goodbye!\n")
        os.Exit(0)
    }
})

Для цього не потрібно 1.8. Але якщо доступний 1.8, то os.Exit(0), на мою думку , це рішення може бути вбудовано сюди замість виклику, якщо це бажано.

Код для виконання всієї цієї роботи з очищення залишається вправою для читача.

Додатковий кредит, якщо ви можете сказати, де цей код очищення може бути найбільш розумно розміщений, оскільки я б не рекомендував робити це тут, і як це звернення до кінцевої точки повинно викликати цей код.

Більше додаткового кредиту, якщо ви можете сказати, де цей os.exit(0)дзвінок (або будь-який вихід із процесу, який ви вирішите використовувати), наведений тут лише для ілюстративних цілей, буде найбільш розумно розміщений.

І все-таки ще більше додаткового кредиту, якщо ви можете пояснити, чому цей механізм сигналізації процесу HTTP-сервера слід розглядати перш за все інші такі механізми, які вважаються працездатними у цьому випадку.