Integration service discovery registry

    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 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.
    2. The gateway gets service instance information from the registry in near-real time.
    3. When the user requests the service through the gateway, the gateway selects one instance from the registry for proxy.

    It is very easy for APISIX to extend the discovery client, the basic steps are as follows

    1. Add the implementation of registry client in the ‘apisix/discovery/‘ directory;

    2. Implement the function for initialization and the _M.nodes(service_name) function for obtaining the list of service instance nodes;

    3. If you need the discovery module to export the debugging information online, implement the _M.dump_data() function;

    4. Convert the registry data into data in APISIX;

    Implementation of Eureka client

    First, create a directory eureka under apisix/discovery;

    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:

    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：

    1. {
    2.   "applications": {
    3.       "application": [
    4.           {
    5.               "name": "USER-SERVICE",                 # service name
    6.               "instance": [
    7.                   {
    8.                       "instanceId": "192.168.1.100:8761",
    9.                       "hostName": "192.168.1.100",
    10.                       "app": "USER-SERVICE",          # service name
    11.                       "ipAddr": "192.168.1.100",      # IP address
    12.                       "status": "UP",
    13.                       "overriddenStatus": "UNKNOWN",
    14.                       "port": {
    15.                           "$": 8761,
    16.                       },
    17.                       "securePort": {
    18.                           "$": 443,
    19.                           "@enabled": "false"
    20.                       },
    21.                       "metadata": {
    22.                           "management.port": "8761",
    23.                           "weight": 100               # Setting by 'eureka.instance.metadata-map.weight' of the spring boot application
    24.                       },
    26.                       "statusPageUrl": "http://192.168.1.100:8761/actuator/info",
    27.                       "healthCheckUrl": "http://192.168.1.100:8761/actuator/health",
    28.                       ... ...
    29.                   }
    30.               ]
    31.           }
    32.       ]
    33.   }
    34. }

    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. Host. 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

    The result of this example is as follows:

    1. [
    2.   {
    3.     "host" : "192.168.1.100",
    4.     "port" : 8761,
    5.     "weight" : 100,
    6.     "metadata" : {
    7.       "management.port": "8761"
    8.     }
    9.   }
    10. ]

    Add the following configuration to conf/config.yaml to add different service discovery clients for dynamic selection during use:

    This name should be consistent with the file name of the implementation registry in the apisix/discovery/ directory.

    Add following configuration in conf/config.yaml ：

    1.   eureka:
    2.     host:                            # it's possible to define multiple eureka hosts addresses of the same eureka cluster.
    3.       - "http://${username}:${password}@${eureka_host1}:${eureka_port1}"
    5.     prefix: "/eureka/"
    6.     fetch_interval: 30               # 30s
    7.     weight: 100                      # default weight for node
    8.     timeout:
    9.       connect: 2000                  # 2000ms
    10.       send: 2000                     # 2000ms
    11.       read: 5000                     # 5000ms

    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 :

    1. $ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
    2. {
    3.     "uri": "/user/*",
    4.     "upstream": {
    5.         "service_name": "USER-SERVICE",
    6.         "type": "roundrobin",
    7.         "discovery_type": "eureka"
    8.     }
    9. }'
    11. HTTP/1.1 201 Created
    12. Date: Sat, 31 Aug 2019 01:17:15 GMT
    13. Content-Type: text/plain
    14. Transfer-Encoding: chunked
    15. Connection: keep-alive
    16. Server: APISIX web server
    18. {"node":{"value":{"uri":"\/user\/*","upstream": {"service_name": "USER-SERVICE", "type": "roundrobin", "discovery_type": "eureka"}},"createdIndex":61925,"key":"\/apisix\/routes\/1","modifiedIndex":61925},"action":"create"}

    Because the upstream interface URL may have conflict, usually in the gateway by prefix to distinguish:

    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.

    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:

    1. function _M.dump_data()
    2.     return {config = local_conf.discovery.eureka, services = applications}

    Then you can call its control api as below:

    1. GET /v1/discovery/{discovery_type}/dump