You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apisix.apache.org by 聂永 <ni...@staff.weibo.com> on 2021/02/01 01:52:57 UTC
Re: [DISCUSS] Add control api support for the discovery module
Hi,
We don't need hardcode for discovery module's control api path.
The real http api path =
The fixed prefix: `/v1/discovery/` + defined `discovery_type` in yaml (eg: `eureka`) + defined uris(eg: `/dump`)
2021年1月29日 22:13，Zexuan Luo <sp...@apache.org>> 写道：
discovery typ
Re: [DISCUSS] Add consul_kv discovery module for apisix
Posted by 聂永 <ni...@staff.weibo.com>.
Hi,
Yes, it support.
And, the discovery module does not matter upstream upper protocol.
> 2021年2月20日 17:04，大可 <hn...@gmail.com> 写道：
>
> Excellent, what about support other protocols like gRPC?
>
> 聂永 <ni...@staff.weibo.com> 于2021年2月20日周六 下午4:25写道：
>
>> Hi,
>>
>> The PR is here: https://github.com/apache/apisix/pull/3615
>>
>> And, all checks have passed now :))
>>
>>
>> 2021年2月20日 14:58，Li Yang <ya...@apache.org>> 写道：
>>
>> Hi,
>>
>> My question is that from your example
>> "http://127.0.0.1:8500/v1/kv/upstreams/webpages/" seems to be the uri
>> we used to query a registered service.
>>
>> Maybe we can split this long connection string to multiple
>> parts, such as consul_server, consul_prefix, service_name...
>>
>> On Fri, Feb 19, 2021 at 2:12 PM 聂永 <nieyong@staff.weibo.com<mailto:
>> nieyong@staff.weibo.com>> wrote:
>>
>> Hi,
>>
>> I am back :)
>>
>> As the `eureka` demo show:
>>
>> ```bash
>> $ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY:
>> edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
>> {
>> "uri": "/user/*",
>> "upstream": {
>> "service_name": "USER-SERVICE",
>> "type": "roundrobin",
>> "discovery_type": "eureka"
>> }
>> }'
>> ```
>>
>> So, we can use the `consul_kv` below:
>>
>> ```bash
>> --- apisix_yaml
>> routes:
>> -
>> uri: /*
>> upstream:
>> service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
>> discovery_type: consul_kv
>> type: roundrobin
>> ```
>>
>> And, we don't need to import another `consul_url` or other variable, just
>> use `service_name` is ok for most service discovery ways.
>>
>> 2021年2月8日 13:00，Li Yang <ya...@apache.org>> 写道：
>>
>> It sounds like a very useful feature for me.
>>
>> My question is how will we configure routes after this feature?
>>
>> Is this your planned way of configuring routes?
>>
>> --- apisix_yaml
>> routes:
>> -
>> uri: /*
>> upstream:
>> service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
>> discovery_type: consul_kv
>> type: roundrobin
>>
>> The service_name variable name seems not accurate enough. Can we call
>> it consul_uri or something like this?
>>
>>
>> On Mon, Feb 8, 2021 at 11:23 AM Zexuan Luo <spacewander@apache.org<mailto:
>> spacewander@apache.org>> wrote:
>>
>> * doc
>> * english
>> * chinese
>>
>> We can only provide the English version of doc.
>>
>> Zexuan Luo <sp...@apache.org>>
>> 于2021年2月8日周一 上午10:48写道：
>>
>> If you need any help, please let us know.
>>
>>
>>
>>
>>
Re: [DISCUSS] Add consul_kv discovery module for apisix
Posted by 大可 <hn...@gmail.com>.
Excellent, what about support other protocols like gRPC?
聂永 <ni...@staff.weibo.com> 于2021年2月20日周六 下午4:25写道：
> Hi,
>
> The PR is here: https://github.com/apache/apisix/pull/3615
>
> And, all checks have passed now :))
>
>
> 2021年2月20日 14:58，Li Yang <ya...@apache.org>> 写道：
>
> Hi,
>
> My question is that from your example
> "http://127.0.0.1:8500/v1/kv/upstreams/webpages/" seems to be the uri
> we used to query a registered service.
>
> Maybe we can split this long connection string to multiple
> parts, such as consul_server, consul_prefix, service_name...
>
> On Fri, Feb 19, 2021 at 2:12 PM 聂永 <nieyong@staff.weibo.com<mailto:
> nieyong@staff.weibo.com>> wrote:
>
> Hi,
>
> I am back :)
>
> As the `eureka` demo show:
>
> ```bash
> $ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY:
> edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
> {
> "uri": "/user/*",
> "upstream": {
> "service_name": "USER-SERVICE",
> "type": "roundrobin",
> "discovery_type": "eureka"
> }
> }'
> ```
>
> So, we can use the `consul_kv` below:
>
> ```bash
> --- apisix_yaml
> routes:
> -
> uri: /*
> upstream:
> service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
> discovery_type: consul_kv
> type: roundrobin
> ```
>
> And, we don't need to import another `consul_url` or other variable, just
> use `service_name` is ok for most service discovery ways.
>
> 2021年2月8日 13:00，Li Yang <ya...@apache.org>> 写道：
>
> It sounds like a very useful feature for me.
>
> My question is how will we configure routes after this feature?
>
> Is this your planned way of configuring routes?
>
> --- apisix_yaml
> routes:
> -
> uri: /*
> upstream:
> service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
> discovery_type: consul_kv
> type: roundrobin
>
> The service_name variable name seems not accurate enough. Can we call
> it consul_uri or something like this?
>
>
> On Mon, Feb 8, 2021 at 11:23 AM Zexuan Luo <spacewander@apache.org<mailto:
> spacewander@apache.org>> wrote:
>
> * doc
> * english
> * chinese
>
> We can only provide the English version of doc.
>
> Zexuan Luo <sp...@apache.org>>
> 于2021年2月8日周一 上午10:48写道：
>
> If you need any help, please let us know.
>
>
>
>
>
Re: [DISCUSS] Add consul_kv discovery module for apisix
Posted by 聂永 <ni...@staff.weibo.com>.
Hi,
The PR is here: https://github.com/apache/apisix/pull/3615
And, all checks have passed now :))
2021年2月20日 14:58，Li Yang <ya...@apache.org>> 写道：
Hi,
My question is that from your example
"http://127.0.0.1:8500/v1/kv/upstreams/webpages/" seems to be the uri
we used to query a registered service.
Maybe we can split this long connection string to multiple
parts, such as consul_server, consul_prefix, service_name...
On Fri, Feb 19, 2021 at 2:12 PM 聂永 <ni...@staff.weibo.com>> wrote:
Hi,
I am back :)
As the `eureka` demo show:
```bash
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
"uri": "/user/*",
"upstream": {
"service_name": "USER-SERVICE",
"type": "roundrobin",
"discovery_type": "eureka"
}
}'
```
So, we can use the `consul_kv` below:
```bash
--- apisix_yaml
routes:
-
uri: /*
upstream:
service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
discovery_type: consul_kv
type: roundrobin
```
And, we don't need to import another `consul_url` or other variable, just use `service_name` is ok for most service discovery ways.
2021年2月8日 13:00，Li Yang <ya...@apache.org>> 写道：
It sounds like a very useful feature for me.
My question is how will we configure routes after this feature?
Is this your planned way of configuring routes?
--- apisix_yaml
routes:
-
uri: /*
upstream:
service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
discovery_type: consul_kv
type: roundrobin
The service_name variable name seems not accurate enough. Can we call
it consul_uri or something like this?
On Mon, Feb 8, 2021 at 11:23 AM Zexuan Luo <sp...@apache.org>> wrote:
* doc
* english
* chinese
We can only provide the English version of doc.
Zexuan Luo <sp...@apache.org>> 于2021年2月8日周一 上午10:48写道：
If you need any help, please let us know.
Re: [DISCUSS] Add consul_kv discovery module for apisix
Posted by Li Yang <ya...@apache.org>.
Hi,
My question is that from your example
"http://127.0.0.1:8500/v1/kv/upstreams/webpages/" seems to be the uri
we used to query a registered service.
Maybe we can split this long connection string to multiple
parts, such as consul_server, consul_prefix, service_name...
On Fri, Feb 19, 2021 at 2:12 PM 聂永 <ni...@staff.weibo.com> wrote:
>
> Hi,
>
> I am back :)
>
> As the `eureka` demo show:
>
> ```bash
> $ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
> {
> "uri": "/user/*",
> "upstream": {
> "service_name": "USER-SERVICE",
> "type": "roundrobin",
> "discovery_type": "eureka"
> }
> }'
> ```
>
> So, we can use the `consul_kv` below:
>
> ```bash
> --- apisix_yaml
> routes:
> -
> uri: /*
> upstream:
> service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
> discovery_type: consul_kv
> type: roundrobin
> ```
>
> And, we don't need to import another `consul_url` or other variable, just use `service_name` is ok for most service discovery ways.
>
> > 2021年2月8日 13:00，Li Yang <ya...@apache.org> 写道：
> >
> > It sounds like a very useful feature for me.
> >
> > My question is how will we configure routes after this feature?
> >
> > Is this your planned way of configuring routes?
> >
> > --- apisix_yaml
> > routes:
> > -
> > uri: /*
> > upstream:
> > service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
> > discovery_type: consul_kv
> > type: roundrobin
> >
> > The service_name variable name seems not accurate enough. Can we call
> > it consul_uri or something like this?
> >
> >
> > On Mon, Feb 8, 2021 at 11:23 AM Zexuan Luo <sp...@apache.org> wrote:
> >>
> >>> * doc
> >> * english
> >> * chinese
> >>
> >> We can only provide the English version of doc.
> >>
> >> Zexuan Luo <sp...@apache.org> 于2021年2月8日周一 上午10:48写道：
> >>
> >>> If you need any help, please let us know.
> >>>
> >>>
>
Re: [DISCUSS] Add consul_kv discovery module for apisix
Posted by 聂永 <ni...@staff.weibo.com>.
Hi,
I am back :)
As the `eureka` demo show:
```bash
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
"uri": "/user/*",
"upstream": {
"service_name": "USER-SERVICE",
"type": "roundrobin",
"discovery_type": "eureka"
}
}'
```
So, we can use the `consul_kv` below:
```bash
--- apisix_yaml
routes:
-
uri: /*
upstream:
service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
discovery_type: consul_kv
type: roundrobin
```
And, we don't need to import another `consul_url` or other variable, just use `service_name` is ok for most service discovery ways.
> 2021年2月8日 13:00，Li Yang <ya...@apache.org> 写道：
>
> It sounds like a very useful feature for me.
>
> My question is how will we configure routes after this feature?
>
> Is this your planned way of configuring routes?
>
> --- apisix_yaml
> routes:
> -
> uri: /*
> upstream:
> service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
> discovery_type: consul_kv
> type: roundrobin
>
> The service_name variable name seems not accurate enough. Can we call
> it consul_uri or something like this?
>
>
> On Mon, Feb 8, 2021 at 11:23 AM Zexuan Luo <sp...@apache.org> wrote:
>>
>>> * doc
>> * english
>> * chinese
>>
>> We can only provide the English version of doc.
>>
>> Zexuan Luo <sp...@apache.org> 于2021年2月8日周一 上午10:48写道：
>>
>>> If you need any help, please let us know.
>>>
>>>
Re: [DISCUSS] Add consul_kv discovery module for apisix
Posted by Li Yang <ya...@apache.org>.
It sounds like a very useful feature for me.
My question is how will we configure routes after this feature?
Is this your planned way of configuring routes?
--- apisix_yaml
routes:
-
uri: /*
upstream:
service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
discovery_type: consul_kv
type: roundrobin
The service_name variable name seems not accurate enough. Can we call
it consul_uri or something like this?
On Mon, Feb 8, 2021 at 11:23 AM Zexuan Luo <sp...@apache.org> wrote:
>
> > * doc
> * english
> * chinese
>
> We can only provide the English version of doc.
>
> Zexuan Luo <sp...@apache.org> 于2021年2月8日周一 上午10:48写道：
>
> > If you need any help, please let us know.
> >
> >
Re: [DISCUSS] Add consul_kv discovery module for apisix
Posted by Zexuan Luo <sp...@apache.org>.
> * doc
* english
* chinese
We can only provide the English version of doc.
Zexuan Luo <sp...@apache.org> 于2021年2月8日周一 上午10:48写道：
> If you need any help, please let us know.
>
>
Re: [DISCUSS] Add consul_kv discovery module for apisix
Posted by Zexuan Luo <sp...@apache.org>.
If you need any help, please let us know.
Re: [DISCUSS] Add consul_kv discovery module for apisix
Posted by 聂永 <ni...@staff.weibo.com>.
Hi,
Here is the consul_kv’s data flow png:
https://user-images.githubusercontent.com/548385/107141841-6ced3e00-6966-11eb-8aa4-bc790a4ad113.png
BTW, I need some time to prepare:
* doc
* english
* chinese
* tests
* CI
* run two instance of consul servers
* code
* a little details adjust
2021年2月7日 21:35，Zexuan Luo <sp...@apache.org>> 写道：
Ignore my question. It seems they are two different things.
Zexuan Luo <sp...@apache.org>> 于2021年2月7日周日 下午9:32写道：
PR is welcome!
BTW, does it require nginx-upsync-module?
聂永 <ni...@staff.weibo.com>> 于2021年2月7日周日 下午5:22写道：
Hi,
I had shared a topic 《基于APISIX的定制开发》 in Apisix DevCon 2020, which
referred to our consul key&value service discovery module a little. And we
want to submit it as a PR for APISIX now.
For users who used nginx-upsync-module
<https://github.com/weibocom/nginx-upsync-module> and consul key value
for service discovery way, maybe need it.
This module called consul_kv, and its worker process data flow is below:
How to use it
1. enable the consul_kv module in yaml
discovery:
consul_kv:
servers:
- "http://127.0.0.1:8500"
- "http://127.0.0.1:8600"
prefix: "upstreams"
skip_keys:
- "upstreams/unused_api/"
timeout:
connect: 1000
read: 1000
wait: 60
weight: 1
delay: 5
connect_type: "long"
default_server:
host: "127.0.0.1"
port: 20999
metadata:
fail_timeout: 1
weight: 1
max_fails: 1
2. register your api service into consul by key&value
curl \
-X PUT \
-d ' {"weight": 120, "max_fails": 2, "fail_timeout": 1}' \
http://127.0.0.1:8500/v1/kv/upstreams/webpages/172.19.5.12:8000
curl \
-X PUT \
-d ' {"weight": 120, "max_fails": 2, "fail_timeout": 1}' \
http://127.0.0.1:8500/v1/kv/upstreams/webpages/172.19.5.13:8000
3. setup your route
--- apisix_yamlroutes:
-
uri: /*
upstream:
service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
discovery_type: consul_kv
type: roundrobin
If it ok, I prepare to submit the codes, tests and docs later :))
Re: [DISCUSS] Add consul_kv discovery module for apisix
Posted by Zexuan Luo <sp...@apache.org>.
Ignore my question. It seems they are two different things.
Zexuan Luo <sp...@apache.org> 于2021年2月7日周日 下午9:32写道：
> PR is welcome!
> BTW, does it require nginx-upsync-module?
>
> 聂永 <ni...@staff.weibo.com> 于2021年2月7日周日 下午5:22写道：
>
>> Hi,
>>
>> I had shared a topic 《基于APISIX的定制开发》 in Apisix DevCon 2020, which
>> referred to our consul key&value service discovery module a little. And we
>> want to submit it as a PR for APISIX now.
>>
>> For users who used nginx-upsync-module
>> <https://github.com/weibocom/nginx-upsync-module> and consul key value
>> for service discovery way, maybe need it.
>>
>> This module called consul_kv, and its worker process data flow is below:
>>
>> How to use it
>>
>> 1. enable the consul_kv module in yaml
>>
>> discovery:
>> consul_kv:
>> servers:
>> - "http://127.0.0.1:8500"
>> - "http://127.0.0.1:8600"
>> prefix: "upstreams"
>> skip_keys:
>> - "upstreams/unused_api/"
>> timeout:
>> connect: 1000
>> read: 1000
>> wait: 60
>> weight: 1
>> delay: 5
>> connect_type: "long"
>> default_server:
>> host: "127.0.0.1"
>> port: 20999
>> metadata:
>> fail_timeout: 1
>> weight: 1
>> max_fails: 1
>>
>> 2. register your api service into consul by key&value
>>
>> curl \
>> -X PUT \
>> -d ' {"weight": 120, "max_fails": 2, "fail_timeout": 1}' \
>> http://127.0.0.1:8500/v1/kv/upstreams/webpages/172.19.5.12:8000
>>
>> curl \
>> -X PUT \
>> -d ' {"weight": 120, "max_fails": 2, "fail_timeout": 1}' \
>> http://127.0.0.1:8500/v1/kv/upstreams/webpages/172.19.5.13:8000
>>
>> 3. setup your route
>>
>> --- apisix_yamlroutes:
>> -
>> uri: /*
>> upstream:
>> service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
>> discovery_type: consul_kv
>> type: roundrobin
>>
>> If it ok, I prepare to submit the codes, tests and docs later :))
>>
>
Re: [DISCUSS] Add consul_kv discovery module for apisix
Posted by Zexuan Luo <sp...@apache.org>.
PR is welcome!
BTW, does it require nginx-upsync-module?
聂永 <ni...@staff.weibo.com> 于2021年2月7日周日 下午5:22写道：
> Hi,
>
> I had shared a topic 《基于APISIX的定制开发》 in Apisix DevCon 2020, which
> referred to our consul key&value service discovery module a little. And we
> want to submit it as a PR for APISIX now.
>
> For users who used nginx-upsync-module
> <https://github.com/weibocom/nginx-upsync-module> and consul key value
> for service discovery way, maybe need it.
>
> This module called consul_kv, and its worker process data flow is below:
>
> How to use it
>
> 1. enable the consul_kv module in yaml
>
> discovery:
> consul_kv:
> servers:
> - "http://127.0.0.1:8500"
> - "http://127.0.0.1:8600"
> prefix: "upstreams"
> skip_keys:
> - "upstreams/unused_api/"
> timeout:
> connect: 1000
> read: 1000
> wait: 60
> weight: 1
> delay: 5
> connect_type: "long"
> default_server:
> host: "127.0.0.1"
> port: 20999
> metadata:
> fail_timeout: 1
> weight: 1
> max_fails: 1
>
> 2. register your api service into consul by key&value
>
> curl \
> -X PUT \
> -d ' {"weight": 120, "max_fails": 2, "fail_timeout": 1}' \
> http://127.0.0.1:8500/v1/kv/upstreams/webpages/172.19.5.12:8000
>
> curl \
> -X PUT \
> -d ' {"weight": 120, "max_fails": 2, "fail_timeout": 1}' \
> http://127.0.0.1:8500/v1/kv/upstreams/webpages/172.19.5.13:8000
>
> 3. setup your route
>
> --- apisix_yamlroutes:
> -
> uri: /*
> upstream:
> service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
> discovery_type: consul_kv
> type: roundrobin
>
> If it ok, I prepare to submit the codes, tests and docs later :))
>
[DISCUSS] Add consul_kv discovery module for apisix
Posted by 聂永 <ni...@staff.weibo.com>.
Hi,
I had shared a topic 《基于APISIX的定制开发》 in Apisix DevCon 2020, which referred to our consul key&value service discovery module a little. And we want to submit it as a PR for APISIX now.
For users who used nginx-upsync-module<https://github.com/weibocom/nginx-upsync-module> and consul key value for service discovery way, maybe need it.
This module called consul_kv, and its worker process data flow is below:
[cid:BBAFF308-06DF-4F9B-BDEE-AA18DC6CC512@staff.sina.com.cn]
How to use it
1. enable the consul_kv module in yaml
discovery:
consul_kv:
servers:
- "http://127.0.0.1:8500"
- "http://127.0.0.1:8600"
prefix: "upstreams"
skip_keys:
- "upstreams/unused_api/"
timeout:
connect: 1000
read: 1000
wait: 60
weight: 1
delay: 5
connect_type: "long"
default_server:
host: "127.0.0.1"
port: 20999
metadata:
fail_timeout: 1
weight: 1
max_fails: 1
2. register your api service into consul by key&value
curl \
-X PUT \
-d ' {"weight": 120, "max_fails": 2, "fail_timeout": 1}' \
http://127.0.0.1:8500/v1/kv/upstreams/webpages/172.19.5.12:8000
curl \
-X PUT \
-d ' {"weight": 120, "max_fails": 2, "fail_timeout": 1}' \
http://127.0.0.1:8500/v1/kv/upstreams/webpages/172.19.5.13:8000
3. setup your route
--- apisix_yaml
routes:
-
uri: /*
upstream:
service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
discovery_type: consul_kv
type: roundrobin
If it ok, I prepare to submit the codes, tests and docs later :))
Re: [DISCUSS] Add control api support for the discovery module
Posted by 聂永 <ni...@staff.weibo.com>.
Hi,
The idea sounds good.
And, we need the real discovery module to export some method, as to implement the _M.dump_datainterface, which is optional.
function _M.dump_data()
return {config = local_conf.discovery.consul_kv, services = applications}
end
So, the default api path would be :
/v1/discovery/<discovery_type>/dump
2021年2月2日 19:23，Zexuan Luo <sp...@apache.org>> 写道：
Since most of service discovery require a dump method, I think it would be
better to implement a common dump method, and use discovery type as an
argument. Therefore we don't need to implement a dump method per service
discovery.
We can require each service discovery to provide two methods:
1. get all known services
2. get the data according to the service.
聂永 <ni...@staff.weibo.com>> 于2021年2月2日周二 上午10:11写道：
The discovery has many modules, such as eureka,consul_kv,etcd_kv, and so
on .
The modules api URI template should have a good structure:
/v1/discovery/<discovery_type>/<service_name>
So, the http api URI path =
The fixed prefix: /v1/discovery/ + defined discovery_type in yaml (eg:
eureka) + defined uris(eg: /dump)
My discovery_type is consul_kv, the consul_kv’s control api:
function _M.control_api()
return {
{
methods = {"GET"},
uris = {"/dump"},
handler = dump_info
},
{
methods = {"PUT"},
uris = {"/update_kv"},
handler = update_info
}
}
end
eg:
* /v1/discovery/consul_kv/dump
* /v1/discovery/consul_kv/update_kv
We maybe need another discovery module in future, as consul_service, we
maybe need export the debugging api below:
* /v1/discovery/consul_service/view_all_services
What do you think ?
2021年2月1日 10:49，Zexuan Luo <sp...@apache.org><mailto:
spacewander@apache.org<ma...@apache.org>>> 写道：
I am confused by the ` defined uris(eg: `/dump`)` part. Why should we need
another part for the uri?
Why not use `v1/discovery/dump`?
聂永 <ni...@staff.weibo.com>> 于2021年2月1日周一
上午9:53写道：
Hi,
We don't need hardcode for discovery module's control api path.
The real http api path =
The fixed prefix: `/v1/discovery/` + defined `discovery_type` in yaml (eg:
`eureka`) + defined uris(eg: `/dump`)
2021年1月29日 22:13，Zexuan Luo <sp...@apache.org><mailto:
spacewander@apache.org<ma...@apache.org>><mailto:
spacewander@apache.org<ma...@apache.org>>> 写道：
discovery typ
Re: [DISCUSS] Add control api support for the discovery module
Posted by Zexuan Luo <sp...@apache.org>.
Since most of service discovery require a dump method, I think it would be
better to implement a common dump method, and use discovery type as an
argument. Therefore we don't need to implement a dump method per service
discovery.
We can require each service discovery to provide two methods:
1. get all known services
2. get the data according to the service.
聂永 <ni...@staff.weibo.com> 于2021年2月2日周二 上午10:11写道：
> The discovery has many modules, such as eureka,consul_kv,etcd_kv, and so
> on .
>
> The modules api URI template should have a good structure:
>
> /v1/discovery/<discovery_type>/<service_name>
>
>
> So, the http api URI path =
> The fixed prefix: /v1/discovery/ + defined discovery_type in yaml (eg:
> eureka) + defined uris(eg: /dump)
>
> My discovery_type is consul_kv, the consul_kv’s control api:
>
> function _M.control_api()
> return {
> {
> methods = {"GET"},
> uris = {"/dump"},
> handler = dump_info
> },
> {
> methods = {"PUT"},
> uris = {"/update_kv"},
> handler = update_info
> }
> }
> end
>
>
> eg:
>
> * /v1/discovery/consul_kv/dump
> * /v1/discovery/consul_kv/update_kv
>
> We maybe need another discovery module in future, as consul_service, we
> maybe need export the debugging api below:
>
> * /v1/discovery/consul_service/view_all_services
>
> What do you think ?
>
>
> 2021年2月1日 10:49，Zexuan Luo <spacewander@apache.org<mailto:
> spacewander@apache.org>> 写道：
>
> I am confused by the ` defined uris(eg: `/dump`)` part. Why should we need
> another part for the uri?
> Why not use `v1/discovery/dump`?
>
> 聂永 <ni...@staff.weibo.com>> 于2021年2月1日周一
> 上午9:53写道：
>
> Hi,
>
> We don't need hardcode for discovery module's control api path.
>
> The real http api path =
> The fixed prefix: `/v1/discovery/` + defined `discovery_type` in yaml (eg:
> `eureka`) + defined uris(eg: `/dump`)
>
>
> 2021年1月29日 22:13，Zexuan Luo <spacewander@apache.org<mailto:
> spacewander@apache.org><mailto:
> spacewander@apache.org<ma...@apache.org>>> 写道：
>
> discovery typ
>
>
>
>
Re: [DISCUSS] Add control api support for the discovery module
Posted by 聂永 <ni...@staff.weibo.com>.
The discovery has many modules, such as eureka,consul_kv,etcd_kv, and so on .
The modules api URI template should have a good structure:
/v1/discovery/<discovery_type>/<service_name>
So, the http api URI path =
The fixed prefix: /v1/discovery/ + defined discovery_type in yaml (eg: eureka) + defined uris(eg: /dump)
My discovery_type is consul_kv, the consul_kv’s control api:
function _M.control_api()
return {
{
methods = {"GET"},
uris = {"/dump"},
handler = dump_info
},
{
methods = {"PUT"},
uris = {"/update_kv"},
handler = update_info
}
}
end
eg:
* /v1/discovery/consul_kv/dump
* /v1/discovery/consul_kv/update_kv
We maybe need another discovery module in future, as consul_service, we maybe need export the debugging api below:
* /v1/discovery/consul_service/view_all_services
What do you think ?
2021年2月1日 10:49，Zexuan Luo <sp...@apache.org>> 写道：
I am confused by the ` defined uris(eg: `/dump`)` part. Why should we need
another part for the uri?
Why not use `v1/discovery/dump`?
聂永 <ni...@staff.weibo.com>> 于2021年2月1日周一 上午9:53写道：
Hi,
We don't need hardcode for discovery module's control api path.
The real http api path =
The fixed prefix: `/v1/discovery/` + defined `discovery_type` in yaml (eg:
`eureka`) + defined uris(eg: `/dump`)
2021年1月29日 22:13，Zexuan Luo <sp...@apache.org><mailto:
spacewander@apache.org<ma...@apache.org>>> 写道：
discovery typ
Re: [DISCUSS] Add control api support for the discovery module
Posted by Zexuan Luo <sp...@apache.org>.
I am confused by the ` defined uris(eg: `/dump`)` part. Why should we need
another part for the uri?
Why not use `v1/discovery/dump`?
聂永 <ni...@staff.weibo.com> 于2021年2月1日周一 上午9:53写道：
> Hi,
>
> We don't need hardcode for discovery module's control api path.
>
> The real http api path =
> The fixed prefix: `/v1/discovery/` + defined `discovery_type` in yaml (eg:
> `eureka`) + defined uris(eg: `/dump`)
>
>
> 2021年1月29日 22:13，Zexuan Luo <spacewander@apache.org<mailto:
> spacewander@apache.org>> 写道：
>
> discovery typ
>
>