Microservices_designing_deploying.en.es

Del diseño a la implementación

01

Del diseño a la implementación por Chris Richardson con Floyd Smith

© Nginx, Inc. 2016 02

Tabla de contenido

1

Prefacio

iii

Introducción a microservicios

1

La construcción de las aplicaciones monolíticas

1

Marchando hacia monolítico Infierno

3

Microservicios - Abordar la complejidad

4

Los beneficios de microservicios

8

Los inconvenientes de microservicios

9

Resumen

11

Microservicios en Acción: Nginx Plus como un servidor proxy inverso 11

2

3

12

El uso de una API de puerta de enlace

Introducción

12

Directa entre cliente y Microservice Comunicación

15

El uso de una API de puerta de enlace

15

Ventajas y desventajas de una API de puerta de enlace

17

La implementación de una puerta de enlace de la API

17

Rendimiento y escalabilidad

17

Utilizando un modelo de programación reactiva

18

La invocación de servicios

18

Descubrimiento de servicio

19

Gestión de Fallos parciales

19

Resumen

20

Microservicios en Acción: Nginx Plus como una API de puerta de enlace

20

La comunicación entre procesos

21

Introducción

21

Estilos de interacción

22

La definición de las API

24

API Evolving

24

Manipulación del fracaso parcial

25

IPC Tecnologías

26

Asíncrono, la comunicación de mensajes basado en

26

Sincrónica, Solicitud / Respuesta IPC

29

DESCANSO

29

Ahorro

31

formatos de los mensajes

31

Resumen

32

Microservicios en Acción: Nginx y Arquitectura de aplicaciones

33

yo

4

5

Descubrimiento de servicio

34

¿Por qué utilizar descubrimiento de servicios?

34

El patrón de descubrimiento del lado del cliente

35

El patrón de descubrimiento del lado del servidor

37

El Service Registry

38

Opciones de servicio de registro

39

El patrón de registro automático

39

El patrón de registro de terceros

41

Resumen

42

Microservicios en Acción: Nginx Flexibilidad

43

Gestión de datos controlada por eventos de microservicios

44

Microservicios y el problema de gestión de datos distribuidos 44

6

Arquitectura dirigido por eventos

47

El logro de atomicidad

50

La publicación de eventos utilizando las transacciones locales

50

La minería una base de datos de registro de transacciones

51

El uso de Abastecimiento de eventos

52

Resumen

54

Microservicios en Acción: Nginx y Optimización de Almacenamiento

54

Elección de una estrategia de implementación de microservicios

55

motivaciones

55

Varias instancias de servicio por patrón anfitrión

56

Instancia de servicio por patrón anfitrión

58

Instancia de servicio por patrón Virtual Machine

58

Instancia de servicio por patrón de contenedores

60

despliegue sin servidor

62

Resumen

63

Microservicios en Acción: Implementación de microservicios Across La

7

variación de los ejércitos con Nginx

63

Refactorización un monolito en microservicios

64

Visión general de Refactoring a microservicios

sesenta y cinco

Estrategia # 1: dejar de cavar

66

Estrategia # 2: Split y del servidor

67

Estrategia # 3: Extracto de Servicios

69

Priorizar módulos que convertir en Servicios

69

Cómo extraer un módulo

69

Resumen

71

Microservicios en Acción: La doma de un monolito con Nginx

72

Los recursos para microservicios y Nginx

73

ii

Prefacio por Floyd Smith

El aumento de microservicios ha habido un notable avance en el desarrollo y despliegue de aplicaciones Con microservicios, se desarrolla una aplicación, o reprogramado, en diversos servicios diferentes que “hablan” entre sí de una manera bien definida - a través de las API, por ejemplo. Cada microService es autónomo, cada uno mantiene su propio almacén de datos (que tiene implicaciones significativas), y cada uno se puede actualizar de forma independiente de los demás.

Pasar a un enfoque basado microservicios-hace que el desarrollo de aplicaciones más rápido y más fácil de manejar, lo que requiere un menor número de personas para implementar más características nuevas. Se pueden hacer cambios y se despliegan más rápido y más fácil. Una aplicación diseñada como una colección de microservicios es más fácil de ejecutar en varios servidores con equilibrio de carga, por lo que es fácil de manejar los picos de demanda y un aumento constante de la demanda con el tiempo, al tiempo que reduce el tiempo de inactividad causado por problemas de hardware o software.

Microservicios son una parte crítica de una serie de avances significativos que están cambiando la naturaleza de la forma en que trabajamos. técnicas de desarrollo de software ágil, aplicaciones a la nube, la cultura DevOps, integración continua y el despliegue continua (CI / CD), y el uso de contenedores que se mueven están siendo utilizados junto microservicios para revolucionar el desarrollo de aplicaciones y la entrega

software de Nginx está fuertemente asociado con microservicios y todas las tecnologías mencionadas anteriormente. Ya sea desplegado como un proxy inverso, o como un servidor web altamente eficiente, Nginx hace que las soluciones basadas en microservicios microservicios basada en el desarrollo de aplicaciones más sencillas y sigue funcionando sin problemas

Con el empate entre Nginx y microservicios siendo tan fuerte, nos hemos quedado una serie de siete partes en microservicios en el sitio web Nginx Escrito por Chris Richardson, que ha tenido una participación temprana con el concepto y su aplicación, las entradas del blog cubren los principales aspectos de microservicios para el diseño y desarrollo de aplicaciones, incluyendo la forma de hacer el movimiento desde una aplicación monolítica. Las entradas de blog ofrecen una visión completa de las principales cuestiones microservicios y han sido muy populares.

iii

En este libro electrónico, nos hemos convertido cada entrada del blog a un capítulo de un libro, y hemos añadido una barra lateral a cada capítulo con la información pertinente para la aplicación de microservicios en Nginx. Si usted sigue el consejo en este documento con cuidado, usted va a resolver muchos problemas de desarrollo potencial, incluso antes de empezar a escribir código. Este libro es también un buen complemento de la Arquitectura de referencia microservicios Nginx , Que implementa la mayor parte de la teoría presentada aquí Los capítulos de libros son:

1. Introducción a la microservicios - Una introducción clara y simple de microservicios, desde su definición conceptual quizá sobrevalorado a la realidad de cómo microservicios se despliegan en la creación y mantenimiento de aplicaciones 2. Uso de una puerta de enlace API - Una API Gateway es el único punto de entrada para su aplicación basada en microservicios enteras, presentando la API para cada microService. Nginx Plus efectivamente se puede utilizar como una API Gateway con equilibrio de carga, almacenamiento en caché de archivos estáticos, y más

3. Comunicación entre procesos en una Arquitectura microservicios - Una vez que se rompe una aplicación monolítica en piezas separadas - microservicios - las piezas necesitan hablar el uno al otro. Y resulta que usted tiene muchas opciones para la comunicación entre procesos, incluida la transferencia de estado representacional (REST). En este capítulo se proporcionan los detalles

4. servicio de reconocimiento en una Arquitectura microservicios - Cuando los servicios se están ejecutando en un entorno dinámico, la búsqueda de ellos cuando los necesite, no es un asunto trivial. En este capítulo, Chris describe una solución práctica a este problema 5. Gestión de datos dirigido por eventos de microservicios - En lugar de compartir un almacén unificado en toda la aplicación de datos (o dos) a través de una aplicación monolítica, cada microService mantiene su propia representación única de datos y almacenamiento Esto le da una gran flexibilidad, pero también puede causar la complejidad, y este capítulo que ayuda a clasificar a través de él .

6. Elección de una estrategia de implementación de microservicios - En un mundo DevOps, cómo hacer las cosas es tan importante como lo que se propuso hacer en el primer lugar. Chris se describen las principales pautas de implementación microservicios para que pueda tomar una decisión informada para su propia aplicación.

7. Refactorizando un monolito en microservicios - En un mundo perfecto, siempre se pueden conseguir el tiempo y dinero para convertir el software de núcleo en las últimas y mejores tecnologías, herramientas y enfoques, sin plazos reales. Pero es muy posible que se encuentre la conversión de un monolito en microservicios, una pequeña ... ... ... ... al pedazo una vez que Chris ... presenta una estrategia para hacer esto con sensatez.

Creemos que encontrará todos los capítulos de mérito, y esperamos que va a volver a este libro electrónico a medida que desarrolle sus propias aplicaciones microservicios Floyd Smith Nginx, Inc

iv

1

Introducción a microservicios

Microservicios están actualmente recibiendo mucha atención: artículos, blogs, debates en los medios sociales, conferencias y presentaciones. Se dirigen rápidamente hacia el pico de expectativas infladas sobre la Gartner ciclo de bombo Al mismo tiempo, hay escépticos en la comunidad de software que desechan microservicios como nada nuevo. Los pesimistas afirman que la idea es sólo un cambio de nombre de la arquitectura orientada al servicio (SOA). Sin embargo, a pesar de tanto el bombo y el escepticismo, la microservicios patrón de Arquitectura tiene importantes beneficios - especialmente cuando se trata de permitir el desarrollo ágil y la entrega de aplicaciones empresariales complejas

Este capítulo es el primero de este siete capítulos de libros electrónicos sobre el diseño, la construcción y el despliegue de microservicios usted aprenderá sobre el enfoque microservicios y cómo se compara con los más tradicionales Modelo de la configuración monolítica Este libro se describen los distintos elementos de una arquitectura microservicios. Usted aprenderá acerca de las ventajas e inconvenientes de la pauta microservicios Arquitectura, si tiene sentido para su proyecto, y cómo aplicarlo.

Primero vamos a ver por qué usted debe considerar el uso de microservicios.

La construcción de las aplicaciones monolíticas Imaginemos que usted comenzaba a construir una nueva aplicación taxi que graniza marca destinada a competir con Uber y Hailo. Después de algunas reuniones y requisitos preliminares recopilación, debe crear un nuevo proyecto, ya sea de forma manual o mediante el uso de un generador que viene con una plataforma como rieles, primavera de arranque, reproducir o Maven.

Microservicios - Del diseño a la implementación de

1

Ch. 1 - Introducción a la microservicios

Esta nueva aplicación tendría un sistema modular arquitectura hexagonal , Como en la Figura 1-1:

MYSQL

Monolithic Architecture

MYSQL ADAPTER PASSENGER

DRIVER

REST API

TWILIO ADAPTER PASSENGER MANAGEMENT YOURBANK 0000 0000 0000 0000 00/00

NOMBRE

TU

00/00

YOUR NAME

BILLING

WEB UI

NOTIFICATION PAYMENTS

DRIVER TRIP MANAGEMENT MANAGEMENT

SENDGRID ADAPTER

STRIPE ADAPTER

La Figura 1-1. Una aplicación de ejemplo de taxi que graniza.

En el núcleo de la aplicación es la lógica de negocio, que se implementa mediante módulos que definen servicios, objetos de dominio, y eventos. Rodeando el núcleo se adaptadores que interactúan con el mundo externo. Los ejemplos de adaptadores incluyen componentes de base de datos de acceso, componentes de mensajería que producen y consumen mensajes, y componentes web que, o bien exponer las API o implementar una interfaz de usuario

Microservicios - Del diseño a la implementación de

2

Ch. 1 - Introducción a la microservicios

A pesar de tener una arquitectura lógica modular, la aplicación se empaqueta y se implementa como un monolito. El formato real depende de la lengua y el marco de la aplicación. Por ejemplo, muchas aplicaciones Java se empaquetan como archivos WAR y desplegados en servidores de aplicaciones tales como Tomcat o embarcadero. Otras aplicaciones Java se empaquetan como archivos JAR ejecutables autónomos. Del mismo modo, los carriles y Node.js aplicaciones se empaquetan como una jerarquía de directorios

Las aplicaciones escritas en este estilo son extremadamente comunes Son fáciles de desarrollar ya que nuestros entornos de desarrollo y otras herramientas se centran en la construcción de una sola aplicación. Este tipo de aplicaciones también son fáciles de probar. Puede implementar pruebas de extremo a extremo con sólo iniciar la aplicación y comprobación de la interfaz de usuario con un paquete de pruebas tales como las aplicaciones monolíticas selenio también son fáciles de implementar Sólo tienes que copiar el paquete de aplicaciones a un servidor También puede escalar la aplicación por parte la ejecución de múltiples copias detrás de un equilibrador de carga. En las primeras etapas del proyecto que funciona bien.

Marchando hacia monolítico Infierno Por desgracia, este enfoque simple tiene una gran limitación. aplicaciones exitosas tienen un hábito de crecimiento con el tiempo y el tiempo convertirse en enormes. Durante cada sprint, el equipo de desarrollo implementa algunas más historias de usuarios, los cuales, por supuesto, significa agregar muchas líneas de código. Al cabo de unos años, su, pequeña aplicación sencilla se habrá convertido en una monolito monstruosa Para dar un ejemplo extremo, Hace poco hablé con un desarrollador que estaba escribiendo una herramienta para analizar las dependencias entre los miles de frascos en sus varios millones de líneas de código de la aplicación (LOC). Estoy seguro de que tomó el esfuerzo concertado de un gran número de desarrolladores lo largo de muchos años para crear una bestia. Una vez que su aplicación se ha convertido en un monolito grande y complejo, su organización de desarrollo es, probablemente, en un mundo de dolor. Cualquier intento de desarrollo ágil y entrega fracasarán. Un problema importante es que la aplicación es abrumadoramente compleja. Es simplemente demasiado grande para cualquier desarrollador individual para comprender plenamente. Como resultado, corrigiendo errores e implementación de nuevas características se hace correctamente difícil y lleva mucho tiempo. Lo que es más, esto tiende a ser una espiral hacia abajo. Si el código base es difícil de entender, gran bola de barro

El tamaño de la aplicación también se ralentizará el desarrollo. Cuanto mayor sea la aplicación, mayor será el tiempo de puesta en marcha es lo encuestados los desarrolladores sobre el tamaño y el rendimiento de sus aplicaciones monolíticas, y algunas veces de puesta en marcha reportados hasta 12 minutos. También he oído anécdotas de aplicaciones que toman hasta 40 minutos para la puesta en marcha. Si los desarrolladores tienen regularmente para reiniciar el servidor de aplicaciones, a continuación, una gran parte de su día será gastado esperando alrededor y su productividad se verá afectada. Otro problema con una aplicación monolítica grande y complejo es que es un obstáculo para el despliegue continuo. Hoy en día, el estado de la técnica de las aplicaciones SaaS es empujar los cambios en la producción muchas veces al día. Esto es extremadamente difícil de hacer con un monolito compleja,

Microservicios - Del diseño a la implementación de

3

Ch. 1 - Introducción a la microservicios

ya que debe volver a desplegar toda la aplicación con el fin de actualizar cualquier parte de ella. Los largos tiempos de puesta en marcha que he mencionado anteriormente no ayuda tampoco Además, dado que el impacto de un cambio no suele ser muy bien entendida, es probable que usted tiene que hacer una amplia prueba manual En consecuencia, el despliegue continuo es casi imposible qué aplicaciones monolíticas también pueden ser difíciles de escala cuando los diferentes módulos tienen necesidades de recursos conflictivos por ejemplo, un módulo podría implementar la lógica de procesamiento de imágenes intensivo de la CPU y lo ideal sería ser desplegado en Amazon instancias EC2 Compute optimizados . Otro módulo podría ser una base de datos en la memoria y el más adecuado para casos optimizadas-Memory EC2 Sin embargo, debido a que estos módulos se despliegan juntos, usted tiene que comprometer en la elección del hardware.

Otro problema con las aplicaciones monolíticas es la fiabilidad Debido a que todos los módulos están funcionando dentro del mismo proceso, un error en cualquiera de los módulos, tales como pérdida de memoria, potencialmente puede derribar todo el proceso. Además, dado que todas las instancias de la aplicación son idénticas, ese error afectará a la disponibilidad de toda la aplicación.

Por último, pero no menos importante, las aplicaciones monolíticas hacen extremadamente difícil la adopción de nuevos marcos y lenguajes. Por ejemplo, imaginemos que usted tiene 2 millones de líneas de código escritas utilizando el marco de XYZ. Sería muy costoso (en tiempo y costo) para volver a escribir toda la aplicación para utilizar el marco ABC más nuevo, incluso si ese marco era considerablemente mejor Como resultado, hay una enorme barrera para la adopción de nuevas tecnologías le pegan con cualquier tecnología elecciones realizadas al inicio del proyecto. Para resumir: si tiene una aplicación crítica para el negocio exitoso que ha crecido hasta convertirse en un monolito monstruosa que muy pocos, en su caso, los desarrolladores a entender. Está escrito usando tecnología obsoleta, improductiva que hace que la contratación de desarrolladores con talento difícil. La aplicación es difícil de escalar y no es fiable. Como resultado,

Entonces, ¿qué puede hacer usted al respecto?

Microservicios - Abordar la complejidad Muchas organizaciones, como Amazon, eBay y Netflix , Han resuelto este problema mediante la adopción de lo que ahora se conoce como el microservicios patrón de Arquitectura . En lugar de construir una sola aplicación monstruosa, monolítica, la idea es dividir la aplicación en conjunto de servicios más pequeños, interconectados

Un servicio típicamente implementa un conjunto de características o funciones distintas, tales como la gestión de pedidos, gestión de clientes, etc Cada microService es un mini-aplicación que tiene su propia arquitectura hexagonal que consiste en la lógica de negocio, junto con diversos adaptadores. Algunos microservicios expondrían a una API que se consume por otros microservicios o por los clientes de la aplicación Otras microservicios podrían implementar una interfaz de usuario web En tiempo de ejecución, cada instancia es a menudo una máquina nube virtual (VM) o un recipiente estibador.

Microservicios - Del diseño a la implementación de

4

Ch. 1 - Introducción a la microservicios

Por ejemplo, una posible descomposición del sistema descrito anteriormente se muestra en la Figura 1-2:

STRIPE ADAPTER

API GATEWAY

REST API

PASSENGER MANAGEMENT

REST API

BILLING

YOURBANK 0000 0000 0000 0000 00/00

NOMBRE

TU

00/00

YOUR NAME

REST API PASSENGER DRIVER Figure 1-2. A monolithic application decomposed intoMANAGEMENT microservices. WEB UI

REST API

PAYMENTS

TWILIO ADAPTER

DRIVER WEB UI

REST API

TRIP MANAGEMENT

REST API

NOTIFICATION

SENDGRID ADAPTER

La Figura 1-2. Una aplicación monolítica descompone en microservicios.

Cada área funcional de la aplicación ahora se implementa su propio microService. Por otra parte, la aplicación web se divide en un conjunto de aplicaciones web más simples - como uno de los pasajeros y uno de los conductores, en nuestro ejemplo de taxi que graniza. Esto hace que sea más fácil de desplegar experiencias distintas para usuarios específicos, dispositivos o casos de uso especializados. Cada servicio de back-end expone una API REST y la mayoría de los servicios de consumir API proporcionadas por otros servicios. Por ejemplo, la administración de controladores utiliza el servidor de notificación a decirle a un controlador disponible de un viaje potencial Los servicios de interfaz de usuario invocan los otros servicios con el fin de hacer que las páginas Web Services también podría utilizar asíncrono, la comunicación La comunicación entre el servicio basado en mensajes serán cubiertos en mas detalle más adelante en este libro electrónico

Microservicios - Del diseño a la implementación de

5

Ch. 1 - Introducción a la microservicios

Algunas API REST también están expuestos a las aplicaciones móviles utilizados por los conductores y pasajeros Las aplicaciones no obstante, tener acceso directo a los servicios de back-end En su lugar, la comunicación está mediada por un intermediario conocido como Puerta de enlace de la API La API Gateway es responsable de tareas tales como el equilibrio de carga, almacenamiento en caché, control de acceso, la medición de la API, y el seguimiento y la se puede implementar de manera efectiva el uso de Nginx Capítulo 2 discute la puerta de enlace API en detalle

Za Sc xis ale - d by ata sp pa lit rti tin tio g s nin im g ila rt hin

gs

Y axis functional decomposition Scale by splitting different things

X axis - horizontal duplication Scale by cloning

La Figura 1-3. El Cubo de escala, que se utiliza tanto en el desarrollo y la entrega.

El patrón microservicios Arquitectura corresponde a la escala del eje Y de la Cubo escala , Que es un modelo 3D de la escalabilidad del excelente libro El arte de la escalabilidad Los otros dos ejes de escala son de escala del eje X, que consiste en la ejecución de múltiples copias idénticas de la aplicación detrás de un equilibrador de carga, y la escala del eje Z (o partición de datos), donde un atributo de la solicitud (por ejemplo, la clave primaria de una fila o la identidad de un cliente) se utiliza para encaminar la petición a un servidor en particular

Las aplicaciones suelen utilizar los tres tipos de escalado juntos. de escala del eje Y se descompone la aplicación en microservicios como se muestra arriba en Figura 1-2

Microservicios - Del diseño a la implementación de

6

Ch. 1 - Introducción a la microservicios

En tiempo de ejecución, la escala del eje X se ejecuta varias instancias de cada servicio detrás de un equilibrador de carga para el rendimiento y la disponibilidad. Algunas aplicaciones también pueden utilizar el escalamiento del eje Z para dividir los servicios de la Figura 1-4 muestra cómo el servicio de administración de viaje podría ser desplegado con estibador que se ejecuta en Amazon EC2

