Existen nuevos requerimientos para los portales API en el campo de los microservicios: mayor flexibilidad, requerimientos de desempeño más elevados y origen (native) en la nube.
APISIX está basado en etcd para guardar y sincronizar la configuración, no en bases de datos relacionales tales como Postgres o MySQL.
Esto no solamente elimina el recabado de información (polling) y hace el código más conciso, sino también hace que la sincronización de la configuración se haga más en tiempo real. Al mismo tiempo, no habrá un punto único en el sistema, lo que resulta más útil.
Adicionalmente, APISIX tiene un enrutado dinámico y carga en caliente de los plug-ins, lo que es especialmente aplicable al manejo de API bajo sistemas de micro-servicios.
Uno de los objetivos del diseño y desarrollo de APISIX es lograr el más elevado desempeño en la industria. Datos de las pruebas específicas pueden consultarse aquí：banco de pruebas - benchmark
APISIX es el portal API de mayor desempeño; con un QPS de un solo núcleo logra 23,000, con un retardo promedio de solamente 0.6 milisegundos.
Sí, en la versión 0.6 contamos con un tablero incorporado, y usted puede operar APISIX a través de la interfase web.
Por supuesto, APISIX provee plugins personalizados y flexibles para que los desarrolladores y las empresas escriban sus propios programas.
Para el centro de la configuración, la configuración del almacenamiento es solamente la función más básica, y APISIX necesita también las siguientes prestaciones:
Más información en Por qué etcd.
Existen dos posibilidades cuando encontramos Luarocks muy lentos:
Para el primer problema usted puede usar https_proxy o usar la opción --server para especificar un servidor de Luarocks al que usted pueda acceder con mayor velocidad. Ejecute el comando luarocks config rocks_servers (este comando es soportado por versiones posteriores a luarocks 3.0) para ver qué servidores están disponibles.
Si usar un proxy no resuelve este problema, usted puede agregar la opción --verbose durante la instalación para ver qué tan lento está. Excluyendo el primer caso, solamente en el segundo, cuando el protocolo git está bloqueado, podemos ejecutar git config --global url."https://".insteadOf git:// para usar el protocolo ‘HTTPS’ en lugar de git.
Un ejemplo, foo.com/product/index.html?id=204&page=2, lanzamiento gris (gray release) basado en id en la cadena de consulta (query string) en URL como una condición：
Hay dos formas diferentes de hacer esto：
vars de la ruta para hacerlo.curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri": "/index.html", "vars": [ ["arg_id", "<=", "1000"] ], "plugins": { "redirect": { "uri": "/test?group_id=1" } } }' curl -i http://127.0.0.1:9080/apisix/admin/routes/2 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri": "/index.html", "vars": [ ["arg_id", ">", "1000"] ], "plugins": { "redirect": { "uri": "/test?group_id=2" } } }'
Aquí encontramos la lista de operadores del lua-resty-radixtree actual： https://github.com/iresty/lua-resty-radixtree#operator-list
traffic-split para hacerlo.Por favor consultar la documentación de plug-in traffic-split.md para ver ejemplos de uso.
Por ejemplo, redireccionar http://foo.com a https://foo.com
Hay varias maneras de hacerlo.
http_to_https en redirect：curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri": "/hello", "host": "foo.com", "plugins": { "redirect": { "http_to_https": true } } }'
vars con el plug-in redirect:curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri": "/hello", "host": "foo.com", "vars": [ [ "scheme", "==", "http" ] ], "plugins": { "redirect": { "uri": "https://$host$request_uri", "ret_code": 301 } } }'
serverless：curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri": "/hello", "plugins": { "serverless-pre-function": { "phase": "rewrite", "functions": ["return function() if ngx.var.scheme == \"http\" and ngx.var.host == \"foo.com\" then ngx.header[\"Location\"] = \"https://foo.com\" .. ngx.var.request_uri; ngx.exit(ngx.HTTP_MOVED_PERMANENTLY); end; end"] } } }'
Luego hacemos una prueba para ver si funciona：
curl -i -H 'Host: foo.com' http://127.0.0.1:9080/hello
La respuesta debería ser:
HTTP/1.1 301 Moved Permanently Date: Mon, 18 May 2020 02:56:04 GMT Content-Type: text/html Content-Length: 166 Connection: keep-alive Location: https://foo.com/hello Server: APISIX web server <html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>openresty</center> </body> </html>
Cuando usted instala OpenResty en MacOs 10.15, usted puede encontrarse con este error
> brew install openresty Updating Homebrew... ==> Auto-updated Homebrew! Updated 1 tap (homebrew/cask). No changes to formulae. ==> Installing openresty from openresty/brew Warning: A newer Command Line Tools release is available. Update them from Software Update in System Preferences or https://developer.apple.com/download/more/. ==> Downloading https://openresty.org/download/openresty-1.15.8.2.tar.gz Already downloaded: /Users/wusheng/Library/Caches/Homebrew/downloads/4395089f0fd423261d4f1124b7beb0f69e1121e59d399e89eaa6e25b641333bc--openresty-1.15.8.2.tar.gz ==> ./configure -j8 --prefix=/usr/local/Cellar/openresty/1.15.8.2 --pid-path=/usr/local/var/run/openresty.pid --lock-path=/usr/ Last 15 lines from /Users/wusheng/Library/Logs/Homebrew/openresty/01.configure: DYNASM host/buildvm_arch.h HOSTCC host/buildvm.o HOSTLINK host/buildvm BUILDVM lj_vm.S BUILDVM lj_ffdef.h BUILDVM lj_bcdef.h BUILDVM lj_folddef.h BUILDVM lj_recdef.h BUILDVM lj_libdef.h BUILDVM jit/vmdef.lua make[1]: *** [lj_folddef.h] Segmentation fault: 11 make[1]: *** Deleting file `lj_folddef.h' make[1]: *** Waiting for unfinished jobs.... make: *** [default] Error 2 ERROR: failed to run command: gmake -j8 TARGET_STRIP=@: CCDEBUG=-g XCFLAGS='-msse4.2 -DLUAJIT_NUMMODE=2 -DLUAJIT_ENABLE_LUA52COMPAT' CC=cc PREFIX=/usr/local/Cellar/openresty/1.15.8.2/luajit If reporting this issue please do so at (not Homebrew/brew or Homebrew/core): https://github.com/openresty/homebrew-brew/issues These open issues may also help: Can't install openresty on macOS 10.15 https://github.com/openresty/homebrew-brew/issues/10 The openresty-debug package should use openresty-openssl-debug instead https://github.com/openresty/homebrew-brew/issues/3 Fails to install OpenResty https://github.com/openresty/homebrew-brew/issues/5 Error: A newer Command Line Tools release is available. Update them from Software Update in System Preferences or https://developer.apple.com/download/more/.
Este es un problema de OS incompatible, y puede superarse con estos dos pasos
brew edit openresty/brew/openresty\ -fno-stack-check en la línea con with-luajit-xcflags.El nivel de log por defecto para APISIX es warn. Sin embargo, usted puede cambiar el nivel de log a info si usted quiere rastrear los mensajes mostrados en core.log.info.
Pasos:
Modificar el parámetro error_log_level: "warn" a error_log_level: "info" en conf/config.yaml
Recargar y reiniciar APISIX
Ahora usted podrá rastrear y examinar el log del nivel info en logs/error.log.
El plug-in The Apache APISIX soporta recargas en caliente. Ver la sección Hot reload en plugins para tener información acerca de cómo hacerlo.
Por defecto, APISIX atiende solamente el puerto 9080 cuando maneja solicitudes HTTP. Si usted desea que APISIX atienda solicitudes de múltiples puertos, Ud. deberá modificar los parámetros relevantes del archivo de configuración como se muestra a continuación:
Modificar el parámetro de puertos atendidos de HTTP, node_listen en conf/config.yaml, por ejemplo:
apisix:
node_listen:
- 9080
- 9081
- 9082
El manejo de las solicitudes HTTPS es similar, modificando el parámetro de puertos atendidos de HTTPS, ssl.listen_port en conf/config.yaml, por ejemplo:
apisix:
ssl:
listen_port:
- 9443
- 9444
- 9445
Recargar y reiniciar APISIX
etcd provee funciones de subscripción para monitorear si la palabra clave específica o si el directorio sufren algún cambio (por ejemplo: watch, watchdir).
APISIX usa etcd.watchdir para monitorear cambios en el contenido del directorio:
Con la ayuda de etcd, cuyas prestaciones de notificación incremental son del nivel de milisegundos, APISIX alcanza este mismo nivel de milisegundos en la sincronización de la configuración.
Por defecto, APISIX leerá la id de instancia en conf/apisix.uid. Si no se encuentra, y ninguna id está configurada, APISIX generará una uuid como la id de instancia.
Si usted desea especificar una id de su preferencia para asegurar la instancia de APISIX a su sistema interno, podrá configurarla en conf/config.yaml, por ejemplo:
``` apisix: id: "your-meaningful-id" ```
En primer lugar asegúrese de que la red entre APISIX y el cluster de etcd no está particionada.
Si la red está en buenas condiciones, por favor revise que su cluster de etcd tenga activado el portal gRPC gateway. Sin embargo, el caso por defecto para esta característica es diferente cuando se usan las opciones de la línea de comandos que cuando se usa el archivo de configuración para iniciar el servidor etcd.
--enable-grpc-gateway.etcd --enable-grpc-gateway --data-dir=/path/to/data
Nótese que esta opción no se muestra en la salida de etcd --help.
enable-grpc-gateway de manera explícita.# etcd.json { "enable-grpc-gateway": true, "data-dir": "/path/to/data" }
Esta distinción fue eliminada por etcd en su ramal principal (master branch), pero no se trasladó la modificación a las versiones anunciadas, así que sea prudente al desplegar su cluster de etcd.
La elevada disponibilidad de APISIX puede dividirse en dos partes:
El plano de datos de Apache APISIX carece de estados y su escala se puede cambiar elásticamente a voluntad. Basta añadir una capa (layer) de LB en el frente.
El plano de datos de Apache APISIX tiene su base en la implementación de alta disponibilidad de etcd cluster y no requiere ninguna dependencia de base de datos relacional.