ciencia puerta de entrada Zuul

¿Por qué utilizar una puerta de enlace

Diferentes micro-servicios en general tienen diferentes direcciones de red, mientras que los clientes externos (como una aplicación de teléfono móvil) pueden tener que llamar a múltiples interfaces de servicio para completar una empresa necesita. Por ejemplo, un teléfono entrada de cine APP, múltiples interfaces podría llamar micro-servicios con el fin de completar una compra de los procesos de negocio, como se muestra a continuación.

Si el cliente se comunique directamente con cada servicio de micro, tendrá las siguientes preguntas:

• El cliente solicitó en repetidas ocasiones diferentes micro-servicio, aumenta la complejidad del cliente.

• solicitud de dominios cruzados, en una determinada escena es relativamente complicado proceso.

• Certificación compleja, requiere cada servicio de certificación independiente.

• Difícil de reconstruir, con la iteración del proyecto pueden necesitar ser re-dividida servicio de micro. Por ejemplo, una pluralidad de servicios pueden combinarse en uno o una pluralidad de división en servicio. Si el cliente se comunican directamente con los micro-servicios, entonces la reconstrucción será difícil de implementar.

• Algunos servicios pueden usar un / navegador antipáticos, acceso directo micro-protocolo de servidor de seguridad que habrá algunas dificultades.

Los problemas anteriores se pueden resolver por medio de la puerta de enlace micro-servicios. pasarela de servicio Micro se interpone una capa intermedia entre el cliente y el servidor, todas las solicitudes pasarán a través de los micro externos pasarela de servicio. Después de la pasarela de servicio utilizando un micro-arquitectura como se muestra a continuación.

En este momento, la puerta de enlace micro-servicios encapsula la estructura interna de la aplicación, la necesidad de cliente única puerta de acceso para interactuar con, sin tener que micro-servicios específicos de la interfaz directamente de llamadas. De esta forma, los desarrolladores pueden simplificarse. Por otra parte, el uso de la puerta de enlace micro-servicios tiene las siguientes ventajas:

• Fácil de controlar. Datos pueden ser recogidos en el micro-monitor y empuje la pasarela de servicio al sistema externo para su análisis.

• Fácil de certificación. La autenticación puede ser realizada en la pasarela de servicio de micro, y luego envía la solicitud al servicio de micro backend, sin autenticación en cada servicio de micro.

• Reduce el número de interacciones entre el cliente y los diversos micro-servicios.

sobre Zuul

Zuul es una fuente abierta Netflix API Gateway (código de dirección de alojamiento: https: //github.com/Netflix/zuul), es esencialmente una aplicación web Servlet. Zuul es la nube de primavera en un cubo de la familia, que puede y Eureka, cinta, Hystrix y otros componentes usado en conjunto.

El núcleo Zuul es una serie de filtros, estos filtros ayudan a lograr las siguientes funciones:

• Autenticación y seguridad: los requisitos de verificación de identificación para todos los tipos de recursos y niega las solicitudes y requerimientos son inconsistentes.

• Revisión y Seguimiento: datos y estadísticas significativas pista en la posición del borde, lo que lleva a la conclusión precisa el estado de producción para nosotros.

• Enrutamiento dinámico: La necesidad de rutas dinámicamente la solicitud a un clúster diferente en el extremo posterior.

• Prueba de esfuerzo: aumentar gradualmente la carga de tráfico a un clúster, para calcular los niveles de rendimiento.

• Distribución de la carga: correspondiente a la capacidad de carga para cada tipo de distribución, y los descartes la solicitud supera el valor límite.

• proceso estático en respuesta: el establecimiento de una respuesta parcial directamente a los bordes para evitar que fluye dentro de la agrupación.

• flexibilidad Multi-regionales: enrutamiento solicitudes a través de regiones de AWS, destinadas a diversificar el uso de ELB y asegurarse de que la posición de borde lo más cerca posible al usuario.

Además, Netflix también utilizan pruebas de funcionalidad de enrutamiento y el estrés precisos Zuul por la versión Canary.

Nota: La descripción anterior de los documentos oficiales Zuul, pero de hecho, la versión de código abierto de Zuul no más de una función son - sólo un Zuul paquete de código abierto unos pocos tarro ella, se refiere a la capacidad de los anteriores debe ser la capacidad de la propia Netflix oficial de Zuul.

Primeros pasos

Definir dos servicios: hola-servidor y el usuario-servidor, respectivamente, que están registrados en el servicio de Eureka, el siguiente ejemplo (aquí abajo también se menciona Zuul registrado subir):

Cuando no es a través de la puerta de entrada, podemos acceder por separado del hola-servidor y el usuario del servidor en las dos interfaces siguientes:

http://localhost:8081/hello
http://localhost:8082/user

Ahora vamos a definir los servicios relacionados Zuul Maven depende de lo siguiente:

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
        <version>2.2.2.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        <version>2.2.2.RELEASE</version>
    </dependency>
</dependencies>

application.yml archivo, agregue la siguiente configuración:

spring:
  application:
    name: zuul-service

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka

server:
  port: 6069

notas de la clase de inicio añaden @EnableZuulProxy

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.zuul.EnableZuulProxy;

@SpringBootApplication
@EnableZuulProxy
public class ZuulServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(ZuulServiceApplication.class, args);
    }
}

