SlideShare una empresa de Scribd logo
ARQUITECTURA
DE
MICROSERVICIOS
El mapa completo
15/Mar/18
Sobre nosotros
■ Julio Palma
■ Twitter: @restalion
■ GitHub: github.com/restalion
■ Technology Architect en Tecnilógica
■ Juanma Cintas
■ Twitter: @juanmacintas
■ GitHub: github.com/juanmacintas
■ Senior Analyst en Tecnilógica
Objetivos de la sesión
 Tener una solución basada en microservicios en producción y poder dormir todas
las noches.
 Entender las diferencias entre una arquitectura monolítica y otra basada en
microservicios.
 Crear un mapa de todos los servicios que necesitaremos de la outer architecture
que nos permita “montar” una solución completa.
 Identificar algunas alternativas para cubrir cada una de las áreas de la outer
architecture.
Objetivos de la sesión
 Tener una solución basada en microservicios en producción y poder dormir todas
las noches.
 Entender las diferencias entre una arquitectura monolítica y otra basada en
microservicios.
 Crear un mapa de todos los servicios que necesitaremos de la outer architecture
que nos permita “montar” una solución completa.
 Identificar algunas alternativas para cubrir cada una de las áreas de la outer
architecture.
¿Qué es la Outer
Architecture?
Monolito
Monolito
Monolito
Monolito
Un único .war
representa una
“Solución”
Monolito
Monolito
EIS
Servicios
DAO
Monolito
Monolito
EIS
Presentación
Métricas
Gestión de erroresServicios
DAO
Monolito
Monolito
PresentaciónConfiguración
Logs
Auditoría
Inversión del
Control
EIS
Seguridad
Métricas
Gestión de erroresServicios
DAO
Monolito
Monolito
Presentación
Inversión del
Control
EIS
DAO DAO
EIS EIS
Configuración
Logs
Auditoría
Seguridad
Métricas
Gestión de errores
Servicio
DAO
Monolito
Monolito
Presentación
Inversión del
Control
EIS
DAO DAO
EIS EIS
Servicio Servicio Servicio
Configuración
Logs
Auditoría
Seguridad
Monolito
1. Una única aplicación para implementar toda la funcionalidad.
2. Un ecosistema común para todas las piezas de la aplicación.
3. Reutilización basada en los componentes (importación).
4. Sencillez de despliegue.
5. Una única versión de los componentes.
6. Aplicaciones complejas cuya responsabilidad es implementar todo el negocio.
7. Fragilidad: un error en cualquier pieza tumba todo el monolito.
Métricas
Gestión de errores
Servicio
DAO
Microservicios
Monolito
Presentación
Inversión del
Control
EIS
DAO DAO
EIS EIS
Servicio Servicio Servicio
Configuración
Logs
Auditoría
Seguridad
Métricas
Gestión de errores
Servicio
DAO
Microservicios
Presentación
Inversión del
Control
EIS
DAO DAO
EIS EIS
Servicio Servicio Servicio
Configuración
Logs
Auditoría
Seguridad
Métricas
Gestión de errores
Servicio
DAO
Microservicios
Presentación
Inversión del
Control
EIS
DAO DAO
EIS EIS
Servicio Servicio Servicio
Configuración
Logs
Auditoría
Seguridad
*HTTP
Métricas
Resistencia
a errores
Servicio
DAO
Microservicios
Presentación
Localización de
servicios
EIS
DAO DAO
EIS EIS
Servicio Servicio Servicio
Configuración
centralizada
Logs distribuidos
Auditoría
Seguridad
(MMI y M2M)
Métricas
Resistencia
a errores
Servicio
DAO
Microservicios
Presentación
Localización de
servicios
EIS
DAO DAO
EIS EIS
Servicio Servicio Servicio
Configuración
centralizada
Logs distribuidos
Auditoría
Seguridad
(H2M y M2M)
Composición
de la solución
Gestión de
la carga
Documentación de
interfaces
Microservicios
1. Muchas aplicaciones que implementan la funcionalidad completa.
2. Ecosistema políglota dentro de una misma solución.
3. Reutilización basada en uso (llamada a interfaces).
4. Despliegue sencillo de cada aplicación, complejo en la solución completa.
5. Varias versiones de la misma aplicación pueden convivir en ejecución.
6. Cada aplicación tiene la responsabilidad (y exclusiva) en un área concreta de la
solución.
7. Se pueden desplegar de forma independiente.
8. Se incrementa la latencia y el tráfico de red.
Objetivos de la sesión
 Tener una solución basada en microservicios en producción y poder dormir todas
las noches.
 Entender las diferencias entre una arquitectura monolítica y otra basada en
microservicios.
 Crear un mapa de todos los servicios que necesitaremos de la outer architecture
