Pila completa de microservicios: componentes centrales detallados y técnicas de desarrollo

Los microservicios, en pocas palabras, son un enfoque de diseño en el que una aplicación se organiza como un conjunto de servicios pequeños y autónomos que pueden ejecutarse de forma independiente y, a menudo, se basan en la funcionalidad empresarial. Estos servicios se ejecutan de forma independiente entre sí y se comunican a través de API bien definidas. En comparación con las aplicaciones monolíticas, la arquitectura de microservicios proporciona mayor flexibilidad y escalabilidad, lo que permite a los equipos desarrollar, implementar y escalar servicios de forma independiente.

1. Registro y descubrimiento de servicios.

En el mundo de los microservicios, el registro y el descubrimiento de servicios son mecanismos clave para garantizar que cada servicio independiente pueda encontrar otros servicios e interactuar con ellos. A medida que las aplicaciones aumentan de tamaño y complejidad, resulta fundamental comprender y gestionar claramente las interacciones entre estos servicios.

1.1 Registro de clientes (ZooKeeper)

Apache ZooKeeper, como piedra angular sólida de los sistemas distribuidos, se ha ganado un gran respeto en la industria. Muchos sistemas distribuidos, incluidos varios marcos de microservicios, dependen de ZooKeeper para proporcionar servicios críticos como nombres, gestión de configuración, servicios de agrupación y sincronización distribuida. Pero aquí nos centraremos en su aplicación como registro de clientes en una arquitectura de microservicio.

Introducción a ZooKeeper
Enlace de descarga de ZooKeeper
ZooKeeper fue creado originalmente por Yahoo, pero luego se convirtió en un proyecto de alto nivel de Apache. Está diseñado para aplicaciones distribuidas y proporciona un conjunto de servicios a través de los cuales las aplicaciones distribuidas pueden continuar funcionando en caso de fallas parciales. Esto se logra a través de la arquitectura central de ZooKeeper, que está diseñada para conectar pequeños nodos informáticos para formar un potente marco distribuido.

Modelo de datos de ZooKeeper

La estructura de datos de ZooKeeper es muy parecida a un sistema de archivos distribuido, que consta de directorios y archivos. Pero en ZooKeeper, cada nodo se llama "znode". Cada znode puede almacenar datos y puede tener nodos secundarios.

Cuando un microservicio quiere registrarse, crea un znode en ZooKeeper. Normalmente, este znode almacenará información clave sobre el servicio, como su dirección IP, puerto y cualquier otro metadato.

Proceso de registro del servicio

1. Inicio y conexión : cuando se inicia un microservicio, inicializa una conexión al clúster de ZooKeeper.
2. Crear znode : un microservicio crea un znode en una ruta especificada, generalmente según el nombre del servicio.
3. Almacenar datos : el servicio almacenará sus metadatos en este znode. Estos metadatos pueden incluir dirección IP, puerto, número de versión, hora de inicio, etc.
4. Latido periódico : para que ZooKeeper sepa que el servicio aún está activo, el servicio enviará periódicamente latidos a sus znodes.
5. Cerrar sesión : cuando un servicio se cierra, elimina sus znodes en ZooKeeper.

[Registro de cliente de ZooKeeper]

import org.apache.zookeeper.ZooKeeper;
import org.apache.zookeeper.CreateMode;
import org.apache.zookeeper.ZooDefs;

// 初始化ZooKeeper客户端并注册服务
public class ServiceRegistry {
    
    
    private static final String ZK_ADDRESS = "localhost:2181";
    private ZooKeeper zooKeeper;

    public ServiceRegistry() throws Exception {
    
    
        // 连接ZooKeeper
        this.zooKeeper = new ZooKeeper(ZK_ADDRESS, 5000, watchedEvent -> {
    
    });
    }

