Escribiendo clientes Eureka con Feign

Una alternativa a la clase RestTemplate habilitada para Spring Ribbon es la biblioteca cliente Feign de Netflix. La biblioteca Feign adopta un enfoque diferente para llamar a un servicio REST al hacer que el desarrollador primero defina una interfaz Java y luego anote esa interfaz con las anotaciones de Spring Cloud para mapear qué servicio basado en Eureka invocará Ribbon.

Spring Cloud generará dinámicamente una clase de proxy que se utilizará para invocar el servicio REST de destino. No se escribe ningún código para llamar al servicio que no sea una definición de interfaz.

Para habilitar el uso del cliente Feign se debe agregar una anotación, @EnableFeignClients, a la clase Application.java

Luego de habilitar el cliente de Feign, veamos una definición de interfaz de cliente de Feign que se puede usar para llama:

/*Package and import left off for conciseness*/

@FeignClient("ejemploService")

public interface EjemploFeignClient {

 @RequestMapping(method= RequestMethod.GET,  value="/v1/ejemplo/{ejemploId}",

 consumes="application/json")

Ejemplo getEjemplo( @PathVariable("ejemploId") String ejemploId);

}

La gente mayor recordarán un framework que trabajaba de forma similar llamado cxf. 

En la anotación @FeignClient le pasámos el nombre de la identificación del servicio que deseamos que represente la interfaz. A continuación, defimos un método, getEjemplo el cual retorna un objeto Ejemplo.

Como se puede ver la definición de la clase usa anotaciones de las cual ya estamos familiarizados. 

Para usar la clase EjemploFeignClient, todo lo que necesitamos hacer es injectarla y usarla. El código de Feign Client se encargará de todo el trabajo de codificación.

Cuando utiliza la clase Spring RestTemplate estándar, todos los códigos de estado HTTP de las llamadas de servicio se devolverán a través del método getStatusCode() de la clase ResponseEntity. Con Feign Client, cualquier código de estado HTTP 4xx – 5xx devuelto por el servicio al que se llama se asignará a una FeignException. FeignException contendrá un cuerpo JSON que se puede analizar para el mensaje de error específico. Feign le brinda la capacidad de escribir una clase de decodificación de errores que asignará el error a una clase de excepción personalizada. 

Dejo link : https://github.com/OpenFeign/feign

Service discovery usando Spring y Netflix Eureka

Ahora vamos a implementar el descubrimiento de servicios configurando un agente de descubrimiento de servicios y luego registrando dos servicios con el agente. Luego, un servicio llamará a otro servicio utilizando la información recuperada por el descubrimiento de servicios. Spring Cloud ofrece múltiples métodos para buscar información de un agente de descubrimiento de servicios. También analizaremos las fortalezas y debilidades de cada enfoque.

Una vez más, el proyecto Spring Cloud hace que este tipo de configuración sea trivial de realizar. Vamos a utilizar Spring Cloud y el motor de descubrimiento de servicios Eureka de Netflix para implementar el patrón de descubrimiento de servicios. Como balanceador de carga del lado del cliente, utilizaremos Spring Cloud y las bibliotecas Ribbon de Netflix.

Vamos a tener que seguir los siguentes pasos:

1. A medida que los servicios se inician se registrarán en el Servicio Eureka. Este proceso de registro le indicará a Eureka la ubicación física y el número de puerto de cada instancia de servicio junto con una ID de servicio para el servicio que se está iniciando.
2. Cuando un servicio llame a otro, utilizará Ribbon, que se comunicará con el servicio de Eureka para recuperar la información de ubicación del servicio y luego almacenarla esto en la caché localmente.
3. Periódicamente, la biblioteca de Netflix Ribbon hará ping al servicio Eureka y actualizará su memoria caché local de ubicaciones de servicio.

Cualquier nueva instancia de servicios será visible, mientras que cualquier instancia que no esté en buen estado se eliminará de la memoria caché local.

A continuación, implementará este diseño configurando su servicio Spring Cloud Eureka. 

Para empezar vamos a agregar la dependencia a Eureka, si usamos maven tenemos que agregar : 

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-eureka-server</artifactId>

