Arquitectura de microservicios en Google App Engine

Los microservicios son un estilo de arquitectura para compilar aplicaciones. Permiten dividir una aplicación grande en partes constituyentes independientes y que cada una de ellas tenga su propio ámbito de responsabilidad. Una aplicación basada en microservicios puede llamar a muchos microservicios internos para generar su respuesta con la finalidad de entregar a un solo usuario o a una solicitud de API.

Una aplicación correctamente implementada y basada en microservicios puede lograr los objetivos siguientes:

  • Definir contratos sólidos entre los diversos microservicios.
  • Permitir ciclos de implementación independientes, incluida la reversión.
  • Facilitar pruebas de actualización simultáneas y A/B en subsistemas.
  • Reducir al mínimo la automatización de pruebas y la sobrecarga de garantía de calidad.
  • Mejorar la claridad de los registros y la supervisión.
  • Proporcionar contabilidad de costos detallada.
  • Aumentar la escalabilidad y confiabilidad de la aplicación en general.

Google App Engine cuenta con algunas características adecuadas para una aplicación basada en microservicios. En esta página se describen las recomendaciones de uso cuando implementas 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 implementar varios microservicios como servicios separados, que solían conocerse como módulos en App Engine. Estos servicios tienen aislamiento total de código; la única forma de ejecutar un código en estos servicios es a través de una invocación HTTP, como una solicitud de usuario o una llamada a la API de RESTful. Un código en un servicio no puede llamar directamente al código en otro servicio. El código se puede implementar en los servicios de manera independiente y los diferentes servicios se pueden escribir en distintos lenguajes, como Python, Java, Go y PHP. Los tipos de instancias de ajuste de escala automático, balanceo de cargas y máquina se administran de forma independiente para los servicios.

Un proyecto de App Engine logra la separación mediante el uso de servicios.

Versiones en los servicios

Además, cada servicio puede tener varias versiones implementadas en simultáneo. Una de estas versiones es la predeterminada, aunque es posible acceder de forma directa a cualquier versión implementada de un servicio, ya que cada versión tiene su propia dirección. Esta estructura abre innumerables posibilidades, incluidas pruebas de humo de una versión nueva, pruebas A/B entre diferentes versiones y operaciones simplificadas de avance y reversión. El marco de trabajo de App Engine proporciona mecanismos para ayudar con la mayoría de estos elementos. Examinaremos estos mecanismos con más detalle en las próximas secciones.

Un proyecto de App Engine puede tener servicios y versiones.

Aislamiento de servicios

Aunque en su mayoría están aislados, los servicios comparten algunos recursos de App Engine. Por ejemplo, Cloud Datastore, Memcache y las listas de tareas en cola son recursos compartidos entre servicios en un proyecto de App Engine. Si bien este intercambio presenta 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 los intercambios no deseados. Se describirán estos patrones más adelante en este artículo.

Los proyectos de App Engine comparten servicios.

Aislamiento de proyectos

Si no deseas depender de estos patrones para lograr el aislamiento y quieres aplicar una separación más formal, puedes utilizar varios proyectos de App Engine. El uso de proyectos en lugar de servicios presenta ventajas y desventajas, que debes equilibrar en función de tu situación. A menos que necesites aprovechar específicamente una de las ventajas que ofrece el uso de varios proyectos, conviene que comiences con varios servicios dentro de un solo proyecto porque el rendimiento será mejor y se reducirá la sobrecarga administrativa. Por supuesto, también puedes elegir un híbrido entre los dos enfoques.

Aislamiento de servicios frente a aislamiento de proyectos

En la tabla siguiente, se muestra una comparación entre el uso de varios servicios y 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 los proyectos, y entre los servicios y las 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 un patrón de desarrollador para aislar los datos. Para el aislamiento de una lista de tareas en cola, se puede emplear una convención de desarrollador de nombres en cola, como user-service-queue-1. Cloud Datastore, Memcache y las listas de tareas en cola son completamente independientes entre proyectos.
Aislamiento de registros Cada servicio (y versión) tiene registros independientes, aunque se pueden visualizar juntos. Cada proyecto (y el servicio y la versión de cada proyecto) tiene registros independientes, aunque todos los registros de un proyecto determinado se pueden visualizar juntos. Los registros de varios proyectos no se pueden visualizar juntos.
Sobrecarga de rendimiento Los servicios del mismo proyecto se implementan en el mismo centro de datos, por lo que la latencia que llama a un servicio desde otro mediante HTTP es muy baja. Los proyectos podrían implementarse en diferentes centros de datos, por lo que las latencias HTTP pueden ser más altas (aunque seguirán siendo bastante bajas, ya que la red de Google es de primer nivel).
Contabilidad de costos Los costos por horas de instancia (la CPU y la memoria para ejecutar tu código) no se separan por servicios. Todas las horas de instancia para un proyecto completo se agrupan juntas. Los costos para diferentes proyectos se dividen, lo que hace que sea muy fácil ver el costo de diferentes microservicios.
Permisos de operador Un operador tiene la capacidad de implementar código, de avanzar y revertir versiones, y de ver los registros de todos los servicios de un proyecto. No hay forma de limitar el acceso a servicios específicos. El acceso del operador se puede controlar por separado en proyectos distintos.
Seguimiento de solicitudes Si utilizas Google Cloud Trace, puedes ver una solicitud y las solicitudes de microservicios resultantes para otros servicios del mismo proyecto como un solo seguimiento compuesto. Esta característica puede facilitar el ajuste del rendimiento. Las llamadas de Cloud Trace se pueden visualizar en los proyectos de GCP si están dentro de la misma organización.

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Entorno estándar de App Engine para Java 8