que nos permita “montar” una solución completa.
 Identificar algunas alternativas para cubrir cada una de las áreas de la outer
architecture.
Estructura de los microservicios
1. BBDD H2 en memoria
2. Acceso con Spring Data
3. Servicios Spring
4. REST Interface
5. Project Lombok
6. Swagger
Servicios de ejemplo
Outer Architecture
Métricas
Resistencia
a errores
Localización de
servicios
Configuración
centralizada
Logs distribuidos
Auditoría
Seguridad
(H2M y M2M)
Composición
de la solución
Gestión de
la carga
Documentación de
interfaces
Configuración
Outer Architecture - Monolito
■ En una aplicación monolítica la configuración de la aplicación se puede realizar
mediante múltiples formas:
– Fichero de propiedades
– Parámetros de configuración en la ejecución
■ La configuración no suele ser un gran problema podemos tener varios tipos de
ficheros, perfiles… que se seleccionan en el momento de “levantar” la aplicación.
■ Tenemos un número limitado de instancias (desarrollo, preproducción,
producción,…) cada una con su configuración específica.
■ Normalmente es el equipo de operaciones el encargado de configurar y mantener
la configuración de los distintos entornos.
Outer Architecture - Microservicios
Configuración
centralizada
■ En un esquema de microservicios la operación se complica:
– Múltiples instancias de la misma aplicación con el mismo perfil, o distinto.
– Versiones distintas del mismo servicio en el mismo entorno.
■ El mantenimiento de las aplicaciones en ejecución se puede llevar desde una
plataforma (sin intervención humana directa).
■ Rolling updates, de los servicios
Outer Architecture - Microservicios
Configuración
centralizada
■ Ejemplo: Config server
■ Distintos tipos de clientes dependiendo de la naturaleza de la aplicación.
Seguridad
Outer Architecture - Monolito
■ El control de acceso a la aplicación se realiza una vez.
– Si tienes acceso mientras dure tu sesión podrás ejecutar todos los servicios
que te permita tu perfil.
■ El acceso al frontal y a los servicios está unificado.
Outer Architecture - Microservicios
Seguridad
(H2M y M2M)
■ Podemos tener esquemas de seguridad independientes por cada servicio o
frontal.
■ Hay que diferenciar entre la seguridad para el acceso a la aplicación por parte
de humanos y las llamadas entre máquinas.
■ Nos permite granularidad a la hora de definir quién tiene acceso a qué servicio
o funcionalidad.
■ Podemos establecer criterios como cuotas de uso.
■ Permite monetizar el consumo de servicios.
Outer Architecture - Microservicios
Seguridad
(H2M y M2M)
IAM
Presentación
Authorization Server
µServices
1
2
3
4
5
6 78
9 10
Acceso a la aplicación de presentación (SAML)
1. El usuario accede a la aplicación de presentación.
2. Se comprueba si está presente el token SAML. Si no redirigimos
al IAM.
3. El IAM muestra la pantalla de login.
4. El usuario introduce sus credenciales.
5. Si son válidas, el IAM genera el token SAML y redirige a la
aplicación de presentación.
Acceso a la aplicación de backend (OAuth2)
6. Se solicita el token al authorization server con las credenciales
del consumidor.
7. Si son válidas genera un token y lo devuelve.
8. Se realiza la llamada al servicio.
9. El resource server captura el token y comprueba contra el
authorization server que sea correcto.
10. Si lo es se realiza la llamada al servicio.
Resource
Server
Outer Architecture - Microservicios
Seguridad
(H2M y M2M)
■ Ejemplo: CAS + SAML para la parte frontal
■ Ejemplo: Okta + SAML para la parte frontal
■ Ejemplo: Oauth2 para la M2M.
■ Ejemplo: 3Scale para el API Management.
Logs
Outer Architecture - Monolito
■ Los logs se escriben en ficheros directamente desde la aplicación.
■ Utilizamos distintos niveles de log dependiendo del entorno (para no penalizar los
entornos productivos).
■ Se pueden consultar los ficheros físicos en el servidor.
■ Utilizamos herramientas como PERL para facilitar el trabajo de análisis de los
ficheros de log.
Outer Architecture - Microservicios
Logs
distribuidos
■ Las instancias de los microservicios son desechables, cuando dejan de tener
utilidad se destruyen.
■ Los ficheros físicos pueden dejar de existir cuando se destruyen los servicios.
■ Incluso en el mejor de los casos podríamos tener muchos ficheros distintos en
distintas localizaciones.
■ El planteamiento en estos casos es la creación de un servicio de logs que los
guarda de forma unificada en una BBDD que nos permite una consulta sencilla
de los mismos.
■ También el uso de herramientas que nos permite trazar la ejecución completa
de la solución por las distintas aplicaciones.
Outer Architecture - Microservicios
Logs
distribuidos
■ Ejemplo: Servcio custom + ElasticSearch + Kibana
■ Ejemplo: Sleuth + Zipkin + ElasticSearch + Kibana
Gestión de errores
Outer Architecture - Monolito
■ Desarrollamos nuestro código para responder correctamente ante los errores.
■ Cuando se produce una excepción la tratamos si es posible de forma que la
aplicación siga funcionando.
■ Si se produce un error catastrófico toda la solución deja de funcionar.
Outer Architecture - Microservicios
Resistencia
a errores
■ Cuando un microservicio falla de forma catastrófica se cae pero su rol puede
ser cubierto por otra instancia del mismo.
■ Además de los errores propios de la aplicación tenemos que ser capaces de
responder ante los errores de los servicios que consumimos.
– Tenemos que ser capaces de responder ante el caso de que un servicio al
que llamamos no responda, o devuelva un error.
■ Definimos mecanismos que nos permiten responder ante este tipo de errores.
Outer Architecture - Microservicios
Resistencia
a errores
■ Ejemplo: Hystrix
Inversión del Control
Outer Architecture - Monolito
■ Mecanismo para localizar los servicios a los que llamamos.
■ Evitamos el mecanismo “clásico” de instanciar los servicios para poder utilizarlos.
■ Se optimizan los recursos utilizados ya que sólo utilizamos el número de instancias
realmente necesarias.
Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
Eureka
Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1
Eureka
1
Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2
Eureka
1, 2
Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3
Eureka
1, 2
3
Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4
Eureka
1, 2
3, 4
Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4 5
Eureka
1, 2, 5
3, 4
Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4 5 6
Eureka
1, 2, 5, 6
3, 4
Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4 5 6 7
Eureka
1, 2, 5, 6
3, 4
7
Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4 5 6 7
Eureka
1, 2, 5, 6
3, 4
7
Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4 5 6 7
Eureka
1, 2, 5, 6
3, 4
7
Outer Architecture - Microservicios
Localización
de servicios
■ Es la extensión del modelo de inversión de control al mundo de microservicios.
■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan
localizarlo.
■ El los consumidores solicitan al registro la forma de llamar al servicio.
■ Una vez localizado el servicio puede ser consumido.
1 2 3 4 5 6 7
Eureka
1, 2, 5, 6
3, 4
7
Outer Architecture - Microservicios
Localización
de servicios
■ Ejemplo: Eureka + Feign
Outer Architecture - Microservicios
Documentación
de los interfaces
■ Una nueva necesidad del modelo de microservicios.
■ Debido a la gran cantidad de servicios necesitamos un mecanismo que nos
permita documentar todos los interfaces disponibles.
■ En el código indicamos esta información y un servicio lo publica y permite su
consumo.
Outer Architecture - Microservicios
Documentación
de los interfaces
■ Ejemplo: Swagger
Outer Architecture - Microservicios
Composición
de la solución
■ Una nueva necesidad del modelo de microservicios.
■ Ya no disponemos de “un war” que nos permite desplegar la solución.
■ Es necesario definir la forma completa de la misma para que el montaje sea
repetible.
■ Se puede realizar a varios niveles y apoyándonos en diversas tecnologías.
Outer Architecture - Microservicios
Composición
de la solución
■ Ejemplo: Docker compose
Outer Architecture - Microservicios
Gestión de
la carga
■ Los servicios se consumen desde distintos orígenes.
■ No podemos controlar cuántas solicitudes vamos a tener en un momento
determinado.
■ ¿Qué hacer cuando el servicio puede empezar a no responder?
■ Establecemos límites de carga a partir de los cuales crecemos horizontalmente.
Outer Architecture - Microservicios
Gestión de
la carga
■ Ejemplo: Openshift +
3Scale
■ Zuul
m4.2xlarge m4.2xlarge m4.2xlarge
m4.xlarge m4.xlarge m4.xlarge m4.xlarge
t2.micro
Bastion Host
m4.large m4.large m4.large
2 Tb 2 Tb 2 Tb
Objetivos de la sesión
 Tener una solución basada en microservicios en producción y poder dormir todas
