¡Fuente abierta! Práctica de la plataforma de detección de puntos de acceso de Netease Yunxin

fondo

Para una plataforma de Internet, especialmente la plataforma PaaS/SaaS de toB, la tecla de acceso rápido es un problema inevitable. Como sistema abierto, la plataforma transporta solicitudes de una gran cantidad de sistemas externos o terminales masivos todos los días. Si bien todas las solicitudes deben cumplir con las reglas de autenticación definidas por la plataforma abierta, las solicitudes repentinas o anormales siempre son inesperadas.

Para el sistema toB, dichas solicitudes incluyen al menos los siguientes tipos:

• Tráfico anormal causado por el uso incorrecto de la postura por parte de los clientes

  Las plataformas PaaS a menudo brindan servicios externos en forma de API y SDK. Aunque brindaremos varias demostraciones y soluciones para guiar a los clientes a usar nuestros servicios de una manera más elegante, nunca se puede predecir que un cliente lo usará de una manera inesperada. manera de llamar a nuestra API.

• Tráfico de un atacante desconocido

  Tomando a Yunxin como ejemplo, nuestros servidores han sido objeto de varios ataques de cuatro y siete capas durante todo el año. El tráfico de la capa 4 generalmente no va directamente al servidor de fondo, pero para el tráfico de la capa 7, además de la protección general de waf, también es necesario descubrir y ubicar la fuente de manera oportuna en la capa empresarial.

• Prueba de presión del cliente

  Sí, los clientes a menudo nos dan grandes sorpresas sin previo aviso. Para evitar que nuestro sistema se vea abrumado por el tráfico repentino, debemos identificar rápidamente dicho tráfico y hacer los comentarios apropiados.

• Cliente del cliente, tráfico anormal causado por una postura incorrecta

  Para los productos toB, la plataforma se enfrenta directamente a desarrolladores o empresas. Además de los clientes finales C, los clientes de los clientes también pueden ser otras empresas. Esta relación complicada ha aumentado considerablemente la incertidumbre.

• Tráfico anómalo a la plataforma generado por el cliente atacado

  También recibimos solicitudes de clientes de vez en cuando, comentarios de que han sido pirateados por productos negros y esperamos poder ayudar a brindar soluciones. Estos productos negros a menudo usan varias herramientas y a menudo van acompañados de un gran tráfico. Los fabricantes de PaaS / SaaS pertenecen al papel de las armas mentirosas.

Para hacer frente a los riesgos de estabilidad del sistema provocados por el tráfico repentino y anormal anterior, la plataforma abierta a menudo establece algunas restricciones QPS (sistema de control de frecuencia) de interfaz para el nivel de inquilino para proteger el sistema. Sin embargo, el control de frecuencia a menudo establece reglas en la capa de entrada (API), que no pueden describir completamente la causa raíz de la presión de tráfico anormal repentina en el sistema (como una determinada clave Redis o una determinada fila de la base de datos), es decir, el sistema de control de frecuencia está orientado hacia el exterior, pero la fuente del riesgo está orientada hacia los recursos internamente Desde el punto de vista del riesgo en sí, la lógica del sistema de control de frecuencia a veces parece un poco extensa. Además, debido a varias razones, los ajustes de la configuración de control de frecuencia a menudo no pueden cubrir la totalidad y, a medida que el sistema continúa hablando, los parámetros relevantes también deben ajustarse continuamente.

Por lo tanto, además del sistema de control de frecuencia, también se necesita una plataforma de detección de puntos de acceso.El sistema de detección de puntos de acceso se centra en los puntos de acceso en sí que causan riesgos para la estabilidad del sistema, de modo que puedan evaluar y descubrir con precisión los puntos de riesgo.

¿Por qué estudiar por cuenta propia?