LOAD BALANCER

EC2 INSTANCE DOCKER CONTAINER

REST API

TRIP MANAGEMENT

DOCKER CONTAINER

EC2 INSTANCE

REST API

DOCKER CONTAINER

TRIP MANAGEMENT

REST API

DOCKER CONTAINER

TRIP MANAGEMENT

La Figura 1-4. Desplegar el servicio de administración de viaje utilizando estibador.

En tiempo de ejecución, el servicio de administración de viaje consiste en múltiples instancias de servicio. Cada instancia de servicio es un contenedor Docker Con el fin de ser altamente disponible, los contenedores se están ejecutando en múltiples máquinas virtuales de la nube. En frente de las instancias de servicio es una equilibrador de carga tales como NGINX que distribuye las solicitudes en todos los casos el equilibrador de carga también puede manejar otras preocupaciones tales como almacenamiento en caché , control de acceso , medición de la API y vigilancia

El patrón microservicios Arquitectura impacta significativamente en la relación entre la aplicación y la base de datos en lugar de compartir un único esquema de base de datos con otros servicios, cada servicio tiene su propio esquema de base de datos Por un lado, este enfoque está en desacuerdo con la idea de una gran empresa modelo de datos. Además, a menudo resulta en la duplicación de algunos datos. Sin embargo, tener un esquema de base de datos por servicio es esencial si se desea beneficiarse de microservicios, ya que asegura el acoplamiento débil. La Figura 1-5 muestra la arquitectura de base de datos para la aplicación de ejemplo.

Cada uno de los servicios tiene su propia base de datos. Por otra parte, un servicio puede usar un tipo de base de datos que mejor se adapte a sus necesidades, la llamada arquitectura persistencia políglota Por ejemplo, la administración de controladores, que encuentra los conductores cerca de un pasajero potencial, debe utilizar una base de datos que soporta eficientes geo-consultas .

Microservicios - Del diseño a la implementación de

7

Ch. 1 - Introducción a la microservicios

REST API

REST API

PASSENGER MANAGEMENT

REST API

DRIVER MANAGEMENT

TRIP MANAGEMENT

DATABASE ADAPTER

DATABASE ADAPTER

DATABASE ADAPTER

PASSENGER MANAGEMENT DATABASE

DRIVER MANAGEMENT DATABASE

TRIP MANAGEMENT DATABASE

Figura 1-5. arquitectura de base de datos para la aplicación de taxi que graniza.

En la superficie, el patrón microservicios La arquitectura es similar a la SOA. Con ambos enfoques, la arquitectura se compone de un conjunto de servicios. Sin embargo, una manera de pensar acerca del patrón microservicios Arquitectura es que es SOA sin la comercialización y el equipaje de percibir especificaciones de los servicios web (WS *) y un bus de servicios empresariales (ESB). aplicaciones basadas en MICROSERVICE favorecen más simples, protocolos ligeros como REST, en lugar de WS * También en gran medida evitar el uso de los ESB y en lugar de implementar la funcionalidad ESB-como en los propios microservicios. El patrón microservicios Arquitectura también rechaza otras partes del SOA, tales como el concepto de una esquema canónico para acceso a datos

Los beneficios de microservicios El patrón microservicios La arquitectura tiene una serie de beneficios importantes. En primer lugar, se aborda el problema de la complejidad. Se descompone lo que sería una aplicación monolítica monstruosa en un conjunto de servicios. Mientras que la cantidad total de la funcionalidad no se modifica, la aplicación se ha roto en trozos o servicios manejables Cada servicio tiene un límite bien definido en forma de una llamada de procedimiento remoto (RPC) impulsada o por mensajes del API. El patrón microservicios Arquitectura impone un nivel de modularidad que en la práctica es extremadamente difícil de conseguir con un código base monolítica. En consecuencia, los servicios individuales son mucho más rápidos para desarrollar, y mucho más fácil de entender y mantener

Microservicios - Del diseño a la implementación de

8

Ch. 1 - Introducción a la microservicios

En segundo lugar, esta arquitectura permite a cada servicio para ser desarrollada de forma independiente por un equipo que se centra en ese servicio. Los desarrolladores son libres de elegir lo tecnologías sentido, siempre que el servicio hace honor al contrato de API. Por supuesto, la mayoría de las organizaciones querrían evitar la anarquía completa mediante la limitación de opciones tecnológicas Sin embargo, esta libertad significa que los desarrolladores ya no están obligados a utilizar las tecnologías obsoletas que posiblemente existían al inicio de un nuevo proyecto. Cuando se escribe un nuevo servicio, tienen la opción de usar la tecnología actual. Por otra parte, ya que los servicios son relativamente pequeñas, se hace más factible para reescribir un servicio de edad utilizando la tecnología actual. En tercer lugar, el patrón microservicios arquitectura permite a cada microService a desplegarse de forma independiente. Los desarrolladores no necesitan coordinar el despliegue de los cambios que son locales a su servicio. Este tipo de cambios se pueden implementar tan pronto como lo han sido probados. El equipo de interfaz de usuario puede, por ejemplo, realizar A | B testing e iterar rápidamente en los cambios de interfaz de usuario. El patrón microservicios Arquitectura hace posible despliegue continuo Finalmente, el patrón microservicios arquitectura permite que cada servicio puede escalar de forma independiente. Puede implementar sólo el número de instancias de cada servicio que cumplan sus limitaciones de capacidad y disponibilidad Por otra parte, se puede utilizar el hardware que mejor se adapte a las necesidades de recursos de un servicio, por ejemplo, puede implementar un servicio de procesamiento de imágenes intensivo de la CPU en instancias EC2 optimizados y desplegar un servicio de base de datos en memoria en casos de memoria optimizado EC2 Este tipo de cambios se pueden implementar tan pronto como lo han sido probados. El equipo de interfaz de usuario puede, por ejemplo, realizar A | B testing e iterar rápidamente en los cambios de interfaz de usuario. El patrón microservicios Arquitectura hace posible despliegue continuo Finalmente, el patrón microservicios arquitectura permite que cada servicio puede escalar de forma independiente. Puede implementar sólo el número de instancias de cada servicio que cumplan sus limitaciones de capacidad y disponibilidad Por otra parte, se puede utilizar el hardware que mejor se adapte a las necesidades de recursos de un servicio, por ejemplo, puede implementar un servicio de

procesamiento de imágenes intensivo de la CPU en instancias EC2 optimizados y desplegar un servicio de base de datos en memoria en casos de memoria optimizado E

Los inconvenientes de microservicios Como escribió hace casi 30 años, Fred Brooks en El mes laboral mítico , no hay plata balas Como cada otra tecnología, el patrón microservicios arquitectura tiene inconvenientes. Un inconveniente es el nombre propio. El termino microService pone énfasis excesivo en el tamaño del servicio. De hecho, hay algunos desarrolladores que abogan por la construcción extremadamente grano fino-10-100 servicios LOC. Mientras que los servicios pequeños son preferibles, es importante recordar que los servicios pequeños son un medio para un fin, y no el objetivo principal. El objetivo de microservicios es suficiente para descomponer la aplicación con el fin de facilitar el desarrollo de aplicaciones ágil y despliegue.

Otro inconveniente importante de microservicios es la complejidad que surge del hecho de que una aplicación microservicios es un sistema distribuido desarrolladores necesitan para elegir y aplicar un mecanismo de comunicación entre procesos basada en cualquiera de mensajería o RPC. Por otra parte, también tienen que escribir código para manejar el fracaso parcial, ya que el destino de una petición puede ser lento o no disponible. Aunque nada de esto es ciencia de cohetes, es mucho más compleja que en una aplicación monolítica, donde los módulos invocan entre sí a través de métodos de nivel de lenguaje de llamadas / Procedimiento

Otro reto es con microservicios las transacciones comerciales arquitectura de base de datos con particiones que actualizar varias entidades de negocios son bastante comunes. Este tipo de transacciones son triviales de implementar en una aplicación monolítica porque hay una sola base de datos en una aplicación basada en microservicios, sin embargo, es necesario actualizar múltiples

Microservicios - Del diseño a la implementación de

9

Ch. 1 - Introducción a la microservicios

bases de datos de propiedad de diferentes servicios. El uso de transacciones distribuidas normalmente no es una opción, y no sólo a causa de la teorema de CAP Ellos simplemente no son compatibles con muchas de las bases de datos NoSQL altamente escalable de hoy y corredores de mensajería. Se termina por tener que utilizar un enfoque basado en la consistencia eventual, que es más difícil para los desarrolladores. Prueba de una aplicación microservicios también es mucho más compleja, por ejemplo, con un marco moderno, como la primavera de arranque, es trivial para escribir una clase de prueba que se pone en marcha una aplicación web monolítica y pone a prueba su API REST. Por el contrario, una clase de prueba similar para un servicio necesitaría para poner en marcha este servicio y cualquier servicio que depende de, o al menos configurar talones para esos servicios. Una vez más, esto no es una ciencia exacta, pero es importante no subestimar la complejidad de hacer esto.

Otro importante desafío con el patrón microservicios La arquitectura es la implementación de cambios que abarcan múltiples servicios Por ejemplo, imaginemos que se está implementando una historia que requiere cambios en los servicios A, B, y C, donde A depende de B y B depende de C en una aplicación monolítica que podría simplemente cambiar los módulos correspondientes, integrar los cambios, y desplegarlos en una sola vez el contrario, en un patrón microservicios Arquitectura es necesario planificar y coordinar la implementación de los cambios a cada uno de los servicios de cuidado. Por ejemplo, lo que se necesita para actualizar el servicio C, seguido por el servicio B, y, finalmente, el servicio A. Afortunadamente, la mayoría de los cambios normalmente afecta solamente un servicio; cambios de servicios múltiples que requieren la coordinación son relativamente raros implementación de una aplicación basada en microservicios-también es mucho más compleja Una aplicación monolítica simplemente se implementa en un conjunto de servidores idénticos detrás de un equilibrador de carga tradicional. Cada instancia de la aplicación está configurado con las ubicaciones (host y puertos) de servicios de infraestructura como la base de datos y un intermediario de mensajes Por el contrario, una aplicación microService consiste típicamente en un gran número de servicios. Por ejemplo, Hailo tiene 160 servicios diferentes y Netflix tiene más de 600, de acuerdo con Adrian Cockcroft

Cada servicio tendrá varias instancias de tiempo de ejecución de muchas más piezas móviles que necesitan ser configurado, desplegado, escalado, y monitoreado. Además, también tendrá que poner en práctica una Servicio mecanismo de descubrimiento que permite un servicio para descubrir los lugares (hosts y puertos) de cualquier otro servicio que necesita para comunicarse. problemas tradicionales de boletos basa y manual se acerca a las operaciones no se pueden escalar a este nivel de complejidad. En consecuencia, la implementación de una aplicación con éxito microservicios requiere un mayor control de los métodos de implementación por los desarrolladores y un alto nivel de automatización. Un enfoque para la automatización es el uso de un off-the-shelf plataforma como servicio (PaaS) como cloud Foundry Un PaaS ofrece a los desarrolladores una manera fácil de desplegar y gestionar sus microservicios. Que los aísla de las preocupaciones tales como la adquisición y configuración de los recursos de TI. Al mismo tiempo, los sistemas y los profesionales de redes que configuran las PaaS puede garantizar el cumplimiento de las mejores prácticas y políticas de la empresa Otra forma de automatizar el despliegue de microservicios es desarrollar lo que es esencialmente su propio PaaS Un punto de partida típico es utilizar una agrupación solución, tal como Kubernetes , En conjunción con una tecnología recipiente tal como acoplable Más adelante en este

Microservicios - Del diseño a la implementación de

10

Ch. 1 - Introducción a la microservicios

ebook vamos a ver cómo la entrega de aplicaciones basadas en software enfoques como Nginx, que maneja fácilmente el almacenamiento en caché, control de acceso, la medición de la API, y el seguimiento a nivel microService, puede ayudar a resolver este problema

Resumen La creación de aplicaciones complejas es de por sí difícil. El patrón monolítico Arquitectura sólo tiene sentido para aplicaciones sencillas y ligeras. Usted va a terminar en un mundo de dolor si lo utiliza para aplicaciones complejas. El patrón microservicios La arquitectura es la mejor opción para aplicaciones complejas, cambiantes, a pesar de los inconvenientes y problemas de ejecución

En capítulos posteriores, voy a bucear en los detalles de los diversos aspectos del patrón de microservicios Arquitectura y discutir temas tales como el descubrimiento de servicios, opciones de implementación de servicios, y las estrategias para refactorización una aplicación monolítica en los servicios.

Microservicios en Acción: Nginx Plus como un servidor proxy inverso por Floyd Smith poderes NGINX más del 50% de los 10.000 sitios web Y eso es en gran parte debido a sus capacidades como un servidor proxy inverso. Puede “gota Nginx frente a” aplicaciones actuales e incluso servidores de bases de datos para obtener todo tipo de capacidades - mayor rendimiento, mayor seguridad, escalabilidad, flexibilidad, y más. Todo ello con poco o ningún cambio en el código de aplicación y la configuración existente. Para los sitios que sufren estrés rendimiento - o anticipar cargas elevadas en el futuro - el efecto puede parecer poco menos que milagroso.

Entonces, ¿qué tiene esto que ver con microservicios? La implementación de un servidor proxy inverso, y el uso de las otras capacidades de Nginx, le da flexibilidad arquitectónica. Un servidor proxy inverso, el almacenamiento en caché estática y archivo de la aplicación, y SSL / TLS y HTTP terminación / 2 todos tomar la carga de su aplicación, liberando a “hacer lo que sólo se” - la aplicación - “puede hacer”.

Nginx también sirve como un equilibrador de carga, un papel crucial en microservicios implementaciones Las características avanzadas en Nginx Plus, incluyendo algoritmos de balance de carga sofisticados, múltiples métodos para la persistencia de la sesión, y la gestión y seguimiento, son especialmente útiles con microservicios. (NGINX ha añadido recientemente apoyo para el descubrimiento de servicio utilizando DNS SRV registros, una característica de vanguardia.) y, como se ha mencionado en este capítulo, Nginx pueden ayudar en la automatización del despliegue de microservicios.

Además, NGINX proporciona la funcionalidad necesaria para alimentar los tres modelos de la Arquitectura de referencia microservicios Nginx El modelo utiliza proxy Nginx como una puerta de enlace de la API; el modelo de router Mesh utiliza un servidor NGINX adicional como un centro para la comunicación entre procesos; y el Modelo de tela utiliza un servidor Nginx por microService, controlando el tráfico HTTP y, opcionalmente, la implementación de SSL / TLS entre microservicios, una capacidad de avance

Microservicios - Del diseño a la implementación de

11

Ch. 1 - Introducción a la microservicios

2

El uso de una API de puerta de enlace

los primer capítulo en este libro de siete capítulos sobre el diseño, la construcción y el despliegue de microservicios introdujeron el patrón microservicios Arquitectura Se discute las ventajas y los inconvenientes de la utilización microservicios y cómo, a pesar de la complejidad de microservicios, que suelen ser la opción ideal para aplicaciones complejas. Este es el segundo artículo de la serie y discutirá microservicios de construcción mediante una API de puerta de enlace Al elegir para construir su aplicación como un conjunto de microservicios, tiene que decidir cómo los clientes de su aplicación interactuarán con los microservicios con una aplicación monolítica sólo hay un conjunto de criterios de valoración, que típicamente se replican, con equilibrio de carga utiliza para distribuir el tráfico entre ellos.

En una arquitectura microservicios, sin embargo, cada microService expone un conjunto de lo que se suele puntos finales de grano fino. En este artículo, examinamos cómo esta comunicación cliente-impactos toapplication y proponemos un enfoque que utiliza una Puerta de enlace de la API

Introducción Imaginemos que usted está desarrollando un cliente móvil nativa para una aplicación comercial. Es probable que usted necesita para implementar una página de detalles del producto, que muestra información sobre cualquier producto dado

Por ejemplo, la Figura 2-1 muestra lo que verá cuando se desplaza a través de los detalles del producto en la aplicación móvil Android de Amazon

Microservicios - Del diseño a la implementación de

12

Ch. 2 - El uso de una puerta de enlace API

La Figura 2-1. Una aplicación de ejemplo.

A pesar de que se trata de una aplicación para teléfonos inteligentes, la página de detalles del producto muestra una gran cantidad de información. Por ejemplo, no sólo no hay información sobre los productos básicos, como el nombre, la descripción y el precio, pero esta página también muestra:

1. Número de artículos del carro de la compra 2 Historial de pedidos 3 Comentarios de los 4 bajo inventario opciones de alerta 5 envío

6. Varios recomendaciones, incluyendo otros productos de este producto es frecuentemente compró con otros, los productos comprados por los clientes que compraron este producto y otros productos vistos por los clientes que compraron este producto 7 Opciones alternativas de compra

Cuando se utiliza una arquitectura de aplicación monolítica, un cliente móvil recupera estos datos al hacer una sola llamada REST para la aplicación, tales como:

GET api.company.com/productdetails/ identificación de producto

A rutas equilibrador de carga la solicitud a una de varias instancias de aplicación idénticos. La aplicación consulta entonces varias tablas de la base y devolver la respuesta al cliente

Microservicios - Del diseño a la implementación de

13

Ch. 2 - El uso de una puerta de enlace API

Por el contrario, cuando se utiliza la arquitectura microservicios, los datos que aparecen en la página de detalles del producto es propiedad de múltiples microservicios. Éstos son algunos de los microservicios potenciales que poseen los datos que aparecen en la página de ejemplo específico del producto:

• Servicio de Compras - Número de artículos en el carrito de la compra •

Orden de Servicio - Historial de pedidos

•

Catálogo de Servicios - Información básica del producto, tales como nombre del producto, la imagen y precio

•

Servicio de Revisión - Comentarios de los lectores

• Servicio de inventario - Aviso de baja del inventario • El servicio de envío - Las opciones de envío, plazos y costes, elaborado por separado de la API del proveedor de envío

•

Recomendación sobre el servicio (s) - Los artículos sugeridos

La Figura 2-2. Mapeo de las necesidades de un cliente móvil a microservicios pertinentes.

Tenemos que decidir cómo el cliente móvil accede a estos servicios Veamos las opciones

Microservicios - Del diseño a la implementación de

14

Ch. 2 - El uso de una puerta de enlace API

Directa entre cliente y Microservice Comunicación En teoría, un cliente podría realizar solicitudes a cada uno de los microservicios directamente. Cada microService tendría un criterio de valoración pública:

https://serviceName.api.company.name Esta URL se asignaría a equilibrador de carga de la microService, que distribuye las solicitudes a través de las instancias disponibles. Para recuperar la información de la página específica del producto, el cliente móvil podría realizar solicitudes a cada uno de los servicios mencionados anteriormente. Por desgracia, hay retos y limitaciones con esta opción. Uno de los problemas es la falta de correspondencia entre las necesidades del cliente y las API de grano fino expuestos por cada uno de los microservicios. El cliente en este ejemplo tiene que hacer siete solicitudes separadas. En aplicaciones más complejas que podría tener que hacer muchos más Por ejemplo, Amazon describe cómo cientos de servicios están involucrados en la prestación de su página de producto. Mientras que un cliente podría hacer que muchas peticiones a través de LAN, probablemente sería demasiado ineficientes a través de Internet pública y sin duda sería poco práctica a través de una red móvil Este enfoque también hace que el código de cliente mucho más complejo Otro problema con el cliente que llama directamente a los microservicios es que algunos pueden utilizar protocolos que no son compatible con la web . Un servicio puede utilizar Thrift RPC binaria mientras que otro servicio puede utilizar el protocolo de mensajería AMQP. Ni el protocolo es particularmente firewalls browseror, y es el más utilizado internamente. Una aplicación debe utilizar protocolos como HTTP y WebSocket fuera del cortafuegos. Ni el protocolo es particularmente firewalls browseror, y es el más utilizado internamente. Una aplicación debe utilizar protocolos como HTTP y WebSocket fuera del cortafuegos. Ni el protocolo es particularmente firewalls browseror, y es el más utilizado internamente. Una aplicación debe utilizar protocolos como HTTP y WebSocket fuera del cortafuegos.

Otro inconveniente de este enfoque es que hace que sea difícil de refactorizar los microservicios. Con el tiempo lo que se quiere cambiar la forma en que el sistema está dividido en los servicios Por ejemplo, podríamos fusionar dos servicios o dividir un servicio en dos o más servicios. Sin embargo, si los clientes se comunican directamente con los servicios, a continuación, realizar este tipo de refactorización puede ser extremadamente difícil.

Debido a este tipo de problemas que rara vez tiene sentido para los clientes de hablar directamente con microservicios

El uso de una API de puerta de enlace Por lo general, un enfoque mucho mejor es utilizar lo que se conoce como una Puerta de enlace de la API Una API Gateway es un servidor que es el único punto de entrada en el sistema es similar a la Fachada

patrón de diseño orientado a objetos. La puerta de enlace API encapsula la arquitectura interna del sistema y proporciona una API que se adapta a cada cliente Podría tener otras responsabilidades tales como la autenticación, el seguimiento, el equilibrio de carga, almacenamiento en caché, la solicitud de configuración y gestión, y la gestión de respuesta estática