las noches.
 Entender las diferencias entre una arquitectura monolítica y otra basada en
microservicios.
 Crear un mapa de todos los servicios que necesitaremos de la outer architecture
que nos permita “montar” una solución completa.
 Identificar algunas alternativas para cubrir cada una de las áreas de la outer
architecture.
Conclusiones
■ Los microservicios no son la respuesta a todos los problemas.
■ Las arquitecturas basadas en microservicios complican el despliegue frente a
las monolíticas.
■ Proporcionan elasticidad ante cargas inesperadas.
■ La definición de los servicios de arquitectura tiene adaptarse al modelo
seleccionado para la solución.
To take away
HACKERS WANTED https://github.com/juanmacintas/ejercicioMircroserviciosSpringCloud

Más contenido relacionado

PDF
Arquitectura de microservicios
PPTX
TDD - Test Driven Development
PDF
Microservicios
PPTX
¿Que son los microservicios?
PDF
비용 관점에서 AWS 클라우드 아키텍처 디자인하기::류한진::AWS Summit Seoul 2018
PPTX
Microservicios.pptx
PDF
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
Arquitectura de microservicios
TDD - Test Driven Development
Microservicios
¿Que son los microservicios?
비용 관점에서 AWS 클라우드 아키텍처 디자인하기::류한진::AWS Summit Seoul 2018
Microservicios.pptx
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017