    // 注册服务
    public void registerService(String serviceName, String serviceInfo) throws Exception {
    
    
        String path = "/services/" + serviceName;
        if (zooKeeper.exists(path, false) == null) {
    
    
            zooKeeper.create(path, serviceInfo.getBytes(),
            ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
        }
    }
}

// 使用方法：
ServiceRegistry registry = new ServiceRegistry();
registry.registerService("myService", "serviceInstanceInfo");

Modelo de consistencia de ZooKeeper

ZooKeeper utiliza un protocolo llamado "Zab" para garantizar la coherencia de sus datos. El protocolo Zab garantiza que todas las operaciones de escritura estén ordenadas, lo que significa que todas las operaciones en varios nodos se realizan en el mismo orden.

seguridad

ZooKeeper proporciona un modelo de seguridad basado en ACL que permite a los administradores controlar qué clientes pueden realizar qué operaciones. Esto es útil para evitar que clientes maliciosos o mal configurados causen daños al sistema.

Resumir

ZooKeeper, como componente clave de los sistemas distribuidos, proporciona una plataforma de registro de servicios confiable y de alta disponibilidad para microservicios. Al comprender su funcionamiento interno, podemos aprovecharlo mejor para impulsar nuestra arquitectura de microservicios.

1.2 Registro de terceros (registrador de servicio independiente)

Con la creciente popularidad de la arquitectura de microservicios, registrar cada servicio directamente a veces puede resultar complejo y llevar mucho tiempo. Por lo tanto, es necesario introducir un mecanismo de registro de servicios de terceros, es decir, un registrador de servicios independiente, para ayudar a gestionar estos servicios.

¿Qué es un registrador de servicios de terceros?

El registrador de servicios de terceros es una capa intermedia entre los microservicios y los centros de registro de servicios. Puede detectar, registrar y cancelar el registro de microservicios automáticamente. En lugar de depender directamente de cada microservicio para registrarse, este enfoque proporciona una ubicación centralizada para la gestión y el seguimiento.

¿Por qué se requiere el registro de terceros?

1. Gestión automatizada : a medida que aumentan los microservicios, registrar, actualizar y cancelar el registro de instancias de servicio manualmente puede resultar engorroso. El registro de terceros puede realizar estas tareas automáticamente.
2. Monitoreo centralizado : mediante un registro de terceros, los desarrolladores y los equipos de operaciones pueden monitorear el estado y la salud de todos los servicios en un solo lugar.
3. Mejor seguridad : dado que todas las operaciones de registro y baja pasan por un punto central, puede controlar mejor qué servicios pueden registrarse, evitando el registro de servicios maliciosos.

Cómo funciona el registro de terceros

1. Detección de servicios : el registrador escaneará periódicamente la red o puntos finales específicos para encontrar nuevas instancias de servicios.
2. Registro de servicio : una vez que se descubre una nueva instancia de servicio, el Registrador la registrará automáticamente en el centro de registro de servicios.
3. Verificación de estado : el registrador verifica periódicamente el estado de cada instancia de servicio. Si se determina que una instancia de servicio ya no está en buen estado o es inaccesible, se cancelará el registro de la instancia del registro de servicios.
4. Gestión de metadatos : para los servicios que requieren configuración adicional, el Registrador puede almacenar y gestionar estos metadatos para garantizar que cada servicio se ejecute como se espera.

escenas a utilizar

A continuación se detallan varios escenarios en los que puede ser necesario un registrador de servicios de terceros:

• Grandes implementaciones : con cientos o miles de instancias de microservicios, no resulta práctico administrar cada instancia manualmente.
• Entorno dinámico : en un entorno de nube, las instancias de servicio pueden iniciarse y cerrarse con frecuencia. El registro de terceros garantiza que el registro de servicios esté siempre actualizado.
• Requisitos de alta seguridad : en entornos de alta seguridad, puede ser necesario garantizar que solo los servicios confiables puedan registrarse.

Desafíos y consideraciones

1. Gastos generales de la red : debido a la necesidad de comprobar con frecuencia el estado de las instancias de servicio, se puede generar una gran cantidad de tráfico de red.
2. Punto único de falla : si el propio registrador falla, puede afectar todas las operaciones de registro y baja del servicio.

El uso del registrador de servicios de terceros puede simplificar enormemente la gestión y el seguimiento de los microservicios. Sin embargo, seleccionar e implementar una solución de registrador adecuada requiere una planificación y pruebas cuidadosas para garantizar que satisfaga las necesidades de su entorno específico.

1.3 Descubrimiento de clientes

En el mundo de los microservicios, el descubrimiento de servicios es uno de los componentes principales. Cuando un servicio necesita interactuar con otro servicio, primero necesita conocer la ubicación del otro servicio. Este es el propósito del descubrimiento de servicios. En el modo de descubrimiento de clientes, el servicio que llama es responsable de saber con qué instancia de servicio debe interactuar.

¿Qué es el descubrimiento de clientes?

El descubrimiento de clientes es un patrón de descubrimiento de servicios en el que un cliente o servicio de consumidor es responsable de determinar las instancias de servicio disponibles en la red y luego comunicarse directamente con una instancia. Esto contrasta con el modelo de descubrimiento del lado del servidor, donde la puerta de enlace API o el equilibrador de carga deciden con qué instancia de servicio se debe hablar.

Cómo funciona el descubrimiento de clientes

1. Registro : cada vez que una instancia de servicio se inicia y está disponible, registra su dirección en el registro de servicios.
2. Consulta : cuando el cliente necesita comunicarse con el servicio, primero consulta el centro de registro del servicio para obtener una lista de todas las instancias de servicio disponibles.
3. Selección : El cliente selecciona uno de la lista de servicios obtenida para la comunicación. Esto generalmente implica algún tipo de equilibrio de carga, como round robin o selección aleatoria.
4. Comunicación : el cliente se comunica directamente con la instancia de servicio seleccionada.

ventaja

1. Flexibilidad : los clientes pueden implementar sus propias estrategias de equilibrio de carga según sea necesario.
2. Latencia reducida : no hay componentes intermediarios (como puertas de enlace API o equilibradores de carga) para manejar las solicitudes, lo que reduce la latencia de la comunicación.

defecto

1. Complejidad del cliente : cada cliente debe implementar la lógica de descubrimiento de servicios y equilibrio de carga.
2. Desafío de coherencia : todos los clientes deben actualizar su lógica y políticas de descubrimiento de servicios de forma coherente.

Herramientas y técnicas para el descubrimiento de clientes.

Muchas herramientas de descubrimiento de servicios, como Eureka, Consul y Zookeeper, admiten el modo de descubrimiento de clientes.

1. Eureka : Eureka, creada por Netflix, es una de las herramientas de descubrimiento de servicios más populares en la arquitectura de microservicios. El cliente Eureka proporciona estrategias de equilibrio de carga integradas y se puede integrar fácilmente con Spring Cloud.
2. Cónsul : Desarrollado por HashiCorp, Consul proporciona una solución de descubrimiento de servicios versátil que admite comprobaciones de estado, almacenamiento KV y múltiples centros de datos.
3. Zookeeper : Como se mencionó anteriormente, Zookeeper es un servicio de coordinación distribuido, que también se usa a menudo para el descubrimiento de servicios.

El descubrimiento de clientes proporciona una forma flexible y de baja latencia para que los microservicios encuentren y se comuniquen con otros servicios. Sin embargo, también aumenta la complejidad del cliente y requiere coherencia lógica y de políticas en todos los clientes. La elección de utilizar el descubrimiento del lado del cliente depende de sus necesidades y limitaciones específicas.

1.4 Descubrimiento del lado del servidor

El descubrimiento del lado del servidor es un patrón de descubrimiento de servicios común en la arquitectura de microservicios. A diferencia del descubrimiento del lado del cliente, el descubrimiento del lado del servidor traslada la responsabilidad de encontrar servicios del cliente al servidor.

¿Qué es el descubrimiento del lado del servidor?

En el descubrimiento del lado del servidor, la aplicación cliente primero solicita un equilibrador de carga central o una puerta de enlace API para conocer la ubicación del servicio. Este componente central consulta el registro de servicios, determina la ubicación de la instancia de servicio y luego enruta la solicitud a esa instancia de servicio.

Cómo funciona el descubrimiento del lado del servidor

1. Registro : al igual que con el descubrimiento de clientes, las instancias de servicio registran su ubicación en el registro de servicios cuando se inician.
2. Solicitudes enrutadas : los clientes envían sus solicitudes a un equilibrador de carga central o puerta de enlace API en lugar de directamente a una instancia de servicio.
3. Seleccione una instancia de servicio : el equilibrador de carga consulta el registro de servicios, encuentra instancias de servicios disponibles y decide a qué instancia enrutar la solicitud.
4. Reenvío de solicitudes : el equilibrador de carga reenvía la solicitud del cliente a la instancia de servicio seleccionada.

[Descubra los servicios de ZooKeeper]

// 从ZooKeeper中发现服务
public List<String> discoverService(String serviceName) throws Exception {
    
    
    String path = "/services/" + serviceName;
    return zooKeeper.getChildren(path, false);
}

// 使用方法：
List<String> serviceInstances = discoverService("myService");

ventaja

1. Cliente simplificado : la lógica del cliente es más simple y solo necesita conocer la ubicación del equilibrador de carga central.
2. Gestión centralizada del tráfico : las formas del tráfico, el enrutamiento y las políticas de equilibrio de carga se pueden gestionar desde una ubicación central.

defecto

1. Mayor latencia : las solicitudes deben pasar por saltos adicionales, lo que puede provocar ligeros retrasos.
2. Riesgo de punto único de falla : si hay un problema con el equilibrador de carga central o la puerta de enlace API, todas las solicitudes pueden verse afectadas.

escenas a utilizar

El descubrimiento del lado del servidor es particularmente adecuado para entornos con una alta diversidad de clientes, como aplicaciones móviles, desarrolladores externos o múltiples interfaces de usuario.

1.5. Cónsul

Consul es una herramienta de distribución de configuración y descubrimiento de servicios desarrollada por HashiCorp. Está diseñado para proporcionar alta disponibilidad y soporte en todos los centros de datos.

Características principales de Cónsul

1. Descubrimiento de servicios : Consul permite que las aplicaciones proporcionen y descubran otros servicios, y proporciona controles de salud para determinar el estado de las instancias de servicios.
2. Almacén de claves/valores : un almacén de claves/valores distribuido para la configuración y la configuración de servicios dinámicos.
3. Múltiples centros de datos : Consul admite múltiples centros de datos, lo que lo hace ideal para aplicaciones a gran escala.

Cómo utilizar Cónsul

1. Instalación y ejecución : Consul es un único archivo binario que se puede descargar desde su sitio web oficial. Se ejecuta en modo agente, con un agente Cónsul en cada nodo.
2. Registro de servicios : los servicios se pueden registrar definiendo un archivo de definición de servicio y luego usando consul agentcomandos.
3. Comprobación de estado : Consul puede comprobar periódicamente el estado de salud de las instancias de servicio a través de varios métodos (como HTTP, TCP y la ejecución de scripts específicos).

Consul frente a otras herramientas de descubrimiento de servicios

Si bien Eureka, Zookeeper y otras herramientas también brindan funcionalidad para el descubrimiento de servicios, Consul ofrece algunas características únicas, como soporte para múltiples centros de datos y almacenamiento de claves/valores.

1.6. eureka

Eureka es una herramienta de descubrimiento de servicios de código abierto de Netflix, que es particularmente adecuada para grandes sistemas distribuidos en entornos de nube. Su nombre deriva del griego y significa "¡lo he encontrado!"

Los componentes principales de Eureka

1. Servidor Eureka : Proporciona servicios de registro de servicios. Todas las aplicaciones cliente que brindan servicios deben registrarse en Eureka y proporcionar información de metadatos.
2. Cliente Eureka : es un cliente Java que se utiliza para simplificar la interacción con el servidor Eureka. El cliente también tiene un equilibrador de carga integrado.

Cómo funciona Eureka

1. Registro del servicio : cuando se inicia el cliente Eureka, registra su propia información en el servidor Eureka y envía periódicamente latidos para renovar el contrato.
2. Consumo de servicios : el consumidor del servicio obtiene la información de registro del servidor Eureka y la almacena en caché localmente. Los consumidores utilizarán esta información para encontrar proveedores de servicios.
3. El servicio se desconecta : cuando el cliente se apaga, envía una solicitud al servidor Eureka pidiéndole que elimine la instancia del registro.

Características de Eureka

1. Disponibilidad : Eureka maneja muy bien fallas parciales debido a problemas de red. Si el cliente no puede comunicarse con el servicio debido a una partición de la red, el cliente almacena en caché el estado del servidor y utiliza esta información para manejar su solicitud.
2. Equilibrio de carga : el cliente Eureka incluye un equilibrador de carga que puede proporcionar equilibrio de carga para solicitudes a instancias de servicio.
3. Integración con Spring Cloud : Eureka se puede integrar perfectamente con Spring Cloud, lo que lo hace ideal para aplicaciones Spring Boot.

1.7. pila inteligente

SmartStack es una herramienta de descubrimiento de servicios desarrollada por Airbnb y se basa en dos componentes principales: Nerve y Synapse.

Nervio

Nerve es un demonio diseñado para ejecutarse en cada instancia de servicio. Es responsable de registrar el servicio en Zookeeper. Si una instancia de servicio deja de funcionar, Nerve será responsable de cancelar su registro en Zookeeper.

Sinapsis

Synapse es otro demonio diseñado para ejecutarse en todas las máquinas que necesitan descubrir servicios. Periódicamente extrae información de registro de servicio de Zookeeper y actualiza la configuración de su balanceador de carga local (como HAProxy).

Funciones de SmartStack

1. Comprobaciones de estado automáticas : Nerve y Synapse trabajan juntos para garantizar que solo se enruten instancias de servicio en buen estado.
2. Resiliencia y confiabilidad : SmartStack garantiza una alta disponibilidad de los servicios, incluso ante particiones de red u otras fallas.
3. Integración con la tecnología existente : al utilizar Zookeeper como almacenamiento central y HAProxy como equilibrador de carga, SmartStack se puede integrar fácilmente con las pilas de tecnología existentes.

1.8. Etc.

Etcd es un almacén de valores clave distribuido de código abierto y de alta disponibilidad, que se utiliza principalmente para la configuración compartida y el descubrimiento de servicios. Desarrollado por CoreOS, etcd está diseñado para clústeres grandes, específicamente para proporcionar almacenamiento de datos confiable para Kubernetes.

Las características principales de etcd.

1. Coherencia y alta disponibilidad : Etcd se basa en el algoritmo Raft para garantizar la coherencia de los datos en sistemas distribuidos.
2. Cerraduras distribuidas : utilice etcd para implementar mecanismos de bloqueo para sistemas distribuidos.
3. Monitoreo y alertas : los pares clave-valor se pueden monitorear para detectar cambios, como cambios de configuración o registro/cancelación del registro del servicio.
4. API simple : etcd proporciona una API RESTful simple, lo que facilita la integración con varias aplicaciones.

Cómo utilizar Etcd

1. Instalación y puesta en marcha : Sus binarios se pueden descargar desde el repositorio GitHub de etcd. Una vez iniciado etcd, comenzará a escuchar las solicitudes de los clientes.
2. Operaciones clave-valor : utilizando la API HTTP o el cliente de línea de comandos proporcionado etcdctl, los usuarios pueden configurar, obtener, eliminar y monitorear pares clave-valor.
3. Descubrimiento de servicios : en etcd, las instancias de servicio almacenan sus direcciones y otros metadatos como pares clave-valor cuando se inician. Los clientes que requieran estos servicios pueden consultar etcd para descubrirlos.

Comparación de etcd con otras herramientas de descubrimiento de servicios

En comparación con herramientas como Zookeeper y Consul, etcd proporciona una API más simple y directa. Está diseñado para satisfacer las necesidades de los clústeres de contenedores modernos como Kubernetes, por lo que es muy adecuado para su uso en este entorno.

2. Puerta de enlace API

En la arquitectura de microservicio, la puerta de enlace API es un servidor, que es el punto de entrada del sistema y es responsable del enrutamiento de solicitudes, la composición de API, el equilibrio de carga, la autenticación, la autorización, la seguridad, etc.

¿Por qué necesitas una puerta de enlace API?

API Gateway es un servidor, del que también se puede decir que es el único nodo que ingresa al sistema. Esto es muy similar al patrón Fachada en los patrones de diseño orientado a objetos. API Gateway encapsula la arquitectura interna del sistema y proporciona API a varios clientes. También puede tener otras características como autorización, monitoreo, equilibrio de carga, almacenamiento en caché, administración y fragmentación de solicitudes, manejo de respuestas estáticas, etc.

1. Entrada única : proporciona una entrada API unificada para consumidores externos, ocultando la estructura interna del sistema.
2. Composición de API : combine las operaciones de múltiples microservicios en una sola operación compuesta, reduciendo así la cantidad de solicitudes y respuestas entre el cliente y el servidor.
3. Equilibrio de carga : distribuya las solicitudes entrantes a múltiples instancias para mejorar la escalabilidad y disponibilidad del sistema.
4. Seguridad : Medidas de seguridad centralizadas como autenticación, autorización y manejo de SSL.

Características comunes de las puertas de enlace API

1. Enrutamiento de solicitudes : reenvío de solicitudes de API al microservicio apropiado.
2. Transformación de solicitud/respuesta : modifica el formato de solicitud y respuesta entre el cliente y el servicio.
3. Agregación de API : combinación de datos y funcionalidades de múltiples servicios en una API única y consistente.
4. Seguridad : Incluye limitación de velocidad, autenticación y autorización.
5. Almacenamiento en caché : proporciona almacenamiento en caché para solicitudes comunes, lo que reduce los tiempos de respuesta y la carga de servicio detrás de ellas.

[Ejemplo de función de puerta de enlace API]

import org.springframework.cloud.gateway.route.RouteLocator;
import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder;
import org.springframework.context.annotation.Bean;

// Spring Cloud Gateway的一个简单配置示例
public class ApiGatewayConfiguration {
    
    
    @Bean
    public RouteLocator gatewayRoutes(RouteLocatorBuilder builder) {
    
    
        return builder.routes()
            .route(r -> r.path("/service-api/**")
            .uri("http://localhost:8080/"))
            .build();
    }
}

API Gateway es responsable del reenvío de solicitudes, la composición y la conversión de protocolos. Todas las solicitudes de los clientes deben pasar primero por API Gateway y luego enrutarlas a los microservicios correspondientes. API Gateway a menudo maneja una solicitud llamando a múltiples microservicios y agregando los resultados de múltiples servicios. Puede convertir entre protocolos web y protocolos no compatibles con la web utilizados internamente, como el protocolo HTTP y el protocolo WebSocket. La siguiente figura muestra una API Gateway adaptada a la arquitectura actual.

2.1 Solicitud de reenvío

En la arquitectura de microservicios, el reenvío de solicitudes es una de las funciones principales de la puerta de enlace API. Cuando un cliente realiza una solicitud, es responsabilidad de API Gateway determinar qué servicio debe manejar la solicitud y reenviarla a la instancia de servicio adecuada.

principio de funcionamiento

1. Enrutamiento dinámico : en lugar de codificar la dirección de un servicio específico, la puerta de enlace determina la ruta dinámicamente. Esto generalmente se basa en un mecanismo de descubrimiento de servicios como Eureka o etcd discutidos anteriormente.
2. Equilibrio de carga : las solicitudes no solo se reenvían a cualquier instancia de servicio, sino que también se tienen en cuenta la carga y el estado de cada instancia.
3. Cadena de filtros : antes y después de reenviar la solicitud, la puerta de enlace puede aplicar una serie de filtros, como filtros de seguridad, filtros de transformación de respuesta, etc.

estrategia de reenvío

1. Loop Robin : seleccione cada instancia de servicio en secuencia.
2. Menos conexiones : reenvía solicitudes a la instancia con la menor cantidad de conexiones.
3. Consciente de la latencia : considere la latencia de cada instancia para decidir el reenvío.
4. Geolocalización : Reenviar según la ubicación geográfica de la fuente de la solicitud.

2.2 Fusión de respuestas

En un entorno de microservicios, la solicitud de un cliente puede requerir que varios servicios trabajen juntos para producir la respuesta final. La puerta de enlace API puede agregar respuestas de múltiples servicios para proporcionar una respuesta unificada y consistente al cliente.

escenas a utilizar

1. Vistas combinadas : por ejemplo, la vista del perfil de un usuario puede necesitar obtener datos del servicio de usuario, del servicio de pedidos y del servicio de revisión.
2. Análisis e informes : agregue datos de múltiples servicios para generar informes complejos.

lograr

1. Solicitudes paralelas : API Gateway puede enviar solicitudes a múltiples servicios en paralelo, lo que reduce el tiempo de respuesta general.
2. Transformación de datos : Convertir y estandarizar formatos de datos de diferentes servicios.
3. Manejo de errores : decida qué hacer cuando uno de los servicios devuelve un error o se agota el tiempo de espera.

2.3 Conversión de protocolo

A medida que la tecnología se desarrolla, diferentes servicios pueden utilizar diferentes protocolos de comunicación. Una puerta de enlace API puede actuar como un conversor de protocolos, convirtiendo las solicitudes de los clientes de un protocolo a otro.

ejemplo

1. HTTP a gRPC : el cliente puede usar HTTP/REST, mientras que el servicio interno usa gRPC. API Gateway puede convertir estos dos tipos de comunicación.
2. Conversión de versión : los clientes más antiguos pueden utilizar versiones de API obsoletas. La puerta de enlace puede convertir estas solicitudes en solicitudes de nueva versión.

2.4 Conversión de datos

En una arquitectura de microservicios, diferentes servicios pueden utilizar diferentes formatos de datos debido a razones históricas, elecciones tecnológicas o preferencias del equipo. La puerta de enlace API actúa como intermediario entre los microservicios y los clientes y, en ocasiones, necesita convertir formatos de datos.

escenas a utilizar

1. Compatibilidad de versiones : cuando un servicio se actualiza y cambia su formato de datos, para garantizar que los clientes más antiguos aún puedan funcionar, la puerta de enlace puede convertir los datos del formato antiguo al nuevo.
2. Estandarización de formatos : convierta XML a JSON o formatos específicos del proveedor a formatos estándar.

Estrategia de transformación de datos

1. Transformación XSLT : para datos XML, puede utilizar XSLT para transformar los datos.
2. Conversión JSON : utilice bibliotecas como Jackson o Gson para convertir datos JSON.
3. Mapeo de datos : define el mapeo entre las estructuras de datos de origen y de destino.

2.5 Certificación de seguridad

Las puertas de enlace API suelen tener la responsabilidad de la seguridad de las aplicaciones porque son el primer punto de contacto para todas las solicitudes entrantes.

Principales características de seguridad

1. Autenticación : determina quién es el solicitante. Los métodos comunes incluyen la autenticación basada en tokens, como JWT.
2. Autorización : Determina lo que el solicitante puede hacer. Por ejemplo, es posible que algunos usuarios solo tengan acceso de lectura, mientras que otros tengan permisos de escritura.
3. Limitación de velocidad : limite la tasa de solicitudes según el usuario o la dirección IP para evitar abusos o ataques.
4. Funcionalidad de firewall : bloquea solicitudes de fuentes maliciosas o bloquea ciertos tipos de solicitudes.

Estrategia de implementacion

1. Clave API : cada solicitud debe incluir una clave API, que la puerta de enlace utiliza para identificar y autenticar al solicitante.
2. OAuth : un marco de autorización estándar que permite a las aplicaciones de terceros acceso limitado a las cuentas de usuario.
3. JWT (JSON Web Tokens) : una forma concisa y autónoma de representar reclamaciones de información entre destinatarios.

3. Centro de configuración

En la arquitectura de microservicio, el centro de configuración es un servicio que almacena la configuración externa. La configuración externa es una configuración independiente de la aplicación y se puede cambiar sin reiniciar la aplicación.

¿Por qué necesitas un centro de configuración?

1. Cambios dinámicos : cambie dinámicamente las configuraciones en tiempo de ejecución sin reiniciar el servicio.
2. Gestión centralizada : para sistemas grandes con una gran cantidad de microservicios, es necesaria una gestión centralizada de las configuraciones.
3. Control de versiones : guarde versiones históricas de configuraciones y pueda retroceder a versiones anteriores.

3.1 Centro de configuración de Zookeeper

Apache ZooKeeper es un servicio de coordinación de código abierto, distribuido y de alto rendimiento para aplicaciones distribuidas. Aunque no está diseñado específicamente para la gestión de la configuración, se utiliza a menudo en este escenario.

Ventajas del Centro de configuración de ZooKeeper

1. Alta disponibilidad : debido a su naturaleza distribuida, ZooKeeper puede proporcionar alta disponibilidad y tolerancia a fallas.
2. Tiempo real : cuando cambia la configuración, las instancias de servicios relacionados se pueden notificar en tiempo real.
3. Bloqueos distribuidos : ZooKeeper admite bloqueos distribuidos, que son útiles para sincronizar configuraciones entre múltiples servicios.

Cómo utilizar ZooKeeper como centro de configuración

1. Crear nodos : en ZooKeeper, puede crear nodos persistentes o nodos temporales para almacenar información de configuración. Los nodos temporales desaparecen cuando el cliente se desconecta.
2. Escuchar cambios de configuración : un servicio puede escuchar cambios en sus nodos de configuración. Cuando otros servicios o administradores cambian la configuración, se notifica al servicio y puede recargar la configuración.
3. Control de versiones : ZooKeeper proporciona un número de versión para cada znode (nodo de datos en ZooKeeper), lo que ayuda a evitar problemas con cambios simultáneos.

[Obtener configuración de ZooKeeper]

// 从ZooKeeper获取配置
public String getConfig(String configKey) throws Exception {
    
    
    String path = "/config/" + configKey;
    if (zooKeeper.exists(path, false) != null) {
    
    
        return new String(zooKeeper.getData(path, false, null));
    }
    return null;
}

// 使用方法：
String myConfigValue = getConfig("myConfigKey");

3.2 Clasificación de datos del centro de configuración

En un entorno de microservicios de gran tamaño, los datos de configuración pueden ser enormes y deben gestionarse y clasificarse de forma eficaz.

Clasificados por ambiente

1. Entorno de desarrollo : la configuración utilizada localmente por los desarrolladores.
2. Entorno de prueba : entorno utilizado para control de calidad y pruebas automatizadas.
3. Entorno de producción : el entorno utilizado por los usuarios reales.

Clasificados por servicio

Para cada microservicio, existe su propia configuración.

Clasificado por función

Por ejemplo, configuración de base de datos, configuración de cola de mensajes, configuración de servicios de terceros, etc.

Permisos y control de acceso

No todos los servicios o personas deberían tener acceso a todas las configuraciones. El centro de configuración debe admitir el control de acceso basado en roles para garantizar que solo los servicios o el personal autorizados puedan leer o modificar las configuraciones.

4. Programación de eventos (Kafka)

Apache Kafka es una plataforma de procesamiento de flujo distribuido que se utiliza para crear canales de transmisión de datos de alto rendimiento, tolerantes a fallas y en tiempo real. En la arquitectura de microservicios, Kafka se utiliza a menudo como componente central de la arquitectura basada en eventos.

Ventajas de Kafka

1. Alto rendimiento : Kafka está diseñado para manejar millones de eventos o mensajes por segundo.
2. Durabilidad : los mensajes se guardan incluso si el consumidor no está disponible temporalmente o falla.
3. Distribuido : los clústeres de Kafka se pueden distribuir en varias máquinas para proporcionar tolerancia a fallas y alta disponibilidad.

Aplicación de Kafka en microservicios

1. Fuente del evento : registra cada evento que ocurre con fines de transacción, auditoría o recuperación.
2. Integración de datos : integre datos de múltiples microservicios en un gran almacén de datos o lago de datos.
3. Procesamiento asincrónico : desacoplar productores y consumidores a través de Kafka permite el procesamiento asincrónico.

[Publicar eventos usando Kafka]

import org.apache.kafka.clients.producer.*;

// Kafka事件发布服务
public class KafkaProducerService {
    
    
    private final Producer<String, String> producer;
    private static final String TOPIC = "event-topic";