Microservicios - Del diseño a la implementación de

15

Ch. 2 - El uso de una puerta de enlace API

La Figura 2-3 muestra cómo una puerta de enlace API típicamente encaja en la arquitectura.

La Figura 2-3. El uso de una API Gateway con microservicios.

La API Gateway es responsable de la solicitud de enrutamiento, la composición y conversión de protocolos. Todas las peticiones de los clientes van primero a través de la API de puerta de enlace. A continuación, rutas solicita a la microService apropiado. La API de puerta de enlace a menudo gestionar una petición invocando múltiples microservicios y la agregación de los resultados se puede traducir entre protocolos de Internet como HTTP y los protocolos y WebSocket-web hostil que se utilizan internamente. La API Gateway también puede proporcionar a cada cliente con un API de costumbre lo general expone una API de grano grueso para clientes móviles. Consideremos, por ejemplo, los detalles del producto escenario. La puerta de enlace API puede proporcionar un punto final (/ Detalles del producto? ProductID = xxx) ese

Microservicios - Del diseño a la implementación de

dieciséis

Ch. 2 - El uso de una puerta de enlace API

permite a un cliente móvil para recuperar todos los detalles del producto con una sola solicitud. La puerta de enlace API controla la solicitud mediante la invocación de los diferentes servicios de información - producto, recomendaciones, comentarios, etc - y la combinación de los resultados Un gran ejemplo de una API es la puerta de enlace Netflix API de puerta de enlace . El servicio de streaming de Netflix está disponible en cientos de diferentes tipos de dispositivos, incluyendo televisores, decodificadores, teléfonos inteligentes, sistemas de juegos, tabletas, etc. Inicialmente, Netflix intentó proporcionar una una talla única para todos API para su servicio de streaming. Sin embargo, descubrieron que no funcionaba bien debido a la amplia gama de dispositivos y sus necesidades únicas. Hoy en día, utilizan una API de puerta de enlace que proporciona una API a medida para cada dispositivo mediante la ejecución de código de adaptador específico del dispositivo. Un adaptador normalmente maneja cada solicitud invocando, en promedio, de seis a siete servicios backend. La puerta de enlace API de Netflix se encarga de mil millones de solicitudes por día

Ventajas y desventajas de una API de puerta de enlace Como era de esperar, el uso de una API Gateway tiene tanto ventajas como inconvenientes. Una ventaja importante de utilizar un API de puerta de enlace es que encapsula la estructura interna de la aplicación. En lugar de tener que invocar servicios específicos, los clientes simplemente comunicarse con la pasarela. La API Gateway proporciona cada tipo de cliente con una API específica. Esto reduce el número de viajes de ida y vuelta entre el cliente y la aplicación. También simplifica el código de cliente. La API Gateway también tiene algunos inconvenientes Es otro componente de alta disponibilidad que se deben desarrollar, desplegar, y logró También hay un riesgo de que la API de puerta de enlace se convierte en una desarrolladores el desarrollo de cuello de botella deben actualizar la API de puerta de enlace a fin de exponer los puntos finales de cada MICROSERVICE

Es importante que el proceso de actualización de la puerta de enlace API de ser lo más ligero posible. De lo contrario, los desarrolladores se verán obligados a esperar en la cola con el fin de actualizar la puerta de entrada. A pesar de estos inconvenientes, sin embargo, para la mayoría de aplicaciones del mundo real que tiene sentido utilizar una API de puerta de enlace

La implementación de una puerta de enlace de la API Ahora que hemos visto las motivaciones y las ventajas y desventajas para el uso de una puerta de enlace de la API, vamos a ver varios problemas de diseño debe tener en cuenta

Rendimiento y escalabilidad Sólo un puñado de empresas operan en la escala de Netflix y la necesidad de manejar miles de solicitudes por día. Sin embargo, para la mayoría de aplicaciones, el rendimiento y la escalabilidad de la puerta de enlace API generalmente es muy importante. Tiene sentido, por lo tanto, la construcción de la API de puerta de enlace en una plataforma que soporta asíncrono, sin bloqueo de E / S. Hay una variedad de diferentes tecnologías que se pueden utilizar para implementar un API escalable Gateway. En la JVM puede utilizar uno de los marcos basados ​en NIO tales Netty, VertX, Primavera del reactor,

Microservicios - Del diseño a la implementación de

17

Ch. 2 - El uso de una puerta de enlace API

o JBoss Undertow. Una opción no JVM popular es Node.js, que es una plataforma construida en el motor JavaScript de Chrome. Otra opción es utilizar Nginx Plus. Nginx Plus ofrece una, escalable, el servidor web de alto rendimiento maduro y proxy inverso que se puede desplegar fácilmente, configurado y programado. Nginx Plus puede administrar la autenticación, control de acceso, solicitudes de balanceo de carga, almacenamiento en caché de las respuestas, y proporciona controles de salud y monitoreo applicationaware

Utilizando un modelo de programación reactiva

La API de puerta de enlace maneja algunas peticiones simplemente encaminarlas al servicio de back-end apropiado Maneja otras solicitudes mediante la invocación de múltiples servicios de back-end y la agregación de los resultados Con algunas peticiones, como una solicitud de detalles del producto, las peticiones a los servicios de back-end son independientes entre sí. Con el fin de minimizar el tiempo de respuesta, la puerta de enlace de la API debe realizar solicitudes independientes simultáneamente. A veces, sin embargo, existen dependencias entre las solicitudes La API Gateway sería primera necesidad de validar la solicitud, activando un servicio de autenticación antes de encaminar la petición a un servicio de back-end. Del mismo modo, en busca de información acerca de los productos en la lista de deseos de un cliente, la puerta de enlace API debe primero recuperar el perfil del cliente que contiene esa información, y luego recuperar la información de cada producto. Netflix vídeo cuadrícula

Escribir código API composición usando el enfoque tradicional de devolución de llamada asincrónica rápidamente te lleva a devolución de llamada infierno. El código será enredado, difícil de entender, y propenso a errores Un enfoque mucho mejor es escribir código API de puerta de enlace en un estilo declarativa utilizando un enfoque reactivo. Los ejemplos de reactivos incluyen abstracciones Futuro en Scala,

CompletableFuture en Java 8, y Promesa en JavaScript. También hay Extensiones reactivas (También llamado Rx o ReactiveX), que fue desarrollado originalmente por Microsoft para la plataforma .NET. Netflix creado RxJava para la JVM específicamente para el uso en sus API Gateway. También hay RxJS JavaScript, que se ejecuta tanto en el navegador y Node.js. El uso de un enfoque reactivo le permitirá escribir código API simple pero eficiente Gateway. La invocación de servicios

Una aplicación basada en microservicios es un sistema distribuido y debe utilizar un mecanismo de comunicación entre procesos. Hay dos estilos de comunicación entre procesos Una opción es utilizar un asíncrono, mecanismo basado en la mensajería Algunas implementaciones utilizan un intermediario de mensajes tales como JMS o AMQP. Otros, como Zeromq, son brokerless y los servicios se comunican directamente

El otro estilo de comunicación entre procesos es un mecanismo de sincronización, tales como HTTP o Thrift. Un sistema utilizará típicamente tanto asíncronos y síncronos estilos. Incluso podría utilizar múltiples implementaciones de cada estilo. En consecuencia, la puerta de enlace API tendrá que soportar una variedad de mecanismos de comunicación.

Microservicios - Del diseño a la implementación de

18

Ch. 2 - El uso de una puerta de enlace API

Descubrimiento de servicio

La API de puerta de enlace necesita saber la ubicación (dirección IP y puerto) de cada microService con la que se comunica En una aplicación tradicional, que probablemente podría HardWire los lugares, pero en una aplicación moderna, basada en la nube microservicios, la búsqueda de los lugares que se necesita es una un problema no trivial

Los servicios de infraestructura, tales como un intermediario de mensajes, por lo general tienen una ubicación estática, que puede especificarse mediante variables de entorno del sistema operativo. Sin embargo, la determinación de la ubicación de un servicio de aplicación no es tan fácil.

Los servicios de aplicaciones han asignado dinámicamente ubicaciones. Además, el conjunto de instancias de un servicio cambia dinámicamente debido a autoscaling y actualizaciones. En consecuencia, la puerta de enlace de la API, como cualquier otro cliente de servicios en el sistema, tiene que utilizar el mecanismo de descubrimiento de servicios del sistema: o descubrimiento del lado del servidor o Del lado del cliente descubrimiento Capítulo 4 describe el descubrimiento de servicios con más detalle Por ahora, vale la pena tener en cuenta que si el sistema utiliza el descubrimiento del lado del cliente, entonces la puerta de enlace de la API debe ser capaz de consultar la

registro de servicios , Que es una base de datos de todas las instancias MICROSERVICE y sus ubicaciones.

Gestión de Fallos parciales Otra cuestión que hay que abordar cuando se implementa una API Gateway es el problema del fracaso parcial. Este problema se plantea en todos los sistemas distribuidos cada vez que un servicio llama a otro servicio que está respondiendo bien lentamente o no está disponible La API de puerta de enlace no debe bloquear indefinidamente a la espera de un servicio de aguas abajo. Sin embargo, la forma en que maneja el fracaso depende de la situación específica y qué servicio está fallando. Por ejemplo, si el servicio recomendación es que no responde en el escenario de los detalles del producto, la puerta de enlace de la API debe devolver el resto de los detalles del producto para el cliente, ya que todavía son útiles para el usuario. Las recomendaciones podrían ser o bien vacío o sustituido por, por ejemplo, una lista de los diez cableada. Si, sin embargo, el servicio de información del producto no responde, entonces la puerta de enlace de la API debe devolver un error al cliente

La API Gateway también podría devolver datos en caché si está disponible. Por ejemplo, dado que los precios de productos cambian con poca frecuencia, la puerta de enlace API podría volver datos de precios en caché si el servicio de precios no está disponible. Los datos se pueden almacenar en caché por el propio API Gateway o ser almacenados en una memoria caché externa, como Redis o Memcached. Al devolver cualquiera de los datos por defecto o los datos almacenados en caché, la puerta de enlace API asegura que los fallos del sistema mínimamente impactan la experiencia del usuario

Netflix Hystrix es una biblioteca muy útil para escribir código que invoca servicios remotos. Hystrix el tiempo de espera de llamadas que superen el umbral especificado. Se implementa una cortacircuitos patrón, que para el cliente de esperar innecesariamente para un servicio que no responde. Si la tasa de error para un servicio supera un umbral especificado, Hystrix dispara el interruptor y todas las peticiones fallará inmediatamente por un período de tiempo especificado. Hystrix le permite definir una acción de retroceso cuando una petición falla, tales como la lectura de una memoria caché o devolver un valor predeterminado. Si está utilizando la JVM que sin duda debe considerar el uso de Hystrix. Y, si está ejecutando en un entorno no-JVM, se debe utilizar una biblioteca equivalente.

Microservicios - Del diseño a la implementación de

19

Ch. 2 - El uso de una puerta de enlace API

Resumen Para la mayoría de las aplicaciones basadas en microservicios, tiene sentido implementar un API Gateway, que actúa como un único punto de entrada en un sistema. La API Gateway es responsable de la solicitud de enrutamiento, la composición y conversión de protocolos. Se proporciona a cada uno de los clientes de la aplicación con un API personalizado. La API Gateway también puede enmascarar los fallos en los servicios de servidor mediante la devolución de los datos almacenados en caché o por defecto. En el siguiente capítulo, vamos a ver en la comunicación entre los servicios

Microservicios en Acción: Nginx Plus como una API de puerta de enlace por Floyd Smith En este capítulo se describe cómo una API de puerta de enlace sirve como un único punto de entrada a un sistema y que puede manejar otras funciones tales como el equilibrio de carga, almacenamiento en caché, la supervisión, traducción de protocolo, y otros - mientras que Nginx, cuando se implementa como un servidor proxy inverso, funciona como un único punto de entrada en un sistema y soporta todas las funciones adicionales mencionadas para una API gateway. Así que usando Nginx como sede de una API Gateway puede funcionar muy bien.

Pensando en Nginx como una puerta de enlace de la API no es una idea que es original a este libro electrónico. Nginx Plus es una plataforma líder para la gestión y protección del tráfico de API basado en HTTP. Puede implementar su propia API Gateway o utilizar una plataforma de gestión de la API existente, muchos de los cuales apalancamiento Nginx. Razones para el uso de Nginx como un Plus Puerta de enlace de la API incluir:

•

Gestión de Acceso - Se puede utilizar una variedad de lista de control de acceso (ACL) métodos e implementar fácilmente SSL / TLS, ya sea a nivel de aplicación web como es típico, o también hasta el nivel de cada individuo microService.

•

Manejabilidad y resiliencia - Puede actualizar el servidor API basada en Nginx Plus sin tiempo de inactividad, el uso de la API de Nginx reconfiguración dinámica, un módulo de Lua, Perl, se reinicia en vivo sin tiempos de inactividad, o los cambios impulsados ​por el chef, de marionetas, ZooKeeper, o DNS.

•

Integración con herramientas de terceros - Nginx Plus ya está integrado con herramientas de vanguardia, tales como 3scale , Kong , y el MuleSoft plataforma de integración (por mencionar sólo herramientas que se describen en el sitio web Nginx.)

Nginx Plus se utiliza ampliamente como una puerta de enlace API en el Arquitectura de referencia microservicios Nginx . Utilizar los artículos reunidos aquí y, cuando esté disponible públicamente, el ARM, para ejemplos de cómo implementar esto en sus propias aplicaciones

Microservicios - Del diseño a la implementación de

20

Ch. 2 - El uso de una puerta de enlace API

3

La comunicación entre procesos

Este es el tercer capítulo de este libro electrónico sobre la creación de aplicaciones con una arquitectura microservicios Capítulo 1 introduce la microservicios patrón de Arquitectura , Lo compara con el patrón de Monolithic Arquitectura, y discute las ventajas y los inconvenientes de la utilización microservicios. Capitulo 2 describe cómo los clientes de una aplicación se comunican con los microservicios través de un intermediario conocido como Puerta de enlace de la API En este capítulo, damos un vistazo a cómo los servicios dentro de un sistema se comunican entre sí Capítulo 4 explora el problema estrechamente relacionado de descubrimiento de servicios.

Introducción En una aplicación monolítica, invocan componentes entre sí a través del método de nivel de idioma o llamadas a funciones. En contraste, una aplicación basada microservicios-es un sistema distribuido que se ejecuta en múltiples máquinas Cada instancia de servicio es típicamente un proceso En consecuencia, como la Figura 3-1 muestra, los servicios deben interactuar utilizando una comunicación entre procesos (IPC) mecanismo.

Más adelante vamos a ver en las tecnologías específicas del IPC, pero primero vamos a explorar diversas cuestiones de diseño.

Microservicios - Del diseño a la implementación de

21

Ch. 3 - Comunicación entre procesos

STRIPE ADAPTER

PASSENGER MANAGEMENT

REST API

BILLING

PASSENGER MANAGEMENT

YOURBANK 0000 0000 0000 0000 00/00

0000

0000

0000

BILLING

NOTIFICATION

TRIP MANAGEMENT

DRIVER MANAGEMENT

REST API

NOMBRE

REST API

PAYMENTS

TU

00/00

0000

YOUR NAME

PAYMENTS

DRIVER MANAGEMENT

TWILIO ADAPTER

REST API

TRIP MANAGEMENT

REST API

NOTIFICATION

SENDGRID ADAPTER

La Figura 3-1. Microservicios utilizan la comunicación entre procesos para interactuar.

Estilos de interacción Al seleccionar un mecanismo IPC para un servicio, es útil pensar primero en cómo interactúan los servicios. Hay una gran variedad de clientes 1 estilos de interacción de servicios Se pueden clasificar en dos dimensiones. La primera dimensión es si la interacción es de uno a uno o uno-a-muchos:

• Uno-a-uno - Cada solicitud de cliente es procesada por exactamente una instancia de servicio • Uno-a-muchos - Cada solicitud es procesada por múltiples instancias de servicio La segunda

dimensión es si la interacción es síncrona o asíncrona: • Sincrónica - El cliente espera una respuesta oportuna del servicio e incluso puede bloquear mientras espera • Asíncrono - El cliente no bloquea a la espera de una respuesta, y la respuesta, en su caso, no es necesariamente envía inmediatamente. La siguiente tabla muestra los diversos estilos de interacción.

UNO-A-UNO

SÍNCRONO ASÍNCRONO

Solicitar respuesta Notificación solicitud / respuesta asíncrona

UNO A MUCHOS

Publicación / suscripción

publicación / respuestas asíncronas

Tabla 3-1. estilos de comunicación entre procesos.

Microservicios - Del diseño a la implementación de

22

Ch. 3 - Comunicación entre procesos

Existen los siguientes tipos de uno-a-uno interacciones, tanto síncrona (petición / respuesta) y asíncrona (notificación y solicitud de respuesta / asíncrono): • Solicitud / respuesta - Un cliente realiza una solicitud a un servicio y espera una respuesta. El cliente espera la respuesta para llegar en el momento oportuno. En una aplicación basada en hilo, el hilo que realiza la petición podría incluso bloquear a la espera

•

Notificación (también conocido como una solicitud de una sola vía) - Un cliente envía una petición a un servicio, pero no hay respuesta se espera o se envía

• Solicitud de respuesta / asíncrono - Un cliente envía una petición a un servicio, que responde de forma asíncrona El cliente no se bloquea mientras espera y se ha diseñado con el supuesto de que la respuesta podría no llegar por un tiempo.

Existen los siguientes tipos de interacciones uno-a-muchos, los cuales son asíncronas: • Publicación / suscripción - Un cliente publica un mensaje de notificación, que se consume por cero o más servicios interesados

• Publicar respuestas asíncronas / - Un cliente publica un mensaje de solicitud, y luego espera una cierta cantidad de tiempo para las respuestas de los servicios interesados.

Cada servicio normalmente utiliza una combinación de estos estilos de interacción. Para algunos servicios, un solo mecanismo IPC es suficiente. Otros servicios podrían tener que utilizar una combinación de mecanismos IPC

La Figura 3-2 muestra cómo los servicios en una aplicación de taxi de granizada podrían interactuar cuando el usuario solicita un viaje

PASSENGER MANAGEMENT

PASSENGER INFO 2 GET REQUEST�RESPONSE

PICKUP 1 REQUEST NOTIFICATION PASSENGER SMARTPHONE

CREATED 3 TRIP PUB�SUB TRIP MANAGEMENT

PASSENGER MANAGEMENT

4

DRIVER PROPOSED PUB�SUB

DISPATCHER

PASSENGER 5 NOTIFY NOTIFICATION

NOTIFICATION

PASSENGER 5 NOTIFY NOTIFICATION

PROPOSED 4 DRIVER PUB�SUB

DRIVER MANAGEMENT

La Figura 3-2. El uso de varios mecanismos IPC para las interacciones de servicio.

Microservicios - Del diseño a la implementación de

23

Ch. 3 - Comunicación entre procesos

Los servicios utilizan una combinación de notificaciones, petición / respuesta, y de publicación / suscripción. Por ejemplo, un teléfono inteligente del pasajero envía una notificación al Servicio de Gestión de viaje para solicitar una recogida. El servicio de gestión de viaje verifica que la cuenta del pasajero se activa mediante el uso de petición / respuesta para invocar el servicio de gestión de pasajeros el servicio de administración de viaje crea entonces el viaje y utiliza de publicación / suscripción para notificar a otros servicios, como el despachador, que localiza un controlador. Ahora que hemos visto los estilos de interacción, vamos a echar un vistazo a cómo definir las API.

La definición de las API API de Un servicio es un contrato entre el servicio y sus clientes. Independientemente de su elección del mecanismo IPC, es importante definir con precisión la API de un servicio utilizando algún tipo de lenguaje de definición de interfaces (IDL). Incluso hay buenos argumentos para utilizar una API-primer acercamiento que definen a los servicios. De comenzar el desarrollo de un servicio escribiendo la definición de interfaz y de su revisión con los desarrolladores de clientes. Es sólo después de la iteración en la definición de API que implemente el servicio. Haciendo este diseño en la delantera aumenta sus posibilidades de construir un servicio que satisfaga las necesidades de sus clientes. Como se verá más adelante en este artículo, la naturaleza de la definición API depende de qué mecanismo IPC está utilizando. Si está utilizando la mensajería, la API se compone de los canales de mensajes y los tipos de mensajes. Si está utilizando HTTP, el API se compone de las direcciones URL y los formatos de solicitud y respuesta. Más adelante describiremos algunos IDL con más detalle.

API Evolving El API de una servicio cambia invariablemente con el tiempo en una aplicación monolítica que suele ser sencillo para cambiar la API y actualizar todas las personas que llaman. En una aplicación basada en microservicios es mucho más difícil, incluso si todos los consumidores de su API son otros servicios en la misma aplicación. Por lo general, no se puede obligar a todos los clientes para actualizar al mismo ritmo con el servicio también, es probable que incrementalmente implementar nuevas versiones de un servicio

de tal manera que ambas versiones antiguas y nuevas de un servicio se ejecutan simultáneamente. Es importante tener una estrategia para hacer frente a estos problemas.

