You’ve used several registries, and you don’t know the difference?

preface

A service registry is essentially a decoupled service provider and service consumer. For any microservice, multiple providers should exist or be supported in principle, depending on the distributed nature of the microservice. Furthermore, in order to support elastic scaling characteristics, the number and distribution of providers of a microservice is often dynamic and cannot be determined in advance. As a result, the static LB mechanism commonly used in the singleton application phase is no longer suitable, and an additional component needs to be introduced to manage the registration and discovery of microservice providers, and this component is the service registry.

Theory of CAP

CAP theory is an important theory in distributed architecture

• Consistency (all nodes have the same data at the same time)

• Availability (Ensuring that each request is responded to regardless of success or failure)

• The loss or failure of any information in the system will not affect the continued operation of the system

about

In my opinion, the failure or breakdown of a certain part in the whole system does not affect the operation or use of the whole system. In addition, the failure of a certain node in a system does not affect the system’s acceptance or sending of requests. CAP cannot be taken for all, but only two of them can be taken

why

If C is the first requirement, then the performance of A will be affected because the data needs to be synchronized, otherwise the results of the requests will be different, but the data synchronization will take time and the availability will be reduced.

If A is the first requirement, then as long as one service is present, the request can be accepted normally, but there is no guarantee that the result will be returned, because in distributed deployment, the data consistency process cannot be cut as fast as the line.

Again, if both consistency and availability are satisfied, then fault tolerance of partition is difficult to guarantee, that is, a single point, is also the basic core of distribution. Ok, understand these theories, you can select service registration and discovery in the corresponding scenario.

Service registry solution

The first consideration in designing or selecting a service registry is the service registration and discovery mechanism. Looking at the major service registry solutions available today, they can be broadly grouped into three categories:

• In-application: directly integrated into the application, relying on the application itself to complete service registration and discovery, the most typical example is Eureka provided by Netflix

• Out of app: Treat your app as a black box and register services with a registry via some mechanism out of app to minimize intrusiveness to your app, such as Airbnb’s SmartStack, HashiCorp’s Consul

• DNS: Registering services as SRV records for DNS, strictly speaking, is a special out-of-application registration, of which SkyDNS is representative

TIP1: For the first type of registration, in addition to Eureka, a one-stop solution, a service registration mechanism can also be realized based on ZooKeeper or Etcd, which is common in large companies, but obviously cost-effective for small companies.

TIP2: Due to the inherent cache defects of DNS, this article does not explore the third type of registration in depth.

In addition to basic service registration and discovery mechanisms, there are at least five aspects to consider from a development and operations perspective:

• Live testing: After a service is registered, how can a service be live tested to ensure its availability?

• Load balancing: When there are multiple service providers, how to balance the load among them?

• Integration: How is the registry integrated on the service provider side or the calling side?

• Runtime dependencies: How does the introduction of a registry affect an application’s runtime environment?

• Availability: How can you ensure the availability of the registry itself, especially to eliminate single points of failure?

Mainstream registry products

Apache Zookeeper -> CP

Different from Eureka, Apache Zookeeper follows CP principles in design, that is, the access request to Zookeeper can get consistent data results at any time, and the system has fault tolerance for network segmentation, but Zookeeper cannot guarantee that every service request is reachable.

From the actual application of Zookeeper, when the Zookeeper cluster is used to obtain the service list, if the Leader of the Zookeeper cluster breaks down, the cluster must elect the Leader. Or more than half of the server nodes in the Zookeeper cluster are unavailable (for example, if there are three nodes, if node 1 detects that node 3 has failed and node 2 also detects that node 3 has failed, the node is considered to have failed), then the request cannot be processed. Therefore, Zookeeper cannot guarantee service availability.

Of course, in most distributed environments, especially when data storage is involved, data consistency should be guaranteed first, which is another reason why Zookeeper design closely follows CP principles.

The same is not true for service discovery, where different nodes in the registry may hold different information about service providers for the same service without catastrophic consequences.

Because for service consumers, consumption is the most important thing, although consumers get information may not be the correct service instance after trying to consumption, also want to rather than because they cannot obtain instance information instead of consumption, resulting in abnormal system better (double tenth a taobao, jingdong, 618 is the best reference) tight according to AP.

When the master node loses contact with other nodes due to a network fault, the remaining nodes re-elect the leader node. The problem is that it takes too long to elect a leader, 30 to 120s, and the entire ZK cluster is not available during the election, which causes the registration service to collapse during the election.

In a cloud deployment environment, it is highly likely that zK cluster will lose its master node due to network problems. Although services can be restored eventually, it is intolerable that registration will be unavailable for a long time due to a long election event.

Spring Cloud Eureka -> AP

Spring Cloud Netflix designed Eureka to follow AP principles (Ereka 1.x is still active due to its closed source, even though 2.0 is now available).

