同步操作将从 iresty/Apache APISIX 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
title |
---|
DNS |
Some service discovery system, like Consul, support exposing service information via DNS. Therefore we can use this way to discover service directly.
First of all, we need to configure the address of DNS servers:
# add this to config.yaml
discovery:
dns:
servers:
- "127.0.0.1:8600" # use the real address of your dns server
Unlike configuring the domain in the Upstream's nodes
field, service discovery via
DNS will return all records. For example, with upstream configuration:
{
"id": 1,
"discovery_type": "dns",
"service_name": "test.consul.service",
"type": "roundrobin"
}
and test.consul.service
be resolved as 1.1.1.1
and 1.1.1.2
, this result will be the same as:
{
"id": 1,
"type": "roundrobin",
"nodes": [
{"host": "1.1.1.1", "weight": 1},
{"host": "1.1.1.2", "weight": 1}
]
}
Note that all the IPs from test.consul.service
share the same weight.
If a service has both A and AAAA records, A record is preferred.
If you want to specify the port for the upstream server, you can add it to the service_name
:
{
"id": 1,
"discovery_type": "dns",
"service_name": "test.consul.service:1980",
"type": "roundrobin"
}
Another way to do it is via the SRV record, see below.
By using SRV record you can specify the port and the weight of a service.
Assumed you have the SRV record like this:
; under the section of blah.service
A 300 IN A 1.1.1.1
B 300 IN A 1.1.1.2
B 300 IN A 1.1.1.3
; name TTL type priority weight port
srv 86400 IN SRV 10 60 1980 A
srv 86400 IN SRV 20 20 1981 B
Upstream configuration like:
{
"id": 1,
"discovery_type": "dns",
"service_name": "srv.blah.service",
"type": "roundrobin"
}
is the same as:
{
"id": 1,
"type": "roundrobin",
"nodes": [
{"host": "1.1.1.1", "port": 1980, "weight": 60, "priority": -10},
{"host": "1.1.1.2", "port": 1981, "weight": 10, "priority": -20},
{"host": "1.1.1.3", "port": 1981, "weight": 10, "priority": -20}
]
}
Note that two records of domain B split the weight evenly. For SRV record, nodes with lower priority are chosen first, so the final priority is negative.
As for 0 weight SRV record, the RFC 2782 says:
Domain administrators SHOULD use Weight 0 when there isn't any server selection to do, to make the RR easier to read for humans (less noisy). In the presence of records containing weights greater than 0, records with weight 0 should have a very small chance of being selected.
We treat weight 0 record has a weight of 1 so the node "have a very small chance of being selected", which is also the common way to treat this type of record.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。