preface

In the microservice architecture, a system is divided into multiple microservices, which are independently developed and deployed, and finally aggregated to form a system to provide services. How are these small services managed as the number of services increases? How can the caller determine the IP and port of the service? What if the service fails? Manual processing is not practical. Unified system management is the best choice. Common service discovery products include Consul, Zookeeper, Etcd, Eureka, etc. NetCore is very popular, so I’ll definitely talk about it first.

The body of the

Consul is a system that enables multi-data center, distributed, high-availability service discovery and configuration sharing, right out of the box, with the following key features:

  • ** Service discovery: ** You can register services through Consul client, where services can include API site, Redis server, MySql server, etc. When other clients need to use the corresponding service, Consu can return the service to the client through DNS or HTTP. You do not need to manually specify IP addresses and ports, and Consul manages them in a unified manner.
  • ** Health Check: **Consul provides the function of checking services so that relevant personnel can learn about the running status of services. Service users of Consul can avoid accessing unhealthy services. For example, if an API site goes down, the caller cannot obtain service information from Consul and returns healthy service information to ensure normal API calls.
  • ** Key-value pair storage: ** stores key-value pair data, which is ideal for use as a configuration center. For example, if there are multiple services, each service has some configuration information. You can configure them in Consul in a unified manner to avoid repeated configuration for each service and greatly reduce the risk of configuration errors.
  • ** Multiple Data Centers: **Consul supports multiple data centers out of the box, each running independently.

After a brief overview of Consul, we will discuss the application of Service discovery and health check as follows:

A brief description of the picture above

  • Each service registers with Consul via a profile or code that reports information to Consul;
  • Consul performs health checks on registered services based on registered information; Grpc, TCP, HTTP can be used.
  • Clients can obtain healthy service information, such as IP addresses and ports, from Consul (service discovery). Either DNS or HTTP works;

Start with the installation, do a Demo, including service registration, service view, health check, and email notification after service failure, which is a process from development to maintenance (but only the Demo kind).

1. Install

Consul Consul installation can be said to be super easy, go to the website -> download -> decompress to complete the installation of www.consul.io/;

Find the download page, select the version suitable for your system, and download it directly, as shown below:

After downloading, directly decompress, then open the command line tool, and run it to see if it is normal, as shown below:

2. Registration services

  • Configuration file format

    You need to prepare a configuration file. In order to view the service data monitored on Consul, you can also specify the corresponding data output directory. Therefore, a data directory is required as follows:

    Config: stores the configuration file. When Conusl starts, it can specify the configuration file location and automatically load all JSON files in this directory.

    Data: This is an empty folder to store data generated during Consul, which is not required.

    Now that you have a directory structure, create a services.json file in config that contains the following contents:

    The configuration information is described in the preceding figure. For the health check, the API service is configured in HTTP mode, that is, the IP address can be accessed properly. You can configure the detection mode as required, such as Grpc, TCP, and script.

    Once you have your profile ready, you can run Consul directly. For a quick start, run Consul in development mode as follows:

    Command parsing:

    Agent: Runs the agent.

    -dev: starts a Server in development mode, as shown in the figure above.

    -confile-file: specifies the Consul configuration file directory and automatically loads all JSON files in this directory.

    -data-dir: specifies the directory where data is stored during Consul, including service status and related information.

    In the configuration file, you do not need to change the code. You only need to ensure that the IP address, port number, and health check path are correct when the service is running. As there is no service available, Consul will check the service every 5s based on the configured information. The service being checked is definitely unhealthy. The Consul console will continuously output the following information:

    Create a new WebAPI project, add a Health check Controller, and specify port 5000 to run with the following code:

    Consul agent detects when it runs, as follows:

  • Embedded code form

    To register the code, import Consul package, specify Consul address and configure related service information in the code, and no other changes are required. The code logic is as follows:

    Configure the following information in the configuration file:

    The service registration code is as follows:

    After registering the service method, you can simply call the Configure method at the end of the Startup file. Consul will be able to detect the service by specifying the corresponding port to start the service. The demo port is 6688. Consul will be able to detect the service.

3. View services

After the service is registered, it must be viewed or used in the following three ways:

  • The UI form

    Consul provides the corresponding page to view and configure information about the registration service. When Consul is launched, you can access the corresponding interface from http://localhost:8500/ (local in this demo) as follows:

    The interface is not a screenshot, small partners point. The visual interface is quite powerful.

  • DNS and HTTP

    You can also view it by command, in two forms, DNS and HTTP. Here is the first HTTP way to demonstrate, DNS way to friends, very simple.

    HTTP form, directly call the interface (of course can be permission control);

    Common interface addresses for querying services are as follows:

    Check out all service: http://localhost:8500/v1/catalog/services

    According to the service name query service, the service name is the name of the specified in the registration service: http://localhost:8500/v1/catalog/service/ service name

    When with the name of the service have more than one, according to the Tag filtering: http://localhost:8500/v1/catalog/service/ service name? tag=test6688

    The same applies to other types of information, such as node information and data center information.

  • The code in the form of

    Rely on Consul package as follows:

    The running results are as follows:

    Of course, this form can also obtain Consul other information, partners debugging know;

4. Monitoring service (abnormal notification to relevant personnel)

For the service itself, the service may be suspended due to network or software or hardware problems. If the service is not recovered in a timely manner, serious consequences may occur. Therefore, timely notification is required when the service is down. Here is a demonstration of the use of mail, the need to set up a simple email; Here, QQ email is used to send, so relevant services of QQ email need to be opened. It can be opened in THE Settings of QQ email, as shown below:

When it is enabled, an SMS message is sent for verification, and then an authorization code is obtained, which will be used in later emails.

For demonstration purposes, the logic for sending email notifications is written in the business service, but a separate service can be used for notifications. The code logic is as follows:

Add a notification interface for listening calls. When listening for service failures, call this interface to send emails:

Now that the code is ready, you need to configure the monitoring. Simply add the monitoring configuration file to the configuration directory, called watchs.json, and it will look like this:

After the configuration file is complete, restart Consul with the same command as the initial one. Then start the service. For the convenience of testing, the service is started by using the command as follows:

dotnet ConsulCodeDemo.dll --urls "http://*:6688"  # specify port to start
dotnet ConsulConfigDemo.dll The default value is 5000, so you don't need to specify it
Copy the code

Note: To run the preceding command, you need to enter the directory of the corresponding compiled file.

When services are running properly, Consul displays that all services are in the healthy state on the Consul interface. Then, disable the service on port 5000 (because the interface configured to send emails is on 6688). If Consul detects that the service is in the healthy state, Consul automatically invoks the interface to send emails.

Relevant personnel receive information can be timely processing.

Source code address: github.com/zyq025/IDS4…

conclusion

Ok, Consul a preliminary study to the first, basics but we also came close to, after all, there are many didn’t speak about common commands, such as cluster structures, ACL configuration didn’t involved, so the next talk to cluster structures, and the ACL configuration, for the use of common commands, built environment, to explain.

A handsome guy who was made ugly by the program, pay attention to “Code variety circle “, learn with me ~~~