El trabajo del arquitecto es proporcionar el andamiaje contra el cual los desarrolladores construirán su código para que todas las piezas de la aplicación encajen.
Al construir una arquitectura de microservicios, el arquitecto de un proyecto se centra en tres tareas clave:
- Descomposición el problema
- Establecer la granularidad del servicio
- Definición de las interfaces de servicio
Descomposición el problema : Frente a la complejidad, la mayoría de las personas intenta dividir el problema en el que están trabajando en partes manejables. Hacen esto para no tener que tratar de encajar todos los detalles del problema en sus cabezas. En cambio, desglosan el problema de manera abstracta en algunas partes clave y luego buscan las relaciones que existen entre estas partes.
En una arquitectura de microservicios, el arquitecto divide el problema empresarial en fragmentos que representan dominios de actividad discretos. Estos fragmentos encapsulan las reglas comerciales y la lógica de datos asociada con una parte particular del dominio comercial.
Aunque desea que los microservicios encapsulen todas las reglas comerciales para realizar una sola transacción, esto no siempre es factible. A menudo, tendrá situaciones en las que necesitará grupos de microservicios que trabajen en diferentes partes del dominio empresarial para completar una transacción completa. Un arquitecto separa los límites de servicio de un conjunto de microservicios al observar dónde el dominio de datos no parece encajar.
Por ejemplo, un arquitecto puede mirar un flujo de negocios que se llevará a cabo mediante código y darse cuenta de que necesita información tanto del cliente como del producto. La presencia de dos dominios de datos discretos es una buena indicación de que hay varios microservicios en juego. La forma en que interactúan las dos partes diferentes de la transacción comercial generalmente se convierte en la interfaz de servicio para los microservicios.
Separar un dominio empresarial es una forma de arte más que una ciencia en blanco y negro. Se pueden utilizar las siguientes pautas para identificar y descomponer un problema empresarial en candidatos a microservicio:
- Describe el problema empresarial y escucha los sustantivos que usas para describir el problema. El uso de los mismos sustantivos una y otra vez al describir el problema suele ser una indicación de un dominio empresarial central y una oportunidad para un microservicio.
- Presta atención a los verbos. Los verbos resaltan acciones y, a menudo, representan los contornos naturales del dominio de un problema. Si se encuentra diciendo "la transacción X necesita obtener datos de la cosa A y la cosa B", eso generalmente indica que hay varios servicios en juego.
- Busque la cohesión de datos. A medida que divide su problema comercial en partes discretas, busque piezas de datos que estén muy relacionadas entre sí. Si de repente, durante el curso de su conversación, está leyendo o actualizando datos que son radicalmente diferentes de los que ha estado discutiendo hasta ahora, es posible que tenga otro candidato de servicio. Los microservicios deben poseer completamente sus datos.
Establecer la granularidad del servicio : Una vez que tenga un modelo de datos simplificado, podemos comenzar el proceso de definir qué microservicios necesitará en la aplicación.
El objetivo es tomar estas piezas importantes de funcionalidad y extraerlas en unidades completamente autónomas que se pueden construir e implementar independientemente de cada una. Pero extraer servicios del modelo de datos implica más que volver a empaquetar el código en proyectos separados. También se trata de extraer las tablas de la base de datos real a las que acceden los servicios y permitir que solo cada servicio individual acceda a las tablas en su dominio específico.
Después de haber dividido un dominio problemático en partes discretas, a menudo nos encontraremos luchando para determinar si hemos logrado el nivel correcto de granularidad para los servicios. Un microservicio que sea demasiado burdo o detallado tendrá una serie de atributos reveladores.
Cuando crea una arquitectura de microservicio, la cuestión de la granularidad es importante, pero puede usar los siguientes conceptos para determinar la solución correcta:
- Es mejor comenzar ampliamente con microservicio y refactorizar a servicios más pequeños. Es fácil exagerar cuando comienza su viaje de microservicio y convierte todo en un microservicio. Pero descomponer el dominio del problema en pequeños servicios a menudo conduce a una complejidad prematura porque los microservicios se convierten en nada más que servicios de datos detallados.
- Concéntrese primero en cómo interactuarán sus servicios entre sí: esto ayudará a establecer las interfaces generales de su dominio de problemas. Es más fácil refactorizar de un grano demasiado grueso a un grano demasiado fino.
- Las responsabilidades del servicio cambiarán con el tiempo a medida que aumente su comprensión del dominio del problema. A menudo, un microservicio adquiere responsabilidades como una nueva aplicación se solicita funcionalidad. Lo que comienza como un único microservicio puede convertirse en varios servicios, con el microservicio original actuando como una orquestación.
Definición de las interfaces de servicio: La última parte se trata de definir cómo los microservicios en su aplicación se comunicarán entre sí. Al construir lógica de negocios con microservicios, las interfaces para los servicios deben ser intuitivas y los desarrolladores deben conocer el ritmo de cómo funcionan todos los servicios en la aplicación aprendiendo uno o dos de los servicios en la aplicación.
En general, las siguientes pautas se pueden utilizar para pensar en el diseño de la interfaz de servicio:
- Adopte la filosofía REST: el enfoque REST de los servicios es fundamentalmente la adopción de HTTP como el protocolo de invocación para los servicios y el uso de verbos HTTP estándar (GET, PUT, POST y DELETE). Modele sus comportamientos básicos en torno a estos verbos HTTP.
- Use URI para comunicar la intención: el URI que usa como end-points para el servicio debe describir los diferentes recursos en su dominio de problemas y proporcionar un mecanismo básico para las relaciones de recursos dentro de su dominio de problemas.
- Use JSON para sus solicitudes y respuestas: la notación de objetos JavaScript (en otras palabras, JSON) es un protocolo de serialización de datos extremadamente liviano y es mucho más fácil de consumir que XML.
- Utilice códigos de estado HTTP para comunicar los resultados: el protocolo HTTP tiene una gran cantidad de códigos de respuesta estándar para indicar el éxito o el fracaso de un servicio. Aprender estos códigos de estado y, lo que es más importante, utilícelos de forma coherente en todos sus servicios.
Todas las pautas básicas conducen a una sola cosa: hacer que sus interfaces de servicio sean fáciles de entender y consumibles. Quiere que un desarrollador se siente y observe las interfaces de servicio y comience a usarlas. Si un microservicio no es fácil de consumir, los desarrolladores harán todo lo posible para solucionarlo y subvertir la intención de la arquitectura.