¿Cómo manejar un cambio de API depende de la magnitud del cambio. Algunos cambios son menores y compatible con la versión anterior. Es posible, por ejemplo, añadir atributos a peticiones o respuestas Tiene sentido para diseñar clientes y servicios a fin de que observen el principio de robustez Los clientes que utilizan una API mayores deben seguir trabajando con la nueva versión del servicio. El servicio proporciona valores por defecto para los atributos de la petición que faltan y los clientes ignoran los atributos cualquier respuesta adicional Es importante utilizar un mecanismo IPC y un formato de mensajería que le permiten evolucionar fácilmente API

A veces, sin embargo, debe hacer grandes cambios, incompatibles con una API Como no se puede obligar a los clientes a actualizar de inmediato, un servicio debe ser compatible con versiones anteriores de la

Microservicios - Del diseño a la implementación de

24

Ch. 3 - Comunicación entre procesos

API para un cierto período de tiempo. Si está utilizando un mecanismo basado en HTTP tales como el descanso, un enfoque consiste en incrustar el número de versión en la URL Cada instancia de servicio puede manejar múltiples versiones al mismo tiempo. Como alternativa, puede implementar diferentes instancias que cada mango de una versión particular

Manipulación del fracaso parcial

Como se menciona en Capitulo 2 sobre el API Gateway, en un sistema distribuido existe el riesgo siempre presente de fallo parcial. Ya que los clientes y servicios son procesos separados, un servicio podría no ser capaz de responder de manera oportuna a la solicitud de un cliente de un servicio puede ser a causa de una avería o por mantenimiento. O el servicio puede estar sobrecargada y respondiendo muy lentamente a las solicitudes

Consideremos, por ejemplo, los detalles de producto escenario del capítulo 2. Imaginemos que el Servicio de Recomendación no responde. Una implementación ingenua de un cliente podría bloquear indefinidamente a la espera de una respuesta. No sólo que se traducen en una experiencia de usuario pobre, sino también, en muchas aplicaciones que consumiría un recurso precioso, como un hilo Finalmente, el tiempo de ejecución se quedaría sin hilos y dejar de responder, como se muestra en la Figura 3-3

IF THE SERVICE IS DOWN THEN THREAD WILL BE BLOCKED

TOMCAT THREAD 1

HTTP REQUEST

THREAD 2 RPC CLIENT CODE

THREAD 3

RECOMMENDATION SERVICE

THREAD N EXECUTE THREAD POOL EVENTUALLY ALL THREADS WILL BE BLOCKED

Figura 3-3. Hilos bloquean debido a un servicio que no responde.

Para evitar este problema, es esencial que el diseño de sus servicios para manejar los fallos parciales.

Microservicios - Del diseño a la implementación de

25

Ch. 3 - Comunicación entre procesos

Un buen método a seguir es el de descrito por Netflix . Las estrategias para tratar con fallos parciales incluyen: •

los tiempos de espera de red - Nunca bloquee indefinidamente y siempre usan tiempos de espera al esperar una respuesta. El uso de los tiempos de espera asegura que los recursos no están atados por tiempo indefinido.

• La limitación del número de solicitudes pendientes - Imponer un límite superior en el número de solicitudes pendientes que un cliente puede tener con un servicio en particular. Si se ha alcanzado el límite, es probable que sea inútil para hacer solicitudes adicionales, y esos intentos tienen que dejar de inmediato.

• patrón de disyuntor - Realizar un seguimiento del número de solicitudes exitosas y fallidas. Si la tasa de error supera un umbral configurado, el disparo del interruptor automático para que nuevos intentos fallan inmediatamente. Si un gran número de solicitudes están fallando, sugiere que el servicio no está disponible y que el envío de solicitudes es inútil. Después de un tiempo de espera, el cliente debe intentarlo de nuevo y, si tiene éxito, cerrar el interruptor.

•

Proporcionar retrocesos - Realizar la lógica de reserva cuando falla una solicitud. Por ejemplo, devolver los datos almacenados en caché o un valor por defecto, como un conjunto vacío de recomendaciones.

Netflix Hystrix es una biblioteca de código abierto que implementa estos y otros patrones. Si está utilizando la JVM que sin duda debe considerar el uso de Hystrix. Y, si está ejecutando en un entorno no-JVM, se debe utilizar una biblioteca equivalente.

IPC Tecnologías Hay un montón de diferentes tecnologías de IPC para elegir. Los servicios pueden utilizar mecanismos sincrónicos de petición / respuesta basada en la comunicación, tales como el descanso o Ahorro basado en HTTP. Alternativamente, pueden utilizar, mecanismos de comunicación basadas en mensajes asíncronos como AMQP o STOMP.

También hay una variedad de diferentes formatos de mensaje. Los servicios pueden utilizar formatos legibles por humanos, basados ​en texto tales como JSON o XML. Alternativamente, se puede utilizar un formato binario (que es más eficiente) como Avro o Protocol Buffers. Más adelante veremos mecanismos IPC síncronos, pero primero vamos a discutir mecanismos IPC asíncronos.

Asíncrono, la comunicación de mensajes basado en Cuando se utiliza la mensajería, los procesos se comunican mediante el intercambio de forma asíncrona mensajes. Un cliente realiza una solicitud a un servicio mediante el envío de un mensaje. Si el servicio se espera para responder, lo hace mediante el envío de un mensaje de retorno al cliente, ya que la comunicación es asíncrona, el cliente no bloquea la espera de una respuesta. En su lugar, el cliente está escrito asumiendo que la respuesta no será recibido inmediatamente

Microservicios - Del diseño a la implementación de

26

Ch. 3 - Comunicación entre procesos

UNA mensaje consta de cabeceras (metadatos, como el emisor) y un cuerpo de mensaje. Los mensajes se intercambian a través canales . Cualquier número de productores puede enviar mensajes a un canal. Del mismo modo, cualquier número de los consumidores pueden recibir mensajes de un canal. Hay dos tipos de canales, punto a punto y publicación-suscripción :

• Un canal de punto a punto de entrega un mensaje a exactamente uno de los consumidores de que están leyendo desde el canal. Servicios usan canales punto a punto para el uno-a-uno estilos de interacción descritos anteriormente

• Un canal de publicación-suscripción entrega cada mensaje a todos los consumidores conectados. Servicios utilizan canales para los estilos de interacción uno-a-muchos descritas anteriormente publicación-suscripción

La figura 3-4 muestra cómo la aplicación de taxi-graniza podría utilizar los canales de publicación-suscripción

TRIP CREATED TRIP MANAGEMENT

NEW TRIPS � PUBLISH�SUBSCRIBE CHANNEL

DISPATCHER

DRIVER PROPOSED

PASSENGER MANAGEMENT

DISPATCHING � PUBLISH�SUBSCRIBE CHANNEL

DRIVER MANAGEMENT

La Figura 3-4. El uso de canales en una aplicación de taxi que graniza de publicación-suscripción.

El servicio de gestión de viaje notifica a los servicios interesados, como el despachador, sobre un nuevo viaje al escribir un mensaje de viaje Creado a una publicación-suscripción de canalizar el despachador encuentra un controlador y notifica a otros servicios escribiendo un mensaje del controlador propuesto a una publicación-suscripción canal

Microservicios - Del diseño a la implementación de

27

Ch. 3 - Comunicación entre procesos

Hay muchos sistemas de mensajería para elegir. Debe elegir uno que es compatible con una variedad de lenguajes de programación.

Algunos sistemas de mensajería soportan protocolos estándar como AMQP y Stomp. Otros sistemas de mensajería han documentado protocolos propietarios, pero hay un gran número de sistemas de mensajería de código abierto para elegir, incluyendo RabbitMQ , Apache Kafka , Apache ActiveMQ y NSQ A un alto nivel, todos ellos soportan alguna forma de mensajes y canales. Todos ellos se esfuerzan por ser fiable, de alto rendimiento y escalable. Sin embargo, existen diferencias significativas en los detalles del modelo de mensajería de cada agente

Hay muchas ventajas en el uso de los mensajes: • Desacopla el cliente del servicio - Un cliente realiza una solicitud, simplemente mediante el envío de un mensaje al canal apropiado. El cliente es completamente inconsciente de las instancias de servicio que no es necesario utilizar un mecanismo de descubrimiento para determinar la ubicación de una instancia de servicio.

• búfer de mensajes - Con un protocolo de petición / respuesta sincrónica, como HTTP, el cliente y el servicio debe estar disponible para la duración del intercambio. Por el contrario, un intermediario de mensajes pone en cola los mensajes escritos a un canal hasta que el consumidor pueda procesarlos. Esto significa, por ejemplo, que una tienda en línea puede recibir los pedidos de los clientes, incluso cuando el sistema de cumplimiento de la orden es lento o no disponible. Los mensajes de órdenes simplemente hacen cola

• interacciones de servicio al cliente flexibles - mensajería compatible con todos los estilos de interacción descritos anteriormente • Explícita la comunicación entre procesos - mecanismos basados ​en RPC intentan hacer la invocación de un servicio remoto tienen el mismo aspecto como llamar a un servicio local Sin embargo, debido a las leyes de la física y la posibilidad de fallo parcial, en realidad son muy diferentes. Mensajería hace que estas diferencias muy explícita para que los desarrolladores no se deje llevar por una falsa sensación de seguridad.

Hay, sin embargo, algunos inconvenientes a la utilización de los mensajes:

• la complejidad operativa adicional - El sistema de mensajería es otro componente del sistema que debe ser instalado, configurado y operado. Es esencial que el intermediario de mensajes sea altamente disponible, de lo contrario la fiabilidad del sistema se ve afectada

• Complejidad de la implementación de petición / respuesta basada en la interacción - Solicitud / interacción responsestyle requiere algo de trabajo para implementar cada mensaje de solicitud debe contener un identificador de canal respuesta y un identificador de correlación. El servicio escribe un mensaje de respuesta que contiene el ID de correlación en el canal de respuesta del cliente utiliza el ID de correlación para que coincida con la respuesta a la solicitud. A menudo es más fácil de usar un mecanismo de IPC que apoya directamente petición / respuesta

Ahora que hemos visto el uso de CIP basadas en la mensajería, examinemos petición / responsebased IPC

Microservicios - Del diseño a la implementación de

28

Ch. 3 - Comunicación entre procesos

Sincrónica, Solicitud / Respuesta IPC Cuando se utiliza un mecanismo IPC basado en la respuesta de solicitud / síncrono, un cliente envía una petición a un servicio El servicio procesa la solicitud y devuelve una respuesta En muchos clientes, el hilo que hace que los bloques de petición a la espera de una respuesta. Otros clientes pueden utilizar el código de cliente asíncrono, dirigido por eventos que tal vez es encapsulado por Futuros o Rx observables Sin embargo, a diferencia de cuando se utiliza la mensajería, el cliente asume que la respuesta llegará en el momento oportuno.

Hay numerosos protocolos para elegir. Dos protocolos populares son REST y de segunda mano. Primero vamos a echar un vistazo en reposo. DESCANSO

Hoy en día está de moda para desarrollar las API en el Sosegado RESTO estilo es un mecanismo IPC que (casi siempre) utiliza HTTP. Un concepto clave en REST es un recurso, que por lo general representa un objeto de negocio, tales como un cliente o producto, o una colección de este tipo de objetos de negocio. RESTO utiliza los verbos HTTP para la manipulación de los recursos, que son referenciadas mediante una dirección URL. Por ejemplo, una OBTENER

solicitud devuelve la representación de un recurso, que puede ser en forma de un documento XML o JSON objeto. UNA ENVIAR solicitud crea un nuevo recurso, y una PONER solicitar las actualizaciones de un recurso

Para citar a Roy Fielding, el creador de ocio: “REST proporciona un conjunto de restricciones arquitectónicas que, cuando se aplica como un todo, hace hincapié en la escalabilidad de las interacciones de los componentes, la generalidad de las interfaces, el despliegue independiente de los componentes, y componentes intermedios para reducir la latencia interacción, reforzar la seguridad y encapsular los sistemas de legado.”

- Roy Fielding, Estilos arquitectónicos y el diseño de arquitecturas de software basado en la red La Figura 3-5 muestra una de las formas en que la aplicación de taxi-graniza podría utilizar REST.

POST �trips

GET �passengers/<<passengerld>>

REST API

PASSENGER SMARTPHONE

201 CREATED

REST API

TRIP MANAGEMENT

200 OK

PASSENGER MANAGEMENT

Figura 3-5. Una aplicación de taxi-graniza utiliza interacción reparador.

Microservicios - Del diseño a la implementación de

29

Ch. 3 - Comunicación entre procesos

smartphone del pasajero solicita un viaje haciendo una ENVIAR solicitud a la / excursiones de recursos del Servicio de Gestión de viaje. Este servicio se encarga de la petición enviando una OBTENER Solicitud de información sobre el pasajero al servicio de gestión de pasajeros. Después de verificar que el pasajero está autorizado para crear un viaje, el servicio de administración de viaje crea el viaje y devuelve una 201 respuesta a los teléfonos inteligentes Muchos desarrolladores afirman sus APIs basadas en HTTP son REST. Sin embargo, como se describe en este Fielding entrada en el blog , No todos ellos son en realidad. Leonard Richardson (sin relación) define un muy útil modelo de madurez para REST que consta de los siguientes niveles:

• Nivel 0 - Clientes de una API de nivel 0 invocar el servicio al hacer HTTP ENVIAR peticiones a su exclusivo criterio de valoración URL. Cada solicitud especifica la acción a realizar, el objetivo de la acción (por ejemplo, el objeto de negocio), y cualquier parámetro.

• Nivel 1 - Un API de nivel 1 es compatible con la idea de los recursos. Para realizar una acción en un recurso, un cliente realiza una ENVIAR solicitud que especifica la acción a realizar y los parámetros

•

Nivel 2 - Un API de nivel 2 utiliza verbos HTTP para realizar acciones: OBTENER para recuperar, ENVIAR para crear y PONER actualizar. Los parámetros de consulta de solicitud y el cuerpo, en su caso, especificar los parámetros de la acción. Esto permite que los servicios aprovechar la infraestructura de red como para el almacenamiento en caché OBTENER peticiones

• Nivel 3 - El diseño de una API de nivel 3 se basa en el principio llamado terriblemente, HATEOAS (Hypertext como el motor del estado de la aplicación). La idea básica es que la representación de un recurso devuelto por una OBTENER solicitud contiene enlaces para realizar las acciones permitidas en ese recurso Por ejemplo, un cliente puede cancelar un pedido a través de un enlace en la representación de pedido devuelto en respuesta a la OBTENER solicitud enviada para recuperar el orden Uno de los beneficios de HATEOAS es incluir no tener que cablear URL en código de cliente. Otra ventaja es que debido a que la representación de un recurso contiene enlaces para las acciones permitidas, el cliente no tiene que adivinar qué acciones se pueden realizar en un recurso en su estado actual.

Existen numerosos beneficios de utilizar un protocolo basado en HTTP: • HTTP es simple y familiar. • Puede probar una API HTTP desde un navegador utilizando una extensión como Cartero , O desde la línea de comandos usando rizo ( asumiendo JSON o se utiliza algún otro formato de texto).

• Que apoya directamente la comunicación de solicitud / respuesta de estilo • HTTP es, por supuesto, con firewalls. • No requiere un corredor intermedio, lo que simplifica la arquitectura del sistema.

Microservicios - Del diseño a la implementación de

30

Ch. 3 - Comunicación entre procesos

Hay algunos inconvenientes a la utilización de HTTP:

• HTTP sólo admite directamente el estilo de solicitud / respuesta de la interacción. Se puede utilizar HTTP para las notificaciones, pero el servidor siempre debe enviar una respuesta HTTP.

• Debido a que el cliente y el servicio se comunican directamente (sin un intermediario para amortiguar los mensajes), ambos deben estar en ejecución para la duración del intercambio.

• El cliente debe conocer la ubicación (es decir, la URL) de cada instancia de servicio. Como se describe en Capitulo 2 sobre el API de puerta de enlace, este es un problema no trivial en un moderno Clientes aplicación debe utilizar un mecanismo de descubrimiento de servicios para localizar las instancias de servicio La comunidad de desarrolladores recientemente ha vuelto a descubrir el valor de un lenguaje de definición de interfaz para la API REST. Hay algunas opciones, incluyendo RAML y Pavonearse Algunos IDL, como Swagger, permiten definir el formato de los mensajes de petición y respuesta. Otros, como RAML, requieren el uso de una especificación separada como JSON esquema

Así como la descripción de las API, IDL suelen tener herramientas que generan stubs cliente y esqueletos de servidor de una definición de interfaz.

Ahorro

Apache Thrift es una alternativa interesante para descansar. Es un marco para la escritura crosslanguage RPC clientes y servidores. Ahorro ofrece un estilo IDL-C para la definición de sus APIs. Se utiliza el compilador de Ahorro para generar talones del lado del cliente y esqueletos de servidor. El compilador genera código para una variedad de idiomas, incluyendo C ++, Java, Python, PHP, Ruby, Erlang, y el Nodo js

Una interfaz Thrift consta de uno o más servicios. Una definición de servicio es análogo a una interfaz Java. Es una colección de métodos inflexible. métodos de Ahorro pueden o bien devolver un valor (posiblemente nula) o, si se definen como de una sola vía, ningún valor. Métodos que devuelven un valor implementar el estilo de solicitud / respuesta de la interacción; el cliente espera una respuesta y podría lanzar una excepción. Unidireccional métodos corresponden al estilo notificación de interacción; el servidor no envía una respuesta. Thrift soporta varios formatos de mensaje: JSON, binario, binario y compacto. Binario es más eficiente que JSON porque es más rápido para decodificar. Y, como su nombre indica, binario compacto es un formato de uso eficiente del espacio. JSON es, por supuesto, y el navegador humano-ambiente. Thrift también le da una opción de protocolos de transporte incluyendo TCP y HTTP sin formato. Raw TCP es probable que sea más eficiente que HTTP. Sin embargo, HTTP es compatible con firewalls, navegador de usar y amigable-humana.

formatos de los mensajes

Ahora que hemos visto HTTP y Thrift, vamos a examinar la cuestión de los formatos de mensaje. Si está utilizando un sistema de mensajería o de descanso, te dan a elegir el formato de mensaje. Otros mecanismos IPC como Thrift pueden soportar sólo un pequeño número de formatos de mensaje, o incluso sólo uno. En cualquier caso, es importante utilizar un mensaje entre lenguajes

Microservicios - Del diseño a la implementación de

31

Ch. 3 - Comunicación entre procesos

formato. Incluso si usted está escribiendo sus microservicios en un solo idioma hoy en día, lo más probable es que va a utilizar otros idiomas en el futuro.

Hay dos tipos principales de formatos de mensaje de texto y binarios. Ejemplos de formatos basados ​en texto incluyen JSON y XML. Una ventaja de estos formatos es que no sólo son legible por humanos, que son auto-descripción. En JSON, los atributos de un objeto están representados por una colección de pares de nombre y valor. Del mismo modo, en los atributos XML están representados por los elementos y valores con nombre. Esto permite a un consumidor de un mensaje de seleccionar los valores que le interesan e ignorar el resto consecuencia, los cambios menores en el formato de los mensajes se pueden hacer fácilmente compatible con versiones anteriores. La estructura de los documentos XML se especifica mediante una esquema XML Con el tiempo, la comunidad de desarrolladores ha dado cuenta de que JSON también necesita un mecanismo similar. Una opción es utilizar JSON esquema , Ya sea independiente o como parte de un IDL como Swagger. Una desventaja de usar un formato de mensaje basado en texto es que los mensajes tienden a ser prolijo, especialmente XML. Debido a que los mensajes son auto-descripción, cada mensaje contiene el nombre de los atributos, además de sus valores. Otro inconveniente es la sobrecarga de analizar texto. En consecuencia, es posible que desee considerar el uso de un formato binario. Hay varios formatos binarios para elegir. Si está utilizando RPC Thrift, puede utilizar Thrift binario. Si te dan a elegir el formato del mensaje, las opciones populares incluyen Los tampones de protocolo y Apache Avro . Ambos formatos proporcionan una IDL escrita a máquina para definir la estructura de los mensajes. Una diferencia, sin embargo, es que Protocol Buffers utiliza campos marcados, mientras que un consumidor Avro necesita saber el esquema con el fin de interpretar los mensajes. Como resultado, la evolución de la API es más fácil con Protocol Buffers que con Avro Este entrada en el blog es una excelente comparación de Thrift, Protocol Buffers y Avro.

Resumen Microservicios deben comunicarse a través de un mecanismo de comunicación entre procesos En el diseño de cómo sus servicios van a comunicarse, es necesario considerar varios aspectos: cómo interactúan los servicios, cómo especificar la API para cada servicio, cómo evolucionan las API, y cómo manejar el fracaso parcial . Hay dos tipos de mecanismos de IPC que microservicios pueden utilizar: mensajería asíncrona y síncrona petición / respuesta con el fin de comunicarse, un servicio debe ser capaz de encontrar otro. En Capítulo 4 vamos a ver el problema de descubrimiento de servicios en una arquitectura microservicios.

Microservicios - Del diseño a la implementación de

32

Ch. 3 - Comunicación entre procesos

