Open southcode arquitectura microservicios

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

OTRAS CHARLAS DE ACCENTURE TECHNOLOGY
Spring Cloud Microservices 101
01 Junio 02 Junio
Open Source Code Inspection, Security and
Testing Power Tools
Integrando Machine Learning en Microservicios
Selenium 1:1Desarrolla aplicaciones web sin usar HTML ni
JavaScript
Accenture Technology Stand
@juanmacintas, @restalion
Sala Colmenar, 11:00
@oscuroweb, @restalion
Sala 1, 16:00
@cloud4dev
Sala Colmenar, 12:00
@_deors
Sala 2, 17:30
@viarellano,
@thetechoddbug
Sala 2, 17:30
Podéis visitarnos en nuestro
stand a lo largo de toda la
conferencia
Introducción a Lagom y primeros pasos
@oscuroweb, David Urdiales
Sala Riogordo 1, 18:00

OBJETIVOS DE LA SESIÓN
 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.

MONOLITO
Servicios
DAO
Monolito
EIS
Presentación
Un único .war
representa una
“Solución”

MONOLITO
EISEIS
Métricas
Gestión de errores
Inversión del
Control
Configuración
Logs
Auditoría
Seguridad
Servicios
DAO
Presentación

MONOLITO
EIS EIS EIS
DAO DAO DAO
Servicio Servicio Servicio
Servicio
Configuración
Logs
Auditoría
Seguridad
Métricas
Gestión de errores
Inversión del
Control
Presentación

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.

MICROSERVICIOS
Métricas
Gestión de errores
Configuración
Logs
Auditoría
Inversión del
Control
Seguridad
EIS EIS EIS
DAO DAO DAO
Servicio
Presentación

MICROSERVICIOS
Métricas
Gestión de errores
Presentación
Configuración
Logs
Auditoría
Inversión del
Control
Seguridad
EIS EIS EIS
DAO DAO DAO
Servicio

MICROSERVICIOS
Métricas
Gestión de errores
Presentación
Configuración
Logs
Auditoría
Inversión del
Control
Seguridad
EIS EIS EIS
DAO DAO DAO
Servicio
*HTTP

MICROSERVICIOS
Métricas
Presentación
Auditoría
EIS EIS EIS
DAO DAO DAO
ServicioSeguridad
(MMI y M2M)
Logs distribuidos
Configuración
centralizada
Resistencia
a errores
Localización de
servicios

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.

OUTER ARCHITECTURE
Métricas
Auditoría
Seguridad
(MMI y M2M)
Logs distribuidos
Configuración
centralizada
Resistencia
a errores
Localización de
servicios
Composición
de la solución
Gestión de
la carga
Documentación de
interfaces

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.
Configuración

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

Configuración
centralizada
 Ejemplo: Config server
 Distintos tipos de clientes dependiendo de la naturaleza de la aplicación.

Seguridad
 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.

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.

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

Logs
 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.

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.

Logs distribuidos
 Ejemplo: Servcio custom + ElasticSearch + Kibana
 Ejemplo: Sleuth + Zipkin + ElasticSearch + Kibana

Gestión de errores
 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.

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.

Resistencia a
errores
 Ejemplo: Hystrix

Inversión del
Control
 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.

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.
 Los consumidores solicitan al registro la forma de llamar al servicio.
 Una vez localizado el servicio puede ser consumido.

Localización de
servicios
 Ejemplo: Eureka + Feign

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.

Documentación de
los interfaces
 Ejemplo: Swagger

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.

Composición de la
solución
 Ejemplo: Docker compose

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.

Gestión de la carga
 Zuul + Ribbon
+ Eureka

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 que adaptarse al modelo
seleccionado para la solución.

TO TAKE AWAY
https://github.com/juanmacintas/ejercicioMircroserviciosSpringCloud
 Ejemplo Outer Architecture en Github:

Open southcode arquitectura microservicios

Más contenido relacionado

Similar a Open southcode arquitectura microservicios (20)

Último (20)

Open southcode arquitectura microservicios