</dependency>

Ahora tenemos que configurar nuestro server, en el archivo application.yml : 

server:

   port: 8761

 

eureka:

   client:

      registerWithEureka: false

      fetchRegistry: false

   server:

       waitTimeInMsWhenSyncEmpty:5

Las propiedades clave que se establecen son el atributo server.port que establece el puerto predeterminado utilizado para el servicio Eureka. El atributo eureka.client.registerWithEureka le dice al servicio que no se registre con un servicio Eureka cuando se inicia la aplicación Spring Boot Eureka porque este es el servicio Eureka. El atributo eureka.client.fetchRegistry se establece en falso para que cuando se inicie el servicio Eureka, no intente almacenar en caché su información de registro localmente. Cuando ejecute un cliente de Eureka, querrá cambiar este valor para los servicios de Spring Boot que se registrarán con Eureka.

Notará que el último atributo, eureka.server.waitTimeInMsWhenSyncEmpty , está comentado. Cuando esté probando su servicio localmente, debe descomentar esta línea porque Eureka no anunciará de inmediato ningún servicio que se registre con él. Esperará cinco minutos de forma predeterminada para dar a todos los servicios la oportunidad de registrarse antes de anunciarlos. Eliminar los comentarios de esta línea para las pruebas locales ayudará a acelerar la cantidad de tiempo que tardará el servicio Eureka en iniciarse y mostrar los servicios registrados en él.

El registro de servicios individuales tardará hasta 30 segundos en aparecer en el servicio Eureka porque Eureka requiere tres pings de latidos consecutivos del servicio separados por 10 segundos antes de decir que el servicio está listo para usarse. Tenga esto en cuenta cuando implemente y pruebe sus propios servicios.

El último trabajo de configuración que va a realizar para configurar su servicio Eureka es agregar una anotación a la clase de arranque de la aplicación que está utilizando para iniciar su servicio Eureka.

package com.assembly.app;

import org.springframework.boot.SpringApplication;

import org.springframework.boot.autoconfigure.SpringBootApplication;

import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication

@EnableEurekaServer

public class EurekaServerApplication {

   public static void main(String[] args) {

      SpringApplication.run(EurekaServerApplication.class, args);

   }

}

Y ya esta, tenemos nuestro server Eureka andando. En post posteriores vamos a registrar nuestros servicios. 

Consumir configuraciones de un servidor de configuración con Spring Cloud

Se acuerdan que en un post anterior hicimos un servidor de configuración con Spring Cloud. Ahora vamos a utilizarlo. 

Cuando el cliente se inicia por primera vez, pasará el perfil de Spring y el end point para comunicarse con el servicio de configuración de Spring Cloud. El valor del perfil Spring se asigna al entorno de las propiedades que se recuperan para el servicio Spring. El servicio Spring Cloud Config luego usará el repositorio de configuración de back-end configurado (sistema de archivos, Git, Consul, Eureka) para recuperar la información de configuración específica para el valor del perfil de Spring pasado en el URI. Spring Boot luego inyectará estos valores en las partes apropiadas de la aplicación.

Lo primero que debe hacer es agregar un par de entradas más al archivo Maven :

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-config-client</artifactId>

</dependency>

La dependencia, spring-cloud-config-client, contiene todas las clases necesarias para interactuar con el servidor de configuración de Spring Cloud.

Una vez definidas las dependencias de Maven, debe indicarle al servicio dónde ponerse en contacto con el servidor de configuración de Spring Cloud. En un servicio Spring Boot que usa Spring Cloud Config, la información de configuración se puede establecer en uno de dos archivos de configuración: bootstrap.yml y application.yml.

El archivo bootstrap.yml lee las propiedades de la aplicación antes de utilizar cualquier otra información de configuración. En general, el archivo bootstrap.yml contiene el nombre de la aplicación para el servicio, el perfil de la aplicación y el URI para conectarse a un servidor Spring Cloud Config.

