Spring Cloud Official Document Chinese version-service discovery: Eureka Server

The Official document address is: http://cloud.spring.io/spring-cloud-static/Dalston.SR3/#spring-cloud-eureka-server

In the example I have done some tests in: http://git.oschina.net/dreamingodd/spring-cloud-preparation

Service Discovery:eureka Server Services discovery: Eureka service-side how to Include Eureka Server creating Eureka service-side

To include Eureka Server in your project, the starter with group Org.springframework.cloud and artifact ID spring-cloud -starter-eureka-server. See the Spring Cloud Project page for details on setting-your build system with the current spring cloud Release Train.

Using the Eureka service requires the introduction of Org.springframework.cloud's Spring-cloud-starter-eureka-server project. You can refer to http://projects.spring.io/spring-cloud/to create your first Eureka service.

How to run a Eureka Server runs Eureka service side

@SpringBootApplication@EnableEurekaServerpublic class Application { public static void main(String[] args) { new SpringApplicationBuilder(Application.class).web(true).run(args); }}

The server has a home page with a UI, and HTTP API endpoints per the normal Eureka functionality under/eureka/*.

Eureka Server has a default UI home page, each Eureka server you have an HTTP API node in/eureka/*

Eureka background reading:see Flux Capacitor and Google group discussion.

To learn more about Eureka background, we recommend reading https://github.com/cfregly/fluxcapacitor/wiki/NetflixOSS-FAQ# eureka-service-discovery-load-balancerhttps://groups.google.com/forum/?fromgroups#!topic/eureka_netflix/ G3p2r7ghnn0

TIP Due to Gradle's dependency resolution rules and the lack of a parent BOM feature, simply depending on spring-cloud-starter -eureka-server can cause failures on application startup. To remedy the spring Boot Gradle plugin must is added and the spring cloud starter parent BOM must be imported like s O:

Gradle introduced:

Build.gradle

buildscript {  dependencies {    classpath("org.springframework.boot:spring-boot-gradle-plugin:1.3.5.RELEASE")  }}apply plugin: "spring-boot"dependencyManagement {  imports {    mavenBom "org.springframework.cloud:spring-cloud-dependencies:Brixton.RELEASE"  }}

High availability, Zones and regions highly available, regional and regional

The Eureka server does not has a backend store, but the service instances with the registry all has to send heartbeats to Keep their registrations up to date (so the can be do in memory). Clients also has a in-memory cache of Eureka registrations (so they don ' t has to go to the registry for every single re Quest to a service).

Eureka servers are not stored on the backend, but service instances in the keygen must maintain their latest registration status with heartbeat information (that is, they can be completed in memory). The client also has a copy of the registration information cache that exists in memory.

By default every Eureka server was also a Eureka client and requires (at least one) service URL to locate a peer. If you don ' t provide it the service would run and work, but it'll shower your logs with a lot of noise on not being AB Le to register with the peer. By default, each Eureka server is also a Eureka client, and it also requires (at least one) service URL to locate the node. Even if the developer does not provide still can run, but will be a large number of unregistered garbage log.

See also below for details of the Ribbon in the client side for Zones and regions.

Standalone Mode Standalone

The combination of the caches (client and server) and the heartbeats make a standalone Eureka server fairly resilient To failure, as long as there is some sort of monitor or elastic runtime keeping it alive (e.g. Cloud Foundry). In standalone mode, you might prefer to switch off the client side behaviour, so it doesn ' t keep trying and failing to Rea Ch its peers. Example:

As long as there is some kind of monitoring or flexible run time to make the service live (like Cloud Foundry), the combination of two cache and heartbeat protocol will allow the Eureka server of the stand-alone to be quite resilient to failure. In stand-alone mode, developers may prefer to shut down the client behavior of the server so that the service side does not have to attempt to access the node unsuccessfully.

Application.yml (Standalone Eureka Server)

server:  port: 8761eureka: instance: hostname: localhost client: registerWithEureka: false fetchRegistry: false serviceUrl: defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

Notice that the serviceurl are pointing to the same host as the local instance.

Note that the serviceurl is the same as the local instance.

Peer Awareness node awareness (high Availability)

Eureka can made even more resilient and available by running multiple instances and asking them to register with each o Ther. In fact, the "the default behaviour, so all" need to does to make it work are add a valid serviceurl to a peer, e.g.

Eureka servers can become more resilient by running multiple instances and requiring registration with each other. In fact, this is the default use of Eureka, then you need to add a valid serviceurl to the node to make it work properly. For example:

application.yml (both Peer Aware Eureka Servers)

---spring: Profiles:peer1eureka: Instance: Hostname:peer1 Client: Serviceurl: Defaultzone:http://peer2/eureka /---spring: Profiles:peer2eureka: instance:  Hostname:peer2 Client: ServiceUrl: defaultzone:http://peer1/eureka/        

In this example we had a YAML file that can is used to run the same server on 2 hosts (Peer1 and Peer2), by running it in Different Spring profiles. You could use this configuration to test the peer awareness on a single host (there's not much value in doing, in PROD uction) by Manipulating/etc/hosts to resolve the host names. In fact, the eureka.instance.hostname isn't needed if you were running on a machine this knows its own hostname (IT's loo ked up using java.net.InetAddress by default).

By running different spring profiles, the Yaml configuration file in this example is the same server (node 1 and Node 2) on different hosts. By manipulating/etc/hosts to forge 127.0.0.1 's hostname, developers can test on the same host (this makes no value in production). In fact, eureka.instance.hostname This configuration item is not available in the production environment (the PC will query java.net.InetAddres to get it).

You can add multiple peers to a system, and as long as they is all connected to the other by at least one edge, they wil L Synchronize the registrations amongst themselves. If the peers is physically separated (inside a data centre or between multiple data centres) then the system can in Princ Iple survive split-brain type failures.

As long as the nodes are connected to each other, developers can add multiple nodes to the system, and the registration information is synchronized between them. If a node is physically detached (in one or more data centers), then the system can in principle ignore the Split-brain type failure and run.

Prefer IP address using IP

In some cases, it's preferable for Eureka to advertise the IP Adresses of services rather than the hostname. Set eureka.instance.preferIpAddress to True and if the application registers with Eureka, it'll use the IT IP Address rat She than its hostname.

In some cases, using IP is better than hostname. Eureka.instance.preferipaddress=true can do that.

Dreamingodd original articles, such as reproduced please indicate the source.

Spring Cloud Official Document Chinese version-service discovery: Eureka Server