Microservicios es un estilo de arquitectura para desarrollar aplicaciones. Gracias a los microservicios, una aplicación grande puede descomponerse en partes independientes, cada una con su propio ámbito de responsabilidad. Para servir una única solicitud de usuario o de API, una aplicación basada en microservicios puede llamar a muchos microservicios internos con los que preparar su respuesta.
Una aplicación basada en microservicios implementada correctamente puede lograr los siguientes objetivos:
- Definir contratos sólidos entre los distintos microservicios.
- Permite ciclos de implementación independientes, incluida la reversión.
- Facilita las pruebas A/B simultáneas de versiones en subsistemas.
- Minimizar la sobrecarga de la automatización de pruebas y del control de calidad.
- Mejorar la claridad del registro y la monitorización.
- Proporciona una contabilidad de costes detallada.
- Aumentar la escalabilidad y la fiabilidad generales de las aplicaciones.
Google App Engine tiene varias funciones que se adaptan bien a las aplicaciones basadas en microservicios. En esta página se describen las prácticas recomendadas que debes seguir al desplegar tu aplicación como una aplicación basada en microservicios en Google App Engine.
Servicios de App Engine como microservicios
En un proyecto de App Engine, puedes desplegar varios microservicios como servicios independientes, antes conocidos como módulos en App Engine. Estos servicios tienen un aislamiento completo del código. La única forma de ejecutar código en estos servicios es mediante una invocación HTTP, como una solicitud de usuario o una llamada a una API RESTful. El código de un servicio no puede llamar directamente al código de otro servicio. El código se puede desplegar en los servicios de forma independiente y los distintos servicios se pueden escribir en diferentes lenguajes, como Python, Java, Go y PHP. El autoescalado, el balanceo de carga y los tipos de instancias de máquina se gestionan de forma independiente para los servicios.
Versiones de los servicios
Además, cada servicio puede tener varias versiones implementadas simultáneamente. En cada servicio, una de estas versiones es la versión de servicio predeterminada, aunque es posible acceder directamente a cualquier versión implementada de un servicio, ya que cada versión de cada servicio tiene su propia dirección. Esta estructura ofrece multitud de posibilidades, como realizar pruebas de humo de una nueva versión, hacer pruebas A/B entre diferentes versiones y simplificar las operaciones de actualización y restauración. El framework de App Engine proporciona mecanismos para ayudarte con la mayoría de estos elementos. Hablaremos de estos mecanismos con más detalle en las próximas secciones.
Aislamiento de servicios
Aunque están aislados en su mayoría, los servicios comparten algunos recursos de App Engine. Por ejemplo, Cloud Datastore, Memcache y Colas de tareas son recursos compartidos entre los servicios de un proyecto de App Engine. Aunque este uso compartido tiene algunas ventajas, es importante que una aplicación basada en microservicios mantenga el aislamiento de código y datos entre los microservicios. Hay patrones de arquitectura que ayudan a mitigar el uso compartido no deseado. Describiremos estos patrones más adelante en este artículo.
Aislamiento de proyectos
Si no quieres depender de estos patrones para conseguir el aislamiento y quieres que la separación se aplique de forma más formal, puedes usar varios proyectos de App Engine. Usar proyectos en lugar de servicios tiene ventajas e inconvenientes, y debes sopesar los pros y los contras en función de tu situación. A menos que tengas una necesidad específica de una de las ventajas que ofrece el uso de varios proyectos, es mejor que empieces usando varios servicios en un solo proyecto, ya que el rendimiento será mejor y la carga administrativa se minimizará. Por supuesto, también puedes elegir una combinación de ambos enfoques.
Comparación entre el aislamiento de servicios y el aislamiento de proyectos
En la siguiente tabla se comparan el uso de varios servicios y el de varios proyectos en una arquitectura de microservicios:
| Varios servicios | Varios proyectos | |
|---|---|---|
| Aislamiento de código | El código implementado es completamente independiente entre servicios y versiones. | El código implementado es completamente independiente entre proyectos, así como entre servicios y versiones de cada proyecto. |
| Aislamiento de datos |
Cloud Datastore y Memcache se comparten entre servicios y versiones. Sin embargo, los espacios de nombres se pueden usar como patrón de desarrollador para aislar los datos.
Para aislar las colas de tareas, se puede usar una convención de nombres de colas de desarrollador, como user-service-queue-1.
|
Cloud Datastore, Memcache y Colas de tareas son completamente independientes entre proyectos. |
| Aislamiento de registros | Cada servicio (y versión) tiene registros independientes, aunque se pueden ver juntos. | Cada proyecto (y cada servicio y versión de cada proyecto) tiene registros independientes, aunque todos los registros de un proyecto determinado se pueden ver juntos. Los registros de varios proyectos no se pueden ver juntos. |
| Sobrecarga de rendimiento | Los servicios del mismo proyecto se implementan en el mismo centro de datos, por lo que la latencia al llamar a un servicio desde otro mediante HTTP es muy baja. | Los proyectos se pueden desplegar en diferentes centros de datos, por lo que las latencias HTTP pueden ser más altas, aunque siguen siendo bastante bajas porque la red de Google es de primera categoría. |
| Contabilidad de costes | Los costes de las horas de instancia (la CPU y la memoria para ejecutar el código) no se separan por servicios, sino que se agrupan todas las horas de instancia de un proyecto. | Los costes de los distintos proyectos se dividen, lo que permite ver fácilmente el coste de los diferentes microservicios. |
| Permisos de operador | Un operador puede desplegar código, lanzar y revertir versiones, y ver los registros de todos los servicios de un proyecto. No hay forma de limitar el acceso a servicios específicos. | El acceso de los operadores se puede controlar por separado en proyectos independientes. |
| Solicitar traza | Con Google Cloud Trace, puedes ver una solicitud y las solicitudes de microservicios resultantes de los servicios del mismo proyecto como un único rastreo compuesto. Esta función puede ayudarte a optimizar el rendimiento más fácilmente. | Las llamadas de Cloud Trace se pueden visualizar en todos los proyectos de GCP si están en la misma organización. |
Siguientes pasos
- Consulta cómo crear y asignar nombres a entornos de desarrollo, prueba, control de calidad, preproducción y producción con microservicios en App Engine.
- Consulta las prácticas recomendadas para diseñar APIs que permitan la comunicación entre microservicios.
- Consulta las prácticas recomendadas para mejorar el rendimiento de los microservicios.
- Consulta cómo migrar una aplicación monolítica a una con microservicios.
- Determina si los microservicios son la opción ideal para tu situación. En su blog personal, el arquitecto de soluciones de Google Preston Holmes ha publicado una entrada sobre algunos de los inconvenientes que ve en los microservicios.