Shulou(Shulou.com)06/02 Report--

In recent years, with the rise of Docker container technology, micro-services and other architectures, people begin to realize the necessity of service discovery. To put it simply, micro-service architecture is a method of sending a single large and full application for × × with some micro-services. Each small service runs in its own process and communicates with a lightweight mechanism, usually HTTP RESTful API. Micro-service emphasizes small fast spirit, any relatively independent functional service is no longer a module, but an independent service. So, when we need to access this service, how do we determine its address? At this point, the service discovery is needed.

Consul is an open source tool developed by HashiCorp, which is used to realize service discovery and configuration in distributed systems. It is usually compared with tools for service registration and discovery such as zookeeper and etcd. Consul is more like a "full stack" solution with built-in service registration and discovery, health check, Key/Value storage, and multi-data center functions. Personal preference for him has three points: 1, out of the box, convenient for operation and maintenance: the installation package contains only one executable file, which is convenient for deployment, does not need other dependencies, and can work seamlessly with lightweight containers such as Docker. 2. With its own ui interface, you can see the registered service directly through the web interface, and update KUnip V. 3. GOSSIP protocol is used to manage members and spread messages in the cluster, and raft protocol, which is the same as etcd, is used to ensure data consistency.

There are four key features provided by Consul:

1. Service discovery. Provide two discovery methods: HTTP and DNS.

2. Health monitoring. Support a variety of ways, HTTP, TCP, Docker, Shell script customized monitoring.

3. KV storage. The storage mode of Key and Value.

4. Multiple data centers. Consul supports multiple data centers.

Of course, Consul also has many icing on the cake features, such as: visual Web interface, configuration template "consul-template" and so on.

The following is a page display of consul ui:

Consul ui interface

The Construction of Consul Cluster

Schematic diagram of cluster architecture:

Consul cluster architecture

Cluster role

The figure above is a simple consul cluster architecture. Consul Cluster has two roles: Server and Client. Whether Server or Client, collectively referred to as Agent,Consul Client is relatively stateless, only responsible for forwarding RPC to Server, with little resource overhead. Server is an agent with a set of extended functions, including participating in Raft elections, maintaining cluster status, responding to RPC queries, interacting with WAN gossip with other data centers, and forwarding queries to leader or remote data centers.

In each data center, client and server are mixed. It is generally recommended that there are 3-5 server. This is based on the tradeoff between availability and performance in case of failure, because the more machines join, the slower it takes to reach a consensus, and a leader is elected between Server. However, there is no limit to the number of client, they can easily expand to thousands or tens of thousands.

Cluster building

Here, a server cluster is built with 5 machines, which are:

172.30.100.1 consul01

172.30.100.2 consul02

172.30.100.3 consul03

172.30.100.4 consul04

172.30.100.5 consul05

1. Create the consul installation directory and put it in the / data/consul directory:

Root@consul01# mkdir-p / data/consul/data

2. Download and decompress the consul software package for the corresponding platform and version. Take version 0.9.2 as an example:

Root@consul01# cd / data/consul

Root@consul01# wget-c https://releases.hashicorp.com/consul/0.9.2/consul_0.9.2_linux_amd64.zip

Root@consul01# unzip consul_0.9.2_linux_amd64.zip

The official download source address is https://releases.hashicorp.com/consul/?_ga=2.141719666.1717434336.1505055948-1038273419.1504238248. Please download your own version.

3. Create a startup configuration file for consul:

Root@consul01# vim consul_config.json

{

"datacenter": "consul-cluster"

"node_name": "consul01"

"bind_addr": "172.30.100.1"

"client_addr": "172.30.100.1"

"server": true

"bootstrap_expect": 5

"data_dir": "/ data/consul/data"

"http_config": {

"response_headers": {

Access-Control-Allow-Origin: "*"

}

}

"log_level": "INFO"

"enable_syslog": true

"ports": {

"http": 8500

"dns": 8600

"serf_lan": 8301

"serf_wan": 8302

}

"enable_script_checks": true

}

Explanation of key parameters:

Bind_addr: the address bound to the internal cluster communication with the-bind argument of the command line. The default is' 0.0.0.0. If there are multiple network cards, you need to specify them, otherwise start the error report.

Client_addr: the same as the-clinet parameter on the command line, the address bound to the client interface. The default is' 127.0.0.1'.

Server:true specifies that the mode of consul agent is server mode

Bootstrap_expect: same as-bootstrap-expect on the command line, the expected number of server in the cluster. Here we have 5 server, which cannot be used with the bootstrap parameter.

Enable_syslog: if enabled, the log of consul will be written to the syslog of the system

Enable_script_checks: whether to enable the monitoring detection script.

For more information on configuration parameters, please see the official link: https://www.consul.io/docs/agent/options.html

For the configuration of the other 4 nodes, just change the node_name to your own.

4. Start consul agent

Root@consul01#. / consul agent-config-file consul_config.json-ui

Specify the location of the configuration file and launch the ui interface. Do the same thing on the other four nodes

5. Add agent to the cluster

Tell the second agent to add to the first agent:

Root@consul02#. / consul join-http-addr http://172.30.100.2:8500 172.30.100.1

On the remaining three nodes, change your http-addr and do the same, such as on consul03:

Root@consul03#. / consul join-http-addr http://172.30.100.3:8500 172.30.100.1

Special note: when joining a cluster, a consul agent only needs to know any node in the cluster. After joining the cluster, the cluster nodes will discover the relationship between each other according to the GOSSIP protocol.

5. Cluster check

After all the nodes are started successfully, you can check whether all the cluster members have joined successfully, and execute the command on any node:

Root@consul03#. / consul members http://172.30.100.3:8500

Node Address Status Type Build Protocol DC

Consul01 172.30.100.1:8301 alive server 0.9.2 2 consul-cluster

Consul02 172.30.100.2:8301 alive server 0.9.2 2 consul-cluster

Consul03 172.30.100.3:8301 alive server 0.9.2 2 consul-cluster

Consul04 172.30.100.4:8301 alive server 0.9.2 2 consul-cluster

Consul05 172.30.100.5:8301 alive server 0.9.2 2 consul-cluster

6. Log in to WEB UI

Enter http://172.30.100.3:8500 in the browser and you will see the UI interface shown in the figure above.

Conclusion:

Now that a consul cluster has been built, the next step is to write about my use in the actual production environment: prometheus monitoring and consul+consul-template dynamically adding monitored nodes. Continuous practical information, welcome to follow.

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.