background
The status quo: Monolithic architecture is gradually being replaced by microservice architecture, where the original two functional modules are split into two services. Originally, communication between two modules was only requiredA function call
Now you can’t do it because they are not in the same process, and even two services may be deployed to different rooms.Communication is the first hurdle to micro services:
- How does ServiceA know where ServiceB is
- How do I avoid accessing an “unhealthy” ServiceB when there may be multiple copies of it providing services, some of which may fail
- How do I control that only ServiceA can access ServiceB
What is the Consul
Consul is a service grid solution that provides a full-featured control plane with service discovery, configuration, and segmentation capabilities. Each of these functions can be used individually or together as needed to build a complete service grid. Consul provides the following core features:
-
Service discovery: When a service is started, it registers service-related information (such as address, port, configuration, and tag) with Consul for centralized management. When you need to access other services, you can query information about dependent services from Consul. The query mode can be HTTP, RPC, or DNS.
-
Health check: in the service registry to Consule can configure the health check, the Consul will regularly check to its, if the check fails, will think this service is not available, as any other service to query the service address, return can eliminate unavailable address (note: the same service tend to have multiple services/address).
-
Secure service Communication: Consul can generate and distribute TLS certificates for services to establish mutual TLS connections. The Intentions can be used to define which services are allowed to communicate. Manage service segments and control accessibility between services by changing Intentions in real time.
-
KV storage: Cousul can be used for simple key and value storage scenarios such as dynamic configuration, function marking, coordination, leader election, etc. Provides a simple HTTP API.
-
Multi-dc: Consul supports multiple data centers out of the box to support high availability scenarios.
The Consul architecture
Typically, the Server side is deployed in multiple data centers, as shown in the figure above.
DATACENTER1
andDATACENTER2
They are independent of each other. They exchange packets through WAN GOSSIP. In a single datacenter, nodes are divided into two colors, server in red and client in purple, and they communicate (business data) through RPCS. A LAN Gosssip is used to communicate between the Client and Server. For example, when a Server node is added or the Server is down, the Client can obtain the Server list and delete or add the Server list.
Consul is a Client/Server architecture that is run by the same code and starts with the -server=false parameter to determine whether Consul is run in Server mode or Agent mode.
Server mode capability
- Deal with the query
- Storing registration Information
- Participating in consensus arbitration and selecting leaders
- Maintain relationships between peripheral (LAN/WAN) nodes
Client mode is responsible for
- Use this node to register for a health check on Consul microservice
- Translate client registration requests and queries into SERVER RPC requests
- Maintains relationships between surrounding nodes (LAN/WAN)
- Cache data from the server to improve performance and reliability
conclusion
This paper introduces Consul at the theoretical level, the background of Consul, the functions supported by Consul and the architecture of Consul.