Integration service discovery registry
Summary
When system traffic changes, the number of servers of the upstream service also increases or decreases, or the server needs to be replaced due to its hardware failure. If the gateway maintains upstream 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:
- 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 mechanism such as a heartbeat, and if the registry and the service are unable to communicate for a long time, the instance will be cancel.When the service goes offline, the registry will delete the instance information.
- The gateway gets service instance information from the registry in near-real time.
- When the user requests the service through the gateway, the gateway selects one instance from the registry for proxy.
How to extend the discovery client?
Basic steps
It is very easy for APISIX to extend the discovery client, the basic steps are as follows
Add the implementation of registry client in the ‘apisix/discovery/‘ directory;
Implement the
_M.init_worker()
function for initialization and the_M.nodes(service_name)
function for obtaining the list of service instance nodes;If you need the discovery module to export the debugging information online, implement the
_M.dump_data()
function;Convert the registry data into data in APISIX;
the example of Eureka
Implementation of Eureka client
First, create a directory eureka
under apisix/discovery
;
After that, add init.lua in the apisix/discovery/eureka
directory;
Then implement the _M.init_worker()
function for initialization and the _M.nodes(service_name)
function for obtaining the list of service instance nodes in init.lua
:
local _M = {
version = 1.0,
}
function _M.nodes(service_name)
... ...
end
function _M.init_worker()
... ...
end
function _M.dump_data()
return {config = your_config, services = your_services, other = ... }
end
return _M
Finally, provide the schema for YAML configuration in the schema.lua
under apisix/discovery/eureka
.
How convert Eureka’s instance data to APISIX’s node?
Here’s an example of Eureka’s data:
{
"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 :
- select the UP instance. When the value of
overriddenStatus
is “UP” or the value ofoverriddenStatus
is “UNKNOWN” and the value ofstatus
is “UP”. - Host. The
ipAddr
is the IP address of instance; and must be IPv4 or IPv6. - Port. If the value of
port["@enabled"]
is equal to “true”, using the value ofport["\$"]
, If the value ofsecurePort["@enabled"]
is equal to “true”, using the value ofsecurePort["\$"]
. - Weight.
local weight = metadata.weight or local_conf.eureka.weight or 100
The result of this example is as follows:
[
{
"host" : "192.168.1.100",
"port" : 8761,
"weight" : 100,
"metadata" : {
"management.port": "8761"
}
}
]
Configuration for discovery client
Initial service discovery
Add the following configuration to conf/config.yaml
to add different service discovery clients for dynamic selection during use:
discovery:
eureka:
...
This name should be consistent with the file name of the implementation registry in the apisix/discovery/
directory.
The supported discovery client: Eureka.
Configuration for Eureka
Add following configuration in conf/config.yaml
:
discovery:
eureka:
host: # it's possible to define multiple eureka hosts addresses of the same eureka cluster.
- "http://${username}:${password}@${eureka_host1}:${eureka_port1}"
- "http://${username}:${password}@${eureka_host2}:${eureka_port2}"
prefix: "/eureka/"
fetch_interval: 30 # 30s
weight: 100 # default weight for node
timeout:
connect: 2000 # 2000ms
send: 2000 # 2000ms
read: 5000 # 5000ms
Upstream setting
L7
Here is an example of routing a request with a URL of “/user/*“ to a service which named “user-service” and use eureka discovery client in the registry :
note
You can fetch the admin_key
from config.yaml
and save to an environment variable with the following command:
admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"//g')
$ curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -i -d '
{
"uri": "/user/*",
"upstream": {
"service_name": "USER-SERVICE",
"type": "roundrobin",
"discovery_type": "eureka"
}
}'
HTTP/1.1 201 Created
Date: Sat, 31 Aug 2019 01:17:15 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive
Server: APISIX web server
{"node":{"value":{"uri":"\/user\/*","upstream": {"service_name": "USER-SERVICE", "type": "roundrobin", "discovery_type": "eureka"}},"createdIndex":61925,"key":"\/apisix\/routes\/1","modifiedIndex":61925}}
Because the upstream interface URL may have conflict, usually in the gateway by prefix to distinguish:
$ curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -i -d '
{
"uri": "/a/*",
"plugins": {
"proxy-rewrite" : {
"regex_uri": ["^/a/(.*)", "/${1}"]
}
},
"upstream": {
"service_name": "A-SERVICE",
"type": "roundrobin",
"discovery_type": "eureka"
}
}'
$ curl http://127.0.0.1:9180/apisix/admin/routes/2 -H "X-API-KEY: $admin_key" -X PUT -i -d '
{
"uri": "/b/*",
"plugins": {
"proxy-rewrite" : {
"regex_uri": ["^/b/(.*)", "/${1}"]
}
},
"upstream": {
"service_name": "B-SERVICE",
"type": "roundrobin",
"discovery_type": "eureka"
}
}'
Suppose both A-SERVICE and B-SERVICE provide a /test
API. The above configuration allows access to A-SERVICE’s /test
API through /a/test
and B-SERVICE’s /test
API through /b/test
.
Notice:When configuring upstream.service_name
, upstream.nodes
will no longer take effect, but will be replaced by ‘nodes’ obtained from the registry.
L4
Eureka service discovery also supports use in L4, the configuration method is similar to L7.
$ curl http://127.0.0.1:9180/apisix/admin/stream_routes/1 -H "X-API-KEY: $admin_key" -X PUT -i -d '
{
"remote_addr": "127.0.0.1",
"upstream": {
"scheme": "tcp",
"discovery_type": "eureka",
"service_name": "APISIX-EUREKA",
"type": "roundrobin"
}
}'
HTTP/1.1 200 OK
Date: Fri, 30 Dec 2022 03:52:19 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Server: APISIX/3.0.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: *
Access-Control-Max-Age: 3600
X-API-VERSION: v3
{"key":"\/apisix\/stream_routes\/1","value":{"remote_addr":"127.0.0.1","upstream":{"hash_on":"vars","type":"roundrobin","discovery_type":"eureka","scheme":"tcp","pass_host":"pass","service_name":"APISIX-EUREKA"},"id":"1","create_time":1672106762,"update_time":1672372339}}
Embedded control api for debugging
Sometimes we need the discovery client to export online data snapshot in memory when running for debugging, and if you implement the _M. dump_data()
function:
function _M.dump_data()
return {config = local_conf.discovery.eureka, services = applications}
end
Then you can call its control api as below:
GET /v1/discovery/{discovery_type}/dump
eg:
curl http://127.0.0.1:9090/v1/discovery/eureka/dump