Imagen de pixabay.com
1. Introducción
BFF (Backend for Frontend) y Gateway son dos conceptos importantes en la arquitectura de microservicios. Estos dos conceptos son relativamente nuevos y algunos desarrolladores e incluso arquitectos no lo entienden.
Este artículo utiliza un hipotético caso de empresa + icono para explicar qué son BFF y gateway y cómo evolucionaron. Espero inspirar a los arquitectos para diseñar e implementar la arquitectura de microservicios.
2. Arquitectura de servicio V1
Hagamos retroceder el tiempo hasta aproximadamente 2011. Supongamos que hay una empresa de comercio electrónico CoolShop con un cierto volumen de negocios. En este momento, ha completado la deconstrucción de la aplicación de bloque único y el servicio SOA interno se ha completado inicialmente. En este momento, su aplicación inalámbrica aún no se ha iniciado. La capa de experiencia del usuario front-end es principalmente una aplicación web tradicional del lado del servidor. La arquitectura general orientada al servicio V1 se muestra en la siguiente figura.
3. Arquitectura orientada a servicios V2
Es hora de llegar a principios de 2012, y las aplicaciones inalámbricas domésticas comenzaron a despegar. CoolShop también siguió de cerca la tendencia del mercado y desarrolló su propia aplicación inalámbrica nativa. Para poder conectarse en línea lo antes posible, el arquitecto de la compañía propuso la siguiente arquitectura V2 para permitir que la aplicación llame directamente a los servicios internos:
Esta arquitectura tiene los siguientes problemas:
- Las aplicaciones inalámbricas y los microservicios internos están fuertemente acoplados, y los cambios en un lado pueden afectar al otro.
- La aplicación inalámbrica necesita conocer los detalles, como la dirección del servicio interno.
- La aplicación inalámbrica necesita desarrollar una gran cantidad de lógica de corte y adaptación de agregación:
- Agregación: una determinada función necesita llamar a varias API de fondo para combinarlas al mismo tiempo. Por ejemplo, si la página de inicio necesita mostrar la clasificación y los detalles del producto, es necesario llamar a la API de clasificación y API del producto al mismo tiempo.
- Recorte: la carga útil que devuelven los servicios de fondo es generalmente más general. La aplicación debe recortarse según el tipo de dispositivo. Por ejemplo, la pantalla del teléfono móvil es pequeña y se debe cortar parte del contenido innecesario. La pantalla del Pad es relativamente grande y se puede cortar parte del contenido.
- Adaptación: un escenario de adaptación común es la conversión de formato. Por ejemplo, algunos servicios en segundo plano son más antiguos y solo admiten el antiguo formato SOAP / XML, pero no admiten el nuevo formato JSON. La aplicación inalámbrica debe adaptarse para manejar diferentes formatos de datos.
- Con el aumento de los tipos de dispositivos (iPhone / Android / iPad / WindowsPhone), el desarrollo de la lógica de corte y adaptación agregada causará mucha duplicación de trabajo en el lado del dispositivo.
3. Arquitectura orientada a servicios V2.1
La arquitectura V2 tiene demasiados problemas y no se ha desarrollado ni implementado. Para resolver los problemas anteriores, el arquitecto decidió introducir un nuevo rol ~ BFF móvil entre dispositivos externos y microservicios internos.
El llamado BFF es en realidad la abreviatura de Backend for Frontend. La traducción al chino es el backend desarrollado para el frontend. Está desarrollado principalmente por el equipo frontend (los microservicios backend generalmente son desarrollados por el equipo backend). BFF puede considerarse como un servicio de adaptación, que adapta los microservicios de back-end (principalmente incluyendo lógica como agregación y formateo y adaptación de formato), y expone API amigables y unificadas a los dispositivos finales inalámbricos para facilitar que los dispositivos inalámbricos accedan al back-end. Servicio.
La nueva arquitectura V2.1 es la siguiente:
Las ventajas de esta arquitectura son:
- La aplicación inalámbrica y los microservicios internos no están acoplados. Al introducir la capa BFF indirectamente, los dos lados se pueden cambiar de forma independiente:
- Si el back-end cambia, a través del escudo BFF, el equipo de front-end no puede verse afectado.
- Si el front-end cambia, a través del blindaje BFF, los microservicios de back-end pueden permanecer sin cambios.
- Cuando existen nuevos requisitos para las aplicaciones inalámbricas, la protección de BFF puede reducir los costos de comunicación y coordinación de los equipos de front-end y back-end. Muchos equipos de front-end pueden satisfacer sus propias necesidades en BFF.
- La aplicación inalámbrica solo necesita conocer la dirección de Mobile BFF, y la interfaz de servicio está unificada, y no necesita conocer la dirección ni los detalles de los microservicios complejos internos.
- La lógica de agregación, corte y adaptación se implementa en Mobile BFF, y la aplicación inalámbrica puede simplificar enormemente la pérdida de peso.
4. Arquitectura de servicio V3
La arquitectura V2.1 fue relativamente exitosa, y la implementación de la implementación apoyó el temprano crecimiento del negocio inalámbrico de CoolShop. Con el mayor crecimiento del volumen de negocios, el número de equipos inalámbricos de I + D también está aumentando, y la arquitectura V2.1 ha expuesto gradualmente los siguientes problemas:
- Al principio solo había un BFF móvil, que era un solo bloque, pero el equipo inalámbrico de I + D aumentaba constantemente, lo que correspondía a varias líneas comerciales. Según la ley de Conway, existe un desajuste entre un único BFF inalámbrico y varios equipos. El costo de comunicación y coordinación entre los equipos es alto y la eficiencia de entrega es baja.
- Mobile BFF no solo incluye la agregación / corte / adaptación de varias líneas comerciales y la lógica comercial, sino que también introduce una gran cantidad de lógica transversal, como la certificación de seguridad, el monitoreo de registros y el fusible limitador de corriente. Con el tiempo, el código se volvió cada vez más complejo, la deuda técnica se acumuló cada vez más, la eficiencia del desarrollo continuó disminuyendo y el número de defectos continuó aumentando.
- El clúster Mobile BFF es un punto único de falla. Los defectos graves del código o las inundaciones de tráfico pueden causar el tiempo de inactividad del clúster y todas las aplicaciones inalámbricas no están disponibles.
Para resolver el problema anterior, el arquitecto decidió introducir un nuevo rol ~ API Gateway entre el dispositivo externo y el BFF interno después de pensar. La nueva arquitectura V3 se muestra en la siguiente figura:
La nueva arquitectura V3 tiene los siguientes ajustes:
- BFF se desacopla y divide según los equipos o líneas de negocio, y se divide en varios microservicios BFF. Cada línea de negocio puede desarrollar y entregar sus propios microservicios BFF en paralelo.
- La puerta de enlace (generalmente operada y mantenida por un equipo marco independiente) se enfoca en funciones transversales (preocupaciones transversales), que incluyen:
- Enrutamiento, enrutamiento de solicitudes de dispositivos inalámbricos a un clúster BFF de microservicio en el back-end.
- Autenticación, autenticación centralizada y autenticación para acceso a API que involucra datos confidenciales.
- Monitoreo, monitoreo de desempeño de llamadas API.
- Limitación y fusión actual, cuando hay un pico de tráfico, o hay una demora o falla en el servicio BFF / micro de back-end, la puerta de enlace puede llevar a cabo activamente la limitación y fusión de corriente, proteger los servicios de back-end y mantener la experiencia del usuario front-end aceptable.
- Asegure la lucha contra la escalada, recopile registros de acceso, analice el comportamiento malicioso en segundo plano y bloquee las solicitudes maliciosas.
- La puerta de enlace introduce otra capa de indirección entre el dispositivo inalámbrico y el BFF, lo que permite que los dos lados cambien de forma independiente, especialmente cuando el BFF de fondo se está actualizando o migrando, para que las aplicaciones del lado del usuario no se vean afectadas.
En la nueva arquitectura V3, la puerta de enlace asume un papel importante: es un arma para desacoplar, dividir y la posterior actualización y migración. Con la cooperación de la puerta de enlace, el BFF de bloque único se da cuenta del desacoplamiento y la división, y cada equipo de línea de negocio puede desarrollar y entregar sus propios microservicios de forma independiente, lo que mejora en gran medida la eficiencia de la investigación y el desarrollo. Además, después de que la lógica transversal se despoja de BFF a la puerta de enlace, los desarrolladores de BFF pueden centrarse más en la entrega de lógica de negocios y lograr una separación arquitectónica de las preocupaciones (Separación de preocupaciones).
5. Arquitectura de servicio V4
El negocio está en constante evolución, y la arquitectura técnica también debe ajustarse constantemente para responder a los cambios en la demanda. En los últimos años, el equipo técnico de CoolShop ha introducido nuevas necesidades comerciales y técnicas, principalmente:
- Abra capacidades empresariales internas y cree la plataforma CoolShop Open API. Con la ayuda de desarrolladores comunitarios externos, innova en la plataforma CoolShop para ampliar aún más la aplicación y la forma de negocio de CoolShop.
- Abandone el modelo de aplicación web tradicional del lado del servidor, presente la arquitectura de separación frontal y posterior, y el front-end adopta tecnologías como la página única H5 para proporcionar a los usuarios una mejor experiencia.
Para satisfacer las necesidades comerciales, el arquitecto ha ampliado y actualizado la arquitectura orientada al servicio. La nueva arquitectura V4 se muestra en la siguiente figura:
La idea general de V4 es similar a V3, excepto que ha expandido nuevos canales de acceso:
- Presente la capa BFF y la puerta de enlace de soporte para API abierta de terceros para ayudar a los desarrolladores de terceros a desarrollar aplicaciones en la plataforma CoolShop Open API.
- Presente la capa BFF para aplicaciones H5 y puertas de enlace compatibles para admitir la separación frontal y posterior y el modo de aplicación H5 de una sola página.
V4 es una arquitectura de microservicio moderna relativamente completa, que se divide en lo siguiente desde afuera hacia adentro: capa de experiencia del usuario final-> capa de puerta de enlace-> capa BFF-> capa de microservicio. Toda la arquitectura tiene niveles claros y responsabilidades claras, es una arquitectura evolutiva flexible que puede soportar la innovación empresarial continua.
6. Conclusión
- En la arquitectura de microservicios, BFF (Backend for Frontend) también se denomina capa de agregación o capa de adaptación. Principalmente asume una función de adaptación: adaptar los microservicios complejos internos a diversas experiencias de usuario (inalámbrico / web / H5 / Terceros, etc.) API amigable y unificada. La personalización agregada es la principal responsabilidad de BFF.
- En la arquitectura de microservicios, la puerta de enlace se centra en la lógica transversal, que incluye enrutamiento, seguridad, monitoreo y fusible limitador de corriente. Por un lado, la puerta de enlace es un arma para dividir y desacoplar, y al mismo tiempo, los desarrolladores pueden centrarse en la realización de la lógica empresarial y lograr la separación de las preocupaciones en la arquitectura.
- La capa de experiencia del usuario final-> capa de puerta de enlace-> capa BFF-> capa de microservicio es una forma típica en capas de la arquitectura moderna de microservicios. Esta arquitectura puede responder de manera flexible a los cambios en las necesidades comerciales y es una arquitectura evolutiva que apoya la innovación.
- La tecnología y los negocios cambian constantemente. Los arquitectos deben ajustar constantemente la arquitectura para responder a estos cambios. Tanto BFF como gateways son productos de la evolución de la arquitectura.
- Bobo recientemente cooperó con Geek Time para lanzar un video curso llamado "Microservice Architecture 160 Lectures". El tercer módulo (que se lanzará en junio) presentará la arquitectura y la práctica de la nueva puerta de enlace de microservicios de Netflix Zuul2 Para un análisis en profundidad, la atención de todos es bienvenida.
· FINAL ·
