As the next generation of microservices architecture, Service Mesh takes the communication between services out of the infrastructure to deliver more reliable application requests, monitor and control traffic. Service Mesh is typically deployed together with applications, acting as a “data plane” agent network and a “control plane” to interact with other agents in place of applications. The emergence of Service Mesh frees business developers from the low-level details of the infrastructure to focus more on business development and improve the efficiency of requirements iteration.
In this article, we will use the Service Registration and discovery toolkit provided by Go-Kit to complete Service registration and discovery, and introduce how Istio performs Service registration and discovery in Service Mesh.
Use the Go-Kit service registration and Discovery toolkit
Independent development of service registration and discovery client can deepen our understanding of microservices and the interaction process of service registration and discovery center, but it will also increase the understanding cost of developers. For example, to understand the interface provided by service registration and discovery center and the specific details of submitted data, As well as the need to maintain the client code continuously to avoid unavailability during service Registry and Discovery Center version upgrade iterations or API updates, etc.
Go-kit, as a set of microservices tools, is intended to help developers solve most of the problems encountered in microservices development, allowing them to focus more on business development.
Go-kit provides client implementations of many service registration and discovery components, supporting multiple service registration and discovery centers including Consul, Etcd, ZooKeeper, and Eureka. Let’s take Consul as an example to see how to use go-Kit’s SD package to simplify the implementation of microservice service registration and discovery.
The SD package provides the following registration and deregistration interfaces, as shown below:
type Registrar interface {
Register() // Service registration
Deregister() // Service logout
}
Copy the codeIn Go-Kit, we instantiate the Registrar interface corresponding to the service registration and discovery component and use the same interface to register and deregister services. Next, the Registrar under the SD/Consul package is instantiated to interact with Consul. The instantiation code is as follows:
func NewDiscoveryClient(host string, port int, registration *api.AgentServiceRegistration) (*DiscoveryClient, error) {
config := api.DefaultConfig()
config.Address = host + ":" + strconv.Itoa(port)
// Generate hashicorp client
client, err := api.NewClient(config)
iferr ! =nil{
return nil, err
}
// Generate SD Consul Client using hashicorp Client
sdClient := consul.NewClient(client)
return &DiscoveryClient{
client: sdClient,
config: config,
registration: registration,
register: consul.NewRegistrar(sdClient, registration, log.NewLogfmtLogger(os.Stderr)),
}, nil
}
Copy the codeDiscoveryclient. register is the Consul registry that is finally instantiated. The ConsulRegistrar implementation relies on sd.consul.client and the sd.Consul.client implementation relies on the Hashicorp Client, consul’s official implementation Client, from the instantiation process. Digging into the implementation of service registration and discovery in the Hashicorp Client will reveal that it is also done by requesting the HTTP API provided by Consul Agent in much the same way as we did in the previous lesson. API. AgentServiceRegistration structure which need to submit to the Consul in service instance information, include the service name and service instance ID, the basic information such as address and service port.
Our service registration and service deregistration implementations can then be delegated to Register, as follows:
func (consulClient *DiscoveryClient) Register(ctx context.Context) {
consulClient.register.Register()
}
func (consulClient *DiscoveryClient) Deregister(ctx context.Context) {
consulClient.register.Deregister()
}
Copy the codeThe implementation of service discovery is also a direct call to the related methods provided by sd.consul.client. By using the Consul toolkit provided by Go-Kit, service registration and discovery can be completed by simply calling the methods provided in the package without understanding the specific interaction logic between Microservice and Consul, greatly reducing the development effort of business personnel.
Istio services are registered and discovered in the Service Mesh
Istio, as one of the landing products of Service Mesh, has become one of the most popular Service Mesh thanks to the rapid development of Kubernetes. Istio is logically divided into data plane and control plane.
- The Data plane, consisting of a set of high-performance intelligent proxies (enbith-modified isTIo-Proxies), controls and coordinates all network traffic for the proxyed service, as well as collects and reports related monitoring data.
- The control plane is responsible for formulating application policies to control the routing of network traffic.
Istio consists of several components. The core components and their functions are as follows:
- Ingressgateway controls the access of external traffic to Istio services.
- Egressgateway controls the traffic between Istio and external services.
- Pilot, which manages service and traffic policies within the service grid. It propagates high-level routing rules for service information and traffic control to the Proxy at run time, and abstracts the platform-specific service discovery mechanism into a standard format that the Proxy can use.
- Citadel, which provides identity authentication and credentials management.
- Galley, responsible for validating, extracting, processing, and distributing configurations.
- Proxy, acting as a Service Proxy, regulates the inbound and outbound traffic of all Service Mesh units.
Proxy belongs to the data plane and is deployed in Pod with applications in the form of Sidecar, while Pilot, Citadel, and Galley belong to the control plane. In addition, additional plug-ins such as Grafana, Istio-Tracing, Kiali, and Prometheus are available for visual data viewing, traffic monitoring, and link tracing.
Istio provides the following installation profiles by default. Component configurations enabled in these profiles are as follows (+ indicates enabled, blank indicates disabled, and – indicates unknown) :
| | * * * * configuration default | demo | minimal | remote | empty | preview | | : – : | : – | : – : | : | : – : | : | : – : | : | : – : | : | : – : | : | : – : | : – | | components/plugins | | | | | | | | Ingressgateway | + | + | | + | | – | | Egressgateway | | + | | | | – | | istiod | + | + | + | | | – | | grafana | | + | | | | – | | tracing | | + | | | | – | | kiali | | + | | | | – | | prometheus | + | + | | | | – |
The ISTIOD encapsulates control plane components, such as Pilot, Citadel, and Galley, and packages them in a unified manner, reducing the difficulty in maintaining and managing multiple components. As you can see from the above table, DemoProfile is the most comprehensive configuration list, suitable for learning and function demonstration. The PreviewProfile will probably use some development-phase test components, which may or may not be enabled. Defaultprofile is officially recommended for installation because of its optimal selection of core components and plug-ins, such as Ingressgateway and Istiod enabled for components and Prometheus enabled for plug-ins.
We can also choose the appropriate profile to install and start the installation according to the requirements of the practice. For example, in the following installation command we use demoprofile:
istioctl manifest apply --set profile=demo
Copy the codeThe preceding commands use Demoprofile to deploy Istio. Istio in this configuration can monitor all aspects of Istio applications on a visual interface. Istio injects the Proxy into the Pod that the application is running as a Sidecar, taking over the network inflow and outflow of the application. We can make the Sidecar injector automatically inject Proxy into the Pod started in Kubernetes namespace by marking it as follows:
kubectl label namespace default istio-injection=enabled
Copy the codeIn the above command, we mark the default namespace as istio-injection. If you do not want to enable the command space tag, inject Proxy Sidecar container for Pod through istioctl kube-inject. Next, we inject the Proxy into the Pod where the Register service is located with the following command:
istioctl kube-inject -f register-service.yaml | kubectl apply -f -
Copy the codeThe YAML configuration of register is as follows:
apiVersion: apps/v1 kind: Deployment metadata: name: register labels: name: register spec: selector: matchLabels: name: Register replicas: 1 template: metadata: name: register labels: name: register app: register # containers: - name: register image: register ports: - containerPort: 12312 imagePullPolicy: IfNotPresent # ... ApiVersion: v1 kind: Service metadata: name: register-service labels: name: register-service spec: selector: name: register ports: - protocol: TCP port: 12312 targetPort: 12312 name: register-service-httpCopy the codeThe major changes include the addition of a Deployment Controller for the Register Service, a new tagging APP, and the corresponding Service resource for the Register Service. If the Kiali plug-in is started during Istio deployment, you can view the information about the Register service on the Kiali platform. Run the following command to open the Kiali control panel. The default account and password are admin:
istioctl dashboard kiali
Copy the code
As you can see from the figure above, there are multiple dimensions in the Kiali console.
- Overview, grid Overview, showing all namespaces with services within Istio;
- Graph, service topology;
- Applications, the application dimension, identifies the app with the app tag set;
- Workloads detect resources in Kubernetes, including Deployment, Job, DaemonSet, etc., whether they are added to Istio or not.
- Kubernetes Services;
- Istio Config: Configures dimensions and displays information about Istio configuration classes.
After the register service is started, we can see the figure of register in the dimensions of Applications, Workloads and Services, as shown in the dimensions of Applications below:
Relying on the rapid development and promotion of Kubernetes, Istio has a strong dependence on Kubernetes, and its Service registration and discovery implementation also mainly depends on Kubernetes Service management. The following diagram illustrates Istio’s service registration and discovery.
From the logical diagram, we can see that Istio service registration and discovery mainly involve the following modules.
- ConfigController: Manages configuration data, including user-configured traffic management and routing rules.
- ServiceController: Is responsible for loading various ServiceRegistry and synchronizing services that need to be managed in the grid from ServiceRegistry. KubeServiceRegistry is used to synchronize Service and Endpoint from Kubernetes to Istio. ConsulServiceRegistry: Synchronize service information from Consul to Istio ExternalServiceRegistry listens for configuration changes in ConfigController, obtains ServiceEntry and WorkloadEntry resources, encapsulates them as service data, and provides them to ServiceController.
- DiscoveryServer: encapsulates the route configuration information in the ConfigController and service information in the ServiceController into a standard format that can be understood by the Proxy and delivers it to the Proxy.
The Pilot component collects available Service data from Service Registries, such as Service in Kubernetes and Consul, into Istio and converts these services into a standard Service format that proxies can understand. The routing rules and traffic control policies configured by the user are delivered to the Proxy. When the proxied application initiates HTTP communication based on the service ID, the Proxy obtains the corresponding service data from the intercepted network request based on the service ID, and selects an appropriate instance to forward the request based on the delivered routing rules.
Based on the rapid development of Kubernetes-based Istio, the most complete support for Service registration and discovery components is also Kubernetes, which relies on Kubernetes’ monitoring of resources such as Pod and Service. Provides flexibility, load balancing, retry, fusing, and traffic limiting for inter-service invocation.
On the other hand, integration and support for third-party service registration and discovery components, such as Consul, Istio’s official implementation is only at the basic level of availability and still needs to be polished and tested in terms of performance and ease of use. Therefore, in the implementation of Istio, it is recommended that Istio be strongly bound with Kubernetes to maximize its functions.
summary
Service registration and discovery is one of the cornerstones of micro service architecture ground practice, because of the centralized service registration and discovery center management a large number of dynamic change of service instance, lets the application service without too much pressure under the condition of micro split and lateral extension service, enhance the flexibility of micro service architecture and scalability.
In this article, we first introduced the Service Registration and discovery toolkit in go-Kit and used the Consul toolkit to improve the implementation of service registration and discovery for the Register service. We then introduced Istio, the leader of the Service Mesh, and its implementation of Service registration and discovery. Istio itself does not provide service discovery capabilities, but it can rely on Kubernetes or third-party service registries to obtain a list of service information and make effective dynamic calls according to the set routing rules. Hopefully, this course will not only deepen your understanding of service registration and discovery in Go microservices, but also understand how Istio implements service registration and discovery at the proxy level.
Recommended reading
The interview collection