Después de iniciar el programa, podemos acceder a las dos interfaces anteriores a través de la pasarela de servicio:

curl http://localhost:6069/hello-server/hello
curl http://localhost:6069/user-server/user

Nota: El valor predeterminado Zuul combinado a Eureka será registrado como un nombre de servicio de acceso ContextPath. En Zuul podemos configurar a medida de una variedad de reglas de enrutamiento que aquí no hacen los detalles pertinentes.

Filtro de solicitudes

El ejemplo anterior, se implementó una solicitud de función de enrutamiento por Zuul, la interfaz para que nuestras aplicaciones de micro-servicios pueden ser prestados a través de una entrada de puerta de enlace API unificado es el acceso del cliente a.

Cada aplicación cliente proporciona una interfaz de usuario solicitudes de servicio, y tienden a tener acceso a ciertas restricciones, el sistema no toma todos ellos abierto a la interfaz micro-servicio. Sin embargo, la función de servicio de enrutamiento actual no limita los derechos, todas las solicitudes se remitirán sin reservas a la aplicación específica y devuelve el resultado, con el fin de lograr el control de seguridad y controlar los permisos solicitados por el cliente, el más simple y brutal cada método es implementar un micro-aplicaciones de servicios de autorización para verificar la firma e identificar el filtro o interceptor. Tal pregunta es demasiado funcional para lograr la redundancia. Una buena práctica es escindir la lógica de comprobación para construir un servicio de autenticación por separado. Después de la terminación de pelar, directamente en las aplicaciones de servicio de micro-verificación llevadas a cabo por la invocación de los servicios del sistema de autenticación, pero esto sólo se ocupa de la separación de la lógica de autenticación, y estos no son parte no la lógica redundante en la naturaleza de la original algunas aplicaciones de micro-interceptores de servicio divididos a cabo redundantes o filtro, todavía existen.

Para este tipo de problemas, un mejor enfoque es el de verificar la terminación de éstas naturaleza no operativa a través de la parte frontal de la puerta de enlace de servicios. Como el servicio de puerta de enlace para unirse, los clientes externos tienen acceso a nuestro sistema unificado de entrada, ya que estos cheque sin importar el negocio específico, ¿por qué no llega a tiempo para completar la solicitud de verificación y filtración, micro-end aplicación de servicio de lata eliminación de filtros complejos y el interceptor, que hace que la complejidad de desarrollar y probar el servicio de micro interfaz de la aplicación se ha reducido en consecuencia. Esto implica otra zuul función principal, el filtro petición.

El siguiente ejemplo de un simple vistazo a la utilización de filtros:

import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.context.RequestContext;
import com.netflix.zuul.exception.ZuulException;
import lombok.extern.log4j.Log4j2;

import javax.servlet.http.HttpServletRequest;

@Log4j2
public class AccessFilter extends ZuulFilter {

