A registered service slow
1. Background
By default, the service started, you need to register on the Eureka Server. But in the development process found that the service registry to speed Eureka Server is slow. Therefore, it is desirable to shorten the time of registration services in order to improve efficiency in the development process.
2. The reason for
service related to a periodic heartbeat registration, default 30 seconds. Only when the metadata instance, the server and the client's local cache are the same, the service can be found in other clients (it may take up to 3 beats). Principle as shown below: 
Therefore, by shortening the waiting client side time interval, i.e. sent by the client to shorten the time interval to a heartbeat Eureka to improve efficiency. In the presence of Eureka eureka.instance.leaseRenewalIntervalInSeconds parameter, the value used to set the time Eureka Eureka Client Server to send a heartbeat interval, default 30 seconds. Arranged to implement a smaller value by this parameter.
3. Solution
eureka.instance.leaseRenewalIntervalInSeconds set to a smaller value.
eureka:
instance:
lease-renewal-interval-in-seconds: 10
4. Notes
in a production environment, the value is recommended to use the default values to ensure that the client is available.
II. Stopped serving micro node does not log off or log off slow
1. Background
In the development environment, we want to Eureka Server service instances can be quickly written off micro stopped. But in the actual development process, often when the service stopped or micro-hang, the service instance is still registered long before disappeared on Eureka Server, need to wait for a long period.
2. The reason for
all this behind the scenes, due to two aspects:
one is to clean up invalid because Eureka Server node cycle length (default 90 seconds);
then on the other hand, Eureka opened a self-protection mode, and not even write off any micro services;
3. solution
Knowing reasons, addressed from the above two aspects:
for the first case, the solution is as follows:
in Eureka Client-side configuration is turned on health checks, and configure a shorter and shorter time to renew update Expire date.
eureka:
client:
healthcheck:
enabled: true //开启健康检查
instance:
lease-renewal-interval-in-seconds: 10 //配置续约更新时间
lease-expiration-duration-in-seconds: 10 //配置续约到期时间
For the second case, the solution is as follows:
in Eureka Server-side configuration closed to protect themselves and configure a shorter Eureka Server cleanup invalid node interval.
eureka:
server:
enable-self-preservation: false //关闭自我保护
eviction-interval-timer-in-ms: 4000 //清理无效节点的时间间隔
4. Note
These configurations are recommended in the development or testing, production environment is recommended to use the default value.
5. expansion program
if the reader understand the advanced features of Eureka Server, then this problem can also be solved manually.
Eureka provides some REST endpoint to register for our management services. Non-JVM can use these micro-service REST endpoints operating Eureka, in order to achieve registration and discovery.
Further, Eureka the REST endpoint may use XML or JSON communicate with the endpoints (default XML), to control the registration of micro and services offline.
Therefore, in this issue, you can use the delete endpoints REST endpoint to delete. The following example of micro-services, how do you do offline? 
Can be deleted by sending the following request:
http://${user}:${password}@localhost:8761/eureka/apps/${application_name}/${server_name}
Wherein the request is a DELETE mode, user: password account password authentication Eureka;
APPLICATION_NAME the Application name;
server_name under the name of a particular Application Server;
therefore, the above example of offline follows:
http://admin:123456@localhost:8761/eureka/apps/ZZ-PROVIDER-USER/windows10.microdone.cn:zz-provider-user:8001
III. Custom Micro services InstanceID
1. background
in Eureka registered service interface, you want to customize the micro services InstanceID, rather than the default value.
2. reasons
in SpringCloud in, InstanceId default value for the service are:
${spring.cloud.clent.hostname}:${spring.cloud.application.name}:${spring.application.port}
3. Solution
only need to configure eureka.instance.instance-id attribute to the micro-service.
eureka:
instance:
instance-id: ${spring.cloud.client.ipAddress}:${server.port}
四.名称异常(UNKNOWD)
1.背景
在Eureka Server的注册界面上，显示微服务名称为UNKNOWN，或者应用状态为UNKNOWN。
当微服务名称为UNKNOWN发生时，显然不符合科学。首先微服务的名称不够语义化，无法看出是哪个微服务，其次我们常常使用应用名称消费对应微服务的接口，这样会导致消费的失败。
而当应用状态为UNKNOWN时，微服务不是UP状态(也即是不健康状态)，同时会导致消费的失败。
2.原因
以下分两种情况讨论
<1>应用名称为UNKNOWN的情况
一般来说有两种情况会导致该问题的发生：
1~未配置spring.application.name或者eureka.instance.appname属性。如果这两个属性均不配置，则会导致应用UNKNOWN的问题；
2~某些版本的SpringFox会导致该问题。例如SpringFox2.6.0。建议使用SpringFox2.6.1或更新的版本；
<2>微服务实例状态为UNKNOWN的情况
该问题一般由健康检查导致。
3.解决方案
针对第一种情况，可以配置spring.application.name或者eureka.instance.appname属性：
spring:
application:
name: zz-provider-user
针对第二种情况，可以配置eureka.client.healthcheck.enabled属性：
eureka:
client:
healthcheck:
enabled: true
注意：该种情况下，eureka.client.healthcheck.enabled=true必须设置在application.yml中，而不能设置在boostrap.yml，否则一些场景下会导致应用状态UNKNOWN的问题。
五.扩展Eureka客户端元数据
1.背景
在Eureka使用过程中，我们常常需要根据自己定义的元数据，来区分不同的微服务。举个栗子，在测试环境的Eureka集群上注册了2个同样的微服务A，B，我们希望在SIT环境消费微服务时只消费到微服务A，而在UAT环境消费时只消费到微服务B，此时通过自己定义的元数据，区分不同环境在消费微服务时的选择。原理图如下：
2.相关思路
通过元数据，可以解决这类问题。那么什么是元数据呢？下面简单介绍下Eureka的元数据。
Eureka的元数据包括标准元数据和自定义元数据。
标准元数据指的是主机名，IP地址，端口号，状态页和健康检查等信息。这些信息都会被发布在服务注册表中，用于服务之间的调用；
自定义元数据可以使用eureka.instance.metadata-map配置，这些数据可以在远程客户端中访问，但是并不会改变客户端的行为；
通过使用DiscoveryClient.getInstances(serviceId)，可查询指定微服务在Eureka上的实例列表
3.解决方案
配置自定义元数据
<1>配置yml文件
eureka:
client:
serviceUrl:
defaultZone: http://admin:123456@peer1:8761/eureka/,http://admin:123456@peer2:8761/eureka/
instance:
prefer-ip-address: true
metadata-map:
service-id: 10000
service-timeout: 60
<2>新增UserController
@RestController
@RequestMapping("/user")
public class UserController {
@Autowired
private DiscoveryClient discoveryClient;
@RequestMapping("/getUserInfo")
public List<ServiceInstance> getUserInfo () {
return discoveryClient.getInstances("zz-provider-user");
}
}
<3>访问元数据
启动应用，通过user/getUserInfo访问。
通过上述步骤实现自定义元数据，解决Eureka分组的问题。除此之外，自定义元数据还可以解决其他场景的问题，例如微服务建立唯一标识，微服务消费排序等问题，在此不再赘述。
IP next six multi-card environment select
1. Background
certain micro server services deployed with multiple NICs, these micro service when registering to Eureka Server, by default if the registration process may result in the service can not be other micro server access.
For example, some servers have eth0, eth1 and eth2 three cards, but only eth1 can be accessed by other servers; if Eureka Client will eth0 or eth2 registered to Eureka Server, the service will not be able to call other micro of the micro-service through this IP interface.
2. solutions
for servers with multiple network interfaces, you can register by specifying the various micro-IP service to the Eureka Server to achieve.
Spring Cloud provides the ability to choose on-demand IP in order to avoid the above problems. Provide SpringCloud comes with four solutions below.
<1> Ignore the specified name card:
spring:
cloud:
inetutils:
ignored-interfaces:
- dokcer0
- veth.*
eureka:
instance:
prefer-ip-address: true
So that it can ignore docker0 card and all cards to veth beginning.
<2> using regular expressions, using the network address specified:
spring:
cloud:
inetutils:
preferredNetworks:
- 192.168
- 10.0
eureka:
instance:
prefer-ip-address: true
<3> Use only site-local addresses:
spring:
cloud:
inetutils:
useOnlySiteLocalInterfaces: true
<4> to manually specify the IP address:
eureka:
instance:
prefer-ip-address: true
ip-address: 127.0.0.1