Microservicios en Acción: Nginx y Arquitectura de aplicaciones por Floyd Smith Nginx le permite implementar diversas opciones de escala y de modo paralelo que hacen que su aplicación más sensible y altamente disponible. Las decisiones que tome para la ampliación y el reflejo afecta a cómo se hace la comunicación entre procesos, el tema de este capítulo.

Nosotros en Nginx recomienda tener en cuenta una arquitectura de cuatro niveles aplicación basada en la aplicación de sus microservicios Forrester tiene un informe detallado sobre el tema, que se puede descargar , Sin cargo, a partir de Nginx.

Los niveles representan clientes (el más nuevo de capa - incluyendo de escritorio o portátil y móvil, usable, o clientes IOT), la entrega, la agregación (incluido el almacenamiento de datos), y los servicios, que incorporan la funcionalidad de aplicaciones y específicas del servicio, en lugar de compartidos, almacenes de datos .

La arquitectura de cuatro niveles es mucho más flexible, escalable, sensible-amigable móvil, y de apoyo inherente del desarrollo de aplicaciones basadas en microservicios y la entrega de la arquitectura anterior, de tres niveles. líderes de la industria tales como Netflix y Uber son capaces de alcanzar el nivel de rendimiento de sus usuarios demandan debido a que utilizan este tipo de arquitectura. NGINX está inherentemente bien adaptado a la arquitectura de cuatro niveles, con capacidades que van desde los medios de transmisión para el nivel de cliente, para cargar el equilibrado y el almacenamiento en caché para el nivel de entrega, herramientas para el alto rendimiento y la comunicación segura basada en API en el nivel de agregación, y el apoyo para la gestión flexible de los casos servicios efímeras en el nivel de servicios. Esta misma flexibilidad hace posible la aplicación de la escala robusto y patrones de reflejo para manejar los cambios en los volúmenes de tráfico, para proteger contra ataques de seguridad, y para proporcionar una alta disponibilidad con configuraciones de conmutación por error disponibles en cualquier momento.

En estas arquitecturas más complejas, que incluyen servicio instanciación ejemplo ya que la demanda requiere y la necesidad de descubrimiento de servicio constante, desacoplados de comunicaciones entre procesos tienden a ser favorecidos. El asíncrono y uno-a-muchos estilos de comunicación aquí pueden ser más flexibles, y en última instancia, ofrecer un mayor rendimiento y fiabilidad, que los estilos de comunicación fuertemente acoplados.

Microservicios - Del diseño a la implementación de

33

Ch. 3 - Comunicación entre procesos

4

Descubrimiento de servicio

Este es el cuarto capítulo de este libro electrónico, que se trata de construir aplicaciones con microservicios Capítulo 1 introduce la microservicios patrón de Arquitectura y discutido las ventajas y los inconvenientes de la utilización microservicios. Capitulo 2 y Capítulo 3 describir los diferentes aspectos de la comunicación entre microservicios. En este capítulo, se explora el problema estrechamente relacionado de descubrimiento de servicios.

¿Por qué utilizar descubrimiento de servicios? Imaginemos que usted está escribiendo un código que invoca un servicio que tiene una API REST API o de segunda mano. Con el fin de hacer una solicitud, el código necesita saber la ubicación de red (dirección IP y puerto) de una instancia de servicio. En una aplicación tradicional que se ejecuta en hardware físico, las ubicaciones de red de instancias de servicio son relativamente estática. Por ejemplo, el código puede leer las ubicaciones de red a partir de un archivo de configuración que se actualiza de vez en cuando

En una aplicación moderna, basada en la nube microservicios, sin embargo, este es un problema mucho más difícil de resolver, como se muestra en la Figura 4-1.

instancias de servicio han asignado dinámicamente ubicaciones de red Por otra parte, el conjunto de instancias de servicio cambia de forma dinámica debido a escala automática, fracasos, y las actualizaciones En consecuencia, su código de cliente necesita utilizar un mecanismo de descubrimiento de servicios más elaborado

Microservicios - Del diseño a la implementación de

34

Ch. 4 - Servicio de Descubrimiento

Dynamically changing

Dynamically assigned

10.4.3.1:8756

REST API SERVICE INSTANCE A

Client or API Gateway

SERVICE CLIENT

Registry Client

10.4.3.99:4545

?

REST API SERVICE INSTANCE B

Registry Client

10.4.3.20:333

REST API SERVICE INSTANCE C

How to load balance?

Registry Client

La Figura 4-1. Un cliente o puerta de enlace API necesita servicios hallazgo de ayuda.

Hay dos patrones principales de descubrimiento de servicios: el descubrimiento del lado del cliente y el descubrimiento del lado del servidor. Veamos primero en el descubrimiento del lado del cliente.

El patrón de descubrimiento del lado del cliente Cuando usas patrón de descubrimiento del lado del cliente , El cliente es responsable de determinar las ubicaciones de red de instancias de servicios disponibles y las solicitudes de equilibrio de carga a través de ellos. El cliente consulta un registro de servicios, que es una base de datos de instancias de servicio disponibles. Luego, el cliente utiliza un algoritmo de balanceo de carga para seleccionar una de las instancias de servicio disponibles y hace una petición

Microservicios - Del diseño a la implementación de

35

Ch. 4 - Servicio de Descubrimiento

La figura 4-2 muestra la estructura de este patrón:

10.4.3.1:8756

SERVICE INSTANCE A

REST API SERVICE INSTANCE A

Registryaware HTTP Client

Registry Client

10.4.3.99:4545 REST API SERVICE INSTANCE B

Registry Client

10.4.3.20:333

SERVICE REGISTRY

REST API SERVICE INSTANCE C

Registry Client

La Figura 4-2. Los clientes pueden asumir la tarea de descubrir los servicios.

La ubicación de red de una instancia de servicio se ha registrado en el registro de servicios cuando se pone en marcha. Se elimina del registro de servicios cuando la instancia termina. registro de la instancia de servicio es típicamente actualiza periódicamente utilizando un mecanismo de latido del corazón. Netflix OSS proporciona un gran ejemplo del patrón de descubrimiento del lado del cliente. Netflix Eureka es un registro de servicios. Proporciona una API REST para gestionar el registro del servicio de la instancia y para la consulta de las instancias disponibles. cinta de Netflix es un cliente de IPC que trabaja con Eureka para cargar consultas de saldo a través de las instancias de servicio disponibles Discutiremos Eureka en más profundidad más adelante en este capítulo

Microservicios - Del diseño a la implementación de

36

Ch. 4 - Servicio de Descubrimiento

El patrón de descubrimiento del lado del cliente tiene una variedad de ventajas y desventajas. Este patrón es relativamente sencillo y, a excepción del registro de servicios, no hay otras piezas móviles Además, dado que el cliente sabe acerca de los casos de servicios disponibles, puede tomar decisiones de equilibrio de carga específicos de la aplicación inteligentes como el uso de hashing consistente. Un inconveniente importante de este patrón es que las parejas del cliente con el registro de servicios. Debe implementar la lógica del lado del cliente de descubrimiento de servicios para cada lenguaje de programación y el marco utilizado por sus clientes de servicios.

Ahora que hemos visto descubrimiento del lado del cliente, vamos a echar un vistazo a el descubrimiento del lado del servidor

El patrón de descubrimiento del lado del servidor El otro enfoque para el descubrimiento de servicios es el patrón de descubrimiento de servidor La figura 4-3 muestra la estructura de este patrón:

10.4.3.1:8756

REQUEST SERVICE INSTANCE A

REST API SERVICE INSTANCE A

ROUTER

Registry Client

LOAD BALANCE

10.4.3.99:4545

QUERY

REST API SERVICE INSTANCE B

Registry Client

SERVICE REGISTRY

REGISTER

10.4.3.20:333

REST API SERVICE INSTANCE C

Registry Client

La Figura 4-3. descubrimiento de servicios también puede ser manejado entre los servidores.

El cliente realiza una solicitud a un servicio a través de un equilibrador de la carga El equilibrador de carga consulta el registro de servicios y rutas cada solicitud a una instancia de servicio disponible Al igual que con el descubrimiento del lado del cliente, las instancias de servicio se registran y se elimine el registro con el registro de servicio de la AWS Elastic Load Balancer (ELB) es un ejemplo de un router descubrimiento del lado del servidor. ELB se utiliza comúnmente para equilibrar la carga de tráfico externo a través de Internet. Sin embargo, también se puede utilizar para cargar ELB tráfico de equilibrio que es interno a una nube privada virtual (VPC).

Microservicios - Del diseño a la implementación de

37

Ch. 4 - Servicio de Descubrimiento

Un cliente realiza peticiones HTTP (o TCP) a través del ELB utilizando su nombre DNS. La carga ELB equilibra el tráfico entre un conjunto de casos registrados Elastic Compute Cloud (EC2) o recipientes EC2 Servicio de contenedor (ECS). No hay un registro de servicios visibles por separado. En su lugar, las instancias de EC2 y contenedores ECS están registrados en la propia ELB. servidores HTTP y los equilibradores de carga, tales como Nginx Plus y NGINX también se puede utilizar como un equilibrador de carga descubrimiento del lado del servidor Por ejemplo, este entrada en el blog describe el uso de la plantilla Consul para reconfigurar dinámicamente NGINX proxy inverso. Plantilla cónsul es una herramienta que se regenera periódicamente archivos de configuración arbitraria a partir de datos de configuración almacenados en la registro de servicios Cónsul . Se ejecuta un comando shell arbitrarios cada vez que cambien los archivos. En el ejemplo descrito en la entrada del blog, Plantilla Consul genera una nginx.conf

archivo, que configura el proxy inverso, y luego ejecuta un comando que dice Nginx para recargar la configuración. Una aplicación más sofisticada podría reconfigurar dinámicamente Nginx Plus utilizando su API HTTP o DNS Algunos entornos de implementación, como Kubernetes y Maratón ejecutar un proxy en cada host en el clúster. El proxy desempeña el papel de un equilibrador de carga descubrimiento del lado del servidor. Con el fin de hacer una petición a un servicio, un cliente de la solicitud de rutas a través del proxy utilizando la dirección IP del host y el puerto asignado al servicio. El proxy reenvía la solicitud de forma transparente a una instancia de servicio disponible que ejecute alguna parte de la agrupación El patrón de descubrimiento de servidor tiene varias ventajas y desventajas. Una gran ventaja de este modelo es que los detalles del descubrimiento se abstraen de distancia desde el cliente. Los clientes simplemente hacen peticiones al equilibrador de carga Esto elimina la necesidad de implementar la lógica de descubrimiento para cada lenguaje de programación y el marco utilizado por sus clientes de servicios. Además, como se mencionó anteriormente, algunos entornos de despliegue que proporcionan esta funcionalidad de forma gratuita. Este patrón también tiene algunos inconvenientes,

El Service Registry los registro de servicios es una parte clave del descubrimiento de servicios. Es una base de datos que contiene las ubicaciones de red de instancias de servicio. Un registro de servicios tiene que ser altamente disponible y actualizada. Los clientes pueden almacenar en caché ubicaciones de red obtenidos en el registro de servicio. Sin embargo, dicha información eventualmente se convierte fuera de fecha y clientes vuelven incapaces de descubrir instancias de servicio. En consecuencia, un registro de servicios consiste en un grupo de servidores que utilizan un protocolo de replicación para mantener la consistencia Como se mencionó anteriormente, Netflix Eureka es buen ejemplo de un registro de servicios. Proporciona una API REST para registrar y consultar instancias de servicio. Una instancia de servicio registra su ubicación en la red utilizando una ENVIAR solicitud. Cada 30 segundos se debe actualizar su registro utilizando una PONER solicitar un registro se elimina, ya sea usando un HTTP BORRAR solicitud o por el tiempo de registro instancia a cabo Como era de esperar, un cliente puede recuperar las instancias de servicio registradas mediante el uso de un servidor HTTP OBTENER solicitud

Microservicios - Del diseño a la implementación de

38

Ch. 4 - Servicio de Descubrimiento

Netflix se consigue una alta disponibilidad mediante la ejecución de uno o más servidores de Eureka en cada zona de disponibilidad de Amazon EC2 Cada servidor Eureka se ejecuta en una instancia EC2 que tiene una dirección IP elástica DNS TEXTO los registros se utilizan para almacenar la configuración de clúster Eureka, que es un mapa de zonas de disponibilidad a una lista de las ubicaciones de red de los servidores de Eureka. Cuando un servidor de Eureka se inicia, consulta DNS para recuperar la configuración de clúster de Eureka, localiza sus pares, y asigna una dirección IP propia elástico sin usar.

clientes Eureka - servicios y clientes de servicios - consulta DNS para descubrir los lugares de la red de servidores de Eureka. Los clientes prefieren utilizar un servidor de Eureka en la misma zona de disponibilidad. Sin embargo, si no hay ninguno disponible, el cliente utiliza un servidor de Eureka en otra zona de disponibilidad. Otros ejemplos de registros de servicio incluyen:

• ETCD - A, distribuido, consistente, almacén de claves-valor altamente disponible que se utiliza para la configuración compartida y descubrimiento de servicios. Dos proyectos notables que utilizan ETCD son Kubernetes y cloud Foundry

•

Cónsul - Una herramienta para el descubrimiento y la configuración de servicios. Proporciona una API que permite a los clientes registrarse y descubre los servicios. Cónsul puede realizar controles de salud para determinar la disponibilidad del servicio

• Apache ZooKeeper - Un ampliamente utilizado, de alto rendimiento servicio de coordinación para las aplicaciones distribuidas. Apache ZooKeeper fue originalmente un subproyecto de Hadoop, pero ahora es un proyecto independiente, de alto nivel

Además, como se señaló anteriormente, algunos sistemas como Kubernetes, Maratón, y AWS no tienen un registro de servicios explícita. En cambio, el registro de servicios es sólo una parte integrada de la infraestructura.

Ahora que hemos visto el concepto de un registro de servicios, vamos a ver cómo las instancias de servicio se registran en el registro de servicios

Opciones de servicio de registro Como se mencionó anteriormente, las instancias de servicio deben estar registrados y no registrados desde el registro de servicios. Hay un par de diferentes maneras de manejar el registro y la anulación del registro. Una opción es que las instancias de servicio se registren, de la patrón de autoinscripción . La otra opción es por algún otro componente del sistema para gestionar el registro de instancias de servicio, la patrón de registro de terceros . Veamos primero el patrón de auto-registro.

El patrón de registro automático Cuando se utiliza el patrón de auto-registro , Una instancia de servicio se encarga de registrar y anular el registro en sí con el registro de servicios. Además, si es necesario, una instancia de servicio envía peticiones de los latidos del corazón para prevenir su registro a expirar.

Microservicios - Del diseño a la implementación de

39

Ch. 4 - Servicio de Descubrimiento

Figura 4-4 muestra la estructura de este patrón.

10.4.3.1:8756

REST API SERVICE INSTANCE A

register(”serviceName, “10.4.3.1:8756”) heartbeat() unregister()

SERVICE REGISTRY

La Figura 4-4. Los servicios pueden manejar su propio registro.

Un buen ejemplo de este enfoque es la Netflix cliente OSS Eureka El cliente Eureka maneja todos los aspectos del registro instancia de servicio y eliminación del registro. los proyecto de la nube de primavera , Que implementa diversos patrones incluyendo el descubrimiento de servicios, hace que sea fácil para registrar automáticamente una instancia de servicio con Eureka. Sólo tiene que anotar la clase de configuración de Java con un @ EnableEurekaClient anotación

El patrón de auto-registro tiene varias ventajas y desventajas. Uno de los beneficios es que es relativamente simple y no requiere otros componentes del sistema Sin embargo, un inconveniente importante es que las parejas las instancias de servicio en el registro del servicio debe implementar el código de registro en cada lenguaje de programación y el marco utilizado por sus servicios

El enfoque alternativo, que desacopla los servicios del registro de servicios, es el patrón de registro de terceros

Microservicios - Del diseño a la implementación de

40

Ch. 4 - Servicio de Descubrimiento

El patrón de registro de terceros Cuando se utiliza el patrón de registro de terceros , Instancias de servicio no son responsables de registrar a sí mismos con el registro de servicios En cambio, otro componente del sistema conocido como el registrador de servicio maneja el registro El registrador servicio de seguimiento de los cambios en el conjunto de instancias que funcionan por el sondeo del entorno de despliegue o suscribirse a los eventos Cuando se da cuenta de una instancia de servicio recientemente disponible, se registra la instancia con el registro de servicios El registrador servicio también anula el registro de instancias de servicio terminados

La figura 4-5 muestra la estructura de este patrón:

10.4.3.1:8756

REST API

HEALTHCHECK SERVICE INSTANCE A

REGISTRAR

register(”serviceName, “10.4.3.1:8756”) heartbeat() unregister()

SERVICE REGISTRY

La Figura 4-5. Un servicio de registro por separado puede ser responsable de registrar otros.

Un ejemplo de un registrador de servicio es el de código abierto Registrator proyecto Se registra de forma automática y las instancias de servicio anula el registro que se implementan como acoplable contenedores Registrator soporta varios registros de servicio, incluyendo ETCD y Cónsul Otro ejemplo de un registrador de servicio es NetflixOSS Prana . Principalmente destinados a los servicios escritos en idiomas que no son de JVM, es una aplicación que se ejecuta el coche lateral al lado de una instancia de servicio. Prana registra y anula el registro de la instancia de servicio con Netflix Eureka. El registrador de servicio es un componente integrado en algunos entornos de despliegue Las instancias de EC2 creadas por un grupo Autoscaling se pueden registrar de forma automática con una empresa de servicios ELB Kubernetes se registran automáticamente y puestos a disposición para el descubrimiento.

Microservicios - Del diseño a la implementación de

41

Ch. 4 - Servicio de Descubrimiento

El patrón de registro de terceros tiene varias ventajas y desventajas. Una ventaja importante es que los servicios están desacoplados del registro de servicios. No es necesario para implementar la lógica del registro de servicio para cada lenguaje de programación y el marco utilizado por los desarrolladores En cambio, el registro instancia de servicio se maneja de una manera centralizada en un servicio dedicado

Un inconveniente de este modelo es que a menos que se construye en el entorno de despliegue, que es otro componente del sistema de alta disponibilidad que usted necesita para configurar y administrar

Resumen En una aplicación microservicios, el conjunto de funcionamiento instancias de servicio cambia dinámicamente. Los casos han asignado dinámicamente ubicaciones de red. En consecuencia, para que un cliente para hacer una petición a un servicio que debe utilizar un mecanismo de servicio-descubrimiento Una parte clave de descubrimiento de servicios es el registro de servicios El registro de servicios es una base de datos de instancias de servicio disponibles. El registro de servicios proporciona una API de gestión y una API de consulta. instancias de servicio están registrados y no registrados con el registro de servicios mediante la API de gestión de la API de consulta es utilizado por los componentes del sistema para descubrir instancias de servicio disponibles

Hay dos patrones principales de servicios de descubrimiento: el descubrimiento del lado del cliente y el descubrimiento del lado del servicio En los sistemas que utilizan descubrimiento de servicios del lado del cliente , Los clientes consultar el registro de servicios, seleccione una instancia disponibles, y hacer una solicitud En los sistemas que utilizan descubrimiento serverside , Los clientes hacen peticiones a través de un router, que consulta el registro de servicio y envía la solicitud a una instancia disponible.

Hay dos principales formas en que las instancias de servicio son marcas registradas y no registradas con el registro de servicios. Una opción es que las instancias de servicio a fin de registrarse en el registro de servicios, el patrón de auto-registro . La otra opción es por algún otro componente del sistema para manejar el registro y la anulación del registro en nombre del servicio, el patrón de registro de terceros

En algunos entornos de despliegue que necesita para configurar su propia infraestructura de servicios-descubrimiento usando un registro de servicios tales como Netflix Eureka , ETCD o Apache ZooKeeper

En otros entornos de despliegue, el descubrimiento de servicios se basa en, por ejemplo, Kubernetes y Maratón manejar el registro instancia de servicio y eliminación del registro También tienen un proxy en cada host del clúster que desempeña el papel de descubrimiento del lado del servidor enrutador Un HTTP proxy inverso y equilibrador de carga tales como NGINX también se pueden utilizar como un equilibrador de carga descubrimiento serverside. El registro de servicios puede empujar a la información de enrutamiento a Nginx e invocar una actualización de configuración grácil; por ejemplo, puede utilizar Plantilla cónsul Nginx soportes Plus mecanismos de reconfiguración dinámica adicionales - puede extraer información sobre las instancias de servicio desde el registro mediante DNS, y proporciona una API para la reconfiguración remota.

Microservicios - Del diseño a la implementación de

42

Ch. 4 - Servicio de Descubrimiento

Microservicios en Acción: Nginx Flexibilidad por Floyd Smith En un entorno microservicios, la infraestructura de backend es probable que estar constantemente cambiando a medida que los servicios se crean, desplegadas, y se escalan hacia arriba y abajo como resultado de AutoScaling, fracasos y actualizaciones Como se describe en este capítulo, se requiere un mecanismo de descubrimiento de servicios en entornos donde ubicaciones de servicio son reasignados dinámicamente

Parte de los beneficios de utilizar Nginx para microservicios es que se puede configurar fácilmente para reaccionar automáticamente a los cambios en la infraestructura de back-end. configuración de Nginx no sólo es fácil y flexible, también es compatible con el uso de plantillas, como utilizado en Amazon Web Services , Por lo que es más fácil de gestionar los cambios para un servicio específico y gestionar el cambio de conjuntos de servicios sujetos a equilibrio de carga

