Spring Cloud official documentation Chinese version-service discovery: Eureka server, cloudeureka

Spring Cloud official documentation Chinese version-service discovery: Eureka server, cloudeureka

Official documentation: http://cloud.spring.io/spring-cloud-static/Dalston.SR3/#spring-cloud-eureka-server

In this article, I did some tests in: http://git.oschina.net/dreamingodd/spring-cloud-preparation

 

Service Discovery: Eureka Server How to Include Eureka Server How to create Eureka Server

To include Eureka Server in your project use 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 up your build system with the current Spring Cloud Release Train.

To use the Eureka service, you must introduce the spring-cloud-starter-eureka-server project of org. springframework. cloud. Refer to http://projects.spring.io/spring-cloud/to create your first eurekaservice.

How to Run a Eureka Server How to Run Eureka Server

@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 /*.

The Eureka server has a default UI homepage. Each Eureka server has an http api node at/eureka /*

Eureka background reading: see flux capacitor and google group discussion.

To learn more about Eureka background, read https://github.com/cfregly/fluxcapacitor/wiki/NetflixOSS-FAQ#eureka-service-discovery-load-balancerhttps://groups.google.com/forum? Fromgroups #! Topic/eureka_netflix/g3p2r7gHnN0

TIPDue 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 this the Spring Boot Gradle plugin must be added and the Spring cloud starter parent bom must be imported like so:

Gradle introduction:

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 High Availability, region and region

The Eureka server does not have a backend store, but the service instances in the registry all have to send heartbeats to keep their registrations up to date (so this can be done in memory ). clients also have an in-memory cache of eureka registrations (so they don't have to go to the registry for every single request to a service ).

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

By default every Eureka server is also a Eureka client and requires (at least one) service URL to locate a peer. if you don't provide it the service will run and work, but it will shower your logs with a lot of noise about not being able to register with the peer. by default, each Eureka server also has an Eureka client, and at least one service URL is also required to locate the node. Even if the developer does not provide the logstore, a large number of junk logs cannot be registered.

See also below for details of Ribbon support on the client side for Zones and Regions.

Standalone Mode

The combination of the two 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 reach its peers. example:

As long as there is a certain monitoring or flexible running time to make the service alive (such as Cloud Foundry), the combination of the two cache and heartbeat protocols can make the standalone Eureka server maintain a considerable elasticity for failures. In standalone mode, developers may prefer to disable the client behavior of the server, so that the server does not have to keep trying to access the node from failure.

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 is pointing to the same host as the local instance.

Note that serviceUrl is the same as that of a local instance.

Peer Awareness Node Awareness (high availability)

Eureka can be made even more resilient and available by running multiple instances and asking them to register with each other. in fact, this is the default behaviour, so all you need to do to make it work is add a valid serviceUrl to a peer, e.g.

The Eureka server can become more elastic by running multiple instances and requiring mutual registration. In fact, this is the default use method of Eureka, so you need to add a valid serviceUrl to the node to make it work normally. For example:

Application. yml(Two 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 have a YAML file that can be used to run the same server on 2 hosts (peer1 and peer2), by running it in different Spring profiles. you cocould use this configuration to test the peer awareness on a single host (there's not much value in doing that in production) by manipulating/etc/hosts to resolve the host names. in fact, the eureka. instance. hostname is not needed if you are running on a machine that knows its own hostname (it is looked 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 ). Developers can test the host name on the same host by manipulating/etc/hosts to forge 127.0.0.1 (in this way, there is no value in the production environment ). In fact, the eureka. instance. hostname configuration item is useless in the production environment (the PC will query java.net. InetAddres to obtain it ).

You can add multiple peers to a system, and as long as they are all connected to each other by at least one edge, they will synchronize the registrations amongst themselves. if the peers are physically separated (inside a data center or between multiple data centres) then the system can in principle into ve split-brain type failures.

As long as nodes are connected to each other, developers can add multiple nodes to the system, and registration information is synchronized between them. If the node is physically separated (in one or more data centers), the system can operate without a split-brain fault in principle.

Prefer IP Address

In some cases, it is preferable for Eureka to advertise the IP Adresses of services rather than the hostname. set eureka. instance. preferIpAddress to true and when the application registers with eureka, it will use its IP Address rather than its hostname.

In some cases, IP address usage is better than hostname. Eureka. instance. preferIpAddress = true.

 

Original dreamingodd article. If the article is reproduced, indicate the source.