    public KafkaProducerService(Properties properties) {
    
    
        this.producer = new KafkaProducer<>(properties);
    }

    public void sendEvent(String key, String value) {
    
    
        producer.send(new ProducerRecord<>(TOPIC, key, value));
        producer.close();
    }
}

// 使用方法：
Properties properties = new Properties();
properties.put("bootstrap.servers", "localhost:9092");
properties.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
properties.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

KafkaProducerService kafkaService = new KafkaProducerService(properties);
kafkaService.sendEvent("eventKey", "eventValue");

5. Seguimiento del servicio (detective inicial)

En un entorno de microservicios complejo, resulta fundamental comprender cómo se propagan las solicitudes a través de diversos servicios. Esto ayuda a diagnosticar problemas de rendimiento, rastrear errores y optimizar el comportamiento general del sistema. Para eso está el seguimiento de servicios.

Spring Cloud Sleuth es un componente de la familia Spring Cloud que proporciona una forma sencilla y eficaz de agregar seguimiento a las aplicaciones Spring Boot.

Cómo funciona Spring Cloud Sleuth

1. ID de solicitud : Sleuth genera automáticamente una identificación única para cada solicitud que ingresa al sistema, llamada "identificación de seguimiento". Esta identificación se propaga por todo el sistema con solicitudes.
2. ID de intervalo : cada vez que llega una solicitud a un nuevo servicio o se inicia una nueva actividad, Sleuth genera un nuevo "ID de intervalo". Esto ayuda a distinguir diferentes partes de la misma solicitud en diferentes servicios.

[Ubicación de Spring Cloud Sleuth]

import org.springframework.cloud.sleuth.zipkin2.ZipkinSpanReporter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class SleuthConfig {
    
    

    @Bean
    public ZipkinSpanReporter makeZipkinSpanReporter() {
    
    
        return new ZipkinSpanReporter() {
    
    
            @Override
            public void report(zipkin2.Span span) {
    
    
                System.out.println(
                    String.format("Reporting span [%s] to Zipkin", span)
                );
            }
        };
    }
}

Este código muestra cómo configurar Spring Cloud Sleuth para integrarlo con Zipkin para informar datos de seguimiento a Zipkin.

Integrar con otras herramientas

Spring Cloud Sleuth se puede integrar con herramientas como Zipkin, Elasticsearch, Logstash, Kibana (ELK stack), etc. para visualizar y analizar datos de seguimiento.

6. Disyuntor de servicio (Hystrix)

En una arquitectura de microservicios, cuando un servicio falla, puede desencadenar una reacción en cadena que provoca que todo el sistema colapse. Un fusible de servicio actúa como un fusible en un circuito eléctrico: cuando se detecta una condición anormal, se "dispara" para evitar daños mayores.

Netflix Hystrix es una de las implementaciones de disyuntores de servicios más conocidas.

Cómo funciona Hystrix

1. Patrón de comando : al usar Hystrix, encapsula el código que llama al servicio remoto en un objeto HystrixCommand.
2. Aislamiento : Hystrix proporciona aislamiento para cada llamada de servicio a través de un grupo de subprocesos o semáforo, lo que garantiza que la falla de un servicio no afectará a otros servicios.
3. Disyuntor : si un servicio remoto falla continuamente hasta un umbral, Hystrix se "disparará" y detendrá automáticamente todas las llamadas al servicio.

。

[Ejemplo de disyuntor Hystrix]

import com.netflix.hystrix.HystrixCommand;
import com.netflix.hystrix.HystrixCommandGroupKey;

public class SimpleHystrixCommand extends HystrixCommand<String> {
    
    