    //过滤器的类型，它决定过滤器在请求的哪个生命周期中执行，这里定义为pre，代表会在请求被理由之前执行。
    @Override
    public String filterType() {
        return "pre";
    }

    //过滤器的执行顺序。当请求在一个阶段中存在多个过滤器时，需要根据该方法返回的值来依次执行
    @Override
    public int filterOrder() {
        return 0;
    }

    //判断该过滤器是否需要被执行。这里我们直接返回了true，因此该过滤器对所有的请求都生效。实际运行中我们可以利用该函数
    //来指定过滤器的有效范围。
    @Override
    public boolean shouldFilter() {
        return true;
    }

    //过滤器的具体执行逻辑。
    @Override
    public Object run() throws ZuulException {
        RequestContext ctx = RequestContext.getCurrentContext();
        HttpServletRequest request = ctx.getRequest();

        log.info("send {} request to {}", request.getMethod(), request.getRequestURI().toString());

        Object accessToken = request.getParameter("accessToken");
        if (accessToken == null) {
            log.warn("access token is empty");
            ctx.setSendZuulResponse(false);
            ctx.setResponseStatusCode(401);
        } else {
            log.info("access token ok");
        }

        return null;
    }
}

Código interfaz ZuulFilter Muestra define cuatro métodos:

• tipofiltro: Tipo (Type) de filtro, que filtra la ejecución de la decisión en la que el ciclo de vida de la solicitud, que se define aquí como el pre, representantes será ejecutado antes de la solicitud es la razón. (El tipo de filtro se describe en detalle en las páginas siguientes)

• filterOrder: filtros de orden de ejecución (orden de ejecución). Cuando hay una solicitud en un filtro de múltiples etapas, necesita ser ejecutado de forma secuencial de acuerdo con el valor devuelto por el método.

• shouldFilter: determinar si el filtro necesita ser realizada (criterios). Aquí volvemos directamente verdadera, por lo que el filtro a todas las peticiones son para tener efecto. La operación real que puede utilizar esta función.

• ejecute: la realización de un filtro específico lógica (Acción).

Añadir esta clase de arranque filtro:

@Bean
public AccessFilter accessFilter(){
    return new AccessFilter();
}

En este caso, entonces el acceso rizo http: // localhost: 6069 / hello-servidor / hola se quejará de interfaces, código de estado 401, es el acceso a la postura correcta:

curl http://localhost:6069/hello-server/hello?accessToken=666

ciclo de vida útil del filtro

Zuul define cuatro filtros estándar: pre, enrutamiento, correos y error, estos tipos de filtros correspondientes al ciclo de vida típico de la solicitud. Nos referimos a la siguiente tabla para contar sobre el ciclo de vida del papel de estos cuatro tipos de filtros, y el orden de ejecución.

Cuando la petición llega a servicio de pasarela API HTTP externo, que primero entra en la primera pre etapa, donde será procesada por tipo pre de filtro. El objetivo principal de este tipo de filtro es a petición de encaminamiento se realiza antes de hacer algunas pre-procesamiento, tales como las restricciones de acceso y similares.

Después de la terminación del proceso de tipo de filtro pre, una petición para entrar en la segunda fase de encaminamiento, es decir, la fase de petición de reenvío de enrutamiento, la petición será procesada tipo de filtro de enrutamiento. El procesamiento específico aquí es la petición externa se reenvía a la instancia de servicio específico proceso de registro, cuando el resultado de la solicitud de servicio se devuelven ejemplo, se ha completado la fase de encaminamiento, una solicitud para entrar en el tercio posterior etapa.

En este punto, la solicitud será procesada tipos de filtros de correos, estos filtros no sólo pueden llegar a solicitar información en el momento de la transformación, sino también para obtener información de las instancias de servicio rendimientos, tipos de filtros en el puesto, podemos hacer frente a Los resultados y algún otro procesamiento o conversión de contenido, como en respuesta a añadir HTTP estándar Header, estadísticas e indicadores de cobro revertido.

