Skip to content

Eureka 2.0 Client Configuration And Use

Jump to bottom
qiangdavidliu edited this page May 29, 2015 · 6 revisions

Prerequisites

  • JDK 1.7

You can get the Eureka 2.0 client binaries from the following sources. Always try to get the latest release as tend to have more fixes.

Adding eureka2-client as a gradle dependency:

dependencies {
    compile "com.netflix.eureka:eureka2-client:2.0.0-rc.2"
}

Adding eureka2-client as a maven dependency:

<dependency>
    <groupId>com.netflix.eureka</groupId>
    <artifactId>eureka2-client</artifactId>
    <version>2.0.0-rc.2</version>
</dependency>

Types of Clients

Eureka 2.0 provide interfaces for two different types of clients specific for eureka operations "interest discovery" and "instance registration".

Server Resolvers

A prerequisite to creating any eureka client is a ServerResolver that specifies the remote eureka server to connect to. Eureka 2.0 comes with some standard ways of creating server resolvers with ServerResolvers. See class javadoc for specifics of use.

Interest Client

The interest client is used to read registered instance information from remote eureka servers based on some specified interest criteria.

Building the Interest Client

EurekaInterestClient registrationClient = new EurekaInterestClientBuilder()
        .withServerResolver(myResolver)
        .build();

Configuring the Interest Client