Nginx Plus cuenta con una sobre la marcha de la API reconfiguración , Eliminando la necesidad de reiniciar Nginx Plus o vuelva a cargar manualmente su configuración conseguirlo para reconocer cambios en el conjunto de los servicios que el equilibrio de carga Nginx Plus Release 8 y versiones posteriores , Los cambios que realice con la API se pueden configurar para persistir en los reinicios y recargas de configuración. (Vuelve a cargar no requieren un reinicio y no bajan de conexiones.) Y Nginx Plus Release 9 y posterior tener soporte para el descubrimiento de servicios de DNS usando SRV registros, lo que permite una mayor integración con plataformas de descubrimiento de servidor existentes, tales como Consul y ETCD

Estamos aquí, en Nginx hemos creado un modelo de gestión de descubrimiento de servicios: 1. Run contenedores acoplables separadas para cada una de varias aplicaciones, incluyendo una aplicación de descubrimiento de servicios tal como ETCD, una herramienta de registro de servicio, uno o más servidores de fondo, y la propia NGINX Plus para equilibrar la carga de los otros contenedores

2. La herramienta de registro supervisa acoplable para los nuevos contenedores y registra nuevos servicios con la herramienta de descubrimiento de servicios, también la eliminación de los recipientes que desaparecen

3. Envases y los servicios que corren se añaden automáticamente a o eliminado del grupo de servidores upstream de carga equilibrada aplicaciones de demostración para este proceso están disponibles para varias aplicaciones al servicio de descubrimiento: API Consul , DNS

SRV registros de Cónsul , ETCD y ZooKeeper

Microservicios - Del diseño a la implementación de

43

Ch. 4 - Servicio de Descubrimiento

5

Gestión de datos controlada por eventos de microservicios

Este es el quinto capítulo de este libro electrónico sobre la creación de aplicaciones con microservicios. los primer capítulo introduce el patrón microservicios Arquitectura y discute las ventajas y los inconvenientes de la utilización microservicios. los segundo y tercero describir los diferentes aspectos de la comunicación dentro de una arquitectura microservicios. los cuarto capítulo explora el problema estrechamente relacionado de descubrimiento de servicios. En este capítulo, se cambia de marcha y miramos a los problemas de gestión de datos distribuidos que se presentan en una arquitectura microservicios

Microservicios y el problema de gestión de datos distribuidos Una aplicación monolítica tiene típicamente una sola base de datos relacional. Un beneficio clave de la utilización de una base de datos relacional es que su aplicación puede utilizar transacciones ACID , Que ofrece importantes garantías:

•

Atomicidad - Los cambios se realizan de forma atómica

• Consistencia - El estado de la base de datos siempre es coherente • Aislamiento - A pesar de que las transacciones se ejecutan al mismo tiempo, parece que se ejecutan en serie • Durable - Una vez que una transacción ha cometido, no se deshace Como resultado, la aplicación puede simplemente comenzar una transacción, el cambio (insertar, actualizar y eliminar) varias filas, y confirmar la transacción.

Microservicios - Del diseño a la implementación de

44

Ch. 5 - orientada a eventos gestión de datos para microservicios

Otra gran ventaja de utilizar una base de datos relacional es que proporciona SQL, que es un lenguaje rico, declarativa, y estandarizada consulta Se puede escribir una consulta que combina datos de varias tablas. El planificador de consulta RDBMS determina entonces la mejor manera de ejecutar la consulta Usted no tiene que preocuparse por los detalles de bajo nivel, tales como la forma de acceder a la base de datos. Y, debido a que todos los datos de la aplicación se encuentra en una base de datos, es fácil para consultar

Por desgracia, el acceso a datos se vuelve mucho más complejo cuando nos movemos a una arquitectura microservicios Eso se debe a que los datos de propiedad de cada uno es microService privado a que microService y sólo se puede acceder a través de su API encapsulado de datos se asegura que las microservicios están libremente acoplados y pueden evolucionar independientemente uno de otro. Si hay varios servicios de acceso a los mismos datos, actualizaciones del esquema requieren cambios coordinados, que consumen mucho tiempo a todos los servicios.

Para empeorar las cosas, diferentes microservicios menudo utilizan diferentes tipos de bases de datos. tienda de aplicaciones modernas y procesos diversos tipos de datos y una base de datos relacional no es siempre la mejor opción. Para algunos casos de uso, una base de datos NoSQL en particular puede tener un modelo de datos más conveniente y ofrecer un mejor rendimiento y escalabilidad. Por ejemplo, tiene sentido para un servicio que almacena y consultas de texto que utilizan un motor de búsqueda de texto como Elasticsearch Del mismo modo, un servicio que almacena los datos del gráfico sociales probablemente tendrá que usar una base de datos gráfica, tales como Neo4j En consecuencia, las aplicaciones basadas en microservicios utilizan a menudo una mezcla de bases de datos SQL y NoSQL, el llamado persistencia políglota enfoque

A, arquitectura políglota-persistente repartió para almacenamiento de datos tiene muchos beneficios, incluyendo servicios débilmente acoplados y un mejor rendimiento y la escalabilidad. Sin embargo, no introducir algunos retos de gestión de datos distribuidos

El primer desafío es cómo implementar las transacciones comerciales que mantienen la consistencia a través de múltiples servicios. Para ver por qué esto es un problema, vamos a echar un vistazo a un ejemplo de una tienda en línea B2B. El Servicio al Cliente mantiene información sobre los clientes, incluyendo sus líneas de crédito. La orden de servicio gestiona órdenes y debe verificar que un nuevo orden no viola el límite de crédito del cliente. En la versión monolítica de esta solicitud, la orden de servicio puede simplemente usar una transacción ACID para comprobar el crédito disponible y crear la orden

Microservicios - Del diseño a la implementación de

45

Ch. 5 - orientada a eventos gestión de datos para microservicios

Por el contrario, en una arquitectura microservicios las tablas orden y cliente están privados de sus respectivos servicios, como se muestra en la Figura 5-1:

La Figura 5-1. Microservicios tienen cada uno sus propios datos.

La orden de servicio no puede acceder a la tabla cliente directamente Sólo puede utilizar la API proporcionada por el Servicio al Cliente de la orden de servicio podría usar potencialmente transacciones distribuidas , También conocida como confirmación en dos fases (2PC). Sin embargo, 2PC por lo general no es una opción viable en aplicaciones modernas El teorema de CAP exige que elegir entre la disponibilidad y la consistencia de estilo ACID, y la disponibilidad suele ser la mejor opción Por otra parte, muchas de las tecnologías modernas, como la mayoría de las bases de datos NoSQL, no son compatibles con 2PC Mantener la consistencia de datos a través de servicios y bases de datos es esencial, por lo que necesitamos otra solución

El segundo reto es cómo implementar las consultas que recuperan datos de múltiples servicios Por ejemplo, imaginemos que la aplicación debe mostrar un cliente y sus últimos pedidos. Si la orden de servicio proporciona una API para recuperar los pedidos de un cliente, entonces puede recuperar estos datos usando un lado de la aplicación se unen a la aplicación recupera el cliente del servicio al cliente y pedidos de los clientes de la orden de servicio. Supongamos, sin embargo, que la orden de servicio sólo es compatible con la búsqueda de las órdenes de su clave primaria (tal vez se utiliza una base de datos NoSQL que sólo es compatible con las recuperaciones basadas en la clave principal). En esta situación, no hay manera obvia para recuperar los datos necesarios.

Microservicios - Del diseño a la implementación de

46

Ch. 5 - orientada a eventos gestión de datos para microservicios

Arquitectura dirigido por eventos Para muchas aplicaciones, la solución es utilizar una arquitectura orientada a eventos En esta arquitectura, un microService publica un evento cuando algo notable sucede, por ejemplo, cuando se actualiza una entidad de negocio Otros microservicios suscribirse a los eventos Cuando un microService recibe un evento que puede actualizar sus propias entidades de negocio, lo que podría conducir a más eventos que se publicó

Puede usar los eventos para implementar las transacciones comerciales que abarcan múltiples servicios Una transacción consiste en una serie de pasos. Cada paso consiste en una microService actualización de una entidad comercial y la publicación de un evento que desencadena el siguiente paso. La siguiente secuencia de diagramas muestra cómo se puede utilizar un enfoque orientado a eventos a la comprobación de crédito disponible al crear un pedido.

Los eventos de intercambio microservicios través de un mensaje Broker:

• La orden de servicio crea un pedido con el estado de NUEVO y publica un evento orden creado

La Figura 5-2. La orden de servicio publica un evento.

Microservicios - Del diseño a la implementación de

47

Ch. 5 - orientada a eventos gestión de datos para microservicios

• El servicio al cliente consume el evento orden creado, el crédito reservas para el fin, y publica un

evento de crédito Reservados

La Figura 5-3. El Servicio al Cliente responde.

• La orden de servicio consume el evento reservado crédito y cambia el estado de la orden de abrir

La Figura 5-4. La orden de servicio actúa sobre la respuesta.

Un escenario más complejo podría incluir medidas adicionales, tales como la reserva de inventario al mismo tiempo que se comprueba el crédito del cliente

Microservicios - Del diseño a la implementación de

48

Ch. 5 - orientada a eventos gestión de datos para microservicios

A condición de que (a) cada servicio actualiza la base de datos de forma atómica y publica un evento

- lo veremos más adelante - y (b) las garantías Message Broker que los eventos se entregan al menos una vez, entonces se puede poner en práctica las transacciones comerciales que abarcan múltiples servicios, es importante tener en cuenta que estos no son transacciones ACID. Ofrecen garantías mucho más débiles, tales como consistencia eventual . Este modelo de transacción ha sido referido como el modelo base

También puede utilizar los eventos para mantener las vistas materializadas que la pre-Unir datos de propiedad de múltiples microservicios El servicio que mantiene la vista se suscribe a los eventos relevantes y actualiza la vista de la Figura 5-5 representa un pedido del cliente Ver Servicio de actualización que actualiza el pedido del cliente Ver basado en eventos publicados por el Servicio de atención al cliente y la orden de servicio

Figura 5-5. El pedido del cliente Vista se accede por dos servicios.

Cuando el cliente Order Ver Servicio de actualización recibe un evento de cliente o una orden, se actualiza la Orden al cliente Ver almacén de datos Se podría implementar el pedido del cliente Ver el uso de una base de datos de documentos tales como MongoDB y almacenar un documento para cada cliente. El pedido del cliente del servicio de consulta Ver maneja las peticiones de un cliente y pedidos recientes mediante la consulta del cliente Order Ver almacén de datos de una arquitectura orientada a eventos tiene varias ventajas y desventajas. Permite la ejecución de transacciones que abarcan múltiples servicios y proporcionan consistencia eventual. Otra ventaja es que también permite que una aplicación para mantener vistas materializadas

Microservicios - Del diseño a la implementación de

49

Ch. 5 - orientada a eventos gestión de datos para microservicios

Un inconveniente es que el modelo de programación es más compleja que cuando se utiliza transacciones ACID. A menudo se debe implementar transacciones de compensación para recuperarse de fallas a nivel de aplicación; por ejemplo, se debe cancelar un pedido si no pasa la verificación de crédito. Además, las aplicaciones deben tratar con datos inconsistentes que se debe a los cambios realizados por transacciones en vuelo son visibles. La aplicación también puede ver inconsistencias si se lee de una vista materializada que aún no se actualiza. Otro inconveniente es que los abonados deben detectar e ignorar los eventos duplicados

El logro de atomicidad En una arquitectura orientada a eventos también existe el problema de la actualización atómicamente la base de datos y la publicación de un evento, por ejemplo, la orden de servicio debe insertar una fila en la tabla de orden y publicar una Orden Creado caso, es indispensable que estas dos operaciones se realizan de forma atómica . Si el servicio se bloquea después de la actualización de la base de datos, pero antes de publicar el evento, el sistema se vuelve inconsistente. La manera estándar para garantizar la atomicidad es utilizar una transacción distribuida que implica la base de datos y el mensaje Broker. Sin embargo, por las razones descritas anteriormente, tales como el teorema de CAP, esto es exactamente lo que no queremos hacer

La publicación de eventos utilizando las transacciones locales Una forma de lograrlo es la atomicidad de la aplicación para publicar eventos utilizando una proceso de múltiples etapas que implica sólo las transacciones locales El truco es tener una tabla de eventos, que funciona como una cola de mensajes, en la base de datos que almacena el estado de las entidades empresariales. La aplicación inicia una transacción de base de datos (local), actualiza el estado de las entidades de negocios, inserta un evento en la tabla de eventos, y confirma la transacción Un hilo aplicación separada o proceso consulta la tabla de eventos, publica los eventos a la Message Broker, y a continuación, utiliza una transacción local para marcar los eventos tal como se publicó la Figura 5-6 muestra el diseño

Figura 5-6. El logro de la atomicidad de las transacciones locales.

Microservicios - Del diseño a la implementación de

50

Ch. 5 - orientada a eventos gestión de datos para microservicios

La orden de servicio inserta una fila en la tabla Order e inserta una orden creado evento en la tabla de eventos. El hilo Editorial evento o proceso de consulta la tabla de eventos para eventos inéditos, publica los eventos, y luego actualiza la tabla de eventos para marcar los eventos según lo publicado

Este enfoque tiene varias ventajas y desventajas. Uno de los beneficios es que garantiza un evento se publica para cada actualización sin depender de 2PC. Además, la aplicación publica eventos a nivel de negocio, lo que elimina la necesidad de inferir ellos. Un inconveniente de este enfoque es que es potencialmente propenso a errores ya que el desarrollador debe recordar a publicar eventos. Una limitación de este enfoque es que es difícil de poner en práctica al utilizar algunas bases de datos NoSQL debido a sus capacidades de transacción y de consulta limitados. Este enfoque elimina la necesidad de 2PC haciendo que la aplicación utilice las transacciones locales para actualizar el estado y publicar eventos Vamos ahora mira un enfoque que logra la atomicidad por tener la aplicación simplemente actualizar el estado

La minería una base de datos de registro de transacciones Otra forma de conseguir la atomicidad sin 2PC es para los eventos que se publicarán por un proceso o subproceso que las minas de transacción de la base de datos o registro de confirmación La aplicación actualiza la base de datos, por lo que los cambios se registran en las transacciones de la base de datos de registro El hilo del registro de transacciones Miner o proceso lee el registro de transacciones y publica eventos a la Message Broker Figura 5-7 muestra el diseño

La Figura 5-7. A Message Broker puede arbitrar las transacciones de datos.

Microservicios - Del diseño a la implementación de

51

Ch. 5 - orientada a eventos gestión de datos para microservicios

Un ejemplo de este enfoque es el de código abierto LinkedIn Databus proyecto de bus de datos minas del registro de transacciones de Oracle y publica eventos correspondientes a los cambios en LinkedIn utiliza bus de datos para mantener varios almacenes de datos derivados en consonancia con el sistema de registro. Otro ejemplo es el mecanismo de flujos de AWS DynamoDB , Que es una base de datos NoSQL administrado. Una corriente DynamoDB contiene la secuencia de tiempo-ordenada de cambios (crear, actualizar y borrar operaciones) realizados a los elementos de una tabla de DynamoDB en las últimas 24 horas. Una aplicación puede leer esos cambios con respecto a la corriente y, por ejemplo, publicar como eventos

minería de registro de transacciones tiene varias ventajas y desventajas. Uno de los beneficios es que garantiza que un evento se publica para cada actualización sin necesidad de utilizar 2PC. minería de registro de transacciones también puede simplificar la aplicación mediante la separación de la publicación de sucesos de la lógica de negocio de la aplicación. Una desventaja importante es que el formato del registro de transacciones es propiedad de cada base de datos y puede incluso cambiar entre las versiones de bases de datos Además, puede ser difícil de realizar ingeniería inversa a los eventos de negocios de alto nivel de los cambios de bajo nivel registrado en el registro de transacciones

minería de registro de transacciones elimina la necesidad de 2PC por tener la aplicación hacer una cosa: actualizar la base de datos. Vamos a ver ahora un enfoque diferente que elimina las actualizaciones y se basa únicamente en los eventos

El uso de Abastecimiento de eventos abastecimiento acontecimiento atomicidad logra sin 2PC mediante el uso de un enfoque radicalmente diferente, eventcentric a la persistencia de las entidades empresariales. En lugar de almacenar el estado actual de una entidad, la aplicación almacena una secuencia de eventos de cambio de estado. La aplicación reconstruye estado actual de la entidad mediante la reproducción de los eventos. Cada vez que el estado de una entidad de negocio cambia, un nuevo evento se añade a la lista de eventos. Dado que el ahorro de un evento es una sola operación, es inherentemente atómica

Para ver cómo funciona evento de abastecimiento, considere la entidad Orden como un ejemplo en un enfoque tradicional, cada uno de los mapas fin de una fila en una tabla de orden y filas en, por ejemplo, una mesa ORDER_LINE_ITEM

Sin embargo, cuando se utiliza el abastecimiento caso, la orden de servicio almacena una Orden en la forma de sus eventos de cambio de estado: Creado, Aprobado, enviado, cancelado Cada evento contiene datos suficientes para reconstruir el estado de la Orden.

Microservicios - Del diseño a la implementación de

52

Ch. 5 - orientada a eventos gestión de datos para microservicios

Figura 5-8. Los eventos pueden tener datos completos de recuperación.

Eventos persisten en una tienda de eventos, que es una base de datos de eventos. La tienda tiene una API para añadir y recuperar eventos de una entidad de la tienda de eventos también se comporta como el Message Broker en las arquitecturas ya hemos descrito anteriormente Proporciona una API que permite a los servicios para suscribirse a eventos de la tienda Evento proporciona todos los eventos a todos los abonados interesados ​el evento tienda es la columna vertebral de una arquitectura orientada a eventos microservicios. abastecimiento acontecimiento tiene varias ventajas. Se resuelve uno de los problemas clave en la implementación de una arquitectura orientada a eventos y hace posible la publicación fiable eventos cada vez que cambia el estado como resultado, que resuelve los problemas de consistencia de datos en una arquitectura microservicios Además, debido a que persiste eventos en lugar de objetos de dominio, sobre todo evita la problema de falta de concordancia objetorelacional abastecimiento acontecimiento también proporciona un registro de auditoría fiable al 100% de los cambios realizados en una entidad comercial y hace que sea posible implementar consultas temporales que determinan el estado de una entidad en cualquier punto en el tiempo. Otra ventaja importante de abastecimiento caso es que la lógica de negocio se compone de entidades de negocios débilmente acoplados que intercambian eventos. Esto hace que sea mucho más fácil la migración de una aplicación monolítica a una arquitectura microservicios

abastecimiento evento también tiene algunos inconvenientes. Es un estilo diferente y desconocida de programación y lo que hay una curva de aprendizaje El almacén de eventos sólo soporta directamente las operaciones de búsqueda de entidades de negocio mediante la clave primaria. Debes usar comando de separación de responsabilidad consulta (CQRS) para implementar consultas. Como resultado, las aplicaciones deben manejar datos consistentes con el tiempo

Microservicios - Del diseño a la implementación de

53

Ch. 5 - orientada a eventos gestión de datos para microservicios

Resumen En una arquitectura microservicios, cada microService tiene su propio almacén de datos privada. Diferentes microservicios pueden utilizar diferentes bases de datos SQL y NoSQL. Mientras que esta arquitectura de base de datos tiene beneficios significativos, que crea algunos problemas de gestión de datos distribuidos. El primer desafío es cómo implementar las transacciones comerciales que mantienen la consistencia a través de múltiples servicios El segundo reto es cómo implementar las consultas que recuperan datos de múltiples servicios.

Para muchas aplicaciones, la solución es utilizar una arquitectura Un desafío orientado a eventos con la implementación de una arquitectura orientada a eventos es la forma de actualizar el estado de forma atómica y cómo publicar eventos. Hay algunas maneras de lograr esto, incluyendo el uso de la base de datos como una cola de mensajes, la minería de registro de transacciones, y el abastecimiento de eventos

Microservicios en Acción: Nginx y Optimización de Almacenamiento por Floyd Smith Un enfoque basado en microservicios al almacenamiento implica un mayor número y variedad de almacenes de datos, una mayor complejidad en la forma de acceder y actualizar datos, y mayores desafíos tanto para Dev y Operaciones en el mantenimiento de la coherencia de datos. Nginx proporciona un apoyo crucial para este tipo de gestión de datos, en tres áreas principales:

1 El almacenamiento en caché de los datos y microcaching - el contenido generado por la aplicación de almacenamiento en caché los archivos estáticos y microcaching con Nginx reduce la carga en su aplicación, lo que aumenta el rendimiento y reduce el potencial de problemas.

2 La flexibilidad y la escalabilidad de datos por tienda - Una vez que se implementa Nginx como un servidor proxy inverso, sus aplicaciones ganar una gran flexibilidad en la creación, el tamaño, correr y cambiar el tamaño de los servidores de almacenamiento de datos para satisfacer las necesidades cambiantes de vital importancia que cada servicio tiene su propio almacén de datos

