Consul server configuration
The biggest advantage of microservice is that the whole project is divided into different services and run on different servers to achieve decoupling and distributed processing. Although micro service has many advantages, it also has some disadvantages. Everything has two sides. In micro services, operation and maintenance will be a big problem. If one day we have a large number of services, then we don’t know which service is on which machine. Some people may say that it’s good to write this part directly in the configuration of the program. When we have few services, we can do this, and we are also allowed to do so. But in practice, we should try our best to avoid doing this. For example, if we change the address of one of our services, the relevant code we designed will have to be modified and re deployed; or we will launch a new one one one day Service or offline a service, at this time we have to modify the program code, which is very unreasonable. Is there anything that can solve this problem? Here we need to use our service registration and discovery.
There is no structure for service registration discovery
< center > architecture without service discovery
In the picture above, we can see that when no service registration is found, a caller needs to maintain the IP and ports of multiple services. This is a very bad practice. When our service is adjusted, it may lead to the failure of service invocation. In addition, the server will be affected by changing servers and new services. In the future, when a service node has a problem, troubleshooting is a great disaster for the program and operation and maintenance personnel, because we don’t know which node has a problem, so we need every server to troubleshoot.
And what does the structure look like when we use the service registration discovery?
Structure with service registration discovery
< center > structure with service registration discovery
We can see from the above diagram that when we have a registry, the caller does not need to maintain all the information of his own services. He only needs to ask the registry to get services, so that he can get the desired service information. In this way, when our service is adjusted, or online and offline services, it should be easy to operate, and the health of the service can be checked in the registration process, so as to help the operation and maintenance personnel quickly locate the faulty server.
Consul is recommended by swoft. Consul is a service registration, discovery and configuration management system written by go.
- Agent: agent is a program resident in the background of consul cluster. Agent has two modes, one is server, the other is client. All agents can run DNS or HTTP interfaces, and are responsible for checking whether the service survives and keeping the service synchronized.
- Client: client is an agent running mode, which forwards all RPCs to the agent server’s agent. The client will have an agent service in the background that forwards requests to the back end with minimum bandwidth consumption, so as to reduce the pressure of the agent server.
- Server: server is another running mode of agent, including using raft algorithm to process data, maintaining cluster state, responding to RPC requests, exchanging data with other cluster servers or remote data center.
- RPC: remote procedure call, a request / response mechanism that allows clients to make server requests.
The above are some important conceptual things for us this time. If we know what each component and each part is doing, the following configuration will be simple and get twice the result with half the effort.
There are many components in consul. We can use one component for the time being, that is, agent. The installation of consul is also very simple. After all, there is only one binary package, so we can download it directly and use it.
1. Log in to the official website to download,Download address
wget https://releases.hashicorp.com/consul/1.2.1/consul_1.2.1_linux_amd64.zip unzip consul_1.2.1_linux_amd64.zip
2. Set the environment variable. If you don’t set it, you can directly move the consumer executable file to the / usr / bin directory
mv consul /usr/bin
OK, after the installation is successful, let’s make some configuration to enable consumer
Stand alone configuration
- Server 1, IP 192.168.1.100
This method is suitable for service debugging
consul agent -bootstrap-expect 1 -server -data-dir /data/consul -node=swoft01 -bind=0.0.0.0 -config-dir /etc/consul.d -enable-script-checks=true -datacenter=sunny -client=0.0.0.0 -ui
Can passhttp://192.168.1.100: 8500 view service information
This method is suitable for the production environment
- Server 1, IP 192.168.1.100
consul agent -bootstrap-expect 2 -server -data-dir /data/consul -node=swoft01 -bind=0.0.0.0 -client=0.0.0.0 -config-dir /etc/consul.d -enable-script-checks=true -datacenter=sunny -client=0.0.0.0
The above command is to start an agent in the server mode. There are two extension machines in the cluster. Set the cluster persistent data to be stored under / data / consuml0, the node name to be swoft01, the binding address to be 0.0.0, the service configuration file to be stored in / etc / consuml. D, the check heartbeat to be started, the name of the data center to be DC1, and the accessible client address to be 0.0.0
- Server 2, IP 192.168.1.110
consul agent -server -data-dir /data/consul -node=swoft02 -bind=0.0.0.0 -client=0.0.0.0 -config-dir /etc/consul.d -enable-script-checks=true -datacenter=sunny -join 192.168.1.100
- Server 3, IP 192.168.1.120
consul agent -server -data-dir /data/consul -node=swoft03 -bind=0.0.0.0 -client=0.0.0.0 -config-dir /etc/consul.d -enable-script-checks=true -datacenter=sunny -join 192.168.1.100
Server 2 and service 3 are used above
-joinJoin the cluster and use the same data name sunny
- Server 4, IP 192.168.1.130
consul agent -ui -data-dir /data/consul -node=swoft04 -bind=0.0.0.0 -config-dir /etc/consul.d -enable-script-checks=true -datacenter=sunny -ui -client=0.0.0.0 -join 192.168.1.100
If the client does not use – server, it will run in client mode. Other parameters are the same as above. After the server and client are started, they can be entered in the browserhttp://192.168.1.130: 8500 to view information
View cluster members:
View cluster information:
-bootstrap-expectThe expected number of servers in the data center. This value should not be provided or must be consistent with other servers in the cluster. Once provided, consul will wait for the specified number of servers to be available and then boot the cluster. This allows automatic selection of the initial leader. This cannot be used with the traditional bootstrap flag. This flag needs to run in server mode.
-serverStart in server mode
-data-dirData storage location, which is used to persist the cluster state
-nodeThe name of this node in the cluster. This has to be unique in the cluster. By default, this is the host name of the computer.
-bindIP address of binding server
-config-dirSpecify the configuration file service. When there is a. JSON ending file in this directory, it will be loaded. For more configuration, please refer toConfiguration template
-enable-script-checksCheck whether the service is active, similar to turning on heartbeat
-datacenterData center name
-clientThe client can access IP, including HTTP and DNS server. By default, this is “127.0.0.1” and only loopback connections are allowed.
-uiOpen the UI interface of Web
-joinJoin an existing cluster
For more information about consumer, please move toOfficial website of consul
WeChat official account: IT is not kicked.