Shulou(Shulou.com)05/31 Report--

Many novices are not very clear about how to explore the native core engine of Dubbo-go cloud in Nacos Go micro-services. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

In recent years, with the gradual development and growth of the Go language community, more and more companies have begun to try to use Go to build micro-service systems, and a number of Go micro-service frameworks have emerged, such as go-micro, go-kit, Dubbo-go, etc., and components related to micro-service governance have gradually begun to work in Go. For example, Sentinel and Hystrix have launched Go language versions, and as the core engine of the micro-service framework-registry. Is also an indispensable component, there are already a number of registries to support the Go language, how to choose? We can compare the current mainstream registries that support the Go language.

Figure 1

According to the comparison of the above table, we can draw conclusions from the following dimensions:

Ecology: all registries support Go, but the Nacos, Consul and Etcd communities are active, while zookeeper and Eureka communities are less active.

Ease of use: Nacos, Eureka and Consul all have ready-made management and control platforms. Etcd and zookeeper themselves as kv storage, there is no corresponding control platform. Nacos supports Chinese interface, which is more in line with the habits of Chinese people.

Scenario support: CP model is mainly for strongly consistent scenarios, such as finance, AP model is suitable for high availability scenarios, Nacos can meet both scenarios, Eureka mainly meets high availability scenarios, Consul, Zookeepr and Etcd mainly meet strong consistent scenarios, and Nacos supports synchronizing data from other registries to facilitate user registry migration

Functional integrity: all registries support health check, and Nacos and Consul support many check methods to meet different application scenarios. Zookeeper can perceive instance changes in real time through keep alive. Nacos, Consul and Eureka all support load balance policies, and Nacos supports more flexible policies through Metadata selector. In addition, Nacos and Eureka all support avalanche protection to avoid avalanche effects on healthy instances due to too many unhealthy instances.

Based on the comparison of the above dimensions, we can see that Nacos has certain advantages as a registry, so how is it doing in the integration of Go microservices ecology? To this end, we have planned this series of articles, which will introduce some of the work and practical experience of Nacos in the ecological integration of Go microservices. The series will consist of the following three chapters:

Exploration of Dubbo-go Cloud Native Core engine

A preliminary study on external dynamic data sources of Sentinel-go

Go-micro Integration Nacos practice

Let's first explore how Nacos integrates with Dubbo-go.

Introduction

Dubbo-go is currently one of the hottest projects in Dubbo's multilingual ecology, and it has been five years since it was launched in 2016. Recently, Dubbo-go released v1.5, which is fully compatible with Dubbo 2.7.x, and supports service registration and discovery in the application dimension, which is consistent with the mainstream registration model, which marks a key step for Dubbo-go to be cloud native.

The registry, as the core engine that drives the service operation, also needs to adapt after switching to the registration model of the application dimension. This paper will analyze how to use Nacos as the core engine to realize the service registration and discovery of the application dimension, and give the corresponding practice case. In addition, the code of this paper is based on Dubbo-go v1.5.1 and Nacos v1.3.2.

Service Registration and Discovery Architecture

From the architecture, we can see that unlike the service registration discovery at the interface level, Dubbo-go 's provider will call Nacos-go-sdk 's RegisterInstance API to register the service instance with Nacos after startup, and the registered service name is the application name, not the interface name. After Conusmer starts, it calls the Subscribe API to subscribe to the service instance changes of the application, and initiates a service call to the instance of the application.

Figure 2

Service model

Figure 3 is our Dubbo-go application dimension service discovery model, which mainly has two hierarchical relationships between service and instance. The attributes of service instance mainly include instance Id, host address, service port, activation status and metadata. Figure 4 shows the service hierarchical storage model of Nacos, which includes three levels: service, cluster and instance. Compared with the two, there is one more level of the cluster dimension, and the instance attribute information can be completely matched.

So when Dubbo-go registers the application service instance to Nacos, we only need to set the cluster as the default cluster and fill in the relevant properties of the service and instance to complete the matching on the service model. In addition, Nacos can register services under different Namespace to achieve multi-tenant isolation.

Figure 3

Figure 4

Service instance heartbeat maintenance