3 El seguimiento y la gestión de los servicios, incluyendo servicios de datos - Con el número de servidores de datos de multiplicación, el apoyo a operaciones complejas es crítico, ya que son herramientas de control y gestión Nginx Plus dispone de herramientas e interfaces integradas para la gestión de rendimiento de las aplicaciones

fogonadura como perro de datos, dynaTrace, y Nueva Relic

Ejemplos de gestión de datos microService específica se incluyen en los tres modelos de la Arquitectura de referencia microservicios Nginx , Que le da un punto de partida para sus propias decisiones de diseño y puesta en práctica

Microservicios - Del diseño a la implementación de

54

Ch. 5 - orientada a eventos gestión de datos para microservicios

6

Elección de una estrategia de implementación de microservicios

Este es el sexto capítulo de este libro electrónico sobre la creación de aplicaciones con microservicios

Capítulo 1 introduce la microservicios patrón de Arquitectura y discute las ventajas y los inconvenientes de la utilización microservicios. Los siguientes capítulos tratan diferentes aspectos de la arquitectura microservicios: utilizando una puerta de enlace API , comunicación entre procesos , descubrimiento de servicios y gestión de datos orientada a eventos En este capítulo, nos fijamos en las estrategias para la implementación de microservicios.

motivaciones Implementación de una aplicación monolítica significa ejecutando uno o más idénticos copias de un solo, por lo general grande, de la aplicación. Por lo general, los servidores de suministro N (físicos o virtuales) y instancias plazo M de la aplicación en cada servidor. El despliegue de una aplicación monolítica no siempre es del todo sencilla, pero es mucho más simple que el despliegue de una aplicación microservicios Un aplicación microservicios se compone de decenas o incluso cientos de servicios. Los servicios se escriben en una variedad de idiomas y marcos. Cada uno es un mini-aplicación con su propia implementación específica, los recursos, la escala y los requisitos de control. Por ejemplo, es necesario ejecutar un cierto número de casos de cada servicio en función de la demanda de ese servicio también, cada instancia de servicio debe estar provisto de la CPU apropiada, la memoria y E / S de recursos Lo que es aún más difícil es que a pesar esta complejidad, el despliegue de servicios debe ser rápido, fiable y rentable.

Microservicios - Del diseño a la implementación de

55

Ch. 6 - Elección de una estrategia de implementación de microservicios

Hay unos pocos patrones de despliegue microService diferentes. Veamos primero a las instancias de servicio múltiple por patrón anfitrión

Varias instancias de servicio por patrón anfitrión Una forma de implementar sus microservicios es utilizar el Varias instancias de servicio por host patrón Cuando se utiliza este patrón, el suministro de uno o más físicos o máquinas virtuales y ejecutar múltiples instancias de servicio en cada uno En muchos sentidos, este es el enfoque tradicional de la implementación de la aplicación Cada instancia de servicio se ejecuta en un puerto bien conocido en uno o más hosts las máquinas anfitrionas son comúnmente tratados como mascotas

La Figura 6-1 muestra la estructura de este patrón:

Host (Physical or VM)

SERVICE-A INSTANCE-1

SERVICE-B INSTANCE-1

SERVICE-C INSTANCE-1

SERVICE-B INSTANCE-2

SERVICE-C INSTANCE-2

Host (Physical or VM)

SERVICE-A INSTANCE-2

La Figura 6-1. Los anfitriones pueden apoyar cada uno múltiples instancias de servicio.

Microservicios - Del diseño a la implementación de

56

Ch. 6 - Elección de una estrategia de implementación de microservicios

Hay un par de variantes de este patrón. Una variante es para cada instancia de servicio de ser un proceso o un grupo de procesos. Por ejemplo, es posible implementar una instancia de servicio de Java como una aplicación web en una Apache Tomcat Un servidor js nodo instancia de servicio puede consistir en un proceso principal y uno o más procesos hijos.

La otra variante de este patrón es de ejecutar múltiples instancias de servicio en el mismo proceso o grupo de procesos. Por ejemplo, se podría implementar varias aplicaciones web Java en el mismo servidor Apache Tomcat o ejecutar varios paquetes OSGi en el mismo contenedor OSGi las instancias de servicio múltiple por patrón anfitrión tiene tanto ventajas como inconvenientes. Una ventaja importante es su uso de recursos es relativamente eficiente. Varias instancias de servicio comparten el servidor y su sistema operativo. Es aún más eficiente si un proceso o grupo ejecuta varias instancias de servicio, por ejemplo, múltiples aplicaciones web que comparten el mismo servidor Apache Tomcat y JVM.

Otra ventaja de este modelo es que el despliegue de una instancia de servicio es relativamente rápido. Simplemente copia el servicio a un host y lo inicia. Si el servicio está escrito en Java, se copia un archivo JAR o WAR. Para otros idiomas, como Node.js o Ruby, copiar el código fuente. En cualquier caso, el número de bytes copiados través de la red es relativamente pequeño. También, debido a la falta de techo, iniciar un servicio suele ser muy rápido. Si el servicio es su propio proceso, simplemente se inicia. De lo contrario, si el servicio es una de las varias instancias que se ejecutan en el grupo mismo proceso contenedor o proceso, ya sea de forma dinámica de implementarlo en el recipiente o reiniciar el contenedor

A pesar de su atractivo, las instancias de servicio múltiple por patrón anfitrión tiene algunos inconvenientes importantes. Una desventaja importante es que hay poco o ningún aislamiento de las instancias de servicio, a menos que cada instancia de servicio es un proceso separado Si bien se puede controlar con precisión la utilización de recursos de cada instancia de servicio, no se puede limitar los recursos de cada instancia usa. Es posible que una instancia de servicio mal comportamiento de consumir toda la memoria o CPU del host.

No existe aislamiento en absoluto si se ejecutan varias instancias de servicio en el mismo proceso. Todas las instancias podrían, por ejemplo, compartir el mismo montón JVM. Una instancia de servicio se porta mal podría fácilmente romper los otros servicios que se ejecutan en el mismo proceso otra parte, que no hay manera de controlar los recursos utilizados por cada instancia de servicio Otro problema significativo con este enfoque es que el equipo de operaciones que se despliega un servicio tiene que conocer la específica detalles de cómo hacerlo. Los servicios pueden ser escritos en una variedad de idiomas y los marcos, por lo que hay una gran cantidad de detalles que el equipo de desarrollo debe compartir con las operaciones. Esta complejidad aumenta el riesgo de errores durante el despliegue. Como se puede ver, a pesar de su familiaridad, las instancias de servicio múltiple por patrón anfitrión tiene algunos inconvenientes importantes.

Microservicios - Del diseño a la implementación de

57

Ch. 6 - Elección de una estrategia de implementación de microservicios

Instancia de servicio por patrón anfitrión Otra manera de desplegar sus microservicios es la Instancia de servicio por host patrón Cuando se utiliza este patrón, se ejecuta cada instancia de servicio de forma aislada en su propia máquina hay dos especializaciones diferentes diferentes de este patrón: Servicio de instancia por máquina virtual y la instancia de servicio por envase

Instancia de servicio por patrón Virtual Machine Cuando se utiliza Instancia de servicio por máquina virtual patrón, empaquetar cada servicio como una imagen de máquina virtual (VM), tales como Amazon EC2 AMI Cada instancia de servicio es una máquina virtual (por ejemplo, una instancia EC2) que se puso en marcha utilizando esa imagen VM. La Figura 6-2 muestra la estructura de este patrón:

VM

SERVICE INSTANCE

Deployed As

VM Packaged As

SERVICE

VM Image

SERVICE INSTANCE

VM

SERVICE INSTANCE

La Figura 6-2. Los servicios pueden cada uno vivir en su propia máquina virtual.

Microservicios - Del diseño a la implementación de

58

Ch. 6 - Elección de una estrategia de implementación de microservicios

Este es el enfoque principal utilizado por Netflix para desplegar su servicio de streaming de vídeo. Netflix paquetes cada uno de sus servicios como EC2 AMI utilizando Aminator Cada instancia de servicio que se ejecuta es una instancia EC2

Hay una variedad de herramientas que se pueden utilizar para construir su propia VM. Puede configurar el servidor de integración continua (CI) (por ejemplo, Jenkins ) Para invocar Aminator a empaquetar sus servicios como EC2 AMI Envasador es otra opción para la creación de la imagen VM automatizado. A diferencia de Aminator, es compatible con una variedad de tecnologías de virtualización, incluyendo EC2, digitalocean, VirtualBox y VMware La compañía Boxfuse tiene una forma convincente para construir imágenes de VM, que supera los inconvenientes de las máquinas virtuales que describo a continuación. Boxfuse empaqueta la aplicación Java imagen de una máquina virtual como mínimo. Estas imágenes son rápidos de construir, de inicio rápido, y son más seguros, ya que exponen una superficie de ataque limitado. La compañia CloudNative tiene la panadería, una oferta SaaS para la creación de EC2 AMI. Puede configurar el servidor de CI para invocar la panadería después de las pruebas para su pase microService. La panadería y luego empaqueta su servicio como un IAM. Usando una oferta SaaS como la panadería significa que usted no tiene que perder el establecimiento de la infraestructura creación IAM valioso tiempo. La instancia de servicio por Modelo de la máquina virtual tiene una serie de beneficios. Una ventaja importante de las máquinas virtuales es que cada instancia de servicio se ejecuta en completo aislamiento. Tiene una cantidad fija de CPU y de memoria y no puede robar los recursos de otros servicios.

Otro de los beneficios de la implementación de sus microservicios como máquinas virtuales es que se puede aprovechar la infraestructura de nube madura. Las nubes como AWS proporcionan características útiles, tales como el equilibrio de carga y autoscaling

Otra gran ventaja de la implementación de su servicio como una máquina virtual es que encapsula la tecnología de aplicación de su servicio Una vez que el servicio ha sido empaquetado como una máquina virtual se convierte en un cuadro negro. API de gestión de la máquina virtual se convierte en el API para desplegar el despliegue del servicio se hace mucho más sencilla y fiable

La instancia de servicio por Modelo de la máquina virtual tiene algunos inconvenientes, sin embargo Un inconveniente es la utilización menos eficiente de los recursos. Cada instancia de servicio tiene la sobrecarga de toda una VM, incluyendo el sistema operativo. Por otra parte, en un IaaS pública típica, las máquinas virtuales vienen en tamaños fijos y es posible que la máquina virtual será subutilizada. Por otra parte, un IaaS pública normalmente cobra por las máquinas virtuales, independientemente de si son ocupado o libre Un IaaS como AWS ofrece autoscaling, pero es difícil de reaccionar rápidamente a los cambios en la demanda . En consecuencia, a menudo hay que sobreprestación de máquinas virtuales, lo que aumenta el costo de la implementación.

Otra desventaja de este enfoque es que la implementación de una nueva versión de un servicio suele ser lento imágenes de VM son típicamente lenta de construir debido a su tamaño Además, las máquinas virtuales es habitualmente lenta para crear una instancia, una vez más debido a su tamaño. Además, un sistema operativo suele tardar algo de tiempo para poner en marcha Nótese, sin embargo, que esto no es una verdad universal, ya que existen máquinas virtuales ligeros como los construidos por Boxfuse.

Microservicios - Del diseño a la implementación de

59

Ch. 6 - Elección de una estrategia de implementación de microservicios

Otro inconveniente de la instancia de servicio por Modelo de la máquina virtual es que por lo general usted (o alguien más en su organización) es responsable de un montón de trabajo pesado indiferenciada. A menos que utilice una herramienta como Boxfuse que se encarga de los gastos indirectos de la construcción y la gestión de las máquinas virtuales, entonces es su responsabilidad Esta actividad necesaria, pero requiere mucho tiempo distrae de su negocio principal.

Veamos ahora en una forma alternativa de implementar microservicios que es más ligero, pero todavía tiene muchas de las ventajas de las máquinas virtuales.

Instancia de servicio por patrón de contenedores Cuando se utiliza la Instancia de servicio por envase patrón, cada instancia de servicio se ejecuta en su propio envase envases son una mecanismo de virtualización a nivel de sistema operativo Un contenedor consiste en uno o más procesos que se ejecutan en un entorno limitado. Desde la perspectiva de los procesos, que tienen su propio espacio de nombres de puerto y sistema de ficheros raíz. Puede limitar los recursos de memoria y CPU de un contenedor Algunas implementaciones de contenedores también tienen I / O tasa limitante. Ejemplos de tecnologías de contenedores incluyen Estibador y zonas de Solaris

La Figura 6-3 muestra la estructura de este patrón:

VM Container

SERVICE INSTANCE

Deployed As

Packaged As

SERVICE

VM Container

Container Image

SERVICE INSTANCE

VM Container

SERVICE INSTANCE

La Figura 6-3. Los servicios pueden cada uno vivir en su propio contenedor.

Microservicios - Del diseño a la implementación de

60

Ch. 6 - Elección de una estrategia de implementación de microservicios

Para utilizar este modelo, se empaqueta el servicio de imágenes de un recipiente como una imagen de contenedores es una imagen del sistema de archivos que consiste en las aplicaciones y bibliotecas necesarias para ejecutar el servicio. Algunas imágenes de contenedores consisten en un completo sistema de archivos raíz de Linux. Otros son más ligeros. Para implementar un servicio de Java, por ejemplo, se construye una imagen recipiente que contiene el tiempo de ejecución de Java, tal vez un servidor Apache Tomcat, y la aplicación Java compilada. Una vez que haya empaquetado servicio de su imagen como un recipiente, a continuación, iniciar uno o más contenedores Por lo general, ejecutar varios contenedores en cada host físico o virtual Es posible utilizar un gestor de clúster como Kubernetes o Maratón para administrar sus contenedores. Un administrador de clusters trata a los anfitriones como un conjunto de recursos. Se decide dónde colocar cada contenedor basado en los recursos requeridos por el contenedor y los recursos disponibles en cada host

La instancia de servicio por el patrón de contenedores tiene tanto ventajas como inconvenientes. Las ventajas de los contenedores son similares a los de las máquinas virtuales. Se aíslan las instancias de servicio unos de otros Puede controlar fácilmente los recursos consumidos por cada contenedor Además, como máquinas virtuales, contenedores encapsulan la tecnología utilizada para implementar los servicios de la API de gestión de contenedores también sirve como el API para la gestión de sus servicios. Sin embargo, a diferencia de las máquinas virtuales, los contenedores son una tecnología ligera imágenes de contenedores son normalmente muy rápido de construir. Por ejemplo, en mi portátil que se necesita tan poco como 5 segundos para empaquetar una primavera de arranque aplicación como estibador envase envases también se inicia muy rápidamente, ya que no hay mecanismo de arranque del sistema operativo larga cuando un contenedor se inicia, lo que corre es el servicio

Hay algunos inconvenientes a la utilización de contenedores. Mientras que la infraestructura de contenedores está madurando rápidamente, no es tan madura como la infraestructura de máquinas virtuales. Además, los recipientes no son tan seguras como las máquinas virtuales, ya que los contenedores comparten el núcleo del sistema operativo anfitrión con otros. Otro inconveniente de los contenedores es que usted es responsable de todo el trabajo indiferenciado de la administración de las imágenes de contenedores. Además, a menos que esté utilizando una solución alojada contenedor como Google Container Engine o Servicio de Amazon EC2 de contenedores

(ECS), entonces debe administrar la infraestructura de contenedores y, posiblemente, la infraestructura de máquina virtual que se ejecuta. Además, los contenedores a menudo se implementan en una infraestructura que tiene precios por VM. En consecuencia, como se ha descrito anteriormente, es probable que incurrir en el costo extra de exceso de aprovisionamiento de máquinas virtuales con el fin de manejar los picos de carga Curiosamente, la distinción entre contenedores y máquinas virtuales es probable que desdibujar Como se mencionó anteriormente, Boxfuse máquinas virtuales son rápidos de construir y empezar. los recipientes transparentes proyecto pretende crear máquinas virtuales de peso ligero también hay un creciente interés en unikernels Estibador, Inc adquirió Sistemas Unikernel a principios de 2016

También existe el concepto más nuevo y cada vez más popular de la implementación del servidor-menos, lo cual es un enfoque que deja de lado la cuestión de tener que elegir entre el despliegue de servicios en contenedores o el aspecto de las máquinas virtuales Vamos a ver que el próximo

Microservicios - Del diseño a la implementación de

61

Ch. 6 - Elección de una estrategia de implementación de microservicios

despliegue sin servidor AWS Lambda es un ejemplo de tecnología de implementación sin servidor. Es compatible con los servicios de Java, Node.js, y Python. Para implementar una microService, se empaqueta como un archivo ZIP y subirlo a AWS Lambda. También proporciona metadatos, que entre otras cosas especifica el nombre de la función que se invoca para gestionar una petición (también conocido como un evento). AWS Lambda se ejecuta automáticamente suficientes instancias de su microService para manejar las peticiones. Usted es simplemente una factura por cada solicitud en base al tiempo empleado y la memoria consumida. Por supuesto, el diablo está en los detalles, y se verá en breve que AWS Lambda tiene limitaciones. Pero la idea de que ni usted como desarrollador, ni nadie en su organización, necesita preocuparse acerca de cualquier aspecto de servidores, máquinas virtuales o contenedores es muy atractivo. UNA función lambda es un servicio sin estado lo general maneja las solicitudes mediante la invocación de servicios de AWS. Por ejemplo, una función lambda que se invoca cuando una imagen se carga en un contenedor de S3 podría introducir un elemento en una tabla de DynamoDB imágenes y publicar un mensaje a una corriente Kinesis para activar el procesamiento de imágenes. Una función Lambda también puede invocar servicios web de terceros

Hay cuatro maneras de invocar una función lambda:

•

Directamente, mediante una solicitud de servicio Web

• De forma automática, en respuesta a un evento generado por un servicio AWS como S3, DynamoDB, Kinesis, o Simple servicio de correo electrónico

•

De forma automática, a través de una puerta de enlace de AWS API para manejar las peticiones HTTP de los clientes de la aplicación

• Periódicamente, según una cron- como horario Como se puede ver, AWS Lambda es un método práctico para implementar microservicios El precio requestbased significa que usted sólo paga por el trabajo que realizan sus servicios efectivamente. Además, debido a que no es responsable de la infraestructura de TI, puede centrarse en el desarrollo de su aplicación

Hay, sin embargo, algunas limitaciones significativas. Las funciones lambda no están destinados a ser utilizados para desplegar servicios de larga ejecución, tales como un servicio que consume mensajes de un intermediario de mensajes de terceros. Las solicitudes se deben completar dentro de los 300 segundos. Los servicios deben ser sin estado, ya que en teoría podría AWS Lambda ejecutar una instancia independiente para cada solicitud. Deben estar escritos en uno de los idiomas admitidos. Los servicios también deben comenzar rápidamente; de lo contrario, podrían ser programados y terminados

Microservicios - Del diseño a la implementación de

62

Ch. 6 - Elección de una estrategia de implementación de microservicios

Resumen La implementación de una aplicación microservicios es difícil que pueda tener decenas o incluso cientos de servicios escritos en una variedad de idiomas y marcos. Cada uno es un mini-aplicación con su propia implementación específica, los recursos, la escala y los requisitos de control. Hay varios patrones de despliegue microService, incluyendo instancia de servicio por máquina virtual y la instancia de servicio por envase. Otra opción interesante para el despliegue de microservicios es AWS Lambda, un enfoque sin servidor. En el siguiente y último capítulo de este libro electrónico, vamos a ver cómo migrar una aplicación monolítica a una arquitectura microservicios

Microservicios en Acción: Implementación de microservicios Across La variación de los ejércitos con Nginx por Floyd Smith Nginx tiene un montón de ventajas para los diversos tipos de despliegue - ya sea para aplicaciones monolíticas, aplicaciones microservicios o aplicaciones híbridas (como se describe en el siguiente capítulo). Con Nginx, puede inteligencia abstracta de diferentes entornos de despliegue y en Nginx. Hay muchas posibilidades de aplicaciones que funcionan de manera diferente si utiliza herramientas que son específicos para diferentes entornos de implementación, pero que funcionan de la misma manera en todos los entornos, si usted usa Nginx.

Esta característica también abre una segunda ventaja específica para Nginx Nginx y Plus: la capacidad de escalar una aplicación mediante la ejecución en varios entornos de despliegue al mismo tiempo Digamos que usted tiene servidores locales que poseen y administran, pero el uso de las aplicaciones está creciendo y que anticipan los picos más allá de lo que los servidores pueden manejar. En lugar de compra, aprovisionamiento y mantenimiento de servidores adicionales caliente “por si acaso”, si ha “ido Nginx”, tiene una poderosa alternativa: Escala en la nube - por ejemplo, escala en AWS . Es decir, manejar el tráfico en sus servidores locales hasta que se alcanza la capacidad, a continuación, girar a instancias MICROSERVICE adicionales en la nube, según sea necesario

Este es sólo un ejemplo de la flexibilidad que el paso a Nginx hace posible. El mantenimiento de entornos de prueba y despliegue separadas, el cambio de la infraestructura de sus entornos, y la gestión de una cartera de aplicaciones en todos los tipos de ambientes todos se convierten en mucho más realista y alcanzable