Cualquier otra información de configuración que desee mantener local para el servicio (y no almacenada en Spring Cloud Config) se puede configurar localmente en los servicios en el archivo application.yml. Por lo general, la información que almacena en el archivo application.yml son datos de configuración que quizás desee tener disponibles para un servicio, incluso si el servicio Spring Cloud Config no está disponible. Los archivos bootstrap.yml y application.yml se almacenan en un directorio de proyectos src/main/resources.

Para que el cliente se comunique con su servicio Spring Cloud Config, debe agregar un archivo /src/main/resources/bootstrap.yml y configurar tres propiedades: spring.application.name, spring.profiles.active y spring.cloud.config.uri.

El archivo bootstrap.yml de los servicios de licencias se muestra en la siguiente lista.

spring.application.name es el nombre de su aplicación y debe asignarse directamente al nombre del directorio dentro de su servidor de configuración de Spring Cloud. Para el servicio de licencias, desea un directorio en el servidor de configuración de Spring Cloud llamado licenseservice.

La segunda propiedad, spring.profiles.active, se usa para decirle a Spring Boot con qué perfil debe ejecutarse la aplicación. Un perfil es un mecanismo para diferenciar los datos de configuración consumidos por la aplicación Spring Boot. Para el perfil del cliente, admitirá el entorno al que se asignará el servicio directamente en su entorno de configuración de la nube. Por ejemplo, al pasar dev como nuestro perfil, el servidor de configuración de Spring Cloud usará las propiedades dev. Si establece un perfil, el servicio de licencias utilizará el perfil predeterminado.

La tercera y última propiedad, spring.cloud.config.uri, es la ubicación donde el servicio de licencias debe buscar el servidor de configuración de Spring Cloud.

punto final. De forma predeterminada, el servicio de licencias buscará el servidor de configuración en http://localhost:8888. Más adelante en el capítulo, verá cómo anular las diferentes propiedades definidas en los archivos boostrap.yml y application.yml al iniciar la aplicación. Esto le permitirá decirle al microservicio de licencias en qué entorno se debe ejecutar.

Ahora, si abre el servicio de configuración de Spring Cloud, con la base de datos de Postgres correspondiente ejecutándose en su máquina local, puede iniciar el servicio de licencias utilizando su perfil predeterminado. Esto se hace cambiando al directorio de servicios de licencias y emitiendo los siguientes comandos:

 

 mvn spring-boot: ejecutar