Eureka Server can also run multiple instances to build a cluster and solve a single point problem. However, unlike ZooKeeper’s leader election process, Eureka Server uses peer-to-peer communication. This is a decentralized architecture. There is no master/slave, and each Peer is Peer. In this architectural style, nodes improve availability by registering with each other, and each node needs to add one or more valid ServiceurLs to point to other nodes. Each node can be treated as a copy of another node.

In a cluster environment, if a Eureka Server is down, requests from the Eureka Client are automatically switched to the new Eureka Server node. After the faulty Server is recovered, Eureka will manage the Server cluster again. When a node begins To accept a client request, all operations are replicated To Peer between nodes, replicating the request To all other nodes that the Eureka Server is currently aware of.

When a new Eureka Server node is started, it first tries to get all registration list information from neighboring nodes and completes initialization. Eureka Server obtains all nodes through the getEurekaServiceUrls() method and updates them periodically through heartbeat contracts.

By default, if the Eureka Server does not receive a heartbeat from a service instance within a certain period of time (default interval is 30 seconds), the Eureka Server will log out of the instance (default interval is 90 seconds, Eureka. Instance. lease-expiration-duration-in-seconds User-defined configuration).

When a Eureka Server node loses too many heartbeats in a short period of time, the node goes into self-protection mode.

As long as one Eureka is still in the cluster, the registration service is guaranteed to be available (guaranteed availability), but the information may not be up to date (not guaranteed consistency). In addition, Eureka also has a self-protection mechanism. If more than 85% of the nodes have no normal heartbeat within 15 minutes, Eureka considers that there is a network failure between the client and the registry, and the following situations may occur:

1. Eureka no longer removes services from the registry that have expired because they have not received heartbeats for a long time

2. Eureka can still accept new service registration and query requests, but will not be synchronized to other nodes (that is, the current node is still available).

3. When the network is stable, the newly registered information of the current instance will be synchronized to other nodes

Therefore, Eureka can cope with the loss of some nodes due to network failure, rather than the whole registration service collapse like ZooKeeper.

Consul

Consul is an open source tool from HashiCorp for service discovery and configuration in distributed systems. Consul is written in the Go language, making it naturally portable (Linux, Windows, and Mac OS X support).

Consul has a built-in service registration and discovery framework, distributed consistency protocol implementation, health check, Key/Value storage, and multi-data center solution, eliminating the need for other tools (such as ZooKeeper) and making it easy to use.

Consul follows CP principles in the CAP principle to ensure strong consistency and partition fault tolerance, and uses Raft algorithm, which is simpler than the Paxos algorithm used by ZooKeeper. Although consistent, availability is reduced. For example, services take longer to register because Raft protocol on Consul requires that more than half of all nodes have been written to in order to be registered. If the Leader fails, Consul service becomes unavailable before the leader is elected again.

Consul is essentially an out-of-app registration, but the registration process can be simplified with the SDK. Service discovery, on the other hand, relies on the SDK by default, but the SDK dependencies can be removed using Consul Template (discussed below).

Consul Template

Consul, the default service caller needs to rely on Consul SDK to discover the service, which is not guaranteed to be non-invasive to the application.

Consul Template allows you to periodically retrieve the latest list of service providers from Consul cluster and refresh LB configurations (such as Nginx’s upstream) so that a single uniform service invocation address can be configured for service callers.

Consul Strong consistency (C) brings:

1. Service registration is slightly slower than Eureka. Consul’s RAFT protocol requires that more than half of the nodes have been successfully written to be considered registered

2. If the Leader fails, the entire Consul is unavailable during a re-election. Consistency is guaranteed at the expense of availability.

Eureka guarantees high availability (A) and ultimate consistency:

1. Service registration is relatively fast, because there is no need to wait for the registration to go to other nodes, and there is no guarantee that the registration will succeed

2. In case of data inconsistency, although the registration information on A and B are not completely the same, each Eureka node can still provide services normally. In this case, if A fails to find the service information when requesting B, it can find the service information when requesting B. This ensures availability at the expense of consistency.

Otherwise, Eureka is a servlet program that runs in a servlet container; Consul is written from go.

Nacos

Nacos, which is open source by Alibaba, supports DNS and RPC-based service discovery. To use Nacos in Spring Cloud, you only need to download Nacos and start Nacos Server. Nacos only needs simple configuration to complete the registration and discovery of services.

Nacos supports dynamic configuration of services in addition to registration discovery of services. Dynamically configured services allow you to manage application configuration and service configuration for all environments in a centralized, external, and dynamic manner. Dynamic configuration eliminates the need to redeploy applications and services when configuration changes, making configuration management more efficient and agile. Centralized configuration management makes it easier to implement stateless services and make it easier for services to scale flexibly on demand.

In short, Nacos = Spring Cloud registry + Spring Cloud Configuration Center.

Reference links: yq.aliyun.com/articles/69… nacos.io

Source: blog.csdn.net/fly910905/a…

The Redis KEYS command should not be used arbitrarily

● Concept: symmetric encryption, asymmetric encryption, public key, private key, signature, certificate

● Use of Mybatis Generator reverse engineering

● XStream Learning Manual

● Stop logging in Java code, this is the correct logging posture!