Re: [DISCUSS] how about the design of APISIX eureka integration?
> yes, Apache APISIX health check is optional. If there is a conflict between Apache APISIX and Eureka's health check, how is it resolved now? Thanks, Ming Wen, Apache APISIX & Apache SkyWalking Twitter: _WenMing ~Jarvis.Qiu 于2020年4月10日周五 下午10:16写道： > Hi, Ming Wen. > > I'm very sorry for reply so late. > > > > First, select nodes that the registry considers to be healthy. Then, > from > > these nodes, select one that APISIX considers healthy. > > Which means there are two health checks here? One is Apache APISIX and > one is Eureka. > > yes, Apache APISIX health check is optional. > > > > From a usage scenario, dynamic DNS service should not be used. That > loses > > the meaning of a registry. > > So dynamic DNS service exist in Eureka, do we ignore it or thrown an > error? > > ignore now. > > > > I think it is needed, but APISIX configuration center still does not > > > support the configuration of this format. > > We can store them in the etcd > > > > the weight in metadata unnecessary. > > we should remove useless data. > > Ok, I do with it. > > > > There are two ways: > > > 1. Fetch all, and then filter out what we need. > > > 2. According to the specified service name, one by one > > This feels like a custom development, how does it become generic? > > This problem can be dealt with later by the new PR. > > > -- Original -- > > From: "Ming Wen"; > > Date: Sun, Apr 5, 2020 09:51 AM > > To: "dev"; > > Subject: Re: [DISCUSS] how about the design of APISIX eureka integration? > > > > First, select nodes that the registry considers to be healthy. Then, > from > > these nodes, select one that APISIX considers healthy. > > Which means there are two health checks here? One is Apache APISIX and > one > > is Eureka. > > > > From a usage scenario, dynamic DNS service should not be used. That > loses > > the meaning of a registry. > > So dynamic DNS service exist in Eureka, do we ignore it or thrown an > error? > > > > I think it is needed, but APISIX configuration center still does not > support the configuration of this format. > We can store them in the etcd > > > > the weight in metadata unnecessary. > we should remove useless data. > > > > There are two ways: > > > 1. Fetch all, and then filter out what we need. > > > 2. According to the specified service name, one by one > > This feels like a custom development, how does it become generic? > > > Thanks, > > Ming Wen, Apache APISIX & Apache SkyWalking > > Twitter: _WenMing > > > > ~Jarvis.Qiu 于2020年4月4日周六 下午8:04写道： > > > Hi, Ming Wen, > > > > >> Common registries: Eureka, Etcd, Consul, Zookeeper, Nacos etc. > > > Apache APISIX uses them for service discovery, so do you trust their > > health > > > check results? > > > > Usually there is no problem. > > > > > What if their health check results conflict with Apache APISIX's own > > > upstream health check? > > > For example, Eureka believes that an upstream node is alive, but Apache > > > APISIX thinks that this node is dead. What should I do? > > > > First, select nodes that the registry considers to be healthy. Then, from > > these nodes, select one that APISIX considers healthy. > > > > > > > another issue: > > > If the dynamic DNS service of the Eureka is used, > > > how does DNS resolver in Apache APISIX guarantee consistency with the > > > Eureka at this time? > > > > From a usage scenario, dynamic DNS service should not be used. That loses > > the meaning of a registry. > > > > And the client load blance becomes the server load blance. > > > > > > > > prefix: "/eureka/" > > > > weight: 100 > > > Whose weight is this? and why we need prefix? > > > > the weight is default value for the service node. Usage: `local weight = > > metadata.weight or local_conf.eureka.weight or 100` > > > > Use prefix in order to shorten the Eureka host. > > > > > > > Do these Eureka nodes need to be updated dynamically? > > > The yaml configuration cannot be dynamically updated. > > > > I think it is needed, but APISIX configuration center still does not > > support the configuration of this format. > > > > > > "port" : 8761, > > > >"weight" : 100, > > > > "metadata&
Re: [DISCUSS] how about the design of APISIX eureka integration?
Hi, Ming Wen.
I'm very sorry for reply so late.
> > First, select nodes that the registry considers to be healthy. Then, from
> these nodes, select one that APISIX considers healthy.
> Which means there are two health checks here? One is Apache APISIX and one is
> Eureka.
yes, Apache APISIX health check is optional.
> > From a usage scenario, dynamic DNS service should not be used. That loses
> the meaning of a registry.
> So dynamic DNS service exist in Eureka, do we ignore it or thrown an error?
ignore now.
> > I think it is needed, but APISIX configuration center still does not
> > support the configuration of this format.
> We can store them in the etcd
> > the weight in metadata unnecessary.
> we should remove useless data.
Ok, I do with it.
> > There are two ways:
> > 1. Fetch all, and then filter out what we need.
> > 2. According to the specified service name, one by one
> This feels like a custom development, how does it become generic?
This problem can be dealt with later by the new PR.
> -- Original --
> From: "Ming Wen";
> Date: Sun, Apr 5, 2020 09:51 AM
> To: "dev";
> Subject: Re: [DISCUSS] how about the design of APISIX eureka integration?
> > First, select nodes that the registry considers to be healthy. Then, from
> these nodes, select one that APISIX considers healthy.
> Which means there are two health checks here? One is Apache APISIX and one
> is Eureka.
> > From a usage scenario, dynamic DNS service should not be used. That loses
> the meaning of a registry.
> So dynamic DNS service exist in Eureka, do we ignore it or thrown an error?
> > I think it is needed, but APISIX configuration center still does not
support the configuration of this format.
We can store them in the etcd
> > the weight in metadata unnecessary.
we should remove useless data.
> > There are two ways:
> > 1. Fetch all, and then filter out what we need.
> > 2. According to the specified service name, one by one
> This feels like a custom development, how does it become generic?
> Thanks,
> Ming Wen, Apache APISIX & Apache SkyWalking
> Twitter: _WenMing
> ~Jarvis.Qiu ??2020??4??4?? 8:04??
> Hi, Ming Wen,
>
> >> Common registries: Eureka, Etcd, Consul, Zookeeper, Nacos etc.
> > Apache APISIX uses them for service discovery, so do you trust their
> health
> > check results?
>
> Usually there is no problem.
>
> > What if their health check results conflict with Apache APISIX's own
> > upstream health check?
> > For example, Eureka believes that an upstream node is alive, but Apache
> > APISIX thinks that this node is dead. What should I do?
>
> First, select nodes that the registry considers to be healthy. Then, from
> these nodes, select one that APISIX considers healthy.
>
>
> > another issue:
> > If the dynamic DNS service of the Eureka is used,
> > how does DNS resolver in Apache APISIX guarantee consistency with the
> > Eureka at this time?
>
> From a usage scenario, dynamic DNS service should not be used. That loses
> the meaning of a registry.
>
> And the client load blance becomes the server load blance.
>
>
> > > prefix: "/eureka/"
> > > weight: 100
> > Whose weight is this? and why we need prefix?
>
> the weight is default value for the service node. Usage: `local weight =
> metadata.weight or local_conf.eureka.weight or 100`
>
> Use prefix in order to shorten the Eureka host.
>
>
> > Do these Eureka nodes need to be updated dynamically?
> > The yaml configuration cannot be dynamically updated.
>
> I think it is needed, but APISIX configuration center still does not
> support the configuration of this format.
>
> > > "port" : 8761,
> > >"weight" : 100,
> > > "metadata" : {
> > > "management.port": "8761",
> > > "weight": 100
> > > }
>
> > the port and weight are repeated twice. Is metadata unnecessary?
>
> the weight in metadata unnecessary. Because no to deal with the metadata,
> use of the metadata of the original data.
>
> > > Then implement the 'init_worker' function for initialization and the
> > 'nodes'
> > > function for obtaining the list of service instance nodes in'
> eureka.lua'
>
> > If we only need to get part of the data from eureka, what should we do?
>
> There are two ways:
>
> 1. Fetch all, and then filter out what we need.
>
> 2. According to the specified service name, one by one
>
>
Re: [DISCUSS] how about the design of APISIX eureka integration?
> First, select nodes that the registry considers to be healthy. Then, from
these nodes, select one that APISIX considers healthy.
Which means there are two health checks here? One is Apache APISIX and one
is Eureka.
> From a usage scenario, dynamic DNS service should not be used. That loses
the meaning of a registry.
So dynamic DNS service exist in Eureka, do we ignore it or thrown an error?
> I think it is needed, but APISIX configuration center still does not
support the configuration of this format.
We can store them in the etcd
> the weight in metadata unnecessary.
we should remove useless data.
> There are two ways:
> 1. Fetch all, and then filter out what we need.
> 2. According to the specified service name, one by one
This feels like a custom development, how does it become generic?
Thanks,
Ming Wen, Apache APISIX & Apache SkyWalking
Twitter: _WenMing
~Jarvis.Qiu 于2020年4月4日周六 下午8:04写道：
> Hi, Ming Wen,
>
> >> Common registries: Eureka, Etcd, Consul, Zookeeper, Nacos etc.
> > Apache APISIX uses them for service discovery, so do you trust their
> health
> > check results?
>
> Usually there is no problem.
>
> > What if their health check results conflict with Apache APISIX's own
> > upstream health check?
> > For example, Eureka believes that an upstream node is alive, but Apache
> > APISIX thinks that this node is dead. What should I do?
>
> First, select nodes that the registry considers to be healthy. Then, from
> these nodes, select one that APISIX considers healthy.
>
>
> > another issue:
> > If the dynamic DNS service of the Eureka is used,
> > how does DNS resolver in Apache APISIX guarantee consistency with the
> > Eureka at this time?
>
> From a usage scenario, dynamic DNS service should not be used. That loses
> the meaning of a registry.
>
> And the client load blance becomes the server load blance.
>
>
> > > prefix: "/eureka/"
> > > weight: 100
> > Whose weight is this? and why we need prefix?
>
> the weight is default value for the service node. Usage: `local weight =
> metadata.weight or local_conf.eureka.weight or 100`
>
> Use prefix in order to shorten the Eureka host.
>
>
> > Do these Eureka nodes need to be updated dynamically?
> > The yaml configuration cannot be dynamically updated.
>
> I think it is needed, but APISIX configuration center still does not
> support the configuration of this format.
>
> > > "port" : 8761,
> > >"weight" : 100,
> > > "metadata" : {
> > > "management.port": "8761",
> > > "weight": 100
> > > }
>
> > the port and weight are repeated twice. Is metadata unnecessary?
>
> the weight in metadata unnecessary. Because no to deal with the metadata,
> use of the metadata of the original data.
>
> > > Then implement the 'init_worker' function for initialization and the
> > 'nodes'
> > > function for obtaining the list of service instance nodes in'
> eureka.lua'
>
> > If we only need to get part of the data from eureka, what should we do?
>
> There are two ways:
>
> 1. Fetch all, and then filter out what we need.
>
> 2. According to the specified service name, one by one
>
> -- Original --
> From: "Ming Wen";
> Date: Wed, Apr 1, 2020 10:00 AM
> To: "dev";
> Subject: Re: [DISCUSS] how about the design of APISIX eureka integration?
>
> hello, Jarvis,
>
> > Common registries: Eureka, Etcd, Consul, Zookeeper, Nacos etc.
> Apache APISIX uses them for service discovery, so do you trust their health
> check results?
> What if their health check results conflict with Apache APISIX's own
> upstream health check?
> For example, Eureka believes that an upstream node is alive, but Apache
> APISIX thinks that this node is dead. What should I do?
>
> another issue:
> If the dynamic DNS service of the Eureka is used,
> how does DNS resolver in Apache APISIX guarantee consistency with the
> Eureka at this time?
>
> > prefix: "/eureka/"
> > weight: 100
> Whose weight is this? and why we need prefix?
> Do these Eureka nodes need to be updated dynamically?
> The yaml configuration cannot be dynamically updated.
>
> > "port" : 8761,
> >"weight" : 100,
> > "metadata" : {
> > "management.port": "8761",
> > "weight": 100
> > }
>
> the port and weight are repeated twice. Is metadata unnecessary?
>
> > Then implement the 'init_worke
Re: [DISCUSS] how about the design of APISIX eureka integration?
Hi, Ming Wen,
>> Common registries: Eureka, Etcd, Consul, Zookeeper, Nacos etc.
> Apache APISIX uses them for service discovery, so do you trust their health
> check results?
Usually there is no problem.
> What if their health check results conflict with Apache APISIX's own
> upstream health check?
> For example, Eureka believes that an upstream node is alive, but Apache
> APISIX thinks that this node is dead. What should I do?
First, select nodes that the registry considers to be healthy. Then, from these
nodes, select one that APISIX considers healthy.
> another issue:
> If the dynamic DNS service of the Eureka is used,
> how does DNS resolver in Apache APISIX guarantee consistency with the
> Eureka at this time?
From a usage scenario, dynamic DNS service should not be used. That loses the
meaning of a registry.
And the client load blance becomes the server load blance.
> > prefix: "/eureka/"
> > weight: 100
> Whose weight is this? and why we need prefix?
the weight is default value for the service node. Usage: `local weight =
metadata.weight or local_conf.eureka.weight or 100`
Use prefix in order to shorten the Eureka host.
> Do these Eureka nodes need to be updated dynamically?
> The yaml configuration cannot be dynamically updated.
I think it is needed, but APISIX configuration center still does not support
the configuration of this format.
> > "port" : 8761,
> >"weight" : 100,
> > "metadata" : {
> > "management.port": "8761",
> > "weight": 100
> > }
> the port and weight are repeated twice. Is metadata unnecessary?
the weight in metadata unnecessary. Because no to deal with the metadata, use
of the metadata of the original data.
> > Then implement the 'init_worker' function for initialization and the
> 'nodes'
> > function for obtaining the list of service instance nodes in' eureka.lua'
> If we only need to get part of the data from eureka, what should we do?
There are two ways:
1. Fetch all, and then filter out what we need.
2. According to the specified service name, one by one
-- Original --
From: "Ming Wen";
Date: Wed, Apr 1, 2020 10:00 AM
To: "dev";
Subject: Re: [DISCUSS] how about the design of APISIX eureka integration?
hello, Jarvis,
> Common registries: Eureka, Etcd, Consul, Zookeeper, Nacos etc.
Apache APISIX uses them for service discovery, so do you trust their health
check results?
What if their health check results conflict with Apache APISIX's own
upstream health check?
For example, Eureka believes that an upstream node is alive, but Apache
APISIX thinks that this node is dead. What should I do?
another issue:
If the dynamic DNS service of the Eureka is used,
how does DNS resolver in Apache APISIX guarantee consistency with the
Eureka at this time?
> prefix: "/eureka/"
> weight: 100
Whose weight is this? and why we need prefix?
Do these Eureka nodes need to be updated dynamically?
The yaml configuration cannot be dynamically updated.
> "port" : 8761,
>"weight" : 100,
> "metadata" : {
> "management.port": "8761",
> "weight": 100
> }
the port and weight are repeated twice. Is metadata unnecessary?
> Then implement the 'init_worker' function for initialization and the
'nodes'
> function for obtaining the list of service instance nodes in' eureka.lua'
If we only need to get part of the data from eureka, what should we do?
Thanks,
Ming Wen, Apache APISIX & Apache SkyWalking
Twitter: _WenMing
~Jarvis.Qiu ??2020??3??29?? 10:46??
> English version doc for the integration design of APISIX eureka.
>
> # Integration service discovery registry
>
> ## Summary
>
> When system traffic changes, the number of servers of the downstream
> service also increases or decreases, or the server needs to be replaced due
> to its hardware failure. If the gateway maintains downstream service
> information through configuration, the maintenance costs in the
> microservices architecture pattern are unpredictable. Furthermore, due to
> the untimely update of these information, will also bring a certain impact
> for the business, and the impact of human error operation can not be
> ignored. So it is very necessary for the gateway to automatically get the
> latest list of service instances through the service registry??As shown in
> the figure below??
>
>
> 1. When the service starts, it will report some of its information, such
> as the service name, IP, port and other information to the registry. The
> services communicate with the registry using a mechani
Re: [DISCUSS] how about the design of APISIX eureka integration?
ot;node":{"value":{"uri":"\/user\/*","upstream": {"service_name":
> "USER-SERVICE", "type":
> "roundrobin"}},"createdIndex":61925,"key":"\/apisix\/routes\/1","modifiedIndex":61925},"action":"create"}
> ```
>
> *Notice**：When configuring `upstream.service_name`, `upstream.nodes` will
> no longer take effect, but will be replaced by 'nodes' obtained from the
> registry.
>
> ## How do I extend the discovery client?
>
> It is very easy for APISIX to extend the discovery client. Let's take
> Eureka as an example.
>
> ### 1. the code structure of discovery client
>
> First, add 'eureka.lua' in the 'lua/apisix/discovery/' directory;
>
> Then implement the 'init_worker' function for initialization and the
> 'nodes' function for obtaining the list of service instance nodes in'
> eureka.lua':
>
> ```lua
> local _M = {
> version = 1.0,
> }
>
>
> function _M.nodes(service_name)
> ... ...
> end
>
>
> function _M.init_worker()
> ... ...
> end
>
>
> return _M
> ```
>
> ### 2. How convert Eureka's instance data to APISIX's node?
>
> Here's an example of Eureka's data：
>
> ```json
> {
> "applications": {
> "application": [
> {
> "name": "USER-SERVICE", # service name
> "instance": [
> {
> "instanceId": "192.168.1.100:8761",
> "hostName": "192.168.1.100",
> "app": "USER-SERVICE", # service name
> "ipAddr": "192.168.1.100", # IP address
> "status": "UP",
> "overriddenStatus": "UNKNOWN",
> "port": {
> "$": 8761,
> "@enabled": "true"
> },
> "securePort": {
> "$": 443,
> "@enabled": "false"
> },
> "metadata": {
> "management.port": "8761",
> "weight": 100 # Setting by
> 'eureka.instance.metadata-map.weight' of the spring boot application
> },
> "homePageUrl": "http://192.168.1.100:8761/";,
> "statusPageUrl": "
> http://192.168.1.100:8761/actuator/info";,
> "healthCheckUrl": "
> http://192.168.1.100:8761/actuator/health";,
> ... ...
> }
> ]
> }
> ]
> }
> }
> ```
>
> Deal with the Eureka's instance data need the following steps :
>
> 1. select the UP instance. When the value of `overriddenStatus` is "UP" or
> the value of `overriddenStatus` is "UNKNOWN" and the value of `status` is
> "UP".
> 2. IP address. The `ipAddr` is the IP address of instance; and must be
> IPv4 or IPv6.
> 3. Port. If the value of `port["@enabled"]` is equal to "true", using the
> value of `port["\$"]`, If the value of `securePort["@enabled"]` is equal to
> "true", using the value of `securePort["\$"]`.
> 4. Weight. `local weight = metadata.weight or local_conf.eureka.weight or
> 100`
>
> By default, the result of this example is as follows:
>
> ```json
> {
> "192.168.1.100:8761":100
> }
> ```
>
> The configuration of this format, which is very easy and clear for static
> configuration, has obvious disadvantages, such as poor extendibility for
> complex scenarios, such as when you want to customize the routing rules by
> the metadata (e.g., grouping, etc.) information of the instance. To solve
> this problem, we have reserved a switch for users to use, that is, when
> 'eureka-enable_metadata' is set to 'true', the result of this example is as
> follows:
>
> ```json
> [
> {
> "ip" : "192.168.1.100",
> "port" : 8761,
> "weight" : 100,
> "metadata"
Re: [DISCUSS] how about the design of APISIX eureka integration?
If the documentation you added is in English, it's even better.
^_^
On Fri, Mar 27, 2020 at 11:55 PM ~Jarvis.Qiu wrote:
>
> the doc updated:
>
> https://github.com/apache/incubator-apisix/pull/1281/commits/ecec0e767086410796325b22ed5c5bdbe3b6f86c#diff-1a9273257fe88b08ad10cb0aa15006d5
>
> add support weight and how the instance data of eureka to upstream nodes of
> APISIX
>
>
> > ---Original---
> > From: "suo zhang"
> > Date: 2020/3/26 17:18:17
> > To: "dev";
> > Subject: Re: [DISCUSS] how about the design of APISIX eureka integration?
>
> > can add this to the document. maybe should simplify it
> > and where is service named "APISIX-EUREKA"? you start extra application
> > server and register on the eureka?
>
> > maybe we should use register API to initial the service on eureka.
>
>
> > ~Jarvis.Qiu 于2020年3月26日周四 下午4:31写道：
>
> > Eureka REST API:
> >
> > https://github.com/Netflix/eureka/wiki/Eureka-REST-operations
> >
> > we just need `GET /eureka/apps`, and its output:
> >
> > {
> > "applications": {
> > "versions__delta": "1",
> > "apps__hashcode": "UP_1_",
> > "application": [
> > {
> > "name": "APISIX-EUREKA",
> > "instance": [
> > {
> > "instanceId": "192.168.1.100:8761",
> > "hostName": "192.168.1.100",
> > "app": "APISIX-EUREKA",
> > "ipAddr": "192.168.1.100",
> > "status": "UP",
> > "overriddenStatus": "UNKNOWN",
> > "port": {
> > "$": 8761,
> > "@enabled": "true"
> > },
> > "securePort": {
> > "$": 443,
> > "@enabled": "false"
> > },
> > "countryId": 1,
> > "dataCenterInfo": {
> > "@class":
> > "com.netflix.appinfo.InstanceInfo$DefaultDataCenterInfo",
> > "name": "MyOwn"
> > },
> > "leaseInfo": {
> > "renewalIntervalInSecs": 30,
> > "durationInSecs": 90,
> > "registrationTimestamp": 1585205921502,
> > "lastRenewalTimestamp": 1585206281274,
> > "evictionTimestamp": 0,
> > "serviceUpTimestamp": 1585205921502
> > },
> > "metadata": {
> > "management.port": "8761"
> > },
> > "homePageUrl": "http://192.168.1.100:8761/";,
> > "statusPageUrl": "
> > http://192.168.1.100:8761/actuator/info";,
> > "healthCheckUrl": "
> > http://192.168.1.100:8761/actuator/health";,
> > "vipAddress": "apisix-eureka",
> > "secureVipAddress": "apisix-eureka",
> > "isCoordinatingDiscoveryServer": "true",
> > "lastUpdatedTimestamp": "1585205921502",
> > "lastDirtyTimestamp": "1585205921295",
> > "actionType": "ADDED"
> > }
> > ]
> > }
> > ]
> > }
> > }
> >
> > tansform to the nodes of upstream:
> >
> > {
> > "192.168.1.100:8761" = 1,
> > }
> >
> > others data (type, retries, timeout Etc.) of upstream are from
> > configuration.
> >
> >
> > > From: "suo zhang";
> > > Da
Re: [DISCUSS] how about the design of APISIX eureka integration?
the doc updated:
https://github.com/apache/incubator-apisix/pull/1281/commits/ecec0e767086410796325b22ed5c5bdbe3b6f86c#diff-1a9273257fe88b08ad10cb0aa15006d5
---Original---
From: "suo zhang"https://github.com/Netflix/eureka/wiki/Eureka-REST-operations
>
> we just need `GET /eureka/apps`, and its output:
>
> {
> "applications": {
> "versions__delta": "1",
> "apps__hashcode": "UP_1_",
> "application": [
> {
>
"name": "APISIX-EUREKA",
>
"instance": [
>
{
>
"instanceId": "192.168.1.100:8761",
>
"hostName": "192.168.1.100",
>
"app": "APISIX-EUREKA",
>
"ipAddr": "192.168.1.100",
>
"status": "UP",
>
"overriddenStatus": "UNKNOWN",
>
"port": {
>
"$": 8761,
>
"@enabled": "true"
>
},
>
"securePort": {
>
"$": 443,
>
"@enabled": "false"
>
},
>
"countryId": 1,
>
"dataCenterInfo": {
>
"@class":
> "com.netflix.appinfo.InstanceInfo$DefaultDataCenterInfo",
>
"name": "MyOwn"
>
},
>
"leaseInfo": {
>
"renewalIntervalInSecs": 30,
>
"durationInSecs": 90,
>
"registrationTimestamp": 1585205921502,
>
"lastRenewalTimestamp": 1585206281274,
>
"evictionTimestamp": 0,
>
"serviceUpTimestamp": 1585205921502
>
},
>
"metadata": {
>
"management.port": "8761"
>
},
>
"homePageUrl": "http://192.168.1.100:8761/";,
>
"statusPageUrl": "
> http://192.168.1.100:8761/actuator/info";,
>
"healthCheckUrl": "
> http://192.168.1.100:8761/actuator/health";,
>
"vipAddress": "apisix-eureka",
>
"secureVipAddress": "apisix-eureka",
>
"isCoordinatingDiscoveryServer": "true",
>
"lastUpdatedTimestamp": "1585205921502",
>
"lastDirtyTimestamp": "1585205921295",
>
"actionType": "ADDED"
>
}
>
]
> }
> ]
> }
> }
>
> tansform to the nodes of upstream:
>
> {
> "192.168.1.100:8761" = 1,
> }
>
> others data (type, retries, timeout Etc.) of upstream are from
> configuration.
>
>
>
>
> > From: "suo zhang"https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md
> > > >
> > > <
> >
>
https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md>
> > >
> > > ;
> > > >
> > > >
> > > >
> > > >
-- 原始邮件 --
> > > > 发件人: "Ming
Wen"https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md&nbsp;for&nbsp;the
> > > >
> > > <
> >
>
https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md&nbsp;for&nbsp;the>
> > >;
> > > >
> > > > <
> > >
> >
>
https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md&nbsp;for&nbsp;the>>
> > > ;;
> > > > design of APISIX eureka integration.&nbsp;
> > > > >
> > > > >
> > > > > I hope you can give me some advice.
> > > > >
> > > > >
> > > > > the PR:&nbsp;
> > > https://github.com/apache/incubator-apisix/pull/1281
> >
> > --
> > Thanks,
> > Ming Wen, Apache APISIX & Apache SkyWalking
> > Twitter: _WenMing
> >
Re: [DISCUSS] how about the design of APISIX eureka integration?
eureka can register to self.
---Original---
From: "suo zhang"https://github.com/Netflix/eureka/wiki/Eureka-REST-operations
>
> we just need `GET /eureka/apps`, and its output:
>
> {
> "applications": {
> "versions__delta": "1",
> "apps__hashcode": "UP_1_",
> "application": [
> {
>
"name": "APISIX-EUREKA",
>
"instance": [
>
{
>
"instanceId": "192.168.1.100:8761",
>
"hostName": "192.168.1.100",
>
"app": "APISIX-EUREKA",
>
"ipAddr": "192.168.1.100",
>
"status": "UP",
>
"overriddenStatus": "UNKNOWN",
>
"port": {
>
"$": 8761,
>
"@enabled": "true"
>
},
>
"securePort": {
>
"$": 443,
>
"@enabled": "false"
>
},
>
"countryId": 1,
>
"dataCenterInfo": {
>
"@class":
> "com.netflix.appinfo.InstanceInfo$DefaultDataCenterInfo",
>
"name": "MyOwn"
>
},
>
"leaseInfo": {
>
"renewalIntervalInSecs": 30,
>
"durationInSecs": 90,
>
"registrationTimestamp": 1585205921502,
>
"lastRenewalTimestamp": 1585206281274,
>
"evictionTimestamp": 0,
>
"serviceUpTimestamp": 1585205921502
>
},
>
"metadata": {
>
"management.port": "8761"
>
},
>
"homePageUrl": "http://192.168.1.100:8761/";,
>
"statusPageUrl": "
> http://192.168.1.100:8761/actuator/info";,
>
"healthCheckUrl": "
> http://192.168.1.100:8761/actuator/health";,
>
"vipAddress": "apisix-eureka",
>
"secureVipAddress": "apisix-eureka",
>
"isCoordinatingDiscoveryServer": "true",
>
"lastUpdatedTimestamp": "1585205921502",
>
"lastDirtyTimestamp": "1585205921295",
>
"actionType": "ADDED"
>
}
>
]
> }
> ]
> }
> }
>
> tansform to the nodes of upstream:
>
> {
> "192.168.1.100:8761" = 1,
> }
>
> others data (type, retries, timeout Etc.) of upstream are from
> configuration.
>
>
>
>
> > From: "suo zhang"https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md
> > > >
> > > <
> >
>
https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md>
> > >
> > > ;
> > > >
> > > >
> > > >
> > > >
-- 原始邮件 --
> > > > 发件人: "Ming
Wen"https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md&nbsp;for&nbsp;the
> > > >
> > > <
> >
>
https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md&nbsp;for&nbsp;the>
> > >;
> > > >
> > > > <
> > >
> >
>
https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md&nbsp;for&nbsp;the>>
> > > ;;
> > > > design of APISIX eureka integration.&nbsp;
> > > > >
> > > > >
> > > > > I hope you can give me some advice.
> > > > >
> > > > >
> > > > > the PR:&nbsp;
> > > https://github.com/apache/incubator-apisix/pull/1281
> >
> > --
> > Thanks,
> > Ming Wen, Apache APISIX & Apache SkyWalking
> > Twitter: _WenMing
> >
Re: [DISCUSS] how about the design of APISIX eureka integration?
can add this to the document. maybe should simplify it
and where is service named "APISIX-EUREKA"? you start extra application
server and register on the eureka?
maybe we should use register API to initial the service on eureka.
~Jarvis.Qiu 于2020年3月26日周四 下午4:31写道：
> Eureka REST API:
>
> https://github.com/Netflix/eureka/wiki/Eureka-REST-operations
>
> we just need `GET /eureka/apps`, and its output:
>
> {
> "applications": {
> "versions__delta": "1",
> "apps__hashcode": "UP_1_",
> "application": [
> {
> "name": "APISIX-EUREKA",
> "instance": [
> {
> "instanceId": "192.168.1.100:8761",
> "hostName": "192.168.1.100",
> "app": "APISIX-EUREKA",
> "ipAddr": "192.168.1.100",
> "status": "UP",
> "overriddenStatus": "UNKNOWN",
> "port": {
> "$": 8761,
> "@enabled": "true"
> },
> "securePort": {
> "$": 443,
> "@enabled": "false"
> },
> "countryId": 1,
> "dataCenterInfo": {
> "@class":
> "com.netflix.appinfo.InstanceInfo$DefaultDataCenterInfo",
> "name": "MyOwn"
> },
> "leaseInfo": {
> "renewalIntervalInSecs": 30,
> "durationInSecs": 90,
> "registrationTimestamp": 1585205921502,
> "lastRenewalTimestamp": 1585206281274,
> "evictionTimestamp": 0,
> "serviceUpTimestamp": 1585205921502
> },
> "metadata": {
> "management.port": "8761"
> },
> "homePageUrl": "http://192.168.1.100:8761/";,
> "statusPageUrl": "
> http://192.168.1.100:8761/actuator/info";,
> "healthCheckUrl": "
> http://192.168.1.100:8761/actuator/health";,
> "vipAddress": "apisix-eureka",
> "secureVipAddress": "apisix-eureka",
> "isCoordinatingDiscoveryServer": "true",
> "lastUpdatedTimestamp": "1585205921502",
> "lastDirtyTimestamp": "1585205921295",
> "actionType": "ADDED"
> }
> ]
> }
> ]
> }
> }
>
> tansform to the nodes of upstream:
>
> {
> "192.168.1.100:8761" = 1,
> }
>
> others data (type, retries, timeout Etc.) of upstream are from
> configuration.
>
>
>
>
> > From: "suo zhang";
> > Date: Thu, Mar 26, 2020 12:54 PM
> > To: "dev";
> > Subject: Re: [DISCUSS] how about the design of APISIX eureka integration?
>
> > > hello. maybe you should give a example and descripte how fetch the data
> > > from eureka and tansform to the data in the upstream.
> > > maybe you should show the APIs of eureka and their‘s output.
>
>
> > Ming Wen 于2020年3月26日周四 下午12:10写道：
>
> > that will be great, and you can also post the design here instead of PR
> >
> > ~Jarvis.Qiu 于2020年3月26日 周四上午11:57写道：
> >
> > > just Chinese version now.
> > >
> > >
> > > I need to spend some time translating it。
> > >
> > >
> > >
> > >
> > > -- 原始邮件 --
> > > 发件人: "Ming Wen" > > 发送时间: 2020年3月26日(星期四) 中午11:54
> > > 收件人: "dev" > >
> > > 主题: Re: [DISCUSS] how about the design of APISIX eureka
> integration?
> >
Re: [DISCUSS] how about the design of APISIX eureka integration?
Eureka REST API:
https://github.com/Netflix/eureka/wiki/Eureka-REST-operations
we just need `GET /eureka/apps`, and its output:
{
"applications": {
"versions__delta": "1",
"apps__hashcode": "UP_1_",
"application": [
{
"name": "APISIX-EUREKA",
"instance": [
{
"instanceId": "192.168.1.100:8761",
"hostName": "192.168.1.100",
"app": "APISIX-EUREKA",
"ipAddr": "192.168.1.100",
"status": "UP",
"overriddenStatus": "UNKNOWN",
"port": {
"$": 8761,
"@enabled": "true"
},
"securePort": {
"$": 443,
"@enabled": "false"
},
"countryId": 1,
"dataCenterInfo": {
"@class":
"com.netflix.appinfo.InstanceInfo$DefaultDataCenterInfo",
"name": "MyOwn"
},
"leaseInfo": {
"renewalIntervalInSecs": 30,
"durationInSecs": 90,
"registrationTimestamp": 1585205921502,
"lastRenewalTimestamp": 1585206281274,
"evictionTimestamp": 0,
"serviceUpTimestamp": 1585205921502
},
"metadata": {
"management.port": "8761"
},
"homePageUrl": "http://192.168.1.100:8761/";,
"statusPageUrl":
"http://192.168.1.100:8761/actuator/info";,
"healthCheckUrl":
"http://192.168.1.100:8761/actuator/health";,
"vipAddress": "apisix-eureka",
"secureVipAddress": "apisix-eureka",
"isCoordinatingDiscoveryServer": "true",
"lastUpdatedTimestamp": "1585205921502",
"lastDirtyTimestamp": "1585205921295",
"actionType": "ADDED"
}
]
}
]
}
}
tansform to the nodes of upstream:
{
"192.168.1.100:8761" = 1,
}
others data (type, retries, timeout Etc.) of upstream are from configuration.
> From: "suo zhang";
> Date: Thu, Mar 26, 2020 12:54 PM
> To: "dev";
> Subject: Re: [DISCUSS] how about the design of APISIX eureka integration?
> > hello. maybe you should give a example and descripte how fetch the data
> > from eureka and tansform to the data in the upstream.
> > maybe you should show the APIs of eureka and their??s output.
> Ming Wen ??2020??3??26?? 12:10??
> that will be great, and you can also post the design here instead of PR
>
> ~Jarvis.Qiu ??2020??3??26?? 11:57??
>
> > just Chinese version now.
> >
> >
> > I need to spend some time translating it??
> >
> >
> >
> >
> > -- --
> > ??: "Ming Wen" > : 2020??3??26??(??) ????11:54
> > ??????: "dev" >
> > : Re: [DISCUSS] how about the design of APISIX eureka integration?
> >
> >
> >
> > Do you have the English version?
> >
> > Thanks,
> > Ming Wen, Apache APISIX & Apache SkyWalking
> > Twitter: _WenMing
> >
> >
> > ~Jarvis.Qiu >
> > > the doc url is :
> > >
> > >
> > >
> > >
> >
> https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md
> > >
> > <
> https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md>
> >
> > ;
> > >
> > >
> > >
> > > -- --
> > > ???
Re: [DISCUSS] how about the design of APISIX eureka integration?
hello. maybe you should give a example and descripte how fetch the data from eureka and tansform to the data in the upstream. maybe you should show the APIs of eureka and their‘s output. Ming Wen 于2020年3月26日周四 下午12:10写道： > that will be great, and you can also post the design here instead of PR > > ~Jarvis.Qiu 于2020年3月26日 周四上午11:57写道： > > > just Chinese version now. > > > > > > I need to spend some time translating it。 > > > > > > > > > > -- 原始邮件 -- > > 发件人: "Ming Wen" > 发送时间: 2020年3月26日(星期四) 中午11:54 > > 收件人: "dev" > > > 主题: Re: [DISCUSS] how about the design of APISIX eureka integration? > > > > > > > > Do you have the English version? > > > > Thanks, > > Ming Wen, Apache APISIX & Apache SkyWalking > > Twitter: _WenMing > > > > > > ~Jarvis.Qiu > > > > the doc url is : > > > > > > > > > > > > > > > https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md > > > > > < > https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md> > > > > ; > > > > > > > > > > > > -- 原始邮件 -- > > > 发件人: "Ming Wen" > > 发送时间: 2020年3月26日(星期四) 中午11:49 > > > 收件人: "dev" > > > > > 主题: Re: [DISCUSS] how about the design of APISIX eureka > > integration? > > > > > > > > > > > > bad link, return 404. > > > > > > Thanks, > > > Ming Wen, Apache APISIX & Apache SkyWalking > > > Twitter: _WenMing > > > > > > > > > ~Jarvis.Qiu > > > > > > Hi: > > > > > > > > > > > > here is a doc : > > > > > > > > > > https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md&nbsp;for&nbsp;the > > > > > < > https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md&nbsp;for&nbsp;the> > >; > > > > > > < > > > https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md&nbsp;for&nbsp;the>> > > ;; > > > design of APISIX eureka integration.&nbsp; > > > > > > > > > > > > I hope you can give me some advice. > > > > > > > > > > > > the PR:&nbsp; > > https://github.com/apache/incubator-apisix/pull/1281 > > -- > Thanks, > Ming Wen, Apache APISIX & Apache SkyWalking > Twitter: _WenMing >
Re: [DISCUSS] how about the design of APISIX eureka integration?
that will be great, and you can also post the design here instead of PR ~Jarvis.Qiu 于2020年3月26日 周四上午11:57写道： > just Chinese version now. > > > I need to spend some time translating it。 > > > > > -- 原始邮件 -- > 发件人: "Ming Wen" 发送时间: 2020年3月26日(星期四) 中午11:54 > 收件人: "dev" > 主题: Re: [DISCUSS] how about the design of APISIX eureka integration? > > > > Do you have the English version? > > Thanks, > Ming Wen, Apache APISIX & Apache SkyWalking > Twitter: _WenMing > > > ~Jarvis.Qiu > > the doc url is : > > > > > > > > > https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md > > > <https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md>> > ; > > > > > > > > ---------- 原始邮件 -- > > 发件人: "Ming Wen" > 发送时间: 2020年3月26日(星期四) 中午11:49 > > 收件人: "dev" > > > 主题: Re: [DISCUSS] how about the design of APISIX eureka > integration? > > > > > > > > bad link, return 404. > > > > Thanks, > > Ming Wen, Apache APISIX & Apache SkyWalking > > Twitter: _WenMing > > > > > > ~Jarvis.Qiu > > > > Hi: > > > > > > > > > here is a doc : > > > > > > https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md&nbsp;for&nbsp;the > > > <https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md&nbsp;for&nbsp;the>>; > > > > < > https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md&nbsp;for&nbsp;the>> > ;; > > design of APISIX eureka integration.&nbsp; > > > > > > > > > I hope you can give me some advice. > > > > > > > > > the PR:&nbsp; > https://github.com/apache/incubator-apisix/pull/1281 -- Thanks, Ming Wen, Apache APISIX & Apache SkyWalking Twitter: _WenMing
Re: [DISCUSS] how about the design of APISIX eureka integration?
Do you have the English version? Thanks, Ming Wen, Apache APISIX & Apache SkyWalking Twitter: _WenMing ~Jarvis.Qiu 于2020年3月26日周四 上午11:53写道： > the doc url is : > > > > https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md > > > > > -- 原始邮件 -- > 发件人: "Ming Wen" 发送时间: 2020年3月26日(星期四) 中午11:49 > 收件人: "dev" > 主题: Re: [DISCUSS] how about the design of APISIX eureka integration? > > > > bad link, return 404. > > Thanks, > Ming Wen, Apache APISIX & Apache SkyWalking > Twitter: _WenMing > > > ~Jarvis.Qiu > > Hi: > > > > > > here is a doc : > > > https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md for the > > > <https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md for the>>; > design of APISIX eureka integration. > > > > > > I hope you can give me some advice. > > > > > > the PR: https://github.com/apache/incubator-apisix/pull/1281
Re: [DISCUSS] how about the design of APISIX eureka integration?
bad link, return 404. Thanks, Ming Wen, Apache APISIX & Apache SkyWalking Twitter: _WenMing ~Jarvis.Qiu 于2020年3月26日周四 上午11:48写道： > Hi: > > > here is a doc : > https://github.com/apache/incubator-apisix/blob/170f4650f1faeb454c1ff69ea97fe1287710ec77/doc/discovery-cn.md for the > design of APISIX eureka integration. > > > I hope you can give me some advice. > > > the PR: https://github.com/apache/incubator-apisix/pull/1281