The EurekaInterestClientBuilder can optionally be given the following configuration classes:

  • EurekaTransportConfig - see [EurekaTransportConfig](#Header EurekaTransportConfig)
  • EurekaRegistryConfig - see [EurekaRegistryConfig](#Header EurekaRegistryConfig)
  • EurekaClientMetricFactory - metrics factory for client level metrics. Default to a Netflix/spectator implementation. A NoOpEurekaClientMetricFactory is also available.
  • EurekaRegistryMetricFactory - metrics factory for metrics generate by the client side eureka registry. Default to a Netflix/spectator implementation. A NoOpEurekaRegistryMetricFactory is also available.

Build and Configuration Changes

Note the above methods for building and configuring the interest client are as of 2.0.0-rc.1 and may change in the future. However we will try to provide transition releases in between changes.

Using the Interest Client

First, decide on the interest criteria for the instances you want to read from the remote eureka servers. An interest DSL is exposed in Interests. By default, eureka supports interests at app level, vipAddress level, and instance level.

Interest<InstanceInfo> myInterest = Interests.forApplications("WriteServer", "ReadServer");

With an interest specified, a stream of ChangeNotifications of instance information matching this Interest can then be generated by calling interestClient.forInterest(myInterest). This returns an rx.Observable of ChangeNotification<InstanceInfo> that can be subscribed to and consumed.

        interestClient.forInterest(myInterest).subscribe(
                new Subscriber<ChangeNotification<InstanceInfo>>() {
                    @Override
                    public void onCompleted() {
                        System.out.println("Change notification stream closed");
                    }

                    @Override
                    public void onError(Throwable e) {
                        System.out.println("Error in the notification channel: " + e);
                    }

                    @Override
                    public void onNext(ChangeNotification<InstanceInfo> changeNotification) {
                        System.out.println("Received notification: " + changeNotification);
                    }
                });

Two transformational functions are provided in InterestFunctions. This can be applied to the base ChangeNotification stream to buffer the notifications into delta lists, or buffer then snapshot the notifications into full snapshot lists that will emit a new snapshot if anything changes.

        interestClient.forInterest(forFullRegistry())
                .compose(ChangeNotificationFunctions.<InstanceInfo>buffers())
                .compose(ChangeNotificationFunctions.<InstanceInfo>snapshots())
                .subscribe(new Subscriber<LinkedHashSet<InstanceInfo>>() {
                    @Override
                    public void onCompleted() {
                        System.out.println("Change notification stream closed");
                    }

                    @Override
                    public void onError(Throwable e) {
                        System.out.println("Error in the notification channel: " + e);
                    }

                    @Override
                    public void onNext(LinkedHashSet<InstanceInfo> instanceInfos) {
                        System.out.println("Received new snapshot: " + instanceInfos);
                    }
                });

Registration Client

The registration client is used to register/update and unregister instance information with remote eureka servers so that they may be discovered by interest clients. The registration client is multi-tenant and can be used to maintain instance information for multiple registrant entities.

Building the Registration Client

EurekaRegistrationClient registrationClient = new EurekaRegistrationClientBuilder()
        .withServerResolver(myResolver)
        .build();

Configuring the Registration Client

The EurekaRegistrationClientBuilder can optionally be given the following configuration classes:

  • EurekaTransportConfig - see [EurekaTransportConfig](#Header EurekaTransportConfig)
  • EurekaClientMetricFactory - metrics factory for client level metrics. Default to a Netflix/spectator implementation. A NoOpEurekaClientMetricFactory is also available.

Build and Configuration Changes

Note the above methods for building and configuring the interest client are as of 2.0.0-rc.1 and may change in the future. However we will try to provide transition releases in between changes.

Using the Registration Client

A prerequisite for registration is the creation of InstanceInfo(s). Example of how to create InstanceInfos.

For each registrant, the registration client requires the registering InstanceInfo to be submitted as an rx.Observable<InstanceInfo>. The register API returns a RegistrationObservable. The registration process for the registrant begins when this RegistrationObservable is subscribed to. The RegistrationObservable also exposes an initialRegistrationResult that will emit onCompleted if the initial registration has completed successfully with the remote server.

Once registration has been initiated (via subscription to the RegistrationObservable), the first emit of the registrant InstanceInfo stream will be used for the initial registration, and any subsequent emits will be updates to the remote server, if they differ from the previous.

Example

        Observable<InstanceInfo> staticInstanceInfo = Observable.just(myInstanceInfo);
        RegistrationObservable registrationObservable = registrationClient.register(staticInstanceInfo);
        registrationObservable.subscribe();
        registrationObservable.initialRegistrationResult().doOnCompleted(new Action0() {
            @Override
            public void call() {
                System.out.println("Initial registration completed");
            }
        }).subscribe();

Alternate example:

        BehaviorSubject<InstanceInfo> infoSubject = BehaviorSubject.create();
        Subscription subscription = registrationClient.register(infoSubject).subscribe();
        // initial registration
        infoSubject.onNext(myInstanceInfo);

        // some business logic that changed instanceInfo
        // update instanceInfo
        InstanceInfo updatedInfo = new Builder().withInstanceInfo(myInstanceInfo).withStatus(Status.DOWN).build();
        infoSubject.onNext(updatedInfo);

        // unregistering
        subscription.unsubscribe();

Unsubscribing from the RegistrationObservable will cause the registrant to be unregistered from the remote server.

Configuration

EurekaTransportConfig

By default, the BasicEurekaTransportConfig is used that provides configuration loading from system properties.

The following properties can be changed for the transport:

  • heartbeatIntervalMs - govern the interval that software heartbeats are sent on the transport channels. Default to 30 seconds.
  • connectionAutoTimeoutMs - all eureka transport connections will timeout after a period of (connectionAutoTimeoutMs/2, 1 + connectionAutoTimeoutMs/2) and automatically reestablish themselves. Set this to 0 to disable this feature.
  • codec - transport encoding protocol. Avro by default, Json codec is also available.

EurekaRegistryConfig

By default, the BasicEurekaRegistryConfig is used that provides configuration loading from system properties.

The following properties can be changed for the registry:

  • evictionTimeoutMs - the amount of time to wait for "unknown" instanceInfos to be removed. An instanceInfo can be "unknown" if for example the connection to the remote server breaks.
  • evictionStrategyType - the eviction strategy, currently only the default of PercentageDrop is available.
  • evictionStrategyValue - the corresponding strategy value of the eviction strategy type. For PercentageDrop this is the percentage of items in the registry that is allowed to be removed before self preservation.

Examples

Clone this wiki locally