Algunas empresas, incluido nuestro cliente, desarrollan el producto a través de una red de socios. Por ejemplo, las grandes tiendas en línea están integradas con el servicio de entrega: solicita un producto y pronto recibe un número de seguimiento para el paquete. Otro ejemplo es cuando compras un seguro o un boleto de Aeroexpress junto con tu boleto aéreo.
Para ello, se utiliza una API, que debe ser emitida a los socios a través de API Gateway. Hemos resuelto este problema. En este artículo te contamos los detalles.
Dado: un ecosistema y un portal API con una interfaz donde los usuarios se registran, reciben información, etc. Necesitamos hacer una puerta de enlace API conveniente y confiable. En el proceso, necesitábamos proporcionar
- registro,
- Control de conexión API,
- monitorear cómo los usuarios usan el sistema final,
- Contabilización de indicadores de negocio.
En el artículo hablaremos sobre nuestra experiencia en la creación de API Gateway, durante la cual resolvimos las siguientes tareas:
- autenticacion de usuario,
- autorización de usuario,
- modificación de la solicitud original,
- solicitud de proxy,
- posprocesamiento de respuestas.
Hay dos tipos de gestión de API:
1. Estándar, que funciona de la siguiente manera. Antes de conectarse, el usuario prueba las funciones, luego paga e integra en su sitio. La mayoría de las veces se utilizan en pequeñas y medianas empresas.
2. Gestión de API B2B grande, cuando la empresa toma por primera vez la decisión comercial de conectarse, se convierte en socio de la empresa con una obligación contractual y luego se conecta a la API. Y después de que se resuelvan todas las formalidades, la empresa recibe acceso de prueba, pasa las pruebas y entra en producción. Pero esto no es posible sin una decisión de gestión para conectarse.
Nuestra solución
En esta parte, hablaremos sobre la creación de una API Gateway.
Los usuarios finales de la puerta de enlace API creada son socios de nuestro cliente. Ya tenemos los contratos necesarios para cada uno de ellos. Solo necesitaremos ampliar la funcionalidad marcando el acceso concedido a la puerta de enlace. En consecuencia, se necesita un proceso controlado de conexión y gestión.
Por supuesto, fue posible tomar alguna solución preparada para resolver el problema de la gestión de API y crear una puerta de enlace de API en particular. Por ejemplo, esto podría ser. No nos convenía, porque en nuestro caso ya teníamos un portal API y un enorme ecosistema construido alrededor de él. Todos los usuarios ya se han registrado, ya entendieron dónde y cómo pueden obtener la información necesaria. Las interfaces necesarias ya existían en el portal API, solo necesitábamos el API Gateway. En realidad, estamos comprometidos en su desarrollo.
Lo que llamamos API Gateway es una especie de proxy. Aquí nuevamente tuvimos una opción: puede escribir su propio proxy o puede elegir algo ya hecho. En este caso, optamos por el segundo camino y elegimos el paquete nginx + Lua. ¿Por qué? Necesitábamos un software confiable y probado que admitiera el escalado. Después de la implementación, no queríamos verificar tanto la corrección de la lógica comercial como la corrección del proxy.
Cada servidor web tiene una canalización de procesamiento de solicitudes. En el caso de nginx, se ve así:
(diagrama de )
Nuestro objetivo era encajar en esta canalización en un punto en el que podamos modificar la solicitud original.
Queremos crear un proxy transparente para que la solicitud siga siendo funcionalmente igual a como vino. Solo controlamos el acceso a la API final, ayudamos a que la solicitud llegue a ella. En caso de que la solicitud fuera incorrecta, la API final debería mostrar el error, pero no a nosotros. La única razón por la que podemos denegar una solicitud es porque el cliente no tiene acceso.
Ya existe para nginx en . Lua es un lenguaje de programación, es muy ligero y fácil de aprender. Por lo tanto, implementamos la lógica necesaria usando Lua.
La configuración de nginx (una analogía con la ruta de la aplicación), donde se realiza todo el trabajo, es bastante comprensible. Cabe destacar aquí la última directiva: post_action.
location /middleware {
more_clear_input_headers Accept-Encoding;
lua_need_request_body on;
rewrite_by_lua_file 'middleware/rewrite.lua';
access_by_lua_file 'middleware/access.lua';
proxy_pass https://someurl.com;
body_filter_by_lua_file 'middleware/body_filter.lua';
post_action /process_session;
}
Considere lo que sucede en esta configuración:
más_clear_input_headers — borra el valor de los encabezados especificados después de la directiva.
lua_need_request_body - controla si el cuerpo de la solicitud original debe leerse antes de ejecutar las directivas rewrite/access/access_by_lua o no. De forma predeterminada, nginx no lee el cuerpo de una solicitud de cliente y, si necesita acceder a él, esta directiva debe activarse.
reescribir_por_lua_file - la ruta al script, que describe la lógica para modificar la solicitud
acceso_por_lua_file — la ruta al script, que describe la lógica que verifica el acceso al recurso.
contraseña_proxy — URL a la que se enviará la solicitud.
body_filter_by_lua_file — la ruta al script, que describe la lógica para filtrar la solicitud antes de devolverla al cliente.
Y, finalmente, post_acción - una directiva oficialmente no documentada con la que puede realizar algunas otras acciones después de que se le da la respuesta al cliente.
A continuación, describiremos en orden cómo resolvimos nuestros problemas.
Autorización/autenticación y solicitud de modificación
Autorización
Creamos la autorización y la autenticación mediante el acceso a certificados. Hay un certificado raíz. A cada nuevo cliente del cliente se le genera su certificado personal, con el que puede acceder a la API. Este certificado se configura en la sección del servidor de la configuración de nginx.
ssl on;
ssl_certificate /usr/local/openresty/nginx/ssl/cert.pem;
ssl_certificate_key /usr/local/openresty/nginx/ssl/cert.pem;
ssl_client_certificate /usr/local/openresty/nginx/ssl/ca.crt;
ssl_verify_client on;modificación
Puede surgir una pregunta justa: ¿qué hacer con un cliente certificado si de repente queremos desconectarlo del sistema? No vuelva a emitir certificados para todos los demás clientes.
Así que nos acercamos sin problemas a la siguiente tarea: modificar la solicitud original. La solicitud inicial del cliente, por lo general, no es válida para el sistema final. Una de las tareas es agregar las partes que faltan a la solicitud para que sea válida. El punto es que los datos que faltan son diferentes para cada cliente. Sabemos que un cliente nos llega con un certificado del que podemos tomar una huella y extraer los datos necesarios del cliente de la base de datos.
Si en algún momento necesitas desconectar al cliente de nuestro servicio, sus datos desaparecerán de la base de datos y no podrá hacer nada.
Trabajar con datos de clientes
Necesitábamos hacer que la solución tuviera una alta disponibilidad, especialmente cómo obtenemos los datos de los clientes. La dificultad es que la fuente principal de estos datos es un servicio de terceros que no garantiza una velocidad suficientemente alta e ininterrumpida.
Por lo tanto, necesitábamos garantizar una alta disponibilidad de los datos de los clientes. Como herramienta, hemos elegido que nos proporciona:
- acceso rápido a los datos
- la capacidad de organizar un grupo de varios nodos con datos replicados en diferentes nodos.
Elegimos la estrategia más simple para entregar datos al caché:
El trabajo con el sistema final se lleva a cabo dentro de las sesiones y hay un límite en el número máximo. Si el cliente no ha cerrado la sesión, tendremos que hacer esto.
Los datos de la sesión abierta provienen del sistema final y se procesan inicialmente en el lado de Lua. Decidimos usar Hazelcast para almacenar estos datos con un trabajo .NET. Luego, en algunos intervalos, verificamos el derecho a la vida de las sesiones abiertas y cerramos las podridas.
Acceso a Hazelcast desde Lua y .NET
No hay clientes de Lua para trabajar con Hazelcast, pero Hazelcast tiene una API REST, que decidimos usar. Para .NET hay , a través del cual planeamos acceder a los datos de Hazelcast en el lado de .NET. Pero no estaba allí.
Al almacenar datos a través de REST y recuperar datos a través de un cliente .NET, se utilizan diferentes serializadores y deserializadores. Por lo tanto, es imposible pasar datos a través de REST, pero obtenerlos a través del cliente .NET y viceversa.
Si está interesado, le informaremos más sobre este problema en un artículo separado. Spoiler - en el esquema.
Registro y monitoreo
Nuestro estándar corporativo para iniciar sesión a través de .NET es Serilog, todos los registros terminan en Elasticsearch y los analizamos a través de Kibana. Me gustaría hacer algo similar en este caso. El único para trabajar con Elastic en Lua, que se encontró, se rompió en el primer requerimiento. Y usamos Fluentd.
- solución de código abierto para proporcionar una sola capa de registro de aplicaciones. Le permite recopilar registros de diferentes capas de la aplicación y luego transmitirlos a una sola fuente.
API Gateway funciona en K8S, por lo que decidimos agregar un contenedor con fluentd en el mismo pody para escribir registros en el puerto tcp abierto existente fluentd.
También exploramos cómo se comportaría fluentd si no tuviera conexión con Elasticsearch. Durante dos días, las solicitudes se enviaron continuamente a la puerta de enlace, los registros se enviaron a fluentd, pero fluentd fue prohibido en IP Elastic. Después de que se restauró la conexión, fluentd superó perfectamente absolutamente todos los registros en Elastic.
Conclusión
El enfoque elegido para la implementación nos permitió entregar un producto realmente funcional para el entorno de combate en solo 2.5 meses.
Si algún día hace tales cosas, le recomendamos que en primer lugar comprenda claramente qué problema está resolviendo y qué recursos ya tiene. Tenga en cuenta las complejidades de la integración con los sistemas de gestión de API existentes.
Comprenda por sí mismo qué es exactamente lo que va a desarrollar: solo la lógica comercial para procesar las solicitudes o, como podría ser en nuestro caso, todo el proxy. No olvides que todo lo que hagas tú mismo debe probarse a fondo después.
Fuente: habr.com
