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 independientes, que antes se conocían 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 servicios de forma independiente, y servicios distintos se pueden escribir en diferentes lenguajes, como Python, Java, Go y PHP. El ajuste de escala automático, el balanceo de cargas y los tipos de instancia de máquina se administran de manera independiente para los 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.
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.
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 implementar 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
- Aprende a crear y asignar nombres a los entornos de desarrollo, prueba, control de calidad, etapa de pruebas y producción con microservicios en App Engine.
- Conoce las recomendaciones para diseñar API que se comuniquen entre microservicios.
- Conoce las recomendaciones relativas al rendimiento de los microservicios.
- Obtén información sobre cómo migrar una aplicación monolítica existente a otra que emplee microservicios.
- Comprende si los microservicios son ideales en tu caso. En su blog personal, Preston Holmes, el arquitecto de soluciones de Google, publicó una entrada sobre ciertas desventajas que detecta en los microservicios.