Además, hay un error de fase especial, la fase se produce única excepción en estas tres etapas se activará. Para profundizar en la comprensión del error en el diagrama de flujo de filtro se ejecuta el filtro siguiente.

En general, el proceso normal es pre -> ruta -> mensaje. Si se produce una excepción en la etapa de pre-filtro, entonces el proceso es: pre -> Error -> después, si se produce una excepción en la etapa de filtrado de ruta, el proceso es: pre -> ruta -> Error -> puesto; si el filtro en la post etapa lanzado, el proceso final es: pre -> ruta -> mensaje -> error.

Además del tipo de filtro por defecto, Zuul también nos permite crear un tipo de filtro personalizado. Por ejemplo, podemos tener personalizar un tipo estático de filtro, generado en respuesta Zuul directamente, sin atrás hacia delante la solicitud a los micro-servicios.

Filtrar función de pasarela API se implementa Zuul el elemento de núcleo, cada uno de la solicitud HTTP entrará Zuul a través de una serie de filtros para dar la petición de respuesta de la cadena de procesamiento y devuelto al cliente. Tomemos, por ejemplo Zuul función de encaminamiento, la función de enrutamiento en una operación real, su asignación y solicitudes de enrutamiento se envían por varios filtros diferentes para completar. En el que el mapa de ruta a través de los principales tipos de filtros pre completó, solicita la configuración de ruta de encaminamiento reglas se corresponden, para encontrar la dirección de destino que se remitirá; y remisión de la porción de solicitud se realiza mediante los tipos de ruta de filtros, para pre tipo de filtro dirección de encaminamiento obtenida para el reenvío.

arquitectura zuul

La siguiente figura muestra el principio de funcionamiento de Zuul núcleo de acuerdo con esta figura, podemos entender mejor el Zuul.

Zuul filtro maravilloso que consiste esencialmente del lenguaje, estos filtros inicialmente un archivo (.groovy final) se almacena en forma de una lista específica a continuación. Zuul FilterFileManager periódicamente en rotación en estos directorios, el filtro recién añadido o modificado se carga dinámicamente en. Después de que el archivo ha sido leído FilterFileManager .groovy que será utilizado para compilar GroovyComplier JVM clase, a continuación, re-instanciado (la Class.newInstance) en objeto ZuulFilter (es decir, filtro), almacenada en FilterRegistry el final. FilterRegistry es un gráfico de objetos FilterLoader incluido, por lo que podemos decir es: ZuulFilter objetos almacenados en FilterLoader en la final.

FilterRegistry puede ser visto como un ConcurrentHashMap, en el que la clave de archivo de ruta .groovy, valor después de que el objeto es ZuulFilter dinámica de carga.

No hay comunicación directa entre el filtro Zuul cada uno de los RequestContext entre ellos por una (puede ser visto como una de ConcurrentHashMap) para la transferencia de datos. RequestContext cada clase para el registro de datos transmitida por la solicitud según la variable ThreadLocal.

Cuando llega una petición Zuul, denominado ZuulServlet primer proceso, hay un objeto ZuulRunner ZuulServlet en dicho RequestContext inicializado antes. También hay un ZuulRunner FilterProcessor, la FilterProcessor obtener ZuulFilter (s) a partir de FilterLoader (FilterRegistry). Con estos ZuulFilter (s) después de, pre tipos de filtros ZuulServlet ejecuta en primer lugar, y luego realizar el tipo de ruta de filtro, la aplicación final del mensaje es el tipo de filtro, si hay un error en la aplicación de estos filtros se ejecutará cuando tipo de error de filtro. Después de la aplicación de estos filtros, los resultados finales de la parte posterior solicitud al cliente.

2.x zuul

21 de mayo de Netflix anunció en su blog oficial micro-servicios oficiales de código abierto la puerta de enlace componentes Zuul 2 (Zuul es Netflix el 12 de junio, 2013 de código abierto, con el fin de facilitar la distinción entre lo siguiente será declarado antes Zuul expresa como Zuul 1 ). Zuul 2 Zuul 1 y los principales mentiras diferencia en la arquitectura, Zuul 2 se ejecuta en un marco de no bloqueo asíncrono, tal Netty. Zuul 1 dependiente de multiproceso para apoyar el crecimiento, el rendimiento y marco Netty Zuul 2 utilizado depende ciclismo eventos y devoluciones de llamada.