Investigamos las soluciones de detección de puntos de acceso existentes, como hotkey de JD.com (https://gitee.com/jd-platform-opensource/hotkey), hotCaffeine de Sohu (https://github.com/sohutv/hotcaffeine), consultamos el Versión de bifurcación interna de hotCaffiene de Netease Cloud Music internamente Después de analizar las características funcionales y nuestras necesidades, decidimos realizar un desarrollo propio basado en las soluciones mencionadas anteriormente por las siguientes razones.

• Todas las soluciones de código abierto anteriores están fuertemente vinculadas a etcd. Etd desempeña el papel de centro de configuración y centro de registro en el sistema, y ​​no puede ser reemplazado por otros servicios. Esperamos reutilizar el centro de configuración y el centro de registro existentes sin un mantenimiento separado. del clúster etcd.

• Las soluciones de código abierto anteriores se centran más en el almacenamiento en caché de teclas de acceso rápido que en la supervisión en sí.

• Queremos que el marco sea lo más simple posible, con dependencias mínimas.

• Esperamos abrir interfaces relevantes en forma de complemento, de modo que se pueda conectar de manera más conveniente a los sistemas internos de diferentes departamentos para desarrollar una lógica comercial personalizada de manera más conveniente.

Con base en las razones anteriores, decidimos desarrollar un marco de detección de teclas de acceso rápido como camellia-hot-key.

estructura del sistema

diagrama de arquitectura

 

 

Principio de arquitectura

Como plataforma de detección de puntos de acceso de propósito general, los siguientes problemas deben resolverse primero al diseñar:

• ¿Cómo recopilar y contar el número de teclas de acceso rápido?

• ¿Cómo definir y administrar reglas de teclas de acceso rápido?

• ¿Cómo utilizar los resultados de detección de claves de puntos de acceso?

¿Cómo recopilar y contar el número de teclas de acceso rápido?

Dado que la clave del punto de acceso es una definición de una dimensión global, se debe necesitar un servidor centralizado para resumirlo.La primera reacción es usar un caché centralizado como redis como una herramienta de administración de contadores centralizada. Sin embargo, frente a una gran cantidad de claves, redis tiene algunos cuellos de botella de rendimiento significativos. Incluso si no se consideran los problemas de rendimiento, la sobrecarga de recursos resultante es enorme. Por lo tanto, debemos diseñar una solución con una sobrecarga de recursos baja .

Cuando volvemos a examinar la escena de detección de teclas de acceso rápido, podemos encontrar que, de hecho, no necesitamos tiempo real, sino solo tiempo casi real (nivel de 100 ms) para cumplir con la mayoría de las escenas. Por lo tanto, a través del almacenamiento en caché local y el procesamiento por lotes, la presión sobre el servidor centralizado puede reducirse en gran medida y las diferentes necesidades de las diferentes empresas pueden satisfacerse ajustando de manera flexible la duración del caché y el tamaño del lote. En cuanto al servidor en sí, en referencia a la idea de fragmentación de ranuras de redis-cluster, podemos fragmentar el servidor de teclas de acceso rápido de acuerdo con ciertas reglas, para garantizar que la misma clave se enrute al mismo nodo del servidor, de modo que el cálculo de la localización completa de teclas de acceso rápido, combinado con el caché local + procesamiento por lotes mencionado anteriormente, finalmente puede completar las estadísticas y el cálculo de una gran cantidad de claves a un costo relativamente bajo.

Además del servidor centralizado, también existe el problema de las claves masivas que deben tratarse en la recopilación y las estadísticas. Obviamente, no podemos registrar crudamente todas las claves dentro de una ventana de tiempo.Una idea simple es usar algoritmos como LRU/LFU para el control de la memoria. Con este fin, investigamos [ConcurrentLinkedHashMap/Guava/Caffeine] y otros marcos de trabajo de código abierto (estos fueron implementados por el mismo autor en diferentes momentos, y rendimos homenaje al autor @Ben Manes). La cafeína es conocida como el rey de los procesos. el almacenamiento en caché y su W-TinyLFU El algoritmo proporciona la tasa de aciertos de caché óptima y también evita que perdamos teclas de acceso rápido en el escenario de detección de puntos de acceso, por lo que Caffeine es, sin duda, nuestra primera opción. Pero después de un análisis más detallado, finalmente elegimos mezclar ConcurrentLinkedHashMap y Caffeine para lograr un rendimiento óptimo.

Después del análisis anterior, la arquitectura básica del servidor es relativamente clara. Todo el sistema incluye dos partes: SDK y servidor: el SDK usa Caffeine para recopilar claves y las informa regularmente al servidor; después de que el servidor las recibe, todavía usa Caffeine para recoger y calcular clave. Para diferentes espacios de nombres, debido a que el número es predecible, ConcurrentLinkedHashMap se usa para la administración (solo se requiere un lru simple para la protección del sistema).

¿Cómo definir y administrar reglas de teclas de acceso rápido?

La detección de teclas de acceso rápido es obviamente un servicio que necesita cambiar las reglas de teclas de acceso rápido de manera flexible. Las reglas de teclas de acceso rápido incluyen principalmente dos partes:

• Una es qué clave necesita ser detectada.

• Qué tipo de tecla es una tecla de acceso rápido.

Para el primero, proporcionamos diferentes modos de coincidencia de reglas clave, como la coincidencia de prefijos, la coincidencia exacta, la inclusión de subcadenas y la coincidencia de todos, que facilitan la configuración comercial en diferentes dimensiones y brindan el concepto de una lista de reglas para coincidir de acuerdo con la prioridad definida.

Para este último, abrimos los dos parámetros de ventana de tiempo y umbral de tecla de acceso rápido para definir la tecla de acceso rápido. La ventana de tiempo es una ventana deslizante. Tomando como ejemplo la regla de 500 veces dentro de 1000 ms, 100 ms se usará como una pequeña ventana deslizante dentro del marco, y las últimas 10 ventanas pequeñas (100 ms * 10 = 1000 ms) se usarán para formar una ventana de destino de 1000 ms Contando, por un lado, este método puede identificar la tecla de acceso rápido por primera vez, por otro lado, no habrá ningún problema de salto en la detección de la tecla de acceso rápido.

Para el uso de reglas de teclas de acceso rápido, además del lado del servidor, el marco también se enviará al SDK, de modo que las claves innecesarias se puedan descartar directamente en el lado del SDK, reduciendo así la transmisión de red innecesaria.

Como un servicio de detección de teclas de acceso rápido de uso general, obviamente atenderá diferentes líneas de negocios, e incluso la misma línea de negocios tendrá diferentes escenarios de negocios. Por lo tanto, además de las reglas de teclas de acceso rápido, definimos el concepto de espacio de nombres. Se pueden definir una o más reglas en cada espacio de nombres. Un servicio admite varios espacios de nombres al mismo tiempo, y cada espacio de nombres está aislado entre sí.

¿Cómo utilizar los resultados de detección de claves de puntos de acceso?

En primer lugar, preestablecemos un método opcional de caché de teclas de acceso rápido en el marco, que se completa conjuntamente con SDK+server. Para algunos escenarios de consulta activa, después de detectar una tecla de acceso rápido, el servidor enviará automáticamente el resultado de la detección al SDK, y el SDK almacenará automáticamente en caché el resultado para evitar la penetración de solicitudes de consulta, proteger el servicio de base de datos/caché backend y proporcionar Para garantizar la puntualidad de la memoria caché, el servidor también notificará al SDK asociado sobre el evento de actualización/eliminación del resultado de la memoria caché, a fin de garantizar que el valor de la memoria caché se actualice lo antes posible, y el SDK también informará el estado de acierto de la memoria caché al servidor, lo cual es conveniente El servidor realiza estadísticas de datos.

Además, el servidor empujará activamente los resultados de la detección a la devolución de llamada definida por la empresa, y la empresa puede realizar un procesamiento personalizado por sí misma, como alarmas, limitación de corriente, oscurecimiento, etc.

En la etapa inicial de acceso, es posible que no sepa cómo configurar la regla de teclas de acceso rápido. Si la configuración es demasiado pequeña, es posible que se sienta abrumado por la notificación de la tecla de acceso rápido. Si la configuración es demasiado grande, es posible que no sea eficaz. Por lo tanto, , el servidor también tiene una tecla de acceso rápido integrada La función de detección topN informa a la empresa de la clave con la mayoría de las solicitudes de acceso en el espacio de nombres, y la empresa puede localizar fallas en función de esto, o establecer reglas de teclas de acceso rápido que cumplan con el real condiciones comerciales basadas en esto.

Complementos y extensiones personalizadas

El principio básico del marco de detección de teclas de acceso rápido se mencionó anteriormente, y camellia-hot-key tuvo en cuenta las diferentes necesidades de las diferentes líneas comerciales al comienzo del diseño, por lo que se adoptó el principio de diseño del complemento para facilitar el negocio sin modificando el código fuente del marco. , se puede usar de manera más flexible y también se puede conectar más fácilmente con los sistemas existentes. El complemento se refleja principalmente en los siguientes puntos:

• centro de registro

A diferencia del servicio de teclas de acceso rápido de código abierto existente, camellia-hot-key no está vinculado a ningún centro de registro, solo necesita implementar la interfaz relevante para integrarse con el centro de registro existente muy rápidamente, como zk (incorporado), eureka (empotrado), etcd, consul, nacos, etc.

• centro de configuración

camellia-hot-key no está vinculado a ningún centro de configuración, pero define la interfaz de configuración de HotKeyConfigService. Solo necesita implementar esta interfaz para alojar rápidamente las reglas de teclas de acceso rápido en su centro de configuración existente (camellia-hot-key tiene un archivo de configuración local + nacos dos vías).

La interfaz de configuración de HotKeyConfigService se define de la siguiente manera:

public abstract class HotKeyConfigService {
    /**
     * 获取HotKeyConfig
     * @param namespace namespace
     * @return HotKeyConfig
     */
    public abstract HotKeyConfig get(String namespace);

    /**
     * 初始化后会调用本方法，你可以重写本方法去获取到HotKeyServerProperties中的相关配置
     * @param properties properties
     */
    public void init(HotKeyServerProperties properties) {
    }

    //回调方法
    protected final void invokeUpdate(String namespace) {
        //xxxx
    }
}

Además, en el diseño de camellia-hot-key, el centro de configuración solo necesita interactuar con el servidor, y el SDK obtendrá automáticamente la configuración (inicialización de configuración + actualización de configuración) a través del servidor sin conectarse directamente con el centro de configuración, tanto como sea posible Simplifique la lógica del SDK (haga que el SDK sea más delgado).

Supervisión de puntos finales y devoluciones de llamadas personalizadas

El servidor de camellia-hot-key proporciona puntos finales de monitoreo http (formato json/formato promethus), que se utilizan para exponer información básica como servidores (como qps, acumulación, etc.).

Además, se proporciona una rica interfaz de devolución de llamada, que incluye, entre otros:

• HotKeyCallback

  La devolución de llamada de detección de tecla de acceso rápido enviará la tecla de acceso rápido al lado comercial en tiempo real a través de esta devolución de llamada. clave para el negocio al mismo tiempo.

• HotKeyTopNCallback

  La devolución de llamada topN de la tecla de acceso rápido, que es una estadística topN de la dimensión global (resumirá los datos de varios nodos de servidor), y el marco devolverá la llamada a la empresa a intervalos regulares (1 minuto de forma predeterminada).

• HotKeyCacheStatsCallback

  Cuando la función de caché de teclas de acceso rápido está habilitada, el SDK informará periódicamente el estado de acierto del caché de teclas de acceso rápido y el servidor devolverá los datos estadísticos a la empresa a través de esta interfaz de devolución de llamada.

Interfaz SDK amigable

Para adaptarse a diferentes escenarios de aplicaciones, el marco proporciona dos SDK diferentes, CamelliaHotKeyMonitorSDK y CamelliaHotKeyCacheSDK.

• CameliaHotKeyMonitorSDK

Se utiliza para la función pura de estadísticas de teclas de acceso rápido. El procesamiento de los resultados de la detección lo completa la propia empresa. El procesamiento de los resultados de la detección se puede realizar en el lado del SDK o en el lado del servidor. Solo hay una interfaz central:

/**
     * 推送一个key用于统计和检测热key
     * @param namespace namespace
     * @param key key
     * @param count count
     * @return Result 结果
     */
    Result push(String namespace, String key, long count);

• CameliaHotKeyCacheSDK

La función de almacenamiento en caché de teclas de acceso rápido está encapsulada, y el SDK almacenará en caché automáticamente las teclas de acceso rápido detectadas localmente, y la parte de acceso al servicio solo necesita implementar la interfaz ValueLoader. La interfaz principal incluye los tres siguientes:

/**
     * 获取一个key的value
     * 如果是热key，则会优先获取本地缓存中的内容，如果获取不到则会走loader穿透
     * 如果不是热key，则通过loader获取到value后返回
     *
     * 如果key有更新了，hot-key-server会广播给所有sdk去更新本地缓存，从而保证缓存值的时效性
     *
     * 如果key没有更新，sdk也会在配置的expireMillis之前尝试刷新一下（单机只会穿透一次）
     *
     * @param namespace namespace
     * @param key key
     * @param loader value loader
     * @return value
     */
    <T> T getValue(String namespace, String key, ValueLoader<T> loader);
    
    /**
     * key的value被更新了，需要调用本方法给hot-key-server，进而广播给所有人
     * @param namespace namespace
     * @param key key
     */
    void keyUpdate(String namespace, String key);
    
    /**
     * key的value被删除了，需要调用本方法给hot-key-server，进而广播给所有人
     * @param namespace namespace
     * @param key key
     */
    void keyDelete(String namespace, String key);

actuación

Para Camellia-hot-key, hemos llevado a cabo muchas optimizaciones y ajustes, que incluyen principalmente lo siguiente:

• Protocolo de transferencia

  El SDK y el servidor usan enlaces largos (basados ​​en netty4) para interactuar con el servidor, y abandonan protocolos como json/text, y usan un protocolo binario más optimizado para optimizar el rendimiento (para reducir las dependencias externas tanto como sea posible, pb , etc. no se utilizan bibliotecas de serialización de terceros).

• Diseño sin bloqueo

  Hay una capa de hash desde el SDK hasta el servidor para garantizar que el mismo servidor procese la misma clave. Además, después de que el servidor reciba el mensaje, también realizará una distribución de hash de acuerdo con la clave, de modo que la misma clave solo será procesada por un hilo, lo que simplifica enormemente el diseño de la ventana deslizante y evita bloqueos (todo el proceso está libre de bloqueo).

• JDK-17

  Usamos jdk8 y jdk17 para realizar pruebas por separado y descubrimos que con el mismo rendimiento, jdk17 tiene un uso de CPU más bajo que jdk8.

El siguiente es un resultado de prueba de rendimiento simple:

 

como todos usamos

Como un marco general de detección de teclas de acceso rápido, varias líneas comerciales dentro de Smart Enterprise se han conectado a este marco y se han conectado sin problemas al sistema existente a través de interfaces personalizadas relacionadas.Tomando IM como ejemplo, tenemos el siguiente negocio El servicio de detección de puntos de acceso está conectado en el proceso:

• Para las solicitudes de IM-SDK, la detección bidimensional se realiza según uid+id+interfaz de arrendatario e id+interfaz de arrendatario para identificar clientes anómalos del lado C e inquilinos anómalos.

• Para la solicitud de IM-openAPI, se realiza una detección de acuerdo con la interfaz de identificación del arrendatario +, para identificar el arrendatario anómalo y la interfaz anómala.

• El nivel de base de datos subyacente, tome db como ejemplo. A través del complemento complemento de mybatis, hemos logrado acceder a la función de detección de puntos de acceso de forma no intrusiva. Usamos el siguiente método para ensamblar la clave de detección: escriba #tenant id#sql#param. La ventaja de esto es que, por un lado, puede identificar Después de liberar el punto de acceso, el arrendatario de origen se puede ubicar rápidamente y, por otro lado, se pueden establecer diferentes reglas para diferentes tipos de operaciones de SQL, como seleccionar/actualizar/insertar/eliminar y diferentes inquilinos

• En términos de almacenamiento en caché, tome redis como ejemplo. Además de la clave redis en sí, para ubicar la fuente convenientemente, la identificación del arrendatario se ensamblará en la clave de detección. En particular, para dao_cache, CamelliaHotKeyCacheSDK también está integrado para habilitar la función de caché para proteger redis cuando sea necesario.

Lo anterior es sobre la entrada. En cuanto a la salida, en función de la interfaz personalizada proporcionada por el marco, nos hemos conectado al sistema de alarma y monitoreo interno, que es conveniente para detectar puntos calientes en primer lugar; y también escribirá datos en el plataforma de datos en tiempo real, lo cual es conveniente para la posterior trazabilidad. En el futuro, también se conectará al sistema de control de flujo de control de frecuencia, de modo que pueda bloquearse automáticamente tan pronto como se detecte tráfico anormal.

Resumir

¿Por qué código abierto?

Cuando desarrollamos el marco camellia-hot-key, lo diseñamos como parte del proyecto de código abierto camellia y simplificamos el núcleo sin agregar lógica comercial, para que todos puedan conectarse directamente a su propio sistema sin modificar el código fuente. .

Esperamos que más personas lo usen, no solo Netease Smart Enterprise, y esperamos maximizar sus funciones y valor.

Por lo tanto, todos los entusiastas del código abierto son bienvenidos a encontrar fallas activamente, y continuaremos mejorando y mejorando camelia juntos, para lograr una situación real en la que todos ganen.

Ensayo

Camellia es un proyecto de código abierto de Yunxin. Además de la tecla de acceso rápido, hay muchos componentes que han sido completamente verificados por el entorno de producción, como redis-proxy, id-gen, delay-queue, etc. Bienvenido a hacer clic en tres enlaces: Me gusta (Estrella), preocupación (PR), comentario (problema)!

dirección de github: https://github.com/netease-im/camellia