Aprender estos 5 patrones de microservicios te hará un mejor ingeniero

Para muchos ingenieros, entrar en microservicios puede ser difícil, porque es difícil decidir dónde deben trazarse las líneas. Para mí, el 99% de los servicios pertenecen a una de las cinco categorías, y dividir las responsabilidades de esta manera le permite pensar en cómo diseñar las características mediante servicios de tuberías de forma similar a como lo haría en las secuencias de comandos shell de Unix.

Vamos a hablar por un momento sobre lo que todos los microservicios tienen en común. Eric Evans, el padre de Domain Driven Design, los define de la siguiente manera: "[servicios] que pueden consumir y producir mensajes". ( Https://www.youtube.com/watch?v=yPvef9R3k-M )

Con esto en mente, para cada patrón de servicio, hablaré sobre los tipos de mensajes que se producen o se consumen.

De nuevo, estos mensajes se pueden subdividir en dos categorías: Eventos y Comandos.

Sin embargo, antes de comenzar, y debido a que el contexto es importante, escuché por primera vez sobre estos patrones de microservicio de Matt Walters , el creador del bus de servicio de la biblioteca. Servicebus es una adaptación de Nodo de una popular biblioteca .Net llamada NServiceBus, que fue creada y popularizada por Udi Dahan.

Servicebus le permite escribir fácilmente comandos de send y listen , y publish y subscribe eventos utilizando AMQP como un lenguaje universal, con cargas útiles JSON. Esto significa que otros lenguajes de programación podrían implementar fácilmente las mismas interfaces y ser capaces de participar sin problemas en un sistema compuesto por partes escritas en muchos idiomas.

Si eres un desarrollador de Go, o Python, a quien le gustaría contribuir con esa causa, ¡envíame un mensaje!

Y sin más preámbulos, los 5 patrones de microservicio.

1. Servicios de modelo

Si me viene a la mente MVC, entonces estás en camino con este tipo de servicio. Los servicios de modelo son donde deberían vivir sus modelos. Los límites generalmente se establecen en el nivel Agregado o Entidad, según la complejidad del dominio.

Los servicios de modelo consumen mensajes sobre cosas que son relevantes dentro de su contexto. Por ejemplo, si tiene un Servicio de inventario, algunos mensajes de comando que serían relevantes para consumir serían inventory.product.create o inventory.product.increaseStock . En respuesta, querrá producir algunos mensajes de Evento para que el resto del sistema pueda conocer cómo está cambiando el modelo y responder a esos cambios. Los mensajes de evento producidos en este ejemplo serían inventory.product.created y inventory.product.stockLevelIncreased .

2. Servicios de desnormalización

Los desnormalizadores son exactamente lo que hacen las bases de datos relacionales, excepto para un sistema distribuido. Están uniendo varias fuentes de entrada normalizadas en una estructura de datos legible que un cliente puede consumir.

Por ejemplo, imagine que tiene una aplicación de comercio electrónico. Cuando los niveles de existencias aumentan o disminuyen o están disponibles en su inventario, su aplicación debe saberlo.

Esto significa que con un servicio de desnormalización se suscribirá a los eventos que se emiten desde el servicio de modelo anterior, y si está utilizando MongoDb, utilizando algo así como mangosta para persistir en esa información en una estructura perfecta para que esa aplicación en particular consuma.

Imagínese si sus ingenieros de aplicaciones están usando algo como Meteor con MongoDB; solo tienen inventario en tiempo real de un sistema externo sin tener que escribir una línea de código. ¡Esto también funciona muy bien con RethinkDB emparejado con suscripciones GraphQL!

Si tiene un equipo que necesita datos en Kafka para el trabajo de Big Data, simplemente agregue un servicio de desnormalización de Kafka.

3. Servicios de puerta de enlace

Los Servicios de puerta de enlace se pueden usar de forma muy similar a los Desmalificadores de señalización. Sin embargo, en lugar de conectarse a una base de datos, es una conexión a una API.

Hace poco estuve trabajando con un motor de recomendación, llamado LiftIgniter, con el que nuestro inventario debía estar sincronizado. El servicio se suscribe a los eventos inventory.product.updated e inventory.product.added , y simplemente PUBLICA los datos formateados a los puntos finales apropiados.

Más tarde, se agregó un servicio adicional que escuchó los mismos eventos y, al construir un servicio Magento Gateway, pudimos mantener una tienda de comercio electrónico actualizada con los niveles de inventario cambiantes también.

4. Servicios de Ingestor

Todo lo que hemos hablado hasta ahora es trabajar con datos que se propagan a través del sistema o que se crean en los servicios de Model. Sin embargo, es un requisito frecuente para obtener datos externos EN EL sistema. Conceptualmente, los datos de una fuente externa deben ser ingeridos en el lenguaje universal que habla el resto del sistema. Este es el trabajo de un servicio de ingestor.

Los servicios de Ingestor generalmente solo producen mensajes. Estos servicios generalmente implican recibir un API POST sobre HTTP o ejecutar un trabajo CRON y raspar en un intervalo. Los datos obtenidos o recibidos se publican en el sistema utilizando el lenguaje universal (AMQP w / JSON).

5. Servicios de adaptador

Un servicio de adaptador es un caso de uso más raro, pero vale la pena mencionarlo. De forma similar a un servicio de puerta de enlace, un adaptador consume mensajes y luego utiliza esos datos para invocar una biblioteca en el sistema. Un ejemplo de esto podría ser el uso de una herramienta de manipulación de gráficos como ImageMagick. ImageMagick es una herramienta poderosa, pero no tiene enlaces Node.js. Un servicio de adaptador resuelve esto ejecutando un proceso secundario y luego produciendo mensajes con los resultados, en el lenguaje universal del sistema.

Servicios API

ACTUALIZACIÓN: 12 de enero de 2018
Un día después de publicar este artículo, me di cuenta de que podría haber confusión sobre dónde encajan las API. Por lo tanto, he decidido agregar esta sección y explicar mi razonamiento. Definitivamente son microservicios, pero no son realmente nuevos, y no figuraban en mi lista de cosas nuevas para enseñar.

Los servicios API deben mantenerse livianos. Si está creando una gran cantidad de lógica empresarial en una API, entonces está construyendo un monolito. Es ligeramente mejor que la combinación de una aplicación y un servidor que solíamos ver con arquitecturas "n-tier", pero finalmente lleva a la infame "Big Ball of Mud" o "Spaghetti Code" también.

Para lograr esto, utilice el "Servicio de desnormalización" desde arriba para proyectar una vista de consulta eficiente de los datos en las bases de datos de las que lee la API. Esto crea un flujo de datos unidireccional, o como escuché primero de Matt, un "Sistema Unidireccional".

Sistemas unidireccionales

El uso de estos patrones anteriores le permite trabajar con eventos inmutables en un flujo de trabajo unidireccional. Si te interesa el desarrollo de aplicaciones, sin dudas estarás familiarizado con la forma en que Redux ha cambiado el juego para la administración estatal. Tener una tienda con estado que rastrea el árbol de componentes le permite razonar fácilmente sobre cómo las acciones afectan el estado porque son simples hechos inmutables que ocurren en una ubicación centralizada.

Si sigue los patrones anteriores, usará lo que a veces se denomina de manera más complicada Segregación de responsabilidad de consulta de comando o CQRS. Comandos son consumidos por los Servicios de modelo, y se producen eventos que son consumidos por Denormalizer o Gateway Services, que actualizan los modelos de lectura. Las consultas se hacen contra el modelo de lectura.

Debido a que está utilizando mensajes inmutables, esto hace que Event Sourcing sea el patrón perfecto para desarrollar sus servicios de Model. Otra creación de Matt Walters que vale la pena consultar, es un micro-framework llamado [fuente] ( https://github.com/mateodelnorte/source ) que funciona perfectamente en armonía con el bus de servicio, para agregar fácilmente capacidades de Event Sourcing para consumir los eventos de su servicio. , y persistirlos a una base de datos.

Conclusión

Finalmente, vale la pena mencionar que con la simplicidad de los servicios, cierta complejidad se traslada necesariamente a la arquitectura. Espero haberle proporcionado una forma de construir mentalmente sistemas de microservicio en su cabeza con algunos bloques genéricos de lego.

Si no ha leído mi otro artículo, " Las 10 piezas de rompecabezas de una arquitectura de microservicio efectiva " ¡lea eso también! Cubre los componentes que hacen una arquitectura de microservicio.

Si desea omitir la parte en la que pasa meses aprendiendo a configurarlo todo usted mismo, estoy preparando un curso web que le mostrará cómo sistematé el proceso y codificado el sistema para que pueda estar activo y en funcionamiento. ¡y eficiente con Microservicios en el menor tiempo posible! Regístrese ahora para obtener acceso antes que los demás. ¡Visita Microservice Driven para obtener información!

¡Gracias por leer! Si me sigues y me das 50 aplausos, ¡realmente me ayudaría a llegar a más personas! Haga clic y #HODL el botón de aplaudir a continuación;)

Si desea ponerse en contacto, puede enviarme un mensaje en LinkedIn o Twitter .