Filtrar Zuul2 es un servicio que se ejecuta en una serie Netty, después de la ejecución de la solicitud se ha completado filtros entrantes resultados transmitidos por Netty cliente, entonces la petición se devuelve a través de una serie de filtros de salida, como se muestra en la figura. Como antes ZuulFilter divide en pre, post, enrutamiento, error, Zuul 2 se divide en tres tipos de filtros:

• Filtros entrantes: ejecutadas antes de enrutamiento

• Filtros punto final: operaciones de enrutamiento

• Después de realizar los datos correspondientes: filtros de salida

Zuul 2 arquitectura sustancialmente como se muestra arriba, y Zuul 1 ninguna diferencia esencial. Antes ZuulFilter divide en pre, post, enrutamiento, el error, Zuul filtro 2 se divide en tres tipos: de entrada, punto final, saliente. En Zuul 2, el extremo frontal del filtro de Netty servidor en lugar del original Zuul 1 Servlet, el extremo posterior del filtro en lugar de utilizar Netty Client HttpClient, de modo que los extremos delantero y trasero puede soportar asíncrona (Zuul1 Servlet 3.0 Especificación se puede utilizar para AsyncServlet apoyo optimize , el extremo frontal puede lograr de apoyo asíncrono más conexiones, y Zuul2 lograr el mismo efecto). En comparación con Zuul 1, Zuul 2 también enriquecer y optimizar mucho en funcionalidad, como el soporte para HTTP / 2, WebSocket de.

Zuul 1 vs Zuul 2

diseño Zuul1 es relativamente simple, fácil de leer el código es relativamente pequeño, es esencialmente un modelo sincronizado Servlet, el bloqueo de multi-hilo, como se muestra a continuación.

de manera sincrónica Servlet utilizando hilo por petición de conexión. En pocas palabras, para cada nueva petición de entrada, un contenedor de servlets debe asignar un hilo hasta que la respuesta se devuelve al cliente en este hilo es liberado para volver al grupo de subprocesos contenedor. Si el fondo es llamadas de servicio que requieren mucho tiempo, entonces el hilo se bloquea durante un bloqueo están ocupados recursos de rosca, no se puede realizar otras tareas. contenedor de servlets tamaño de grupo de subprocesos es limitado, el cliente actual solicita una gran cantidad de antecedentes y servicio lento tiempo relativamente largo, es fácil que se quede sin hilo grupo de subprocesos contenedor, provocando que el contenedor no puede aceptar nuevas solicitudes, Netflix esto también ha desarrollado un Hystrix componentes del fusible para resolver el problema del agotamiento de los recursos servicio lento.

Este patrón de bloqueo síncrono es relativamente sencillo modelo de programación, toda la solicitud -> Procesamiento -> flujo (flujo de llamadas) se procesan en respuesta a un hilo, sino también facilitar la comprensión del desarrollo y depuración, depuración más conveniente. Sin embargo, el modo de bloqueo síncrono general, se iniciará una gran cantidad de hilos, el cambio de hilo por encima inevitablemente introduce. Además, el modo de bloqueo síncrono, el número de los contenedores hilo se fija generalmente, dando lugar a ciertas restricciones en el número de conexiones, cuando un lento servicios de back-office, grupo de subprocesos contenedor se agota fácilmente, una vez contenedor empobrecido rechazará la nueva solicitud, esta vez hilo contenedor no lo hace muy ocupado, pero IO se denomina servicios de back-office bloqueados, pero no puede hacer otras cosas.

En general, el modo de bloqueo síncrono es más adecuado para escenarios de computación intensiva (CPU) con destino. Para IO escenas intensivos (IO obligado), bloqueo síncrono hilo de modo consumirá una gran cantidad de recursos en vano, que están a la espera para el estado IO bloqueado, y no hacer el trabajo sustantivo.