    private final String name;

    public SimpleHystrixCommand(String name) {
    
    
        super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
        this.name = name;
    }

    @Override
    protected String run() throws Exception {
    
    
        // 这里放可能会失败的代码
        return "Hello, " + name + "!";
    }

    @Override
    protected String getFallback() {
    
    
        return "Fallback for: " + name;
    }
}

// 使用方法：
String response = new SimpleHystrixCommand("Test").execute();

6.1 Mecanismo del disyuntor Hystrix

Los disyuntores son el corazón de Hystrix. Su principio de funcionamiento es similar al de un fusible de circuito real:

1. Estado cerrado : este es un estado normal y todas las solicitudes se procesarán normalmente. Si la tasa de falla excede un umbral predeterminado, el disyuntor pasa al estado "abierto".
2. Estado abierto : en este estado, para evitar mayores daños, todas las solicitudes fallan automáticamente sin intentar llamar al servicio remoto.
3. Estado medio abierto : después de un período de tiempo, el disyuntor pasará a un estado medio abierto, lo que permitirá que pasen algunas solicitudes. Si estas solicitudes tienen éxito, el disyuntor volverá al estado cerrado; en caso contrario, se abrirá nuevamente.

Estos tres estados garantizan que el sistema pueda recuperarse rápidamente ante una falla, al mismo tiempo que proporcionan un buffer para que los servicios remotos tengan tiempo de recuperarse.

7. Gestión de API

Con la aplicación generalizada de microservicios, la cantidad, variedad y complejidad de las API han aumentado dramáticamente. La gestión eficaz de API tiene como objetivo simplificar el diseño, implementación, mantenimiento y monitoreo de las API al tiempo que garantiza su seguridad, confiabilidad y disponibilidad.

Componentes centrales de la gestión de API

1. Puerta de enlace API : como punto de entrada de la API, es responsable del enrutamiento, combinación, conversión, verificación, limitación de velocidad, etc.
2. Diseño y documentación de API : proporcione un conjunto de pautas de diseño de API estandarizadas y mantenga continuamente la documentación de API.
3. Monitoreo y análisis de API : supervise el uso, el rendimiento y los errores de la API y proporcione información basada en datos.

Desafíos de la gestión de API

1. Control de versiones : a medida que cambian las necesidades comerciales, la API puede cambiar. Una consideración importante es cómo no afectar las versiones existentes de la API de administración de clientes.
2. Límites de tarifas y cuotas : para evitar abusos y garantizar un uso justo, es necesario establecer límites de uso para las API.
3. Seguridad : incluida autenticación, autorización, prevención de ataques maliciosos, etc.
4. Compatibilidad : las nuevas versiones de API deben ser compatibles con versiones anteriores para no afectar a los usuarios existentes.

Mejores prácticas para la gestión de API

1. Especificación de API abierta (OAS) : utilice un formato de descripción de API estándar, como OpenAPI, para garantizar la coherencia.
2. Pruebas de API : similar a las pruebas de software, pero más centradas en el contrato, el rendimiento y la seguridad de la API.
3. Gestión del ciclo de vida de la API : defina el ciclo de vida completo de la API desde el diseño hasta su obsolescencia y administre la API de acuerdo con este ciclo de vida.

En la arquitectura de microservicios, la gestión de API se ha convertido en un componente clave. Cuando aumenta la cantidad de servicios, no tener una estrategia de gestión de API eficaz puede generar rápidamente el caos. A través de los métodos y herramientas anteriores, las organizaciones pueden garantizar la salud, la seguridad y la eficiencia de sus API.

[Ejemplo de control de flujo API]

// 使用Spring Boot Rate Limiter进行API流量控制
import io.github.bucket4j.Bucket;
import io.github.bucket4j.Bandwidth;
import io.github.bucket4j.Refill;
import io.github.bucket4j.local.LocalBucketBuilder;

import java.time.Duration;

public class RateLimiterService {
    
    