los Arquitectura de referencia microservicios Nginx está explícitamente diseñado para apoyar este tipo de implementación flexible, con el uso de contenedores durante el desarrollo y despliegue como un supuesto. Considere un movimiento de contenedores, si no está ya, y para Nginx Nginx o Plus para facilitar su traslado a microservicios y asegurar el futuro de sus aplicaciones, el desarrollo y la flexibilidad de implementación y personal

Microservicios - Del diseño a la implementación de

63

Ch. 6 - Elección de una estrategia de implementación de microservicios

7

Refactorización un monolito en microservicios

Este es el séptimo y último capítulo de este libro electrónico sobre la creación de aplicaciones con microservicios Capítulo 1 introduce la Microservice patrón de Arquitectura y discute las ventajas y los inconvenientes de la utilización microservicios. Los capítulos siguientes discuten diferentes aspectos de la arquitectura microservicios: utilizando una puerta de enlace API , comunicación entre procesos , descubrimiento de servicios , gestión de datos orientada a eventos y desplegar microservicios . En este capítulo, nos fijamos en las estrategias para la migración de una aplicación monolítica a microservicios

Espero que este libro electrónico le ha dado una buena comprensión de la arquitectura microservicios, sus ventajas y desventajas, y cuándo usarlo. Tal vez la arquitectura microservicios es un buen ajuste para su organización.

Sin embargo, no es bastante buena probabilidad de que está trabajando en una aplicación monolítica grande y compleja. Su experiencia diaria de desarrollar y desplegar su aplicación es lenta y dolorosa. Microservicios parecen como un nirvana distante. Afortunadamente, existen estrategias que se pueden utilizar para escapar del infierno monolítica. En este artículo, describo cómo refactorizar incremental una aplicación monolítica en un conjunto de microservicios.

Microservicios - Del diseño a la implementación de

64

Ch. 7 - Refactorizando un monolito en microservicios

Visión general de Refactoring a microservicios El proceso de transformación de una aplicación monolítica en microservicios es una forma de

la modernización de aplicaciones . Eso es algo que los desarrolladores han estado haciendo durante décadas. Como resultado, hay algunas ideas que podemos reutilizar al refactorizar una aplicación en microservicios

Una de las estrategias para no utilizar es la reescritura de “Big Bang”. Esto es cuando uno se concentra todos sus esfuerzos de desarrollo en la construcción de una nueva aplicación basada en microservicios desde cero. A pesar de que suena atractivo, es muy arriesgado y probablemente terminará en un fracaso. Como Martin Fowler Según los informes, dijo , “Lo único que un Big Bang reescribir garantías es un Big Bang!” En lugar de una reescritura Big Bang, debe refactorizar incrementalmente su aplicación monolítica. Se agrega poco a poco una nueva funcionalidad, y crear extensiones de funcionalidad existente, en forma de microservicios - modificar su aplicación monolítica de manera complementaria, y la ejecución de los microservicios y el monolito modificado en tándem. Con el tiempo, la cantidad de funcionalidad implementada por la aplicación monolítica se encoge, hasta que desaparece por completo o se convierte en otra microService Esta estrategia es similar a el mantenimiento de su coche mientras se conduce por la autopista a 70 mph - un reto, pero mucho menos riesgoso que intentar una reescritura Big bang

Martin Fowler se refiere a esta estrategia de modernización de aplicaciones como el Aplicación estrangulador . El nombre proviene de la vid estrangulador (también conocido como estrangulador fig) que se encuentra en las selvas tropicales. Una vid estrangulador crece alrededor de un árbol con el fin de llegar a la luz del sol por encima del dosel del bosque. A veces, el árbol muere, dejando una modernización de aplicaciones vid treeshaped sigue el mismo patrón. Vamos a construir una nueva aplicación que consiste en microservicios todo el uso de la herencia, que se encogerá y quizás, con el tiempo, Die

Veamos las diferentes estrategias para hacer esto.

Microservicios - Del diseño a la implementación de

sesenta y cinco

Ch. 7 - Refactorizando un monolito en microservicios

Estrategia # 1 - dejar de cavar los Ley de agujeros dice que cada vez que usted está en un agujero que debe dejar de cavar Este es un gran consejo a seguir a la hora de su aplicación monolítica se ha vuelto inmanejable. En otras palabras, usted debe dejar de hacer el monolito más grande Esto significa que cuando se está implementando una nueva funcionalidad no debe agregar más código para el monolito. En cambio, la gran idea con esta estrategia es poner ese código nuevo en un microService independiente Figura 7-1 muestra la arquitectura del sistema después de aplicar este enfoque.

HTTP REQUEST

REQUEST ROUTER Old HTTP requests

New HTTP requests

WEB API

GLUE CODE

WEB API

GLUE CODE

SERVICE

MONOLITH

La Figura 7-1. La implementación de nuevas funcionalidades como un servicio separado en lugar de añadir un módulo al monolito.

Microservicios - Del diseño a la implementación de

66

Ch. 7 - Refactorizando un monolito en microservicios

Así como el nuevo servicio y el monolito legado, hay otros dos componentes de la primera es un router solicitud, que gestiona las peticiones entrantes (HTTP). Es similar a la puerta de enlace API se describe en Capitulo 2 El router envía las solicitudes correspondientes a la nueva funcionalidad para el nuevo servicio. encamina legado solicita al monolito. El otro componente es el código de unión, que integra el servicio con el monolito Un servicio raramente existe en forma aislada y, a menudo tiene que acceder a los datos de propiedad del monolito. El código de pegamento, que reside en la del monolito, el servicio, o ambos, es responsable de la integración de datos. El servicio utiliza el código de unión para leer y escribir datos de propiedad del monolito

Hay tres estrategias que un servicio puede utilizar para acceder a los datos del monolito:

• Invocar un API remota proporcionada por el monolito •

Acceder a la base de datos del monolito directamente

• Mantener su propia copia de los datos, que se sincroniza con la base de datos del monolito El código de unión a veces se llama una capa anti-corrupción Esto es debido a que el código de unión impide que el servicio, que tiene su propio modelo de dominio prístina, de ser contaminado por los conceptos de modelo de dominio del monolito legado. El código de pegamento se traduce entre los dos modelos diferentes. La capa anti-corrupción término apareció por primera vez en el libro de lectura obligatoria Domain Driven Design por Eric Evans y luego se perfeccionó en una papel blanco El desarrollo de una capa anti-corrupción puede ser una tarea no trivial Pero es esencial para crear una si quiere hacer crecer su salida del infierno monolítica.

La implementación de nuevas funcionalidades como un servicio ligero tiene un par de ventajas. Evita que el monolito se vuelva aún más difícil de manejar. El servicio se puede desarrollar, desplegar y escalar independientemente del monolito. Experimenta los beneficios de la arquitectura microService para cada servicio nuevo que se crea. Sin embargo, este enfoque no hace nada para abordar los problemas con el monolito. Para solucionar esos problemas que necesita para romper el monolito. Veamos estrategias para hacer eso.

Estrategia # 2 - Split y del servidor Una estrategia que se contrae la aplicación monolítico es dividir la capa de presentación de las capas de lógica de negocio y acceso a datos. Una aplicación típica de la empresa se compone de al menos tres diferentes tipos de componentes:

• Capa de presentación - Los componentes que manejan las peticiones HTTP y poner en práctica ni una API REST () o una interfaz web basada en HTML. En una aplicación que tiene una interfaz de usuario sofisticada, la capa de presentación es a menudo un cuerpo sustancial de código.

• Capa de lógica de negocio - Los componentes que son el núcleo de la aplicación e implementan las reglas de negocio •

capa de datos de acceso - Componentes que tienen acceso a los componentes de infraestructura, tales como bases de datos y los intermediarios de mensajes

Microservicios - Del diseño a la implementación de

67

Ch. 7 - Refactorizando un monolito en microservicios

Generalmente hay una separación limpia entre la lógica de presentación en un lado y la lógica de negocio y de acceso a datos en la otra la capa de negocio ha una API de grano grueso que consiste en uno o más fachadas, que encapsulan componentes de business-lógicos. Esta API es una fibra natural de largo de la cual se puede dividir en dos el monolito aplicaciones más pequeñas Una aplicación contiene la capa de presentación La otra aplicación contiene la lógica de negocio y acceso a datos. Después de la separación, la aplicación lógica de presentación hace llamadas remotas a la aplicación lógica de negocio Figura 7-2 muestra la arquitectura antes y después de la refactorización.

BROWSER

BROWSER

WEB APPLICATION

WEB APPLICATION

REST API

REST API

BUSINESS LOGIC

BUSINESS LOGIC

DATABASE ADAPTER

DATABASE ADAPTER

MYSQL

MYSQL

Figura 7-2. Refactorización una aplicación existente.

La división de un monolito de esta manera tiene dos ventajas principales. Se le permite desarrollar, desplegar y escalar las dos aplicaciones de forma independiente el uno del otro. En particular, se permite a los desarrolladores de presentación de capa para iterar rápidamente en la interfaz de usuario y fácilmente realizar A | B pruebas, por ejemplo. Otra ventaja de este enfoque es que expone una API remoto que puede ser llamado por los microservicios que desarrolle

Esta estrategia, sin embargo, es sólo una solución parcial. Es muy probable que una o ambas de las dos aplicaciones habrá un monolito inmanejable Usted necesita usar la tercera estrategia para eliminar el monolito o monolitos restante

Microservicios - Del diseño a la implementación de

68

Ch. 7 - Refactorizando un monolito en microservicios

Estrategia # 3 - Extracto de Servicios La tercera estrategia refactorización es convertir los módulos existentes en el monolito en microservicios independientes Cada vez que se extrae un módulo y convertirlo en un servicio, el monolito se encoge Una vez que haya convertido suficientes módulos, el monolito dejará de ser un problema O bien se desaparece por completo o se hace lo suficientemente pequeño que es un simple servicio de

Priorizar módulos que convertir en Servicios Una aplicación monolítica grande, complejo consta de decenas o cientos de módulos, todos los cuales son candidatos para la extracción. Averiguar qué módulos para convertir primero es a menudo difícil. Un buen método es empezar con un par de módulos que son fáciles de extraer. Esto le dará la experiencia con microservicios en general y el proceso de extracción, en particular Después de eso, se debe extraer los módulos que le dará el mayor beneficio. La conversión de un módulo en un servicio suele ser lento desea clasificar los módulos por el beneficio que recibirá. Por lo general es beneficioso para extraer módulos que cambian con frecuencia. Una vez que haya convertido un módulo en un servicio, puede desarrollar y desplegar de forma independiente del monolito, lo que acelerará el desarrollo. También es beneficioso para extraer módulos que tienen necesidades de recursos significativamente diferentes de las del resto del monolito. Es útil, por ejemplo, para activar un módulo que tiene una base de datos en memoria en un servicio, que luego se puede implementar en hosts, si los servidores metal desnudo, VMS, o instancias de nubes, con grandes cantidades de memoria. Del mismo modo, puede ser útil para extraer los módulos que implementan algoritmos computacionalmente costosos, ya que el servicio se puede implementar en hosts con una gran cantidad de CPU. Al girar los módulos con los requisitos de recursos particulares en los servicios, usted puede hacer su aplicación más fácil y menos costoso a escala si los servidores desnudos de metal, máquinas virtuales, o instancias de nubes, con grandes cantidades de memoria. Del mismo modo, puede ser útil para extraer los módulos que implementan algoritmos computacionalmente costosos, ya que el servicio se puede implementar en hosts con una gran cantidad de CPU. Al girar los módulos con los requisitos de recursos particulares en los servicios, usted puede hacer su aplicación más fácil y menos costoso a escala si los servidores desnudos de metal, máquinas virtuales, o instancias de nubes, con grandes cantidades de memoria. Del mismo modo, puede ser útil para extraer los módulos que implementan algoritmos computacionalmente costosos, ya que el servicio se puede implementar en hosts con una gran cantidad de CPU. Al girar los módulos con los requisitos de recursos particulares en los servicios, usted puede hacer su aplicación más fácil y menos

Cuando averiguar qué módulos para extraer, es útil para buscar los límites de grano grueso (también conocido como costuras) existente. Ellos hacen que sea más fácil y más barato para activar módulos en los servicios. Un ejemplo de un límite de este tipo es un módulo que sólo se comunica con el resto de la aplicación a través de mensajes asíncronos puede ser relativamente barato y fácil de convertir dicho módulo en una microService

Cómo extraer un módulo La primera etapa de extracción de un módulo es definir una interfaz de grano grueso entre el módulo y el monolito Es sobre todo probable una API bidireccional, ya que el monolito tendrá los datos de propiedad del servicio y viceversa. A menudo es difícil de implementar un API tales a consecuencia de las dependencias enredadas y los patrones de interacción de grano fino entre el módulo y el resto de la aplicación. La lógica de negocio implementa mediante el patrón de modelo de dominio es especialmente difícil de refactorizar debido a las numerosas asociaciones entre las clases del modelo de dominio. A menudo tendrá que hacer cambios en el código significativos para romper estas dependencias. La Figura 7-3 muestra la refactorización.

Microservicios - Del diseño a la implementación de

69

Ch. 7 - Refactorizando un monolito en microservicios

REST API

REST API

BUSINESS LOGIC

BUSINESS LOGIC MODULE X

MODULE X

Step 1

MODULE Y

MODULE Z

MODULE Y

MODULE Z

DATABASE ADAPTER

DATABASE ADAPTER

Step 2

MYSQL

MYSQL

REST API

REST API

BUSINESS LOGIC

REST CLIENT

REST API

BUSINESS LOGIC

MODULE X MODULE Z

MODULE Y

REST API

REST CLIENT

DATABASE ADAPTER

DATABASE ADAPTER

MYSQL

MYSQL

Figura 7-3. Un módulo de un monolito puede convertirse en un microService.

Microservicios - Del diseño a la implementación de

70

Ch. 7 - Refactorizando un monolito en microservicios

Una vez que implementa la interfaz de grano grueso, que gire el módulo en un servicio independiente Para ello, debe escribir código para que el monolito y el servicio para comunicarse a través de una API que utiliza una comunicación entre procesos (IPC) mecanismo. Figura 7-3 muestra la arquitectura antes, durante y después de la refactorización. En este ejemplo, el módulo Z es el módulo candidato para extraer sus componentes se utiliza por el módulo X y utiliza Módulo Y. El primer paso refactorización es definir un par de APIs de grano grueso. La primera interfaz es una interfaz de entrada que se utiliza por el módulo de X para invocar Módulo Z. La segunda es una interfaz de salida utilizado por el módulo de Z para invocar Módulo Y. El segundo paso refactorización gira el módulo en un servicio independiente. Las interfaces de entrada y de salida son implementadas por el código que utiliza un mecanismo IPC. Lo más probable es que tenga que construir el servicio mediante la combinación de módulo Z con una Chasis marco Microservice que maneja temas transversales tales como el descubrimiento de servicios Una vez que haya extraído un módulo, usted tiene otro servicio que se puede desarrollar, desplegar y escalar independientemente del monolito y cualquier otro servicio. Incluso se puede reescribir el servicio a partir de cero; en este caso, el código API que integra el servicio con el monolito se convierte en una capa anti-corrupción que se traduce entre los dos modelos de dominio Cada vez que se extrae un servicio, dar un paso más en la dirección de microservicios. Con el tiempo, el monolito se encogerá y tendrá un número creciente de microservicios.

Resumen El proceso de migración de una aplicación existente en microservicios es una forma de modernización de aplicaciones no debe moverse a microservicios reescribiendo su aplicación a partir de cero. En su lugar, usted debe refactorizar incrementalmente su aplicación en un conjunto de microservicios. Hay tres estrategias que puede utilizar: la implementación de la nueva funcionalidad que microservicios; la división de los componentes de presentación de los componentes de negocio y acceso a datos; y la conversión de los módulos existentes en el monolito en los servicios Con el tiempo crecerá el número de microservicios, y la agilidad y la velocidad de su equipo de desarrollo aumentarán

Microservicios - Del diseño a la implementación de

71

Ch. 7 - Refactorizando un monolito en microservicios

Microservicios en Acción: La doma de un monolito con Nginx por Floyd Smith Como este capítulo se describe, la conversión de un monolito a microservicios es probable que sea un proceso lento y difícil, sin embargo, uno con muchos beneficios. Con Nginx, puede comenzar a conseguir algunos de los beneficios de microservicios antes de empezar el proceso de conversión. Se puede comprar un montón de tiempo para el traslado a microservicios por “dejar caer Nginx frente a” su aplicación monolítica existente. He aquí una breve descripción de los beneficios que se relacionan con microservicios:

•

Mejor soporte para microservicios - Como se mencionó en la barra lateral para el Capítulo 5, Nginx, y

Nginx Plus en particular, tienen capacidades que ayudan a permitir el desarrollo de aplicaciones microservicesbased Al comenzar a re-diseñar la aplicación monolítica, sus microservicios se obtienen mejores resultados y más fácil de manejar debido a las capacidades de Nginx.

•

abstracción funcional en entornos - Mover capacidades en Nginx como un servidor proxy inverso reduce el número de cosas que variará cuando se implementa a través de nuevos entornos, desde los servidores logras varios sabores de nubes públicas, privadas e híbridas. Esto complementa y se extiende la flexibilidad inherente a microservicios.

•

La disponibilidad de la Arquitectura de Referencia microservicios Nginx - A medida que avanza a Nginx, se puede pedir un préstamo al Arquitectura de referencia microservicios Nginx , Tanto para definir la estructura definitiva de su aplicación después del traslado a microservicios, y de usar partes de la MRA según sea necesario para cada nueva microService se crea.

En resumen, la implementación de Nginx como un primer paso en su transición quita la presión de su aplicación monolítica, hace que sea mucho más fácil de alcanzar todos los beneficios de microservicios, y le da modelos para su uso en la fabricación de la transición. Usted puede aprender más acerca de la ARM y obtener una prueba gratuita de Nginx Plus hoy

Microservicios - Del diseño a la implementación de

72

Ch. 7 - Refactorizando un monolito en microservicios

Los recursos para microservicios y Nginx por Floyd Smith

La página web Nginx ya es un valioso recurso para las personas que buscan aprender sobre microservicios y ponerlas en práctica en sus organizaciones a partir de descripciones introductorias, como el primer capítulo de este libro electrónico, a los recursos avanzados, tales como el Modelo de la tela de la arquitectura de referencia de Nginx Microsoft, hay un curso de nivel seminario de posgrado en microservicios disponibles en https://www.nginx.com

Aquí hay algunos consejos y trucos, y algunos recursos clave, para empezar en su viaje con Nginx y microservicios: • búsqueda en el sitio y la búsqueda de la tela. La mejor manera de buscar en la página web Nginx para el material microservicios es utilizar la búsqueda de sitio específico en Google:

º sitio: nginx.com tema para buscar en la página web Nginx º

sitio: nginx.com/blog tema para buscar el blog Nginx Todas las publicaciones de blog etiquetados, por lo que una vez que encuentre un tema que desea hacer un seguimiento de, simplemente haga clic en la etiqueta para ver todos los mensajes relevantes autores están vinculados a todos sus artículos, así

º Buscar tema nginx para encontrar contenido relevante tanto para Nginx y su tema de elección en la Web como un todo - hay un montón de grandes cosas por ahí. digitalocean puede ser el mejor lugar para empezar externa

•

recursos de General NGINX. A continuación se presentan enlaces a diferentes tipos de contenido en el sitio Nginx:

º

Comentarios en el blog . Una vez que encuentre un mensaje en microservicios, haga clic en el microservicios etiqueta para ver todos esos puestos

º

webinars Haga clic en el microservicios un filtro para ver microservicios-seminarios web pertinentes.

º

Documentos técnicos, informes y libros electrónicos . Usar la búsqueda sitio de esta parte del sitio, como se describió anteriormente, para encontrar recursos relacionados específicamente con microservicios y otros temas de su elección.

º Nginx canal de YouTube . Nginx tiene decenas de videos, incluyendo todas las presentaciones de varios años de nuestra conferencia anual. Muchos de estos videos se han convertido en las entradas del blog, si lo prefiere leer a ver; buscar el nombre del que habla en el blog Nginx

Microservicios - Del diseño a la implementación de

73

Los recursos para microservicios y Nginx

• recursos específicos. Microservicios es el único tema más popular, y lo mejor cubiertas de, en el sitio web Nginx. Aquí están algunos “mejor de los mejores” recursos para que pueda empezar.

º

Este libro electrónico como una serie blog . Busque en el blog Nginx para encontrar las entradas del blog de Chris Richardson que eran (ligera) adaptados para formar los siete capítulos de este libro electrónico.

º

Microservicios construcción de libros electrónicos . Una descarga gratuita de un libro de animales O'Reilly en microservicios Hace falta decir más?

º Microservicios en Netflix . Netflix es una empresa líder en implementación microservicios, trasladarse a la nube, y haciendo sus esfuerzos disponible como código abierto - todos basados ​en Nginx, por supuesto.

º ¿Por Nginx para contenedores y microservicios? El inimitable Owen Garrett sobre un tema caro a nuestros corazones

º

La implementación de microservicios . Una consideración diferente sobre el tema de este libro electrónico, haciendo hincapié en la arquitectura de cuatro niveles.

º Presentación de la arquitectura de referencia microservicios Nginx . servicios profesionales experto Chris Stetson introduce el MRA

Microservicios - Del diseño a la implementación de

74

Los recursos para microservicios y Nginx