1, common registry
1), zookeeper: high consistency (data consistent with the plurality of nodes);
2), eureka: time availability (the system can not be accessed rarely);
3), consul: appeal two compromise solutions.
High Availability: eliminate single points of failure, reliability overlap fault detection.
Centralized management: use registry to manage the service. (Example the Eureka)
To centralized management: Each service instance, there is a copy. (Refer to local git repository, be regarded as a copy)
2, Eureka service discovery / registration
1), Eureka Server: provide service registry and discovery. Manage all registration services, as well as examples of information and status. (Maintain a registry)
Activation: @EnableEurekaServer.
Service synchronization principle: between a plurality of registry, through asynchronous mode (a timed thread, each transmission registry) (so each node for each fixed time points, a state may be slightly different). Upon receipt of a registration request, a registration center will send the registration information to other registries, registry services to achieve synchronization.
Self-protection principle: When the registration service, the proportion of heart failure services accounted for 85% +, self-protection mechanism is triggered registry, so the current instance that survive do not expire. (Ensure high availability A) but the service consumers can easily get the failed instance. So the client needs to have fault tolerance mechanisms, such as current limiting circuit breakers.
When debugging local temporarily closed registry self-protection mechanism.
Configuration file attributes:
eureka.client.register-with-eureka: flase, do not register themselves to themselves.
eureka.client.fetch-registry: not retrieve (pull service), only to maintain the list of examples.
2), Eureka Client: to provide for the current service registration, synchronization, and find examples of information services and other state or ability.
Activation: @EnableEurekaClient (Write dead binding Eureka) or @EnableDiscoveryClient (recommend this kind of comment).
Service Registration principle: Client activated when the transmission mode REST requests, registers itself to the registry, and bring some of their own some metadata information services. REST center receives registration request, the metadata information in the presence of a bilayer Map, key of the first layer is the service name, key of the second layer is the instance name (IP address) of a particular service.
Instance name configuration: the instance name is InstanceInfo instanceId parameters, is to distinguish between different services that uniquely identifies the same instance. Native to achieve is to use the host name as the default, you can not start more than one instance of the same service in the same host.
Service contract principle: Client maintains a heartbeat to continue to tell the registry also " alive " , to prevent the registration center " culling mission " The Client instance is deleted from the registration list. There are two parameters can be adjusted, a task is the renewal interval (default 30 seconds), a time to failure is the definition of a service (default 90 seconds).
Access to services principle: query information from the list of services that are currently registered with the server and cached locally (default 30 seconds) and periodically refresh the service status.
Offline service principle: when a Client normal closing operation, to trigger a request to the offline REST registry, registration center receiving the request, the service status to offline. Or not properly shut down, but the service is stopped, the registry creates a scheduled task at boot time, the default for each period of time (default 60 seconds), the list of the current Super League (default 90 seconds) did not renew the task of culling out.
Client also need to obtain a list of URL's Eureka Server. (Zone Region and to achieve, many relationship.) Acquiring a first region according EurekaClientConfig, then obtaining a plurality of zone according to a region, and then determine which one of Zone serviceUrls loading configuration parameters in accordance with the algorithm.
When Ribbon implement service calls for Zone settings to achieve special effects in regional affinity load balancing. Ribbon default priority access to the same client in a server instance in the Zone, not only access other instances Zone. Zone is defined by a familiar, with the actual deployment of the physical structure, it can effectively design a fault-tolerant cluster of regional faults.
Configuration file attributes:
eureka.client.serverUrl.defaultZone = http: // IP: port / eureka: Sign up to which the registry.
3, high availability service management
CAP: C consistency, availability A, P partitions fault tolerance (data consistency can not be reached within the time limit, it would have to choose a partition between A and C).
Configuration tools : host multi-registry, registry DNS, broadcast.
1), high availability registry: between a plurality of registry, registration with each other. When the service is registered with multiple registration center.
After a Client to register their services to a registration center, between the registry synchronization, when linked to a registration center node, Client can be accessed by other registries nodes, high availability purposes.
Reference: "SpringCloud real"