Al ejecutar este comando sin establecer ninguna propiedad, el servidor de licencias intentará conectarse automáticamente al servidor de configuración de Spring Cloud utilizando el punto final (http://localhost:8888) y el perfil activo (predeterminado) definido en bootstrap.yml archivo del servicio de licencias.

Si desea anular estos valores predeterminados y apuntar a otro entorno, puede hacerlo compilando el proyecto de servicio de licencias en un JAR y luego ejecutar

el JAR con una anulación de propiedad del sistema -D. La siguiente llamada de línea de comando demuestra cómo iniciar el servicio de licencias con un perfil no predeterminado:

java -Dspring.cloud.config.uri=http://localhost:8888 \

-Dspring.profiles.active=dev \

-jar destino/servicio de licencias-0.0.1-SNAPSHOT.jar

Con la línea de comando anterior, está anulando los dos parámetros:

spring.cloud.config.uri y spring.profiles.active. Con la propiedad del sistema -Dspring.cloud.config.uri=http://localhost:8888, está apuntando a un servidor de configuración que se está ejecutando fuera de su caja local.

Con la propiedad del sistema –Dspring.profiles.active=dev, le indica al cliente que use el perfil de desarrollo (leído del servidor de configuración) 

Construyendo nuestro servidor de configuración con Spring Cloud

El servidor de configuración de Spring Cloud es una aplicación basada en REST que está construida sobre Spring Boot. No viene como un servidor independiente. En su lugar, puede elegir embeberlo en una aplicación Spring Boot existente o iniciar un nuevo proyecto Spring Boot con el servidor embebido.

Vamos a hacer una nueva aplicación string boot como servidor de configuraciones. Yo voy a utilizar spring initializr pero podemos agregar estas dependencias en un nuevo proyecto o uno existente. 

<dependencies>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-config</artifactId>

</dependency>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-config-server</artifactId>

</dependency>

</dependencies>

O con gradle sería así : 

implementation 'org.springframework.cloud:spring-cloud-starter-config'

implementation 'org.springframework.cloud:spring-cloud-config-server'

La primera dependencia es la dependencia spring-cloud-starter-config que utilizan todos los proyectos de Spring Cloud. La segunda dependencia es el proyecto de inicio spring-cloud-config-server. Esto contiene las bibliotecas centrales para spring-cloud-config-server.

Necesitamos configurar un archivo más para que el servidor de configuración central esté en funcionamiento. Este archivo es el archivo application.yml y lo debemos generar en el directorio src/main/resources. El archivo application.yml le dirá a su servicio de configuración de Spring Cloud qué puerto escuchar y dónde ubicar el back-end que entregará los datos de configuración. En mi caso el appication.yml es así : 

server:
  port: 8888
spring:
  profiles:
    active: native
  cloud:
    config:
      server:
        native:
          searchLocations: file:///{projectPath}/resources

Ojo que {projectPath} es donde esta el proyecto, la dirección por ejemplo el mio esta en /home/emanuel/misProyectos/application. 

En la configuración de Spring Cloud, todo funciona con una jerarquía. La configuración de la aplicación está representada por el nombre de la aplicación y luego un archivo de propiedades para cada entorno para el que se desea tener información de configuración. En cada uno de estos entornos, configurará dos propiedades de configuración. 

Vamos a suponer que tenemos 3 entornos uno de dev, otro de uat y otro de prod. Vamos a crear directorios para cada uno de los entornos en src/main/resources una carpeta por cada entorno. 

El mapeo de las carpetas y los archivos va a ser de la siguiente manera : 

/{application}/{profile}[/{label}]

/{application}-{profile}.yml

/{label}/{application}-{profile}.yml

/{application}-{profile}.properties

/{label}/{application}-{profile}.properties

Noten que el label es opcional. Por lo tanto si hacemos archivos application-dev.properties o application-uat.properties esto debería andar. 

Y por ultimo le decimos a spring que vamos a utilizar spring config con esta anotación : 

@SpringBootApplication
@EnableConfigServer
public class SettingsApplication {

Ahora levantamos el servidor y si necesitamos las configuraciones de uat deberíamos hacer : 

http://localhots:8888/application/uat

Tendremos este resultado : 

{"name":"demo","profiles":["uat"],"label":null,"version":null,"state":null,"propertySources":[{"name":"file:/home/emanuel/Projects/spring-cloud/settings/src/main/resources/demo-uat.yml","source":{"env":"dev"}},{"name":"file:/home/emanuel/Projects/spring-cloud/settings/src/main/resources/application.yml","source":{"server.port":8888,"spring.profiles.active":"native","spring.cloud.config.server.native.searchLocations":"file:///home/emanuel/Projects/spring-cloud/settings/src/main/resources"}}]}

Y listo, nos queda ver como podemos consumir estos settings. (pero eso es para otro post) 

Dejo link: https://cloud.spring.io/spring-cloud-config

La gestión de la configuración en Microservicios parte 2

En el post anterior vimos como podemos mantener las configuraciones de nuestros microservicios y ahora veamos que productos hay en el mercado:

Etcd: Proyecto de código abierto escrito en Go. Se utiliza para el descubrimiento de servicios y la gestión de configuración. Utiliza el protocolo raft (https://raft.github.io/) para su modelo de computación distribuida. Como beneficios podemos nombrar: 

• Muy rápido y escalable
• Distribuible
• Impulsado por línea de comandos
• Fácil de usar y configurar

Eureka: Escrito por Netflix. Extremadamente probado en batalla. Se utiliza tanto para el descubrimiento de servicios como para la gestión de forma clave-valor. Como características podemos nombrar: 

• Almacén distribuido clave-valor.
• Flexible; requiere esfuerzo para configurar
• Ofrece actualización dinámica del cliente lista para usar

Cónsul: Escrito por Hashicorp. Similar a Etcd y Eureka en características, pero usa un algoritmo diferente para su modelo de computación distribuida (protocolo SWIM; https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf).

• Rápido
• Ofrece descubrimiento de servicios nativos con la opción de integrarse directamente con DNS
• No ofrece actualización dinámica para el cliente de inmediato.

ZooKeeper: un proyecto de Apache que ofrece capacidades de bloqueo distribuidas. A menudo se utiliza como una solución de gestión de la configuración para acceder a datos valor-clave.

• Las soluciones más antiguas y probadas en batalla
• El más complejo de usar
• Se puede utilizar para la gestión de la configuración, pero solo debe tenerse en cuenta si ya está utilizando ZooKeeper en otras piezas de su arquitectura.

Servidor de configuración de Spring Cloud: un proyecto de código abierto que ofrece una solución de administración de configuración general con diferentes backends. Puede integrarse con Git, Eureka y Consul como back-end.

• Almacén distribuido clave-valor no distribuido
• Ofrece una estrecha integración para los servicios Spring y no Spring 
• Puede usar múltiples backends para la creación de historias
• datos de configuración que incluyen sistema de archivos, Eureka, Consul y Git

El servidor de configuración Spring Cloud ofrece múltiples backends para almacenar datos de configuración. Si ya está utilizando herramientas como Eureka y Consul, puede conectarlas directamente al servidor de configuración de Spring Cloud.

De todas las soluciones, el servidor de configuración de Spring Cloud puede integrarse directamente con la plataforma de control de fuente Git. La integración de la configuración de Spring Cloud con Git elimina una dependencia adicional en sus soluciones y facilita el control de versiones de los datos de configuración de su aplicación.

Las otras herramientas (Etcd, Consul, Eureka) no ofrecen ningún tipo de control de versiones nativo y, si lo desea, debe crearlo usted mismo. Si su tienda usa Git, el uso del servidor de configuración Spring Cloud es una opción atractiva.

Ejemplo de microservicio con Spring boot y Spring Cloud

Vamos hacer un hola mundo con microservicios y Spring boot. Ojo usamos algunas tecnologías, no todo porque es un hola mundo: 

//Removed other imports for conciseness

import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;

import com.netflix.hystrix.contrib.javanica.annotation.HystrixProperty;

import org.springframework.cloud.netflix.eureka.EnableEurekaClient;

import org.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker;

@SpringBootApplication

@RestController

@RequestMapping(value="hello")

@EnableCircuitBreaker //Enables the service to use the Hystrix and Ribbon libraries

@EnableEurekaClient //Service discovery 

public class Application {

public static void main(String[] args) {

    SpringApplication.run(Application.class, args);

    }

    @HystrixCommand(threadPoolKey = "helloThreadPool")

    public String helloRemoteServiceCall(String firstName, String lastName){

        ResponseEntity<String> restExchange = restTemplate.exchange( 

            "http://logical-service-id/name/[ca]{firstName}/{lastName}",

             HttpMethod.GET,

             null, String.class, firstName, lastName);

        return restExchange.getBody();

}

    @RequestMapping(value="/{firstName}/{lastName}", method = RequestMethod.GET)

    public String hello( @PathVariable("firstName") String firstName,

        @PathVariable("lastName") String lastName) {

         return helloRemoteServiceCall(firstName, lastName)

    }

}

La anotación @EnableCircuitBreaker le dice que el microservicio Spring va a utilizar las bibliotecas de Netflix Hystrix en su aplicación. La anotación @EnableEurekaClient dice que el  microservicio se registre con un agente de Eureka Service Discovery y que utilizará el descubrimiento de servicios para buscar puntos finales de servicios REST remotos en su código. La configuración se lleva a cabo en un archivo de propiedades que le indicará al servicio simple la ubicación y el número de puerto de un servidor Eureka para contactar. Usamos Hystrix cuando declaramos el método de saludo:

@HystrixCommand(threadPoolKey = "helloThreadPool")

public String helloRemoteServiceCall(String firstName, String lastName)

La anotación @HystrixCommand hace dos cosas. Primero, cada vez que se llama al método helloRemoteServiceCall, no se invocará directamente. En cambio, el método se delegará a un grupo de subprocesos administrado por Hystrix. Si la llamada tarda demasiado (el valor predeterminado es un segundo), Hystrix interviene e interrumpe la llamada. Esta es la implementación del patrón de circuit breaker . Lo segundo que hace esta anotación es crear un grupo de subprocesos llamado helloThreadPool que es administrado por Hystrix. Todas las llamadas al método helloRemoteServiceCall solo se producirán en este grupo de subprocesos y se aislarán de cualquier otra llamada de servicio remoto que se realice.

Lo último a tener en cuenta es lo que ocurre dentro del método helloRemoteServiceCall. La presencia de @EnableEurekaClient le ha dicho a Spring Boot que va a usar una clase RestTemplate modificada (no es así como la Spring RestTemplate estándar funcionaría de fábrica) cada vez que realiza una llamada de servicio REST. Esta clase RestTemplate le permitirá pasar un ID de servicio lógico para el servicio que está intentando invocar:

ResponseEntity<String> restExchange = restTemplate.exchange(http://logical-service-id/name/{firstName}/{lastName}

La clase RestTemplate se pondrá en contacto con el servicio de Eureka y buscará la ubicación física de una o más de las instancias del servicio "nombre". Como consumidor del servicio, su código nunca tiene que saber dónde se encuentra ese servicio.

Además, la clase RestTemplate está usando la biblioteca Ribbon de Netflix. Ribbon recuperará una lista de todos los puntos finales físicos asociados con un servicio. Cada vez que el cliente llama al servicio, realiza un "round-robins" de la llamada a las diferentes instancias del servicio en el cliente sin tener que pasar por un equilibrador de carga centralizado. Al eliminar un equilibrador de carga centralizado y trasladarlo al cliente, elimina otro punto de falla (el equilibrador de carga baja) en la infraestructura de su aplicación.

Haciendo microservicios con Spring Cloud

 

El equipo de Spring ha integrado una gran cantidad de proyectos open source usados en el mercado en un subproyecto de Spring conocido colectivamente como Spring Cloud. 

Spring Cloud envuelve el trabajo de empresas de código abierto como Pivotal, HashiCorp y Netflix en la implementaciones de patrones para trabajar con microservicios orientados a la nube. Spring Cloud simplifica la instalación y configuración de estos proyectos en aplicaciones Spring para que el desarrollador pueda concentrarse en escribir código, sin quedar enterrado en los detalles de la configuración de toda la infraestructura necesaria para construir e implementar una aplicación de microservicio.

Veamos un gráfico que muestra las implementaciones a patrones de microservicios con spring cloud : 

Empecemos por el principio, todo estos framework se apoyan en spring boot. Spring Boot es la tecnología central utilizada en la implementación de microservicios. Spring Boot simplifica enormemente el desarrollo de microservicios al simplificar las tareas principales de crear microservicios basados en REST. Spring Boot también simplifica enormemente la asignación de verbos de estilo HTTP (GET, PUT, POST y DELETE) a URL y la serialización del protocolo JSON hacia y desde objetos Java, así como la asignación de excepciones de Java a códigos de error HTTP estándar.

Spring Cloud Config maneja la administración de los datos de configuración de la aplicación a través de un servicio centralizado para que los datos de configuración de la aplicación (particularmente los datos de configuración específicos de su entorno) estén claramente separados de su microservicio implementado. Esto asegura que no importa cuántas instancias de microservicio aparezcan, siempre tendrán la misma configuración. Spring Cloud Config tiene su propio repositorio de administración de propiedades, pero también se integra con proyectos de código abierto como los siguientes:

• Git: Git (https://git-scm.com/) es un sistema de control de versiones de código abierto que le permite administrar y realizar un seguimiento de los cambios en cualquier tipo de archivo de texto. Spring Cloud Config puede integrarse con un repositorio respaldado por Git y leer los datos de configuración de la aplicación fuera del repositorio.
• Consul — Consul (https://www.consul.io/) es una herramienta de descubrimiento de servicios de código abierto que permite que las instancias de servicio se registren en el servicio. Los clientes del servicio pueden preguntarle a Consul dónde se encuentran las instancias del servicio. Consul también incluye una base de datos basada en el almacén de valores clave que Spring Cloud Config puede utilizar para almacenar datos de configuración de la aplicación.
• Eureka — Eureka (https://github.com/Netflix/eureka) es un proyecto de Netflix de código abierto que, como Consul, ofrece capacidades de descubrimiento de servicios similares. Eureka también tiene una base de datos de valores clave que se puede usar con Spring Cloud Config.

Con el descubrimiento del servicio Spring Cloud, puede abstraer la ubicación física (IP y / o nombre del servidor) de donde se implementan sus servidores de los clientes que consumen el servicio. Los consumidores de servicios invocan la lógica empresarial de los servidores a través de un nombre lógico en lugar de una ubicación física. El descubrimiento de servicios de Spring Cloud también maneja el registro y la cancelación del registro de las instancias de servicios a medida que se inician y apagan. El descubrimiento de servicios de Spring Cloud se puede implementar utilizando Consul (https://www.consul.io/) y Eureka (https://github.com/Netflix/eureka) como su motor de descubrimiento de servicios.

Spring Cloud se integra en gran medida con los proyectos de código abierto de Netflix. Para los patrones de resiliencia del cliente de microservicio, Spring Cloud envuelve las bibliotecas de Netflix Hystrix (https://github.com/Netflix/Hystrix) y el proyecto Ribbon (https://github.com/Netflix/Ribbon) y hace que sean fácil de usar. 

Con las bibliotecas de Netflix Hystrix, puede implementar rápidamente patrones de resistencia del cliente de servicio, como los patrones Circuit breakers y Bulkhead.

Si bien el proyecto Netflix Ribbon simplifica la integración con agentes de descubrimiento de servicios como Eureka, también proporciona equilibrio de carga del lado del cliente de las llamadas de servicio de un consumidor de servicios. Esto hace posible que un cliente continúe realizando llamadas de servicio incluso si el agente de descubrimiento de servicios no está disponible temporalmente.

Spring Cloud utiliza el proyecto Netflix Zuul (https://github.com/Netflix/zuul) para proporcionar capacidades de enrutamiento de servicios para su aplicación de microservicio. Zuul es una puerta de enlace de servicios que procesa las solicitudes de servicio y se asegura de que todas las llamadas a sus microservicios pasen por una única "puerta de entrada" antes de que se invoque el servicio de destino. Con esta centralización de llamadas de servicio, puede aplicar políticas de servicio estándar, como autenticación de autorización de seguridad, filtrado de contenido y reglas de enrutamiento.

Spring Cloud Stream (https://cloud.spring.io/spring-cloud-stream/) es una tecnología habilitadora que le permite integrar fácilmente el procesamiento de mensajes livianos en su microservicio. Con Spring Cloud Stream, puede crear microservicios inteligentes que pueden usar eventos asincrónicos a medida que ocurren en su aplicación. Con Spring Cloud Stream, puede integrar rápidamente sus microservicios con agentes de mensajes como RabbitMQ (https://www.rabbitmq.com/) y Kafka (http://kafka.apache.org/).

Spring Cloud Sleuth (https://cloud.spring.io/spring-cloud-sleuth/) le permite integrar identificadores de seguimiento únicos en las llamadas HTTP y los canales de mensajes (RabbitMQ, Apache Kafka) que se utilizan dentro de su aplicación. Estos números de seguimiento, a veces denominados identificadores de correlación o seguimiento, le permiten realizar un seguimiento de una transacción a medida que fluye a través de los diferentes servicios de su aplicación. Con Spring Cloud Sleuth, estos ID de seguimiento se agregan automáticamente a cualquier declaración de registro que realice en su microservicio.

La verdadera belleza de Spring Cloud Sleuth se ve cuando se combina con herramientas de tecnología de agregación de registros como Papertrail (http://papertrailapp.com) y herramientas de rastreo como Zipkin (http://zipkin.io). Papertail es una plataforma de registro basada en la nube que se utiliza para agregar registros en tiempo real de diferentes microservicios en una base de datos consultable. Open Zipkin toma datos producidos por Spring Cloud Sleuth y le permite visualizar el flujo de sus llamadas de servicio involucradas para una sola transacción.

Spring Cloud Security (https://cloud.spring.io/spring-cloud-security/) es un marco de autenticación y autorización que puede controlar quién puede acceder a sus servicios y qué pueden hacer con sus servicios. Spring Cloud Security se basa en tokens y permite que los servicios se comuniquen entre sí a través de un token emitido por un servidor de autenticación. Cada servicio que recibe una llamada puede verificar el token proporcionado en la llamada HTTP para validar la identidad del usuario y sus derechos de acceso al servicio. Además, Spring Cloud Security es compatible con JavaScript Web Token (https://jwt.io). JavaScript Web Token (JWT) estandariza el formato de cómo se crea un token OAuth2 y proporciona estándares para firmar digitalmente un token creado.

Dejo link : http://projects.spring.io/spring-cloud/

Microservicios con Spring

Spring se ha convertido en el framework de desarrollo de facto para crear aplicaciones basadas en Java. En esencia, Spring se basa en el concepto de inyección de dependencia. En una aplicación Java normal, la aplicación se descompone en clases en las que cada clase suele tener vínculos explícitos con otras clases de la aplicación. Los enlaces son la invocación de un constructor de clase directamente en el código. Una vez que se compila el código, estos puntos de enlace no se pueden cambiar.

Esto es problemático en un proyecto grande porque estos vínculos externos son frágiles y hacer un cambio puede resultar en múltiples impactos posteriores en otro código. Un marco de inyección de dependencia, como Spring, le permite administrar más fácilmente grandes proyectos de Java al externalizar la relación entre los objetos dentro de su aplicación a través de convenciones (y anotaciones) en lugar de aquellos objetos que tienen conocimientos codificados entre sí. Spring actúa como intermediario entre las diferentes clases de Java de su aplicación y administra sus dependencias. Spring esencialmente le permite ensamblar su código como un conjunto de ladrillos de Lego que se unen.

La rápida inclusión de funciones de Spring impulsó su utilidad, y el marco se convirtió rápidamente en una alternativa más liviana para los desarrolladores de aplicaciones empresariales de Java que buscaban una forma de crear aplicaciones utilizando la pila J2EE. El stack J2EE, aunque poderosa, fue considerada por muchos como bloatware, con muchas características que nunca fueron utilizadas por los equipos de desarrollo de aplicaciones. Además, una aplicación J2EE le obligó a utilizar un servidor de aplicaciones Java completo (y pesado) para implementar sus aplicaciones.

Lo sorprendente del marco de Spring y un testimonio de su comunidad de desarrollo es su capacidad para mantenerse relevante y reinventarse. El equipo de desarrollo de Spring vio rápidamente que muchos equipos de desarrollo se estaban alejando de las aplicaciones monolíticas donde la presentación de la aplicación, el negocio y la lógica de acceso a los datos estaban empaquetados y desplegados como un solo artefacto. En cambio, los equipos se estaban moviendo hacia modelos altamente distribuidos donde los servicios se construían como servicios pequeños y distribuidos que podían implementarse fácilmente en la nube. En respuesta a este cambio, el equipo de desarrollo de Spring lanzó dos proyectos: Spring Boot y Spring Cloud.

Spring Boot es una nueva visión del framework de Spring. Si bien abarca las características centrales de Spring, Spring Boot elimina muchas de las características "empresariales" que se encuentran en Spring y, en su lugar, ofrece un marco orientado a microservicios basados ​​en Java y orientados a REST (Transferencia de estado representacional). Con unas pocas anotaciones simples, un desarrollador de Java puede crear rápidamente un microservicio REST que se puede empaquetar e implementar sin la necesidad de un contenedor de aplicaciones externo.

Debido a que los microservicios se han convertido en uno de los patrones arquitectónicos más comunes para la creación de aplicaciones basadas en la nube, la comunidad de desarrollo de Spring nos ha proporcionado Spring Cloud. El framework de Spring Cloud simplifica la puesta en funcionamiento e implementación de microservicios en una nube pública o privada. Spring Cloud incluye varios frameworks de microservicios de gestión de la nube populares en un framework común y hace que el uso y la implementación de estas tecnologías sean tan fáciles de usar como anotar su código.