La actualidad más candente (20)

PPTX
Java Spring framework, Dependency Injection, DI, IoC, Inversion of Control
PDF
Implementando una Arquitectura de Microservicios
PDF
소프트웨어 아키텍처
PDF
[Spring Camp 2018] 11번가 Spring Cloud 기반 MSA로의 전환 : 지난 1년간의 이야기
PPTX
MSA ( Microservices Architecture ) 발표 자료 다운로드
PPTX
Princípios SOLID
PDF
Domain Driven Design
PPTX
Microservice vs. Monolithic Architecture
PPTX
Tarea1 programacion-distribuida
PPTX
Domain Driven Design(DDD) Presentation
PPSX
SOLID Principles and The Clean Architecture
PDF
Patrones de creación
PDF
CICLO DE DESARROLLO DE ARQUITECTURA DE SOFTWARE.pdf
PDF
Especificación y resultados de las pruebas de software
PDF
Microservice Architecture | Microservices Tutorial for Beginners | Microservi...
PPT
Spring Core
PPTX
Patron de Arquitectura Broker
PDF
MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?
PDF
Cuadro comparativo modelos para el desarrollo de software
Java Spring framework, Dependency Injection, DI, IoC, Inversion of Control
Implementando una Arquitectura de Microservicios
소프트웨어 아키텍처
[Spring Camp 2018] 11번가 Spring Cloud 기반 MSA로의 전환 : 지난 1년간의 이야기
MSA ( Microservices Architecture ) 발표 자료 다운로드
Princípios SOLID
Domain Driven Design
Microservice vs. Monolithic Architecture
Tarea1 programacion-distribuida
Domain Driven Design(DDD) Presentation
SOLID Principles and The Clean Architecture
Patrones de creación
CICLO DE DESARROLLO DE ARQUITECTURA DE SOFTWARE.pdf
Especificación y resultados de las pruebas de software
Microservice Architecture | Microservices Tutorial for Beginners | Microservi...
Spring Core
Patron de Arquitectura Broker
MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?
Cuadro comparativo modelos para el desarrollo de software
Publicidad

Similar a Arquitectura de microservicios (20)

PPTX
Open southcode arquitectura microservicios
PDF
Microservicios - RabbitMQ
PPTX
Microservicios.pptx
PDF
An evening with... Microservices - Session 1
PPTX
arquitectura de microservicios en el diseño de aplicaciones.pptx
PPTX
Reestructuración y Optimización de una de una Aplicación Monolítica.
PDF
MuleSoft y la Arquitectura Orientada a Microservicios (MSA)
PDF
Arquitectura_de_microservicios.pdf
PPTX
arquitectura de......Microservicios.pptx
PPTX
Trabajo de microservicios
PDF
Microservicios, un nuevo enfoque para arquitecturas orientas a servicios.
PPTX
ADR - Introducción a Microservicios - Incluye notas del presentador (1).pptx
PPTX
ADR - Introducción a Microservicios - Incluye notas del presentador (1).pptx
PPTX
Trabajo de microservicios
PDF
Micro vs Nano (servicios)
PDF
Microservicios y Gestion de APIs
PPT
Servidores De Aplicacion
PPT
Servidores de-aplicacion-1211055568915043-9
PPTX
Arquitectura Microservicios en plataformas TI.pptx
PDF
Patrones de Diseño en la Arquitectura de Integración Moderna
Open southcode arquitectura microservicios
Microservicios - RabbitMQ
Microservicios.pptx
An evening with... Microservices - Session 1
arquitectura de microservicios en el diseño de aplicaciones.pptx
Reestructuración y Optimización de una de una Aplicación Monolítica.
MuleSoft y la Arquitectura Orientada a Microservicios (MSA)
Arquitectura_de_microservicios.pdf
arquitectura de......Microservicios.pptx
Trabajo de microservicios
Microservicios, un nuevo enfoque para arquitecturas orientas a servicios.
ADR - Introducción a Microservicios - Incluye notas del presentador (1).pptx
ADR - Introducción a Microservicios - Incluye notas del presentador (1).pptx
Trabajo de microservicios
Micro vs Nano (servicios)
Microservicios y Gestion de APIs
Servidores De Aplicacion
Servidores de-aplicacion-1211055568915043-9
Arquitectura Microservicios en plataformas TI.pptx
Patrones de Diseño en la Arquitectura de Integración Moderna
Publicidad

