Microservices. Microservices con WSO2
Julio Cejas
Arquitecto Chakray El objetivo de este documento es describir como el enfoque , Microservicios, Microservicio s, denominado “SOA ligero” ligero” puede ser implementado mediante el WSO2 Lean Enterprise Middleware.
Índice
Introducción
3
Una pequeña historia
4
Que es un Microservice
5
Sobre las Aplicaciones Monolíticas
6
Microservices y un API Gateway
7
Microservices en WSO2
8
Patrón WSO2 ESB como API Gateway Microservice
8
Patrón WSO2 ESB como Message Gateway Microservice
9
Patrón WSO2 ESB como API Gateway y Message Gateway
10
Patrón WSO2 Stack y soporte WS-Eventing para Microservice
11
Patron WSO2 Gateway con WSO2 GW para Microservices
12
Patrón WSO2 Microservice con WSO2 MSS
13
Patroness Generales WSO2 Microservices sobre ESB Patrone
15
WSO2 Microserv Microservices ices y el Fracaso Parcial
15
WSO2 Microservices y Timeouts
16
WSO2 Microservices Bulkheads
17
WSO2 Microservices y Cache
17
WSO2 Microservices y la Distribución de Carga
17
WSO2 Microservices y descubrimiento de Endpoints
17
WSO2 Microservices Contenedo Contenedores res
17
WSO2 Microservices Máquinas Virtuales
18
WSO2 Microservices Monitoreo y Análisis de Datos
18
Recomendaciones Generales
18
En esencia
19
Sobr el autor
20
www.chakray.com
2
Introducción
Actualmente los microservicios (microservices en inglés), han estado irrumpiendo dentro de la disciplina SOA por su enfoque pragmático, ágil; y su ajustado enfoque al negocio y no en la tecnología. El objetivo de este do cumento es describir como este enfoque denominado “SOA ligero” puede ser implementado mediante el WSO2 Lean Enterprise Middleware. En las siguientes secciones realizaré una pequeña inmersión en el concepto de mi-
croservice, algunas reexiones y conclusiones.
www.chakray.com
3
Una pequeña historia Generalmente cuando iniciamos proyectos de software de gran envergadura comenzamos con la identicación del vocabulario asociado a un determinando contexto o dominio, los convertimos en un modelo de información y abordamos sus relaciones posteriormente. Es muy común tener un modelo de dominio realmente grande que posteriormente es realizado mediante un modelo relacional de base de datos. Sobre este modelo, se plantean todas las necesidades de información, relaciones, persistencia y servicios. En la medida que crece este modelo se generan problemas en el mantenimiento de sus relaciones, dependencias, rendimiento y capacidades de cambio; sobre todo cuando crecen las demandas del siste ma y la existencia de nuevos requisitos. Generalmente si desarrollamos un servicio para obtener el detalle de una factura, utilizamos un modelo subyacente con muchas relaciones a otras tablas; sobre este modelo se establecen muchas dependencias; fácilmente reconocibles cuando un cambio pequeño en un atributo de una tabla implica el cambio de muchos artefactos de software, o bajar y subir toda una solución; en esencia un cambio pequeño impacta a toda la solución. Por años se ha abordado el desarrollo de software con este enfoque estándar: el establecimiento de un modelo de dominio que represente el vocabulario de un negocio y sus relaciones; representándola en toda su extensión. Microservice viene a plantear un enfoque distinto.
www.chakray.com
4
Que es un Microservice En esencia, un microservice es un artefacto de software que está diseñado para evitar que dependa de un modelo de relaciones extenso y pesado; el cual debe cumplir con una función de negocio concreta; además de contar con una implementación simple y pensada en la integración con otros. Su objetivo es propiciar el desarrollo de componentes individuales que sean capaces de evolucionar y escalar de forma independiente. En este enfoque, los contratos se adaptan a las necesidades del negocio y no a un modelo de dominio y/o una estructura de datos grande y relacional. Su enfoque es evitar la creación de soluciones frágiles y complejas.
En el diagrama anterior se puede observar como una aplicación monolítica puede ser di-
vidida en servicios independientes que cumplen con una función concreta de negocio. A continuación se enumeran las principales características de microservices:
01 Los servicios tiene una responsabilidad micro con un enfoque ajustado al negocio. 02 Viven dentro de un contenedor con un ciclo de vida independiente (ejecutado en su propio proceso).
03 Son organizados de forma vertical sobre las capacidades de negocio y no de tecnología. 04 Están diseñado bajo el principio de bajo acoplamiento.
www.chakray.com
5
05 Son desarrollados pensando en la coreografía y no en la orquestación. 06 Son diseñados para soportar el fracaso (tolerante a fallas). 07 Sus modelos de implementación y su gobierno se realizan de forma descentralizada. 08 Sus modelos de implementación no son compartidos, por ejemplo sus modelos de dominio y el modelo de persistencia son exclusivos e individuales.
09 Se comunican sobre mecanismos ligeros como HTTP o JMS. 10 Crecen individualmente. 11 Pueden ser auto escalados de forma individual.
Sobre las Aplicaciones Monolíticas El desarrollo de arquitecturas monolíticas seguirá siendo una alternativa para el desarrollo de soluciones y dependerá del grado de distribución, tamaño, necesidades de integración y mediación de la solución, para optar por una arquitectura microservice. En
esencia, es importante recalcar que no toda solución debe ser abordada bajo un enfoque de microservices. Las aplicaciones monolíticas pueden ser construidas con una modularidad útil, evitando las áreas complejas que los microservices introducen en cualquier arquitectura. Si los límites de la solución pueden
ser gestionados, son pequeños y no existe la necesidad de conformación de una arquitectura distribuida; la solución puede abordarse bajo estrategias de aplicaciones monolíticas.. Inclusive, se puede combinar una arquitectura monolítica y microservice aprovechando lo mejor de ambos enfoques. Una recomendación concreta es comenzar con una arquitectura monolítica para luego romperla o dividirla en microservices, con
este enfoque se puede explorar, descubrir y explotar los límites y extensiones de la solución, estableciendo un mapa de ruta más sólido para el diseño y arquitectura de microservices.
www.chakray.com
6
Microservices y un API Gateway En arquitecturas basadas en microservice es recomendable la utilización de una puerta de enlace conocida como API Gateway. La puerta de enlace es responsable de la petición, encaminamiento, composición y traducción de protocolos. Todas las solicitudes de los clientes se dirigen primero a la puerta de enlace para luego invocar al microservice apropiado. El Gateway a menudo maneja peticiones a múltiples microservices para agregar sus resultados.
La recomendación general es que los clientes no invoquen directamente los microservices, sino a través de un Gateway que permita simplicar y ajustar los requerimientos a las ne-
cesidades funcionales y especícas de la aplicación. La puerta de enlace API encapsula la arquitectura del sistema interno proporcionando una API que se adapte a cada cliente. El Gateway puede tener otras responsabilidades, como la autenticación, control, distribución de carga, almacenamiento en caché, manipulación respuestas, entre otros.
El API Gateway proporciona: 01 Un único punto de acceso. 02 Oculta al cliente los detalles asociadas a la invocación de microservices enlazados o relacionados.
03 Disminuye las solicitudes o invocaciones a servicios a través de la red. 04 Simplica los clientes proxys de acceso. 05 Proporciona un api personalizado.
www.chakray.com
7
Microservices en WSO2 WSO2 es un stack maduro que proporciona modelos de implementación exibles y ligeros para soportar las características más importantes y relevantes de microservices. En las próximas secciones describiré las estrategias y patrones que pueden ser incorporados en sus iniciativas WSO2 para dar soporte a este enfoque.
Patrón WSO2 ESB como API Gateway Microservice Un ESB (Enterprise Service Bus) es una infraestructura que puede realizar servicios de mediación, enrutamiento, enriquecimiento y la incorporación de políticas sobre servicios web y otros artefactos. Estas características pueden ser utilizadas para implementar un Gateway para arquitecturas microservices. En esencia, en este patrón, utilizamos el WSO2 ESB y todas sus características para desplegar un Gateway para nuestra plataforma de mi croservices.
El WSO2 ESB Gateway puede ofrecer un mecanismo que permita el acceso a microservices individuales desde aplicaciones mediante la conformación de una puerta de enlace, proporcionando un único punto de entrada para todos los clientes. Este Gateway puede ser distribuido y soportar alta disponibilidad (HA) y clustering; es importante destacar que este ESB solo puede ser utilizado para tareas de Gateway. A continuación se enumeran las funciones que este ESB debe cumplir como Gateway:
01 Aislar a los clientes sobre la lógica de integración, composición, entres los microservicios.
02 Aislar al cliente de la ubicación de microservices. 03 Proporcionar una API óptima para cada cliente.
www.chakray.com
8
04 Reducir el número de peticiones (ida y vuelta). 05 Simplicar la invocación o llamada a múltiples microservices desde el cliente. 06 Incorporar políticas de cache, autenticación, autorización, entre otros. 07 Exponer APIs adaptadas a las necesidades de los clientes. WSO2 permite la conformación de un Gateway para arquitecturas basadas en microservices que puede escalar de forma independiente, coordinados y gestionados sobre HA y clustering; de igual forma pueden ser establecida en contenedores como Docker para gestionar un ciclo de vida independiente y en cluster de contenedores Linux como Kubernetes.
Patrón WSO2 ESB como Message Gateway Microservice Utilizando el WSO2 ESB como un Gateway y limitando sus funciones para arquitecturas microservices, podemos implementar dos tipos de gawatey, uno para APIs y otro para mensajes. Una de las características de microservices es su capacidad de comunicación sobre mecanismos ligeros como HTTP o JMS. Un patrón de diseño r ecomendado es la conformación de un Gateway de mensajería que pueda enriquecer e incluir políticas a los mensajes que son intercambiados entre microservices cuando utilizamos JMS como norma de comunicación. Sobre este enfoque podemos utilizar un WSO2 ESB como mediador de mensajes (messages JMS).
www.chakray.com
9
Bajo este patrón, podemos utilizar la capacidad del WSO2 ESB para la gestión de storage de mensajes, utilizando la funcionalidad de Message Stores (Store Mediator) para almace-
nar mensajes de forma temporal. Actualmente el Store mediator puede ser utilizado para almacenar mensajes en memoria, en jms o implementaciones que pueden ser customizadas como la utilización de REDIS, entre otras tecnologías. Otro componente que puede ser utilizado en este patrón son los message processor, quienes pueden consumir mensajes de los message stores y procesarlos. En este procesamiento, los mensajes pueden ser enviados a endpoints almacenados y consultados sobre un registro. WSO2 permite la conformación de un Gateway de mensajería para arquitecturas basadas en microservices que puedan escalar de forma independiente, coordinados y gestionados sobre HA y clustering; de igual forma pueden ser establecida en contenedores como Docker. Es importante destacar que este ESB solo puede ser utilizado para tareas de Gateway Message.
Patrón WSO2 ESB como API Gateway y Message Gateway En la siguiente graca se puede observar la inclusión de ambos enfoques:
Resumiendo, WSO2 ESB puede ser utilizado como componente para la conformación de API Gateways y message Gateways; estableciendo un único punto de acceso para arquitecturas basada en microservices. Los gateways pueden desarrollar políticas para la validación, seguridad, cache, garantía de entrega, tolerancia a fallas, logging, audit, entre otras. Bajo este enfoque WSO2 ESB asume y desarrolla diversos roles, limitando y estandarizando su función en contextos de arquitectura.
www.chakray.com
10
Patrón WSO2 Stack y soporte WS-Eventing para Microservice WSO2 proporciona la capacidad para desarrollar servicios de datos, decisión y dominio especíco bajos diversos productos de su stack. Los servicios de datos (WSO2 DSS) pue den responder a las necesidades de la capa de persistencia y puede comunicarse con otros servicios mediante una forma independiente y altamente desacoplada basada en el transporte JMS. WSO2 DSS soporta el estándar WS-Eventing que puede ser utilizado para disparar eventos durante la ocurrencia de ciertas condiciones en los datos, tanto en el request como en su response. El event-trigger contiene una suscripción que cualquier cliente pue-
de utilizar para recibir noticaciones enviadas desde un tópico a una cola de mensajería o incluso correo electrónico. En esencia, WSO2 DSS, BRS, AS proporcionan soporte al estándar WS-Eventing, con lo cual podemos habilitar la comunicación entre servicios de forma asíncrona. Este enfoque permite que los servicios estén desacoplados utilizando un estilo de comunicación ligero basado en mensajes por ejemplo JMS. Este enfoque permite por ejemplo establecer en dpoints como el siguiente:
jms:/Ordertopic?transport.jms.DestinationType=queue&transport.jms. ContentTypeProperty=Content-Type&java.naming.provider.url=tcp://localhost:61616&java.naming. factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&transport.jms.Connection FactoryType=queue&transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory
De igual forma cada servicio de datos puede ser expuesto sobre el transporte JMS. En el siguiente diagrama se puede observar que pueden ser inyectados al request o response eventos que pueden ser disparados ante la ocurrencia de un evento, soportada por Xpath y WS-Eventing. El payload o carga útil puede ser enviada a un topic interno y posteriormente a un JMS Queue/Topic a través de una suscripción establecida. De igual forma pueden ser utilizados listener para el envió a otros queues/topics.
Es importante destacar que se recomienda la utilización de una capa Facade(Gateway)
para evitar la proliferación de conexiones punto a punto entre los servicios.
www.chakray.com
11
Patron WSO2 Gateway con WSO2 GW para Microservices WSO2 actualmente se encuentra desarrollando un Gateway más enfocado y dirigido para el soporte del patrón Facade y microservices. Sobre este escenario, no se utilizaría el WSO2 ESB (limitando sus funciones) como un Gateway. WSO2 Gateway (WSO2 GW) es un Gateway de alto rendimiento, una puerta de entrada ligera para mensajes, centrada en la implementación de patrón Gateway/Facade. Su objetivo es encapsular mensajes entre sistemas heterogéneos con tecnologías, protocolos y normas diversas. WSO2 GW será la puerta de enlace de mensajería que servirá de Gateway para productos como WSO2 Enterprise Service Bus, WSO2 Security Gateway, entre otros.
Entre las características más relevantes: 01 Gateway de alto rendimiento y baja latencia. 02 10 veces más rápido que el transporte HTTP presente actualmente en WSO2 ESB. 03 Soporte de miles de conexiones concurrentes. 04 Enrutamiento basado en Apache Camel y Spring Framework. 05 Balanceo de carga y conmutación por error (Circuit Breaker / Kill Switch). 06 Soporte mejorado para gestión de errores. 07 REST/APIs basadas en DSL Camel RESTful. 08 Estadísticas de enrutamiento a través de JMX.
www.chakray.com
12
Con este enfoque se podrá establecer servicios RESTfull directamente, por ejemplo:
Además, incluirá un modelo de enrutamiento, por ejemplo:
iot:http://iot/posts/${header.id}
Patrón WSO2 Microservice con WSO2 MSS WSO2 se encuentra desarrollando un modelo más aislado del ESB para aquellas implementaciones que requieran la implementación del paradigma microservice mediante es-
trategias como el Non-blocking IO, procesamiento y programación concurrente basada en Netty, Patrón Disruptor, Java 8, Programación Reactiva, entre otros; mejorando las limitaciones actuales del enfoque ESB y su planteamiento basado en roles. El producto es denominado WSO2 Microservice Server (WSO2 MSS).
www.chakray.com
13
WSO2 MSS permite la construcción y entrega de aplicaciones orientadas en microservices sobre servicios REST, ofreciendo una arquitectura de alto rendimiento (tiempo de ejecución y arranque) y la garantía del bajo consumo de recursos. WSO2 MSS ha incorporado la gestión de métricas y análisis a través de la integración con WSO2 Data Analytics Server (WSO2 DAS), que ofrece una solución completa para el análisis de datos. Cada microser -
vice se desarrolla para un solo propósito y es desplegado de forma independiente, lo cual garantizará su escalabilidad y abilidad.
Entre sus características más relevantes: 01 Tiempo de ejecución rápido. 02 Soportado sobre el kernel WSO2 Carbon 5.0. 03 Bajo consumo de memoria. 04 Modelo de desarrollo simple para su implementación y monitoreo. 05 Utilización de WSO2 Developer Studio para su desarrollo, incluye denición de su API a través de Swagger.
06 Integración con WSO2 Data Analytics Server para análisis de datos. 07 Seguimiento de las solicitudes mediante un identicador único. 08 Transporte basado en Netty 4.0. 09 Seguridad basada en JWT. 10 Soporte de Interceptores personalizados. 11 Soporte a Streaming de entrada y salida. Con WSO2 MSS ahora se podrá anotar los servicios. Entre las anotaciones más relevantes:
ANOTACIÓN
PROPÓSITO
@HTTPMonitoring
Anotación que permitirá que el microservice envié la información detallada de su comportamiento en tiempo de ejecución al WSO2 DAS, por ejemplo: startNanoTime, serviceName, serviceClass, responseTime, requestSizeBytes, httpMethod, requestUri, entre otros.
@Metered
Anotación que permite establecer una métrica para medir la tasa de eventos en un tiempo determinado.
@Timed
Anotación que permite establecer una métrica para medir la duración de
ejecución de una determinada función de negocio. @Counted
www.chakray.com
Anotación q ue permite establecer una métrica para incrementar o decrementar un contador.
14
Para establecer un microservice: @Path(“/micro”) @HTTPMonitoring
public class MicroService { … @GET
@Path(“/dispositivo/{id}”) @Metered
public int getDispositivo(@PathParam(“id”) int id) { return persistence.getDispositivo(id); }
Para iniciar un microservice, se podrá utilizar: new MicroservicesRunner() .deploy(new MicroService())
.start();
Pueden ser colocados interceptores que pueden gestionar políticas de validación, seguri-
dad, métricas entre otros; por ejemplo: .addInterceptor(new MetricsInterceptor(MetricReporter.CONSOLE, MetricReporter.JMX, MetricReporter.DAS))
WSO2 MSS esta soportada por las siguientes tecnologías: Carbon server, IO netty, Netty jaxrs Http, gson, imbusDS Java library; entre otros marcos Open Source. Es importante destacar que soporta JSON Web Token para la seguridad de servicios REST.
Patrones Generales WSO2 Microservices sobre ESB WSO2 Microservices y el Fracaso Parcial Generalmente cuando el Gateway debe componer u orquestar microservices que están
distribuidos este puede enfrentarse a un “fracaso parcial” cuando este invoca un servicio que responde lentamente o no está disponible. Generalmente el Gateway no puede esperar de forma indenida a que el servicio envié una respuesta. El Gateway debe decidir si retornar un error al cliente o proporcionar información parcial a partir de un cache. WSO2 permite incorporar estrategias para el fracaso parcial y el cache mediante en dpoints en WSO2 ESB. Cuando la llamada a un microservice supere un umbral establecido, se implementa un patrón denominado disyuntor o circuit-breaker, cancelando la espera
www.chakray.com
15
innecesaria cuando un servicio no esté disponible o no responda. Si la tasa de error para
un servicio supera un umbral especico, WSO2 puede disparar un interruptor y todas las peticiones fallarán inmediatamente por un período de tiempo. Este patrón puede ser implementado mediante la conguración adecuada de endpoints en el WSO2 ESB. En la siguiente sección, se puede observar una conguración estándar de Endpoints que permite implementar el patrón circuit-breaker.
60000 101507,101508 3 400 300 fault
WSO2 Microservices y Timeouts WSO2 ESB tiene la capacidad de aislar el acceso a la red utilizando patrones de timeouts. Su función principal es evitar que el cliente (proxy) que requiere consumir un servicio es-
pere de forma indenida por la respuesta del servicio proveedor. Para implementar este patrón, WSO2 ESB proporciona Endpoints; los endpoints proporcionan propiedades como la duración del timeout y la acción si el timeout ha superado un determinado umbral. De igual forma se pueden utilizar secuencias de excepción que pue den invocar servicios de cache o responder datos temporales. En esencia, un endpoint permite la interrupción de forma denitiva cuando ha alcanzado una taza de timeouts establecida. Este patrón evita que la falla se propague y degrade los servicios de la solución. En la siguiente sección, se puede observar una conguración estándar de Endpoints que permite implementar el patrón timeout sobre WSO2 ESB.
320 fault
www.chakray.com
16
WSO2 Microservices Bulkheads WSO2 ESB permite el establecimiento de estrategias para evitar el fracaso en cascada mediante endpoints congurados de forma adecuada; pudiendo aislar problemas de red o servicios sin afectar la arquitectura de la solución. El Bulkheads es un patrón que establece prácticas para reducir el riesgo de fracaso y así evitar la degradación y sus consecuencias mediante barreras como la implementación del patrón timeout, retries, circuit-breaker, entre otros.
WSO2 Microservices y Cache WSO2 ESB permite el establecimiento de cache en memoria o el desarrollo de implementaciones customizables para la utilización de base de datos tradicionales o key-value (Redis por ejemplo). La puerta de enlace o Gateway puede incluir una barrera para asegurar que
fallos en los sistemas externos afecten la funcionalidad.
WSO2 Microservices y la Distribución de Carga NGINX es una alternativa escalable para microservices, que proporciona un servidor web de alto rendimiento, fácil de desplegar, congurar y programar.
WSO2 Microservices y descubrimiento de Endpoints WSO2 Gateway necesitará conocer la ubicación (dirección IP y puerto) de cada microser-
vice con el que se comunicará; su localización puede realizarse mediante un proceso de descubrimiento contra un registro (WSO2 Governance Registry), permitiendo que los endpoints puedan establecerse dinámicamente en tiempo de ejecución.
WSO2 Microservices Contenedores La gestión operativa de microservicios puede convertirse fácilmente en una tarea muy compleja en la medida que estos van creciendo; para facilitar su administración es recomendable la utilización de contenedores como Docker. Docker es un ambiente virtual basado en Linux (LinuX Containers) que permite establecer contenedores para los microservices o tecnologías como mysql, nginx, entre otros.
WSO2 Microservices Máquinas Virtuales Generalmente las plataformas para microservices son virtualizadas mediante tecnologías VM (virtual machines) como VirtualBox, VMWare, AWS, entre otros. En algunos casos podemos tener diversos entornos de virtualización para plataforma de microservices. WSO2 y todo su stack puede ser gestionado sobre ambiente virtualizados, recomendando la utilización de Vagrant para la administración de diversos ambiente virtualizado. Tecnologías como Puppet y Chef pueden ser utilizados con WSO2 para automatizar la infraestructura de WSO2 Microservice.
www.chakray.com
17
WSO2 Microservices Monitoreo y Análisis de Datos WSO2 ESB y WSO2 MSS permiten la integración con el producto de análisis de datos WSO2 DAS que soporta análisis batch, en tiempo real, predictivo e interactivo. Con esta estrategia la capacidad de monitoreo y alertas en plataforma para Microservices es sopor-
tada de forma individual o centralizada.
Recomendaciones Generales WSO2 ofrece un soporte completo a todo el stack de aspectos necesarios para construir una plataforma de microservices, proporcionando estrategias concretas y viables a los desafíos de implementaciones sobre ambientes distribuidos.
01 Identique el modelo de arquitectura WSO2 Microservice más ajustado a su solución.
02 Establezca una estrategia para responder a la latencia y tolerancia a fallas para su arquitectura de Microservices. Utilice endpoints, y evita la fragilidad en esta área.
03 Establezca un API Gateway y un Messaje Gateway para su arquitectura de microservices.
04 Desarrolle microservices mediante el stack actual de WSO2 o sobre el producto WSO2 MSS.
05 Establezca un Gateway mediante WSO2 ESB o WSO2 GW. 06 Implemente una estrategia basada en Event Store para publicación y suscrición de eventos.
07 Incorpore una estrategia de garantía de entrega en su arquitectura de microservice. 08 Framework como vagrant, saboteur, wiremock, hixtrix, cucumber pueden ser combinado para establecer un stack sólido para las pruebas de microservices.
09 Utilice marcos como Docker, Kubernetes y Vagrant para simplicar la administración de contenedores y máquinas virtuales.
www.chakray.com
18
En esencia · Dentro de una arquitectura Microservices el WSO2 ESB puede desarrollar funciones asociadas a la conformación de un API Gateway y un Message Gateway. · Los productos del stack WSO2 pueden utilizar el estándar ws-eventing para establecer mecanismos de comunicación desacoplados y ligeros basados en HTTP o JMS.
· Los microservices pueden ser implementados sobre plataformas como WSO2 DSS, BRS, AS dentro de un contenedor con un ciclo de vida independiente (ejecutado en su propio proceso), por ejemplo Docker. · Todos los microservicios sobre WSO2 pueden ser desplegados en un Cluster y HA
sobre servicios de contenedores como Docker y Kubernetes para su administración. · Los microservices pueden ser desplegados como un war en contenedores como Jetty o Tomcat e incluir el descubrimiento de servicios mediante un registro (WSO2 GR).
· Los microservices en WSO2 pueden ser soportados por bundels OSGi. · Patrones de tolerancia a falla como timeout y circuit-breaker puede ser implementados mediante endpoints en el Gateway (WSO2 ESB o WSO2 GW). · El WSO2 ESB Gateway puede inyectar políticas de cache, seguridad, logging, audit, validación, garantía de entrega, entre otros.
· La plataforma WSO2 ya incluye microservices especializados en servicios de gestión de identidades para autenticación y autorización. · Cada servicio es AutoMonitoreable, es decir informa constantemente su estado en tiempo de ejecución. · Cada servicio cuenta con un dashboard que permite ver su comportamiento en
tiempo de ejecución de forma individual. · Si es necesaria la integración de indicadores del comportamiento de servicios en
tiempo de ejecución, estos pueden ser congurados utilizando eventos que pueden enriquecer una plataforma WSO2 DAS. · Cada servicio puede contar con aspectos de logging, auditoria, excepciones de forma independiente o estos pueden ser inyectados dentro de un servicio Gateway (ESB o servicios sobre un servidor de aplicaciones). · OSGI es la base de WSO2, proporcionando servicios con interfaces uniformes como la forma primaria de encapsulación.
WSO2 es un stack Open Source que puede ser utilizado para implementar en toda su
extensión una arquitectura de MicroService. Espero que estos modelos de implementación y recomendaciones fortalezcan su iniciativa y proporcionen una arquitectura más sólida, ágil y exible.
www.chakray.com
19
¡Muchas gracias! Sobre el autor:
Julio Cejas Arquitecto Chakray /
[email protected]
Especialista con más de 15 años de experiencia como Consultor y Arquitecto en la construcción de Sistemas Críticos basados en productos free y open source. Combina su experiencia en Computer Security y su pasión tecnolo gía free y opensource para construir disruptive solutions.
¿Quieres dominar WSO2 Microservices? Conoce nuestro curso “WSO2 Microservices fundamentos para
desarrolladores” y especializate en la mayor tendencia del sector.
SABER MÁS
www.chakray.com
20
[email protected]
www.chakray.com
www.chakray.com
21
