Background
I was often asked if it is possible to put API gateway and RPC service in the same process, and how to do it? There are also devs who put the external service and the message queue in the same process. Let's see how to solve such a problem more elegantly.
Problem
Let's use two mocking services as an example. We have two services that need to be started on two different ports in one process. The code is as following.
package main
import (
"fmt"
"net/http"
)
func morning(w http.ResponseWriter, req *http.Request) {
fmt.Fprintln(w, "morning!")
}
func evening(w http.ResponseWriter, req *http.Request) {
fmt.Fprintln(w, "evening!")
}
type Morning struct{}
func (m Morning) Start() {
http.HandleFunc("/morning", morning)
http.ListenAndServe("localhost:8080", nil)
}
func (m Morning) Stop() {
fmt.Println("Stop morning service...")
}
type Evening struct{}
func (e Evening) Start() {
http.HandleFunc("/evening", evening)
http.ListenAndServe("localhost:8081", nil)
}
func (e Evening) Stop() {
fmt.Println("Stop evening service...")
}
func main() {
// todo: start both services here
}
The code is simple enough to have a request for the morning service and the service returns morning! and a request for the evening service and the service returns evening. Let's try to implement it~
First try
Is it possible to start both services in main? Let's try.
func main() {
var morning Morning
morning.Start()
defer morning.Stop()
var evening Evening
Start()
Stop()
}
After starting, let's verify with curl.
$ curl -i http://localhost:8080/morning
HTTP/1.1 200 OK
Date: Mon, 18 Apr 2022 02:10:34 GMT
Content-Length: 9
Content-Type: text/plain; charset=utf-8
morning!
$ curl -i http://localhost:8081/evening
curl: (7) Failed to connect to localhost port 8081 after 4 ms: Connection refused
Why only morning succeeds, but evening cannot be requested?
Let's add a print statement to main and try
func main() {
fmt.Println("Start morning service...")
var morning Morning
morning.Start()
defer morning.Stop()
fmt.Println("Start evening service...")
var evening Evening
Start()
Stop() defer evening.
}
Re-run and see.
$ go run main.go
Start morning service...
It only prints Start morning service..., so the evening service is not started at all. The reason for this is that morning.Start() blocks the current goroutine, so the subsequent code is not executed.
Second try
This is where WaitGroup come in handy. As the name implies, WaitGroup is used to wait a group of operations and wait for them to be done so that the waiting goroutine can continue. Let's try it out.
func main() {
var wg sync.WaitGroup
wg.Add(2)
go func() {
defer wg.Done()
fmt.Println("Start morning service...")
var morning Morning
defer morning.Stop()
morning.Start()
Start() }()
go func() {
defer wg.Done()
fmt.Println("Start evening service...")
var evening Evening
defer evening.Stop()
evening.Start()
Start() }()
wg.Wait()
}
Try it.
$ go run main.go
Start evening service...
Start morning service...
Okay, both services are up, so let's verify with curl.
$ curl -i http://localhost:8080/morning
HTTP/1.1 200 OK
Date: Mon, 18 Apr 2022 02:28:33 GMT
Content-Length: 9
Content-Type: text/plain; charset=utf-8
morning!
$ curl -i http://localhost:8081/evening
HTTP/1.1 200 OK
Date: Mon, 18 Apr 2022 02:28:36 GMT
Content-Length: 9
Content-Type: text/plain; charset=utf-8
evening!
It works, and we see that our process with WaitGroup is
- remember that we have several services that need
wait - add the services one by one
- wait for all services to finish
Let's see how go-zero handle it~
Third try
In go-zero, we provide a ServiceGroup to easily manage the start and stop of multiple services. Let's see how it is done by using it in our scenario.
import "github.com/zeromicro/go-zero/core/service"
// more code here
func main() {
group := service.NewServiceGroup()
defer group.Stop()
group.Add(Morning{})
group.Add(Evening{})
group.Start()
}
As you can see, the code is much more readable and we can't accidentally miscalculate how many to add to WaitGroup. And ServiceGroup also makes sure that services that Start later Stop first, which is the same as defer, and makes it easier to clean up resources.
The ServiceGroup not only manages the Start/Stop of each service, but also provides graceful shutdown, which actively calls the Stop method of each service when a SIGTERM signal is received, and for HTTP services, you can exit gracefully with server.Shutdown for HTTP services and server.GracefulStop() for gRPC services.
Summary
The implementation of ServiceGroup is simple enough, with 82 lines of code.
$ cloc core/service/servicegroup.go
------------------------------------------------------------------
Language files blank comment code
------------------------------------------------------------------
Go 1 22 14 82
------------------------------------------------------------------
The code is short and concise, every service (Restful, RPC, MQ) is basically managed by ServiceGroup in go-zero, which is very convenient and worth reading.
Project address
https://github.com/zeromicro/go-zero
Welcome to use go-zero and star to support us!
Top comments (0)