    private Bucket createNewBucket() {
    
    
        Refill refill = Refill.greedy(10, Duration.ofMinutes(1));
        Bandwidth limit = Bandwidth.classic(10, refill).withInitialTokens(1);
        return LocalBucketBuilder.builder().addLimit(limit).build();
    }

    public boolean tryConsumeToken(Bucket bucket) {
    
    
        return bucket.tryConsume(1);
    }
}

// 使用方法：
RateLimiterService rateLimiter = new RateLimiterService();
Bucket bucket = rateLimiter.createNewBucket();
boolean canProcessRequest = rateLimiter.tryConsumeToken(bucket);
if (canProcessRequest) {
    
    
    // 处理API请求
} else {
    
    
    // 超出限额，拒绝请求或等待
}

El código anterior muestra cómo implementar la limitación de velocidad de la API en una aplicación Spring Boot utilizando la biblioteca Bucket4j.

La seguridad de los microservicios es otra área importante. Las principales preocupaciones incluyen la seguridad de las comunicaciones (como el uso de cifrado TLS), la autenticación y autorización de API y la seguridad de los datos.

[Ejemplo de autenticación de seguridad API]

// 使用Spring Security进行API安全认证
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;

@EnableWebSecurity
public class APISecurityConfig extends WebSecurityConfigurerAdapter {
    
    

    @Override
    protected void configure(HttpSecurity http) throws Exception {
    
    
        http
            .authorizeRequests()
                .antMatchers("/public/**").permitAll()
                .antMatchers("/private/**").authenticated()
                .and()
            .httpBasic();
    }
}

El fragmento de código anterior muestra cómo configurar la autenticación básica para rutas API usando Spring Security. /public/La API siguiente es pública, mientras que /private/la API siguiente requiere autenticación.