After registering the application service instance information with Nacos, the Provider of Dubbo-go needs to actively report the heartbeat to let the Nacos server know whether the instance is alive or not to determine whether to remove the node from the instance list. The work of maintaining the heartbeat is done in Nacos-SDK-go. As can be seen in the code in figure 5, when Dubbo-go calls RegisterInstance to register a service instance, SDK not only calls Nacos's Register API, but also calls AddBeatInfo to add service instance information to the local cache. Service instance information is regularly sent to Nacos through background collaboration to maintain the heartbeat.

When the service is offline, the anti-registration can be performed by calling DeRegisterInstance, and the local heartbeat retention task can be removed, and the instance will also be removed from the Nacos instance list.

Figure 5

Subscription service instance change

Dubbo-go 's Consumer calls Nacos-SDK-go 's Subscribe API when it starts. The API input is shown in figure 6. When subscribing, you only need to pass ServiceName, that is, the application name and the callback function SubscribeCallback,Nacos, to notify Dubbo-go through the callback function when the service instance changes. How does Nacos-SDK-go perceive changes in the service instance of Nacos? There are two main ways:

Nacos server actively pushes. When Nacos-SDK-go starts, it listens on a UDP port, which is passed as a parameter when calling Nacos Register API. Nacos records Ip and port. When the service instance changes, Nacos sends UDP requests to all Ip and ports listening to the service, and pushes the changed service instance information.

Nacos-SDK-go queries periodically. SDK calls the query API regularly on the subscribed service instance, and notifies Dubbo-go through the callback API if the query changes. As a backstop policy, it ensures that the Nacos server can still perceive the change after the push fails.

Figure 6

In addition, Nacos-SDK-go also supports push empty protection. When the list of instances pushed by Nacos is empty, the local cache is not updated and Dubbo-go changes are not notified, so as to avoid failure caused by Consumer being called without available instances. At the same time, SDK also supports local persistent storage of service instance information, which ensures that Consumer restart can also obtain available instances during Nacos service failure, with disaster recovery effect.

Example practice 1. Environmental preparation

Dubbo-go samples code download: https://github.com/apache/dubbo-samples/tree/master/golang, the hello world code directory discovered by the application-level service based on the Nacos registry is at registry/servicediscovery/nacos

Figure 7

To build the Nacos server, refer to the official document: https://nacos.io/zh-cn/docs/quick-start.html, or use the official public Nacos service: http://console.nacos.io/nacos( account password: nacos, for testing only), or purchase Ali Cloud service: https://help.aliyun.com/document_detail/139460.html.

2. Build the Server end

When you enter the registry/servicediscovery/nacos/go-server/profiles file, you can see that there are three folders: dev, release and test, corresponding to development, test and production configuration, respectively. We use dev configuration to build the development environment. There are log.yml and server.yml files under the dev file. Modify the server.yml configuration below.

Remote configuration, where the public Nacos service is used, and address supports the configuration of multiple addresses, separated by commas. The params parameter configures the log directory of the nacos-sdk.

Remote: nacos: address: "console.nacos.io:80" timeout: "5s" params: logDir: "/ data/nacos-sdk/log"

ConfigCenter configuration:

Config_center: protocol: "nacos" address: "console.nacos.io:80"

Configure the server-side environment variables:

Server.yml file path on export CONF_PROVIDER_FILE_PATH=server side log.yml file path on export APP_LOG_CONF_FILE=server side

Go to registry/servicediscovery/nacos/go-server/app and run the main method of server.go. You can see from the console of Nacos that the application user-info-server has been registered successfully.

Console address of Nacos: http://console.nacos.io/nacos/#/serviceManagement?dataId=&group=&appName=&namespace=

Figure 8

Figure 9

3. Build the Client end

The configuration file of client is in the registry/servicediscovery/nacos/go-server/profiles directory, and the places that need to be modified are the same as those on the server side, which will not be discussed here.

Configure the client-side environment variables:

Server.yml file path on export CONF_CONSUMER_FILE_PATH=client side log.yml file path on export APP_LOG_CONF_FILE=client side

Enter registry/servicediscovery/nacos/go-client/app, run the main method of client.go, and see the following log output, which indicates that the call to server is successful.

Figure 10

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.