1. Uso de API Gateway
API Gateway utilizará los siguientes tres escenarios en mi análisis.
- API abierta Las empresas necesitan abrir sus datos y capacidades como plataformas de desarrollo y, por lo general, proporcionarlos en forma de descanso. Los mejores ejemplos son Taobao Open Platform, Tencent's QQ Development Platform y WeChat Open Platform. La plataforma abierta Open API inevitablemente involucrará el acceso de las aplicaciones del cliente, la administración de los permisos API, la administración de los tiempos de llamadas, etc. Habrá inevitablemente un portal unificado para la administración, que es cuando la puerta de enlace API puede desempeñar un papel.
- Pasarela de microservicios . El concepto de microservicios se propuso por primera vez en 2012. Con la vigorosa promoción de Martin Fowler, los microservicios se han desarrollado vigorosamente después de 2014. En la arquitectura de microservicios, hay un componente que se puede decir que es indispensable: la puerta de enlace de microservicios. La puerta de enlace de microservicios maneja el equilibrio de carga, el almacenamiento en caché, el enrutamiento, el control de acceso, el proxy de servicio, la supervisión, el registro, etc. La puerta de enlace API existe como una puerta de enlace de microservicios en la arquitectura de microservicios.
- Plataforma de gestión de servicios API . La arquitectura de microservicios anterior puede ser difícil de implementar para una empresa. Hay muchos sistemas heredados en la empresa, y todos deben extraerse a medida que cambian los micro servidores, lo cual es demasiado costoso para la empresa. Sin embargo, dado que existe una gran cantidad de servicios API entre diferentes sistemas, es necesario administrar las llamadas de servicio entre sistemas, ver claramente la relación entre las llamadas del sistema y monitorear las llamadas entre sistemas. La puerta de enlace API puede resolver estos problemas. Podemos pensar que si no hay una implementación a gran escala de la arquitectura de microservicios, para las empresas, la puerta de enlace de microservicios es la plataforma de gestión de servicios API de las empresas.
En segundo lugar, la posición de la puerta de enlace API en la estructura general de la empresa.
Con el aumento en la complejidad de los sistemas de información, una empresa inevitablemente aparecerá como aplicaciones externas asociadas, aplicaciones de red pública propias de la empresa, aplicaciones de intranet empresarial, etc., estas tres aplicaciones deben distinguirse en arquitectura, el nivel de disposición de las tres aplicaciones, El método de acceso también es diferente.
Por lo tanto, en mi diseño, estas tres aplicaciones se administran con diferentes puertas de enlace para la administración de API, a saber: puerta de enlace API (aplicación asociada OpenAPI), puerta de enlace API (aplicación interna), puerta de enlace API (aplicación de red pública interna).
3. Cómo aplicar la puerta de enlace API en las empresas
1. Para la puerta de enlace API utilizada por OpenAPI, los socios generales deben acceder a la plataforma OpenAPI en forma de aplicaciones, y los socios deben solicitar las aplicaciones en la plataforma OpenAPI.
Por lo tanto, además de la puerta de enlace OpenAPI, debe existir una plataforma para que los socios la utilicen, lo que requiere que la puerta de enlace OpenAPI proporcione API a la plataforma de usuario para acceder.
La siguiente arquitectura:
Por supuesto, si se trata de un escenario simple, es posible que no necesite proporcionar un portal orientado a los socios. Solo necesita agregar la identificación / clave de la aplicación del socio directamente por el personal de operaciones de la compañía. En este caso, el portal del socio no es necesario. Subsistema
2. La puerta de enlace API de la intranet puede considerarse como una puerta de enlace de microservicio o una plataforma de administración de servicios API de la intranet en términos de su función.
Cuando una empresa gestiona todas las aplicaciones utilizando la arquitectura de microservicios, la puerta de enlace API funciona como una puerta de enlace de microservicios.
Cuando la empresa solo usa el método de la API de descanso para acceder a las llamadas entre el sistema y la puerta de enlace API para administrar las llamadas, entonces la puerta de enlace API desempeña el papel de la administración del servicio API.
La referencia de arquitectura es la siguiente:
3. Para las aplicaciones de la red pública interna de la compañía (como la APP y el sitio web de la compañía), si la administración es más detallada, es posible que una puerta de enlace API independiente pueda manejar esta parte de la aplicación de la red pública interna en la arquitectura. Podría estar utilizando una puerta de enlace API para socios.
Si usa una puerta de enlace API independiente, existen los siguientes beneficios:
- Las prioridades para los socios y el negocio principal de la empresa son diferentes: diferentes puertas de enlace API pueden aislar el impacto comercial.
- El proceso de administración utilizado por la API interna puede ser diferente del proceso de administración para los socios.
- Los requisitos de la API interna en términos de expansión de funciones y otros aspectos son generalmente mayores que los requisitos de OpenAPI para funciones.
Según el análisis anterior, si la empresa es capaz, se recomienda utilizar la puerta de enlace API OPEN asociada y la puerta de enlace de la aplicación de red pública interna por separado.
4. ¿Cuáles son las soluciones competitivas de API Gateway?
1. Para la puerta de enlace API de la plataforma Open API, mi análisis solo puede elegir la puerta de enlace API como la solución. La industria no ha encontrado ninguna otra solución que pueda usarse como entrada de la plataforma Open API.
2. Para la puerta de enlace API como una puerta de enlace de microservicio, existen muchas soluciones entre las que puede elegir la industria, que también dependen del esquema de implementación del microservidor. Algunos esquemas de implementación de la arquitectura de microservicio no requieren la puerta de enlace de microservicio.
- Service Mesh, que es una arquitectura emergente basada en puertas de enlace sin API, completa el acceso de protección a la capa de red a través del proxy en el cliente, a fin de lograr los cambios mínimos en la capa de aplicación, los productos actuales de Service Mesh todavía están en desarrollo, y no hay muy Productos maduros y directamente aplicables. El producto de más rápido crecimiento es Istio. Se recomienda que preste mucha atención al desarrollo de productos relacionados y al uso comercial.
- Basado en la arquitectura duboo, generalmente no se requiere una puerta de enlace en esta arquitectura. El cliente accede directamente al proveedor de servicios y el centro de registro devuelve la dirección del servidor al cliente.
V. Solución API Gateway
La solución de código abierto de la nube privada es la siguiente:
- Kong kong es una solución de desarrollo secundaria basada en Nginx + Lua, https://konghq.com/
- Netflix Zuul, zuul es un componente recomendado de Spring Cloud, https://github.com/Netflix/zuul
- naranja, este programa de código abierto fue desarrollado por los chinos, http://orange.sumory.com/
Soluciones de nube pública:
- Amazon API Gateway, https: //aws.amazon.com/cn/api-gateway/
- Alibaba Cloud API Gateway, https://www.aliyun.com/product/apigateway/
- Tencent Cloud API Gateway, https://cloud.tencent.com/product/apigateway
Soluciones de desarrollo propio:
- Basado en la solución Nginx + Lua + OpenResty, puede ver que Kong y Orange se basan en esta solución
- Basado en Netty, modelo IO sin bloqueo. A través de la búsqueda en línea, podemos ver que algunas compañías como Yirendai en China se basan en este esquema, que es un esquema maduro.
- Basado en la solución Node.js. Esta solución aplica las características inherentes sin bloqueo de Node.js.
- Esquema basado en Java Servlet. zuul se basa en este esquema, que no es muy eficiente, por lo que siempre se critica a zuul.
Seis, cómo las empresas eligen API Gateway
Si desea elegir una puerta de enlace API existente, debe tener en cuenta los siguientes aspectos.
1. Rendimiento y disponibilidad
Una vez que se adopta la puerta de enlace API, la puerta de enlace API servirá como el núcleo de la aplicación empresarial, por lo que se requiere rendimiento y disponibilidad.
- Desde el punto de vista del rendimiento, cuanto más corto sea el mayor consumo de tiempo de la puerta de enlace, mejor. Personalmente, creo que necesita menos de 10 ms. El sistema necesita usar IO sin bloqueo, como epoll, NIO, etc. La interacción entre la puerta de enlace y varias dependencias también debe ser sin bloqueo, para garantizar una alta disponibilidad del sistema en general, como: programación receptiva Node.js y RxJava y Future basados en Java.
- La puerta de enlace debe admitir la implementación del clúster y el bloqueo de un servidor no debe afectar la disponibilidad del sistema en general.
- Varios conjuntos de puertas de enlace deberían admitir la misma plataforma de administración y el mismo centro de monitoreo. Por ejemplo, la puerta de enlace OpenAPI de una empresa y las diferentes puertas de enlace de microservicio de múltiples grupos de sistemas de aplicaciones internas se pueden monitorear en el mismo centro de monitoreo.
2. Escalabilidad y mantenibilidad
Siempre hay un lugar donde un producto no puede satisfacer las necesidades de producción, por lo tanto, es necesario pensar en cómo llevar a cabo el desarrollo secundario y el mantenimiento del producto, y si es conveniente para el equipo de la compañía hacerse cargo y mantener el producto.
3. Demanda de correspondencia
Debe evaluar si cada puerta de enlace API puede cumplir los requisitos, por ejemplo: si la plataforma OpenAPI necesita usar la puerta de enlace API, entonces debe mirar la puerta de enlace API para considerar los productos en los requisitos básicos de OpenAPI, como el acceso a aplicaciones de socios, la integración del portal de socios y el límite de acceso. Si puede cumplir con los requisitos.
Si se trata de una puerta de enlace de microservicios, es necesario pensar si el producto es lo suficientemente potente desde los aspectos de operación, mantenimiento, monitoreo y administración de microservicios.
4. ¿Es de código abierto? ¿La empresa tiene la capacidad de desarrollarse?
Los productos de código abierto existentes como kong, zuul y orange tienen las funciones básicas de las puertas de enlace API básicas. La mayoría de estos productos de código abierto están muy lejos de un buen uso.
Por ejemplo, no hay una interfaz de usuario que proporcione funciones de administración, la función de monitoreo es débil, no es compatible con la plataforma OpenAPI y no hay funciones de operación y operación y mantenimiento de la compañía.
Por supuesto, los productos de código abierto pueden obtener el código fuente. Si la compañía tiene fuertes capacidades de I + D y puede mantener estos productos de código abierto, después del desarrollo secundario, kong y zuul aún deben adaptarse a algunas compañías, pero deben tenerse en cuenta los siguientes puntos:
- Kong se basa en ngnix + lua, desde la perspectiva de la compañía es más difícil encontrar personas que puedan mantener este producto de arquitectura. Es necesario evaluar si la empresa actual tiene la capacidad de mantener este producto.
- El rendimiento de Zuul no es alto bajo una alta concurrencia debido a razones arquitectónicas, y también necesita integrar el sistema de gestión y monitoreo Zulu adaptativo de código abierto basado en la investigación.
- Dado que el naranja no se usa ampliamente y es una persona doméstica que es de código abierto, no es rico en sostenibilidad y recursos comunitarios. Puede que no sea fácil encontrar a alguien a quien preguntar después de un problema.
Además, Kong ofrece una versión empresarial de la puerta de enlace API, que por supuesto también se basa en ngnix + lua. La versión empresarial puede adquirir su soporte técnico, capacitación y otros servicios, así como funciones de administración y monitoreo de interfaz.
5. Nube pública o nube privada
Ahora Amazon, Alibaba y Tencent Cloud están proporcionando pasarelas API básicas en la nube pública. Por supuesto, las funciones básicas de estas pasarelas no deben ser un problema, pero el desarrollo secundario, las funciones extendidas y las funciones de monitoreo pueden no satisfacer las necesidades de personalización de algunos usuarios.
Además, debido a su propia seguridad de la información, muchas empresas no pueden utilizar el servicio de puerta de enlace API de la red pública de la red externa. De esta forma, solo se selecciona la solución de nube privada.
En términos de requisitos, si una puerta de enlace API basada en una nube pública solo puede ser aplicada por personal interno para aplicaciones de redes externas, no puede ser un portal de socios personalizado, que no es adecuado para las necesidades de algunas empresas.
Si se usa como una puerta de enlace de microservicios, en la mayoría de los casos, se espera que el servidor de la puerta de enlace y el servidor del proveedor de servicios estén en la red interna. En este caso, solo la puerta de enlace API de la nube privada puede satisfacer la demanda.
Según el análisis anterior, la puerta de enlace API pública básica de la nube solo satisface las necesidades de algunos clientes simples. Para muchas empresas, la puerta de enlace API privada de la nube es la opción correcta.
Lectura recomendada: si no comprende Spring, entonces el entrevistador de la gran fábrica no entenderá por qué se atreve a venir a la entrevista.