Último (10)

PDF
DIMENSIONADO DE UNA INSTALACION FOTOVOLTAICA.pdf
DOCX
trabajo programacion.docxxdxxxddxdxxdxdxxxdxxdxdxd
PDF
Su punto de partida en la IA: Microsoft 365 Copilot Chat
PPTX
sistemas de informacion.................
PDF
Conceptos básicos de programación por Antonia Diaz Bernal
PDF
Conceptos básicos de programación por Antonia Díaz Bernal
PDF
Software para la Administración Y Control de Condominios
PPTX
Derechos_de_Autor_y_Creative_Commons.pptx
PDF
ANÁLISIS Y DISEÑO DE ALGORITMOS
PDF
simulacion de teoria de control para maquinas
DIMENSIONADO DE UNA INSTALACION FOTOVOLTAICA.pdf
trabajo programacion.docxxdxxxddxdxxdxdxxxdxxdxdxd
Su punto de partida en la IA: Microsoft 365 Copilot Chat
sistemas de informacion.................
Conceptos básicos de programación por Antonia Diaz Bernal
Conceptos básicos de programación por Antonia Díaz Bernal
Software para la Administración Y Control de Condominios
Derechos_de_Autor_y_Creative_Commons.pptx
ANÁLISIS Y DISEÑO DE ALGORITMOS
simulacion de teoria de control para maquinas