Zuul2 diseño es relativamente complejo, que no es fácil de leer el código, se utiliza un modelo de programación asíncrona no bloqueante Netty, como se muestra en la figura.

Si es necesario leer Zuul 2 código fuente, por "[análisis de código fuente Zuul2] (http://springcloud.cn/view/344)" artículo sobre la ayuda podría ser más eficaz.

En la figura anterior, se puede entender simplemente como el frente hay una cola dedicada a las peticiones del usuario, hay una cola de back-end responsable del procesamiento de la llamada de servicio fondo, el medio de la rosca bucle de eventos (Event bucle de hilo), que monitorizan simultáneamente tanto antes como después eventos en la cola, un acontecimiento desencadena una función de devolución de llamada para controlar el evento. En este modo requiere menos hilos, sustancialmente sólo un bucle de eventos nuclear la CPU de procesamiento de hilos en cada uno, el extremo frontal puede ser muchas conexiones, sólo la conexión en una cola, el hilo no necesita para iniciar el evento por el hilo de bucle de eventos gatillo, no hay problemas multi-threading de bloqueo.

hilos asincrónicos no-bloqueo comenzaron pequeño, menos contexto hilo uso de los recursos de conmutación de sobrecarga es menos. Conexiones aceptable no bloqueante modo mucho mayor, puede entenderse simplemente como una solicitud para introducir únicamente la cola, la capacidad de la cola se pueden ajustar muy grande, siempre que sin tiempo de espera, la cola de petición será procesada secuencialmente. modo asíncrono permite que el modelo de programación se complica. modelo asíncrono sin una clara definición de la solicitud -> Procesamiento -> flujo de ejecución respuesta, su flujo es activado por un evento, el flujo de procesamiento de solicitud puede ser apagado en cualquier momento, para ser logrado a través de algunos mecanismos internos asociados id para todo el flujo de ejecución y luego juntos, lo que ofrece a los desarrolladores de depuración de operación y mantenimiento introduce una serie de complejidades, como es muy difícil de depurar el flujo de solicitudes asíncronas dentro del IDE.

En general, el modo de no bloqueo asíncrono es más conveniente para el escenario IO intensiva (IO obligado), este escenario la mayoría del tiempo en el sistema de procesamiento de IO, CPU de computación más ligero, un pequeño hilo de bucle de eventos puede manejar.

En cuanto a rendimiento y la alineación Zuul2 Zuul1, Netflix da un rendimiento Zuul2 datos vaga sustancialmente mejor que el rendimiento Zuul1 20% aquí se refiere principalmente al número de peticiones procesadas por segundo por nodo. ¿Por qué es vaga? Debido a que esta información está sujeta a numerosas afectar al medio ambiente de prueba real, modos de escena de tráfico y otros factores, es difícil de reproducir los datos de prueba. Incluso el aumento de rendimiento del 20% es cierto, de hecho, este aumento de rendimiento no es muy grande, y la complejidad de la introducción de asíncrono en comparación con el aumento del 20% vale la pena es un problema. Netflix en sí es un poco vago en su blog [Referencias 5] y [ppt Referencias 8], incluso en sí mismo tiene alguna duda.

Entonces la pregunta es, si usted elige utilizar Zuul1 o Zuul2 o primavera Nube de puerta de enlace, o es también Kong?

Referencs

1. https://netflixtechblog.com/announcing-zuul-edge-service-in-the-cloud-ab3af5be08ee

2. https://www.jianshu.com/p/9c104186572d

3. http://www.itmuch.com/spring-cloud/finchley-16/

4. http://www.itmuch.com/spring-cloud/zuul/zuul-ha/

5. https://netflixtechblog.com/zuul-2-the-netflix-journey-to-asynchronous-non-blocking-systems-45947377fb5c

6. https://mp.weixin.qq.com/s/QkeIVTn97VmOc0Y18PAvYQ

7. https://blog.csdn.net/yang75108/article/details/86991401

8. https://github.com/strangeloop/StrangeLoop2017/blob/master/slides/ArthurGonigberg-ZuulsJourneyToNonBlocking.pdf