Mejores prácticas de Spring Cloud Gateway en la arquitectura de microservicios

prefacio

Este artículo se compila a partir del intercambio de la reunión de la estación Guangzhou del campamento de prácticas de tecnología nativa en la nube. La experiencia proviene del producto Alibaba Cloud CSB 2.0 desarrollado por nuestro equipo. Está desarrollado en base a SpringCloud Gateway de código abierto. Con la premisa de ser totalmente compatible con el uso de código abierto, se han realizado muchas transformaciones a nivel empresarial, que involucran características funcionales, estabilidad, seguridad y rendimiento.

¿Por qué necesita una puerta de enlace de microservicios?

Desde un punto de vista funcional, las puertas de enlace de microservicios generalmente se usan para proporcionar de manera uniforme funciones como autenticación y autorización, limitación de corriente, interrupción de circuitos y conversión de protocolos.

Desde la perspectiva de los escenarios de uso:

El tráfico norte-sur debe usarse junto con la puerta de enlace de tráfico y la puerta de enlace de microservicio, principalmente para distinguir el tráfico externo del tráfico de microservicio y proporcionar servicios externos con las capacidades de microservicio internas a través de un punto de acceso HTTP unificado.
Para el tráfico este-oeste, en algunos sistemas con un volumen comercial relativamente grande, se puede aislar una serie de microservicios de acuerdo con el dominio comercial. La comunicación de microservicios en el mismo dominio comercial utiliza el mecanismo de descubrimiento de servicios y el acceso entre dominios comerciales, se recomienda utilizar la puerta de enlace de microservicios.

Funciones principales de la puerta de enlace de microservicios

Las palabras clave de arquitectura de microservicio y puerta de enlace de microservicio/API ya no son conceptos nuevos. Los selectores de tecnología han pasado de prestar atención a una tecnología por curiosidad a prestar más atención a la esencia de esta tecnología. Las funciones de varios productos de puerta de enlace en el mercado se están volviendo gradualmente homogéneas, lo que básicamente se puede resumir en la misma imagen:

Comparación de selección de puerta de enlace

Cuando una empresa elige usar un producto de puerta de enlace, generalmente tiene dos opciones. Una es hacer un desarrollo secundario basado en un determinado producto de código abierto, y la otra es elegir un determinado producto comercial listo para usar. En cualquier caso, debe seleccionarse desde los aspectos de estabilidad, seguridad, rendimiento y compatibilidad comercial. Por favor, crea que hoy estoy compartiendo desde la perspectiva de Spring Cloud Gateway, y haré todo lo posible para ser lo más objetivo y justo posible.

Un producto como Zuul apareció en la comunidad de SpringCloud en los primeros días. Hoy en día, si busca información sobre puertas de enlace de microservicio, hay una alta probabilidad de que aparezca. El hecho de que su modelo de comunicación sea un modelo de hilo sincrónico no es suficiente para respaldarlo como una selección de productos de puerta de enlace de nivel empresarial. Compararé principalmente SpringCloud Gateway, Alibaba Cloud CSB 2.0, Nginx, Kong y Envoy.

Estrictamente hablando, estas puertas de enlace no son adecuadas para la comparación, ya que todas tienen sus propios escenarios aplicables y la tabla es solo para referencia.

La ventaja de SpringCloud Gateway es que puede estar bien conectado con la comunidad Spring y el sistema de microservicios SpringCloud. Esta es exactamente la misma razón por la cual el lenguaje Java es popular. Por lo tanto, si el sistema de lenguaje de una empresa es una pila de tecnología Java y desarrolla microservicios basados en SpringBoot/SpringCloud, elegir SpringCloud Gateway como puerta de enlace de microservicios tendrá ventajas únicas.

Ventajas de la selección de Spring Cloud Gateway:

Spring Cloud Gateway tiene muchas funciones listas para usar y muchos puntos de extensión
Adecuado para la pila de tecnología Java
La ecología de la comunidad Spring/SpringCloud es buena
Adecuado para integración ecológica con microservicios SpringBoot/SpringCloud

Introducción a Spring Cloud Gateway

No se preocupe si no ha aprendido antes sobre Spring Cloud Gateway. La siguiente pequeña sección presentará el uso básico de Spring Cloud Gateway. Este es un ejemplo muy básico de configuración de enrutamiento de Spring Cloud Gateway.

spring:
  cloud:
    gateway:
      routes:
        - id: aliyun
          uri: https://www.aliyun.com
          predicates:
            - Host=*.aliyun.com
        - id: httpbin
          uri: http://httpbin.org
          predicates:
            - Path=/httpbin/**
          filters:
            - StripPrefix=1
        - id: sca-provider
          uri: lb://sca-provider
          predicates:
            - Path=/sca/**
          filters:
            - StripPrefix=1
    nacos:
      discovery:
        server-addr: mse-xxxxx-p.nacos-ans.mse.aliyuncs.com:8848

Este ejemplo presenta varios ejemplos de configuración de enrutamiento comunes a las puertas de enlace de microservicio:

Coincidencia de ruta de host
Coincidencia de ruta de ruta de prefijo
Coincidencia de ruta de ruta de prefijo y detección de servicios

Spring Cloud Gateway admite una rica lógica de coincidencia de enrutamiento para hacer frente a varios tipos de demandas comerciales:

Entre ellos, Path, Header y Method son las aserciones más utilizadas.

Para escenarios donde las rutas de solicitud de la puerta de enlace, los parámetros y las rutas y los parámetros de la solicitud del servicio de back-end son inconsistentes, SpringCloud Gateway también proporciona muchos GatewayFilters listos para usar para personalizar las solicitudes y las respuestas.

La guía de usuario de Spring Cloud Gateway se ha presentado hasta el momento. Si desea conocer la guía de desarrollo, se recomienda consultar la documentación oficial de Spring Cloud Gateway.

Funciones de código abierto frente a requisitos de funciones empresariales

Como todos sabemos, poner directamente productos de código abierto en producción y uso a nivel empresarial generalmente enfrentará algunos desafíos, después de todo, los escenarios son diferentes. Tomando la escalabilidad como ejemplo, la mayoría de los productos de código abierto se enfocan en puntos de extensión enriquecidos para satisfacer las diversas necesidades de los usuarios de código abierto, mientras que los productos de nivel empresarial tienen un solo escenario, y el rendimiento y la estabilidad son las primeras consideraciones.Cuando hay una compensación entre los dos, se requieren algunas compensaciones.

Spring Cloud Gateway de código abierto no es compatible con algunas funciones importantes de nivel empresarial listas para usar. Si elige Spring Cloud Gateway para crear una puerta de enlace de microservicios de nivel de producción, entonces mi sugerencia es complementar estas capacidades. A continuación, dedicaré más tiempo a presentar algunas transformaciones de nivel empresarial que hemos realizado sobre la base del código abierto, con la esperanza de poder tirar ladrillos para atraer jade.

Control de pantalla blanca

En la superficie, Spring Cloud Gateway no tiene una consola de administración. En un nivel más profundo, Spring Cloud Gateway aún se encuentra en el nivel de un marco de desarrollo, no tan producto. Al mismo tiempo, su modelo de dominio no está tan claramente dividido. Para decirlo de manera agradable, esto muestra que Spring Cloud Gateway tiene suficiente espacio para la transformación.

Nuestros principios de transformación tienen dos puntos. Uno es ser totalmente compatible con las reglas y modelos de código abierto, y no destruir la semántica de las reglas subyacentes, para que podamos evolucionar junto con el ritmo de la comunidad y tener la oportunidad de contribuir a la comunidad en el futuro. El segundo es distinguir entre el modelo de dominio del estado de I+D y el modelo de producto del estado de usuario. Hemos abstraído objetos de dominio como rutas, servicios, fuentes, consumidores, políticas y complementos.

Detrás de la gestión y el control de la pantalla blanca, también significa que todas las configuraciones: configuración de enrutamiento, configuración de servicios, configuración de políticas... son todas dinámicas y los cambios de configuración tendrán efecto en tiempo real.

Refactorización del esquema de configuración

Como se mencionó anteriormente, la transformación de la configuración tiene efecto en tiempo real, algunas personas pueden tener dudas, ¿el código abierto no admite ya el almacenamiento de la configuración de enrutamiento en Nacos? Sí, el código abierto admite dos métodos de configuración. Uno es configurar el enrutamiento en application.yaml, que es el más simple, pero la cuajada para la configuración de enrutamiento debe reiniciar el proceso, lo cual es muy engorroso. El segundo es alojar la configuración en un componente del centro de configuración, como Nacos, para lograr una configuración distribuida y una actualización dinámica. Sin embargo, creemos que esto no es suficiente para admitir los requisitos de nivel empresarial. La solución de código abierto de almacenar la configuración en un único ID de datos tiene los siguientes puntos débiles:

Empuje de configuración lento: la cantidad de configuración es grande, la transmisión de red es lenta y toma 5 minutos para empujar la configuración de 10,000 niveles
Gran radio de explosión: no se admite la división de la configuración y la configuración incorrecta afecta el proceso de análisis, lo que da como resultado la indisponibilidad general del enrutamiento de la puerta de enlace.
Escala de configuración: un solo valor tiene un límite de tamaño de 10M y solo admite enrutamiento de mil niveles

La división de la configuración es imperativa, pero también hay muchas dificultades, como la gestión de la monitorización dinámica, el proceso de garantizar la estabilidad es especialmente complicado y la garantía de coherencia de datos entre la capa de visualización adicional y el centro de configuración real, etc. Consulte la siguiente figura para ver el esquema:

Hay otro detalle en la figura, que también es la razón por la que elegimos Nacos como el centro de configuración primero. El mecanismo de instantáneas de nacos-client puede garantizar que cuando los componentes del centro de control y configuración no estén disponibles, incluso si se reinicia el intermediario de la puerta de enlace, la ruta no se perderá y se garantizará su propia disponibilidad.

Después de la transformación de este esquema, hemos logrado importantes efectos de optimización:

Optimización del tiempo de inserción: configuración 1w 5 minutos -> 30 segundos
Se aumenta el límite superior de la cantidad de configuración: 1000 -> 10w
Garantiza la eventual consistencia de los impulsos de configuración.

Conversión de protocolos x descubrimiento de servicios

Al juntar estas dos transformaciones de nivel empresarial, los dos módulos también están estrechamente relacionados en términos de implementación.

Conversión de protocolo: en lo que respecta al sistema de microservicios de Java, el marco Dubbo o el marco GRPC pueden aparecer en el servicio de back-end, e incluso algunas empresas antiguas usarán el marco de WebService. La mayoría de las veces, la puerta de enlace de la que hablamos solo está conectada al protocolo de comunicación HTTP, que limita nuestro servicio de back-end al marco SpringBoot o SpringCloud. La capacidad de la puerta de enlace para admitir diferentes tipos de protocolos de back-end se denomina conversión de protocolo.

Descubrimiento de servicios: el marco de microservicios es inseparable del descubrimiento de servicios. Los centros de registro comunes incluyen Nacos, Eureka, etc. Por ejemplo, SpringCloud Gateway de código abierto admite el acoplamiento con los centros de registro Nacos/Eureka.

Los puntos débiles de tales funciones de código abierto son:

SpringCloud Gateway solo admite HTTP2HTTP, no HTTP2DUBBO, HTTP2GRPC, HTTP2WEBSERVICE
Spring Cloud Gateway solo admite la configuración estática de un solo registro

Algunas demandas comunes a nivel empresarial:

Existen diferentes tipos de arquitecturas de microservicios: SpringCloud, Dubbo, GRPC
La puerta de enlace admite el acceso entre entornos y necesita conectarse a varios registros o espacios de nombres

En respuesta a estos puntos débiles y demandas, comparta algunas dificultades y experiencias que encontramos durante la transformación.

Cuando se admiten diferentes protocolos, es posible que el marco de servicio correspondiente ya tenga una capa remota y una capa de descubrimiento correspondientes. Nuestra opción es introducir solo el paquete de dos partes remoto del protocolo para resolver el problema de conversión de protocolo. Para la capa de descubrimiento, debe autoencapsularse para evitar el malentendido de usar la capa de descubrimiento del protocolo correspondiente. Debido a que volviendo al campo de puerta de enlace, el descubrimiento de servicios y la conversión de protocolos son módulos equivalentes. El ServiceDiscoveryFIlter abstracto es responsable del descubrimiento de servicios, y ProtocolTransferFilter es responsable de la comunicación de protocolo punto a punto.

En la capa de descubrimiento de servicios, para adaptarse a los modelos (push y pull) de diferentes registros, se proporcionan dos implementaciones, PullServiceRegistry y PushServiceRegistry. Estas transformaciones se implementan independientemente del módulo spring-cloud-loadbalancer. La implementación predeterminada de código abierto tiene muchas limitaciones. Por ejemplo, solo admite el esquema de modelo de extracción + lista de servicios de caché. De hecho, el modelo de inserción puede proporcionar un mayor rendimiento en tiempo real para el descubrimiento de servicios de puerta de enlace.

Proceso básico: detección de servicios serviceName -> nx IP, equilibrio de carga IP n -> 1, conversión de protocolo IP comunicación punto a punto.

Tal conjunto de mecanismos de expansión puede lograr una rápida expansión cuando se necesitan conectar nuevos tipos de protocolos, centros de registro y algoritmos de equilibrio de carga.

fusible limitador de corriente

Si ha leído detenidamente la documentación de Spring Cloud Gateway, encontrará que el código abierto tiene un soporte muy limitado para la limitación de corriente y la ruptura de circuitos. Se basa en gran medida en un Redis para la limitación de corriente del clúster, y el esquema de limitación de corriente se implementa por sí mismo, y podemos confiar más en las soluciones proporcionadas por Sentinel. De hecho, el Sentinel de código abierto también proporciona algunas capacidades listas para usar para Spring Cloud Gateway, y no hay problema a nivel de uso, principalmente porque carece de algunas capacidades de observabilidad.

Durante la transformación, se debe prestar especial atención al uso de una versión superior de Sentinel, es decir, el esquema de limitación de corriente implementado por el modelo de umbral proporcional.Después de integrar Sentinel, proporcionamos dos tipos de modelos de limitación de corriente de acuerdo con los escenarios generales de la puerta de enlace: el disyuntor de limitación de corriente basado en la relación de llamadas lentas y el disyuntor de límite de corriente basado en la relación de código de respuesta. Con la ayuda de las capacidades de Sentinel, es una pena lograr una recuperación gradual.

Construcción de sistemas observables

Se puede decir que la construcción del sistema de observabilidad es la distancia entre muchos productos de código abierto y el uso a nivel empresarial, y lo mismo ocurre con Spring Cloud Gateway.

Las puertas de enlace generalmente necesitarán registrar tres tipos de métricas de observabilidad.

Métricas: como se muestra en la figura anterior, registre el número de solicitudes, QPS, código de respuesta, P99, P999 y otros indicadores
Rastreo: el enlace de la puerta de enlace se puede conectar en serie con los enlaces del sistema de microservicios posteriores para realizar un monitoreo completo del enlace
Registro: imprima registros de puerta de enlace por categoría, categorías de registro comunes como accessLog, requestLog, remotingLog, etc.

SpringCloud Gateway de código abierto integra micrometer-registry-prometheus y proporciona un panel listo para usar: https://docs.spring.io/spring-cloud-gateway/docs/3.1.8/reference/html/gateway-grafana-dashboard.json Los indicadores que requieren más dimensiones deben ser enterrados por sí mismos.

La solución Trace recomienda conectarse a opentelemetry.

Falta la solución de registro en el código abierto de SpringCloud Gateway. En la producción real, al menos el registro de acceso debe imprimirse para registrar la información de la solicitud, y el registro de solicitud debe estar habilitado para registrar la información de carga útil y la información del cuerpo de respuesta de la solicitud según sea necesario, así como el registro conectado al servicio de back-end para solucionar algunos problemas de conexión. Esquema de recopilación de registros Nuestra práctica es enviar accessLog a la salida estándar, lo cual es conveniente para la configuración y recopilación bajo la arquitectura K8s, o usar el esquema de agente de registro para la recopilación de archivos.

optimización del rendimiento

Además de la optimización y adición de funciones, el rendimiento de la puerta de enlace también es un punto de especial preocupación para los usuarios. En el artículo anterior, no clasifiqué Spring Cloud Gateway como una categoría de puerta de enlace particularmente de alto rendimiento, principalmente en base a nuestra práctica, y descubrí que hay mucho espacio para la optimización. En los siguientes capítulos, compartiré algunas optimizaciones de rendimiento basadas en Spring Cloud Gateway.

La ruta de optimización de la puerta de enlace es difícil y larga. Para verificar el efecto de la optimización, es inevitable crear una línea de base de rendimiento, que debe optimizarse para los puntos de referencia.

Algunas técnicas de optimización de uso común también son aplicables en la puerta de enlace, como: almacenamiento en caché, carga diferida, asignación previa, optimización de la complejidad del algoritmo, operaciones amigables con la CPU y cambio reducido de subprocesos.

gráfico de llama

La observación del rendimiento a través de gráficos de llamas puede analizar grandes puntos de pérdida de rendimiento desde una perspectiva macro:

Un gráfico de llama de puerta de enlace ideal debería ser que la mayor parte del tiempo se gaste en IO, es decir, la pérdida relacionada con la red en el gráfico Además, se debe prestar atención a las clases que ocupan la CPU. A través del gráfico de llamas, también hemos localizado bastantes puntos de pérdida de rendimiento y los hemos optimizado.

Optimización de clasificación de GlobalFilter

En Spring Cloud Gateway, las solicitudes se filtran a través de GlobalFilter y GatewayFilter. Puede ver esta lógica en FilteringWebHandler:

  public Mono<Void> handle(ServerWebExchange exchange) {
    Route route = exchange.getRequiredAttribute(GATEWAY_ROUTE_ATTR);
    List<GatewayFilter> gatewayFilters = route.getFilters();

    List<GatewayFilter> combined = new ArrayList<>(this.globalFilters);
    combined.addAll(gatewayFilters);
    // TODO: needed or cached?
    AnnotationAwareOrderComparator.sort(combined);

    return new DefaultGatewayFilterChain(combined).filter(exchange);
  }

La implementación de código abierto volverá a ensamblar un FilterChain en cada nivel de solicitud y lo ordenará. La asignación y clasificación de memoria ocupará la CPU, lo que sin duda conducirá a una degradación del rendimiento. A partir de los comentarios, podemos ver que Contributor mismo es consciente del problema de rendimiento aquí, pero no se ha solucionado.

Un método de optimización factible es activar la actualización de FilterChain cuando cambia la ruta o la política, de modo que no sea necesario reconstruir FilterChain cuando se solicite. La observación de este problema de rendimiento se debe a la ocupación de FilteringWebHandler.handle en el gráfico de llamas.

Empuje incremental de enrutamiento

En el capítulo anterior sobre funciones de nivel empresarial, presenté el plan de transformación del centro de configuración, que mencionaba el problema del gran radio de explosión de la solución de código abierto, que se puede ver en el siguiente código:

public class RouteDefinitionRouteLocator implements RouteLocator {

  @Override
  public Flux<Route> getRoutes() {
    Flux<Route> routes = this.routeDefinitionLocator.getRouteDefinitions().map(this::convertToRoute);

    if (!gatewayProperties.isFailOnRouteDefinitionError()) {
      // instead of letting error bubble up, continue
      routes = routes.onErrorContinue((error, obj) -> {
        if (logger.isWarnEnabled()) {
          logger.warn("RouteDefinition id " + ((RouteDefinition) obj).getId()
              + " will be ignored. Definition has invalid configs, " + error.getMessage());
        }
      });
    }

    return routes.map(route -> {
      return route;
    });
  }

Se puede ver que Spring Cloud Gateway considera la configuración de enrutamiento como un todo, y cualquier cambio de enrutamiento hará que se reconstruya toda la secuencia de ruta. Y de forma predeterminada, si una de las configuraciones de enrutamiento es incorrecta, todo el enrutamiento de la puerta de enlace no estará disponible, a menos que isFailOnRouteDefinitionError esté desactivado.

Nuestro plan de transformación es utilizar la estructura del mapa para la transformación y cooperar con el impulso incremental de la configuración de enrutamiento para realizar la actualización de la ruta en un solo punto.

public class DynamicRouteRepository implements Ordered, RouteLocator, ApplicationEventPublisherAware, RouteDefinitionWriter {

  private RouteConverter routeConverter;

  static class RouteKey implements Ordered {
    private String id;
    private int order;
    ...
  }

  static final Map<RouteKey, Route> ORDERED_ROUTE = new TreeMap<>((o1, o2) -> {
    int order1 = o1.order;
    int order2 = o2.order;
    if (order1 != order2) {
      return Integer.compare(order1, order2);
    }
    return o1.id.compareTo(o2.id);
  });

  private static final Map<String, Integer> ORDER = new HashMap<>();

  public Route getRouteById(String id) {
    return ORDERED_ROUTE.get(new RouteKey(id, ORDER.getOrDefault(id, 0)));
  }
  ...
}

Optimización de la memoria de enrutamiento

Esta optimización provino de nuestra investigación de un problema de producción, y no éramos conscientes del problema al principio. El problema es que cuando el número de rutas es muy grande, el consumo de memoria supera nuestras expectativas.Después del volcado, se encuentra que el contenido de configuración de la misma ruta reside en la memoria en tres formas.

Caché propio del Centro de configuración de Nacos
El enrutamiento de SpringCloud Gateway define la ocupación de RouteDefinition
Ocupación de la ruta de enrutamiento real de Spring Cloud Gateway

La ocupación de Nacos es la esperada, pero RouteDefinition es en realidad solo una variable intermedia. Si el proceso es razonable, no es necesario que resida en la memoria. Después de la optimización, eliminamos una ocupación y aumentamos la cantidad de rutas admitidas.

Optimización de pérdida de memoria

Este problema generalmente proviene de la práctica de producción. La capa inferior de Spring Cloud Gateway se basa en Netty para la comunicación de IO. Aquellos que están familiarizados con Netty deben saber que tiene un diseño de búfer de lectura-escritura. Si el contenido de comunicación es pequeño, generalmente se verá en el búfer de fragmentación. Cuando el contenido de comunicación es grande, como la carga de la carga de archivo, lo que designará a la nueva memoria. capaz de recuperarse por completo, lo que resulta en fugas de memoria fuera del montón. Y esta parte de la memoria fuera del montón la asigna netty usando unsafe, que no se puede observar a través de las herramientas JVM convencionales y está muy oculta.

Teniendo en cuenta el costo de la transformación, finalmente elegimos agregar una línea de parámetros de inicio -Dio.netty.allocator.type=unpooled, de modo que cuando la solicitud pierda el búfer fragmentado, la memoria temporal asignada no se agrupará para evitar problemas de rendimiento de la memoria.

Algunas personas pueden tener dudas sobre si -Dio.netty.allocator.type=unpooled conducirá a una degradación del rendimiento. No hay necesidad de preocuparse por esto. Primero, solo los paquetes grandes activarán la asignación de memoria. La mejor práctica de la puerta de enlace no debe permitir requisitos como la carga de archivos, y este parámetro es solo un comportamiento encubierto para escenarios no convencionales.

URI preconstruidos

Este tema candente es aportado por org.springframework.cloud.client.loadbalancer.LoadBalancerUriTools, y SpringCloud Gateway hace referencia a spring-cloud-loadbalancer para resolver problemas de equilibrio de carga y detección de servicios.

    private static URI doReconstructURI(ServiceInstance serviceInstance, URI original) {
        String host = serviceInstance.getHost();
        String scheme = (String)Optional.ofNullable(serviceInstance.getScheme()).orElse(computeScheme(original, serviceInstance));
        int port = computePort(serviceInstance.getPort(), scheme);
        if (Objects.equals(host, original.getHost()) && port == original.getPort() && Objects.equals(scheme, original.getScheme())) {
            return original;
        } else {
            boolean encoded = containsEncodedParts(original);
            return UriComponentsBuilder.fromUri(original).scheme(scheme).host(host).port(port).build(encoded).toUri();
        }
    }

Tenga en cuenta que la última línea de construcción es en realidad un cambio para un objeto inmutable, por lo tanto, realiza una copia profunda y refactoriza un URI. Este comportamiento también ocurre a nivel de llamada. No subestime este tipo de comportamiento, ocupará seriamente la CPU.

La solución de optimización es construir la parte inmutable por adelantado cuando se envía la ruta y admitir la modificación para parámetros de nivel de llamada variables. Esto es lo mismo que la optimización del impulso incremental de enrutamiento.

Por consideraciones de contrato, el sistema Spring utiliza ampliamente variables inmutables para transmitir información del contrato. Sin embargo, en algunos puntos de extensión, realmente se desea cambiarlos, por lo que se deben realizar copias profundas, lo que resulta en una degradación del rendimiento. Las aplicaciones de nivel empresarial deben encontrar un punto de equilibrio entre ellas.

caché de objetos

Trate de evitar la nueva palabra clave en el enlace de llamada, lo que aumentará la sobrecarga de la CPU y afectará a IO. Puede usar ThreadLocal o la tecnología de agrupación de objetos para la reutilización de objetos.

Si la nueva palabra clave solo aparece en escenarios asincrónicos, como la inicialización y la inserción de configuración, que suele ser un comportamiento único, entonces, en aras de la legibilidad del código, no hay muchos requisitos.

Resumir

El intercambio de hoy presenta brevemente la comparación de algunas puertas de enlace principales y se centra en los escenarios aplicables de Spring Cloud Gateway. Y analizó que si Spring Cloud Gateway se pone en producción y se usa en la empresa, creemos que es necesario agregar y modificar algunas capacidades.Finalmente, presentamos algunas de nuestras soluciones de optimización para algunos escenarios comunes de optimización del rendimiento. Estas experiencias se derivan completamente de la práctica de nuestra puerta de enlace de microservicios CSB 2.0 basada en la transformación de SpringCloud Gateway. CSB 2.0 es un producto de puerta de enlace adecuado para la salida de privatización. Este año, también lo exportaremos en la nube pública EDAS, así que estad atentos.

Autor: Xu Jingfeng (Shimakaze)

¡Haga clic para probar los productos en la nube de forma gratuita ahora para comenzar el viaje práctico en la nube!

Enlace original

Este artículo es el contenido original de Alibaba Cloud y no se puede reproducir sin permiso.