Arquitectura de microservicios

  • 2. Sobre nosotros ■ Julio Palma ■ Twitter: @restalion ■ GitHub: github.com/restalion ■ Technology Architect en Tecnilógica ■ Juanma Cintas ■ Twitter: @juanmacintas ■ GitHub: github.com/juanmacintas ■ Senior Analyst en Tecnilógica
  • 3. Objetivos de la sesión  Tener una solución basada en microservicios en producción y poder dormir todas las noches.  Entender las diferencias entre una arquitectura monolítica y otra basada en microservicios.  Crear un mapa de todos los servicios que necesitaremos de la outer architecture que nos permita “montar” una solución completa.  Identificar algunas alternativas para cubrir cada una de las áreas de la outer architecture.
  • 4. Objetivos de la sesión  Tener una solución basada en microservicios en producción y poder dormir todas las noches.  Entender las diferencias entre una arquitectura monolítica y otra basada en microservicios.  Crear un mapa de todos los servicios que necesitaremos de la outer architecture que nos permita “montar” una solución completa.  Identificar algunas alternativas para cubrir cada una de las áreas de la outer architecture. ¿Qué es la Outer Architecture?
  • 10. Métricas Gestión de erroresServicios DAO Monolito Monolito Presentación Inversión del Control EIS DAO DAO EIS EIS Configuración Logs Auditoría Seguridad
  • 11. Métricas Gestión de errores Servicio DAO Monolito Monolito Presentación Inversión del Control EIS DAO DAO EIS EIS Servicio Servicio Servicio Configuración Logs Auditoría Seguridad
  • 12. Monolito 1. Una única aplicación para implementar toda la funcionalidad. 2. Un ecosistema común para todas las piezas de la aplicación. 3. Reutilización basada en los componentes (importación). 4. Sencillez de despliegue. 5. Una única versión de los componentes. 6. Aplicaciones complejas cuya responsabilidad es implementar todo el negocio. 7. Fragilidad: un error en cualquier pieza tumba todo el monolito.
  • 13. Métricas Gestión de errores Servicio DAO Microservicios Monolito Presentación Inversión del Control EIS DAO DAO EIS EIS Servicio Servicio Servicio Configuración Logs Auditoría Seguridad
  • 14. Métricas Gestión de errores Servicio DAO Microservicios Presentación Inversión del Control EIS DAO DAO EIS EIS Servicio Servicio Servicio Configuración Logs Auditoría Seguridad
  • 15. Métricas Gestión de errores Servicio DAO Microservicios Presentación Inversión del Control EIS DAO DAO EIS EIS Servicio Servicio Servicio Configuración Logs Auditoría Seguridad *HTTP
  • 16. Métricas Resistencia a errores Servicio DAO Microservicios Presentación Localización de servicios EIS DAO DAO EIS EIS Servicio Servicio Servicio Configuración centralizada Logs distribuidos Auditoría Seguridad (MMI y M2M)
  • 17. Métricas Resistencia a errores Servicio DAO Microservicios Presentación Localización de servicios EIS DAO DAO EIS EIS Servicio Servicio Servicio Configuración centralizada Logs distribuidos Auditoría Seguridad (H2M y M2M) Composición de la solución Gestión de la carga Documentación de interfaces
  • 18. Microservicios 1. Muchas aplicaciones que implementan la funcionalidad completa. 2. Ecosistema políglota dentro de una misma solución. 3. Reutilización basada en uso (llamada a interfaces). 4. Despliegue sencillo de cada aplicación, complejo en la solución completa. 5. Varias versiones de la misma aplicación pueden convivir en ejecución. 6. Cada aplicación tiene la responsabilidad (y exclusiva) en un área concreta de la solución. 7. Se pueden desplegar de forma independiente. 8. Se incrementa la latencia y el tráfico de red.
  • 19. Objetivos de la sesión  Tener una solución basada en microservicios en producción y poder dormir todas las noches.  Entender las diferencias entre una arquitectura monolítica y otra basada en microservicios.  Crear un mapa de todos los servicios que necesitaremos de la outer architecture que nos permita “montar” una solución completa.  Identificar algunas alternativas para cubrir cada una de las áreas de la outer architecture.
  • 20. Estructura de los microservicios 1. BBDD H2 en memoria 2. Acceso con Spring Data 3. Servicios Spring 4. REST Interface 5. Project Lombok 6. Swagger
  • 22. Outer Architecture Métricas Resistencia a errores Localización de servicios Configuración centralizada Logs distribuidos Auditoría Seguridad (H2M y M2M) Composición de la solución Gestión de la carga Documentación de interfaces
  • 23. Configuración Outer Architecture - Monolito ■ En una aplicación monolítica la configuración de la aplicación se puede realizar mediante múltiples formas: – Fichero de propiedades – Parámetros de configuración en la ejecución ■ La configuración no suele ser un gran problema podemos tener varios tipos de ficheros, perfiles… que se seleccionan en el momento de “levantar” la aplicación. ■ Tenemos un número limitado de instancias (desarrollo, preproducción, producción,…) cada una con su configuración específica. ■ Normalmente es el equipo de operaciones el encargado de configurar y mantener la configuración de los distintos entornos.
  • 24. Outer Architecture - Microservicios Configuración centralizada ■ En un esquema de microservicios la operación se complica: – Múltiples instancias de la misma aplicación con el mismo perfil, o distinto. – Versiones distintas del mismo servicio en el mismo entorno. ■ El mantenimiento de las aplicaciones en ejecución se puede llevar desde una plataforma (sin intervención humana directa). ■ Rolling updates, de los servicios
  • 25. Outer Architecture - Microservicios Configuración centralizada ■ Ejemplo: Config server ■ Distintos tipos de clientes dependiendo de la naturaleza de la aplicación.
  • 26. Seguridad Outer Architecture - Monolito ■ El control de acceso a la aplicación se realiza una vez. – Si tienes acceso mientras dure tu sesión podrás ejecutar todos los servicios que te permita tu perfil. ■ El acceso al frontal y a los servicios está unificado.
  • 27. Outer Architecture - Microservicios Seguridad (H2M y M2M) ■ Podemos tener esquemas de seguridad independientes por cada servicio o frontal. ■ Hay que diferenciar entre la seguridad para el acceso a la aplicación por parte de humanos y las llamadas entre máquinas. ■ Nos permite granularidad a la hora de definir quién tiene acceso a qué servicio o funcionalidad. ■ Podemos establecer criterios como cuotas de uso. ■ Permite monetizar el consumo de servicios.
  • 28. Outer Architecture - Microservicios Seguridad (H2M y M2M) IAM Presentación Authorization Server µServices 1 2 3 4 5 6 78 9 10 Acceso a la aplicación de presentación (SAML) 1. El usuario accede a la aplicación de presentación. 2. Se comprueba si está presente el token SAML. Si no redirigimos al IAM. 3. El IAM muestra la pantalla de login. 4. El usuario introduce sus credenciales. 5. Si son válidas, el IAM genera el token SAML y redirige a la aplicación de presentación. Acceso a la aplicación de backend (OAuth2) 6. Se solicita el token al authorization server con las credenciales del consumidor. 7. Si son válidas genera un token y lo devuelve. 8. Se realiza la llamada al servicio. 9. El resource server captura el token y comprueba contra el authorization server que sea correcto. 10. Si lo es se realiza la llamada al servicio. Resource Server
  • 29. Outer Architecture - Microservicios Seguridad (H2M y M2M) ■ Ejemplo: CAS + SAML para la parte frontal ■ Ejemplo: Okta + SAML para la parte frontal ■ Ejemplo: Oauth2 para la M2M. ■ Ejemplo: 3Scale para el API Management.
  • 30. Logs Outer Architecture - Monolito ■ Los logs se escriben en ficheros directamente desde la aplicación. ■ Utilizamos distintos niveles de log dependiendo del entorno (para no penalizar los entornos productivos). ■ Se pueden consultar los ficheros físicos en el servidor. ■ Utilizamos herramientas como PERL para facilitar el trabajo de análisis de los ficheros de log.
  • 31. Outer Architecture - Microservicios Logs distribuidos ■ Las instancias de los microservicios son desechables, cuando dejan de tener utilidad se destruyen. ■ Los ficheros físicos pueden dejar de existir cuando se destruyen los servicios. ■ Incluso en el mejor de los casos podríamos tener muchos ficheros distintos en distintas localizaciones. ■ El planteamiento en estos casos es la creación de un servicio de logs que los guarda de forma unificada en una BBDD que nos permite una consulta sencilla de los mismos. ■ También el uso de herramientas que nos permite trazar la ejecución completa de la solución por las distintas aplicaciones.
  • 32. Outer Architecture - Microservicios Logs distribuidos ■ Ejemplo: Servcio custom + ElasticSearch + Kibana ■ Ejemplo: Sleuth + Zipkin + ElasticSearch + Kibana
  • 33. Gestión de errores Outer Architecture - Monolito ■ Desarrollamos nuestro código para responder correctamente ante los errores. ■ Cuando se produce una excepción la tratamos si es posible de forma que la aplicación siga funcionando. ■ Si se produce un error catastrófico toda la solución deja de funcionar.
  • 34. Outer Architecture - Microservicios Resistencia a errores ■ Cuando un microservicio falla de forma catastrófica se cae pero su rol puede ser cubierto por otra instancia del mismo. ■ Además de los errores propios de la aplicación tenemos que ser capaces de responder ante los errores de los servicios que consumimos. – Tenemos que ser capaces de responder ante el caso de que un servicio al que llamamos no responda, o devuelva un error. ■ Definimos mecanismos que nos permiten responder ante este tipo de errores.
  • 35. Outer Architecture - Microservicios Resistencia a errores ■ Ejemplo: Hystrix
  • 36. Inversión del Control Outer Architecture - Monolito ■ Mecanismo para localizar los servicios a los que llamamos. ■ Evitamos el mecanismo “clásico” de instanciar los servicios para poder utilizarlos. ■ Se optimizan los recursos utilizados ya que sólo utilizamos el número de instancias realmente necesarias.
  • 37. Outer Architecture - Microservicios Localización de servicios ■ Es la extensión del modelo de inversión de control al mundo de microservicios. ■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan localizarlo. ■ El los consumidores solicitan al registro la forma de llamar al servicio. ■ Una vez localizado el servicio puede ser consumido. Eureka
  • 38. Outer Architecture - Microservicios Localización de servicios ■ Es la extensión del modelo de inversión de control al mundo de microservicios. ■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan localizarlo. ■ El los consumidores solicitan al registro la forma de llamar al servicio. ■ Una vez localizado el servicio puede ser consumido. 1 Eureka 1
  • 39. Outer Architecture - Microservicios Localización de servicios ■ Es la extensión del modelo de inversión de control al mundo de microservicios. ■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan localizarlo. ■ El los consumidores solicitan al registro la forma de llamar al servicio. ■ Una vez localizado el servicio puede ser consumido. 1 2 Eureka 1, 2
  • 40. Outer Architecture - Microservicios Localización de servicios ■ Es la extensión del modelo de inversión de control al mundo de microservicios. ■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan localizarlo. ■ El los consumidores solicitan al registro la forma de llamar al servicio. ■ Una vez localizado el servicio puede ser consumido. 1 2 3 Eureka 1, 2 3
  • 41. Outer Architecture - Microservicios Localización de servicios ■ Es la extensión del modelo de inversión de control al mundo de microservicios. ■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan localizarlo. ■ El los consumidores solicitan al registro la forma de llamar al servicio. ■ Una vez localizado el servicio puede ser consumido. 1 2 3 4 Eureka 1, 2 3, 4
  • 42. Outer Architecture - Microservicios Localización de servicios ■ Es la extensión del modelo de inversión de control al mundo de microservicios. ■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan localizarlo. ■ El los consumidores solicitan al registro la forma de llamar al servicio. ■ Una vez localizado el servicio puede ser consumido. 1 2 3 4 5 Eureka 1, 2, 5 3, 4
  • 43. Outer Architecture - Microservicios Localización de servicios ■ Es la extensión del modelo de inversión de control al mundo de microservicios. ■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan localizarlo. ■ El los consumidores solicitan al registro la forma de llamar al servicio. ■ Una vez localizado el servicio puede ser consumido. 1 2 3 4 5 6 Eureka 1, 2, 5, 6 3, 4
  • 44. Outer Architecture - Microservicios Localización de servicios ■ Es la extensión del modelo de inversión de control al mundo de microservicios. ■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan localizarlo. ■ El los consumidores solicitan al registro la forma de llamar al servicio. ■ Una vez localizado el servicio puede ser consumido. 1 2 3 4 5 6 7 Eureka 1, 2, 5, 6 3, 4 7
  • 45. Outer Architecture - Microservicios Localización de servicios ■ Es la extensión del modelo de inversión de control al mundo de microservicios. ■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan localizarlo. ■ El los consumidores solicitan al registro la forma de llamar al servicio. ■ Una vez localizado el servicio puede ser consumido. 1 2 3 4 5 6 7 Eureka 1, 2, 5, 6 3, 4 7
  • 46. Outer Architecture - Microservicios Localización de servicios ■ Es la extensión del modelo de inversión de control al mundo de microservicios. ■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan localizarlo. ■ El los consumidores solicitan al registro la forma de llamar al servicio. ■ Una vez localizado el servicio puede ser consumido. 1 2 3 4 5 6 7 Eureka 1, 2, 5, 6 3, 4 7
  • 47. Outer Architecture - Microservicios Localización de servicios ■ Es la extensión del modelo de inversión de control al mundo de microservicios. ■ Cuando un servicio se arranca se “registra” para que sus consumidores puedan localizarlo. ■ El los consumidores solicitan al registro la forma de llamar al servicio. ■ Una vez localizado el servicio puede ser consumido. 1 2 3 4 5 6 7 Eureka 1, 2, 5, 6 3, 4 7
  • 48. Outer Architecture - Microservicios Localización de servicios ■ Ejemplo: Eureka + Feign
  • 49. Outer Architecture - Microservicios Documentación de los interfaces ■ Una nueva necesidad del modelo de microservicios. ■ Debido a la gran cantidad de servicios necesitamos un mecanismo que nos permita documentar todos los interfaces disponibles. ■ En el código indicamos esta información y un servicio lo publica y permite su consumo.
  • 50. Outer Architecture - Microservicios Documentación de los interfaces ■ Ejemplo: Swagger
  • 51. Outer Architecture - Microservicios Composición de la solución ■ Una nueva necesidad del modelo de microservicios. ■ Ya no disponemos de “un war” que nos permite desplegar la solución. ■ Es necesario definir la forma completa de la misma para que el montaje sea repetible. ■ Se puede realizar a varios niveles y apoyándonos en diversas tecnologías.
  • 52. Outer Architecture - Microservicios Composición de la solución ■ Ejemplo: Docker compose
  • 53. Outer Architecture - Microservicios Gestión de la carga ■ Los servicios se consumen desde distintos orígenes. ■ No podemos controlar cuántas solicitudes vamos a tener en un momento determinado. ■ ¿Qué hacer cuando el servicio puede empezar a no responder? ■ Establecemos límites de carga a partir de los cuales crecemos horizontalmente.
  • 54. Outer Architecture - Microservicios Gestión de la carga ■ Ejemplo: Openshift + 3Scale ■ Zuul m4.2xlarge m4.2xlarge m4.2xlarge m4.xlarge m4.xlarge m4.xlarge m4.xlarge t2.micro Bastion Host m4.large m4.large m4.large 2 Tb 2 Tb 2 Tb
  • 55. Objetivos de la sesión  Tener una solución basada en microservicios en producción y poder dormir todas las noches.  Entender las diferencias entre una arquitectura monolítica y otra basada en microservicios.  Crear un mapa de todos los servicios que necesitaremos de la outer architecture que nos permita “montar” una solución completa.  Identificar algunas alternativas para cubrir cada una de las áreas de la outer architecture.
  • 56. Conclusiones ■ Los microservicios no son la respuesta a todos los problemas. ■ Las arquitecturas basadas en microservicios complican el despliegue frente a las monolíticas. ■ Proporcionan elasticidad ante cargas inesperadas. ■ La definición de los servicios de arquitectura tiene adaptarse al modelo seleccionado para la solución.
  • 57. To take away HACKERS WANTED https://github.com/juanmacintas/ejercicioMircroserviciosSpringCloud

Notas del editor

  • #6: Esto es un monolito
  • #7: Esto es un monolito
  • #8: Esto es un monolito
  • #9: Esto es un monolito
  • #10: Esto es un monolito
  • #11: Esto es un monolito
  • #12: Esto es un monolito
  • #14: Esto es un monolito
  • #15: Esto es un monolito
  • #16: Esto es un monolito
  • #17: Esto es un monolito
  • #18: Esto es un monolito