MICROSERVICES.

MICROSERVICES CON
WSo2.
por Julio Cejas - IT Advisor SUNQU
WhitePaper

1
Microservices. Microservices con WSo2 | Sunqu | 2016
 Índice

Introducción 3
Una pequeña historia 3
Qué es un MicroService 4
Sobre las Aplicaciones Monolíticas 5
Microservices y un API Gateway 6
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
WhitePaper

Patrón WSO2 Stack y soporte WS-Eventing para Microservice 10

Patron WSO2 Gateway con WSO2 GW para MicroServices 11
Patrón WSO2 MicroService con WSO2 MSS 13
Patrones Generales WSO2 MicroServices sobre ESB 16
WSO2 Microservices y el Fracaso Parcial 16
WSO2 Microservices y Timeouts 17
WSO2 Microservices Bulkheads 17
WSO2 Microservices y Cache 18
WSO2 Microservices y la Distribución de Carga 18
WSO2 Microservices y descubrimiento de Endpoints 19
WSO2 Microservices Contenedores 19
WSO2 Microservices Máquinas Virtuales 19
WSO2 Microservices Monitoreo y Análisis de Datos 19
Recomendaciones Generales 20
En esencia 21

2
Microservices. Microservices con WSo2 | Sunqu | 2016
 Introducción

Actualmente los microservicios (microservices en inglés), han estado irrumpiendo dentro

de la disciplina SOA por su enfoque pragmático y ágil y su ajustado enfoque al negocio
y no en la tecnología. El objetivo de este documento es describir cómo 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 microservice, algunas reflexiones y conclusiones.

Una pequeña historia

Generalmente cuando iniciamos proyectos de

software de gran envergadura comenzamos
WhitePaper

con la identificació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 sistema y la
existencia de nuevos requisitos.
Generalmente si desarrollamos un servicio
para obtener el detalle de una factura,

3 3
Microservices. Microservices con WSo2 | Sunqu | 2016
 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.

Durante 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. Microservice viene a plantear un enfoque distinto.

Qué 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. Éste debe cumplir
WhitePaper

con una función de negocio concreta y, además, 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 cómo una aplicación monolítica puede ser

44 Microservices. Microservices con WSo2 | Sunqu | 2016

 dividida en servicios independientes que cumplen con una función concreta de negocio.
A continuación se enumeran las principales características de microservices:

1. Los servicios tienen una responsabilidad micro con un enfoque ajustado al negocio.
2. Viven dentro de un contenedor con un ciclo de vida independiente (ejecutado en su propio
proceso).
3. Son organizados de forma vertical sobre las capacidades de negocio y no de tecnología.
4. Están diseñados bajo el principio de bajo acoplamiento.
5. Son desarrollados pensando en la coreografía y no en la orquestación.
6. Son diseñados para soportar el fracaso (tolerante a fallas).
7. Sus modelos de implementación y su gobierno se realizan de forma descentralizada.
8. Sus modelos de implementación no son compartidos. Por ejemplo, sus modelos de
dominio y el modelo de persistencia son exclusivos e individuales.
9. Se comunican sobre mecanismos ligeros como HTTP o JMS.
WhitePaper

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. Incluso se puede combinar una arquitectura
monolítica y microservice aprovechando lo mejor de ambos enfoques.

5
Microservices. Microservices con WSo2 | Sunqu | 2016
 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.
 
WhitePaper

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

6
6 Microservices. Microservices con WSo2 | Sunqu | 2016
 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 simplificar y ajustar los
requerimientos a las necesidades funcionales y específicas de la aplicación. La puerta
de enlace API encapsula la arquitectura del sistema interno proporcionando una API
WhitePaper

que se adapte a cada cliente. El Gateway puede tener otras responsabilidades, como la
autenticación, control, distribución de carga, almacenamiento en caché y manipulación
respuestas entre otros.
El API Gateway proporciona:
1. Un único punto de acceso.
2. Oculta al cliente los detalles asociadas a la invocación de microservices
enlazados o relacionados.
3. Disminuye las solicitudes o invocaciones a servicios a través de la red.
4. Simplifica los clientes proxys de acceso.
5. Proporciona un api personalizado.

7
Microservices. Microservices con WSo2 | Sunqu | 2016
 MicroServices en WSO2

WSO2 es un stack maduro que proporciona modelos de implementación flexibles 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
WhitePaper

plataforma de microservices.

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, además, 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:

1. Aislar a los clientes sobre la lógica de integración y composición entre los

microservicios.
2. Aislar al cliente de la ubicación de microservices.
3. Proporcionar una API óptima para cada cliente.
4. Reducir el número de peticiones (ida y vuelta).
5. Simplificar la invocación o llamada a múltiples microservices desde el cliente.
6. Incorporar políticas de cache, autenticación, autorización, entre otros.
7. 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

8
Microservices. Microservices con WSo2 | Sunqu | 2016
 sobre HA y clustering. De la misma forma, pueden ser establecidas 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 más destacadas de microservices es su capacidad
de comunicación sobre mecanismos ligeros como HTTP o JMS. Un patrón de diseño
recomendado 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).
WhitePaper

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 almacenar 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, los
cuales pueden consumir mensajes de los message stores y procesarlos. En este
procesamiento, los mensajes pueden ser enviados a endpoints almacenados y

9
Microservices. Microservices con WSo2 | Sunqu | 2016 9
 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 la misma forma, pueden ser establecidas
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 el siguiente gráfico 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
WhitePaper

la validación, seguridad, cache, garantía de entrega, tolerancia a fallas, logging y audit

entre otras.
Bajo este enfoque WSO2 ESB asume y desarrolla diversos roles, limitando y
estandarizando su función en contextos de arquitectura. 

Patrón WSO2 Stack y soporte WS-Eventing para Microservice

10
10 Microservices. Microservices con WSo2 | Sunqu | 2016
 WSO2 proporciona la capacidad para desarrollar servicios de datos, decisión y dominio
específico bajos diversos productos de su stack. Los servicios de datos (WSO2 DSS)
pueden 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 puede utilizar para recibir notificaciones 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
WhitePaper

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
endpoints 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.ActiveMQInit
ialContextFactory&transport.jms.ConnectionFactoryType=queue&transport.jms.Co
nnectionFactoryJNDIName=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 envio a otros queues/topics.

11
Microservices. Microservices con WSo2 | Sunqu | 2016
 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.

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,
WhitePaper

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 y WSO2 Security Gateway entre otros.
Entre las características más relevantes:

1. Gateway de alto rendimiento y baja latencia.

2. 10 veces más rápido que el transporte HTTP presente actualmente en WSO2 ESB.
3. Soporte de miles de conexiones concurrentes.
4. Enrutamiento basado en Apache Camel y Spring Framework.
5. Balanceo de carga y conmutación por error (Circuit Breaker / Kill Switch).
6. Soporte mejorado para gestión de errores.
7. REST/APIs basadas en DSL Camel RESTful.
8. Estadísticas de enrutamiento a través de JMX.

12
Microservices. Microservices con WSo2 | Sunqu | 2016
 Con este enfoque se podrá establecer servicios RESTfull directamente, por ejemplo:

<rest path="/iot">
<get uri="/dispositivo">
<to uri="direct:getDispositivos"/>
</get>
<get uri="/dispositivo/{id}">
<to uri="direct:getDispositivosById"/>
</get>
</rest>

Además, incluirá un modelo de enrutamiento, por ejemplo:

<route>
WhitePaper

<from uri=" direct:getDispositivosById "/>

<recipientList>
<simple>iot:http://iot/posts/${header.id}</simple>
</recipientList>
</route>

Patrón WSO2 MicroService con WSO2 MSS

WSO2 se encuentra desarrollando un modelo más aislado del ESB para aquellas imple-
mentaciones que requieran la implementación del paradigma MicroService mediante
estrategias como el Non-blocking IO, procesamiento y programación concurrente
basada en Netty, Patrón Disruptor, Java 8 y Programación Reactiva, entre otros. De esta
forma, se mejoran las limitaciones actuales del enfoque ESB y su planteamiento basado
en roles. El producto es denominado WSO2 MicroService Server (WSO2 MSS).

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 microService se desarrolla para un solo propósito y es

13
Microservices. Microservices con WSo2 | Sunqu | 2016
 desplegado de forma independiente, lo cual garantizará su escalabilidad y fiabilidad.
Entre sus características más relevantes se encuentran:

1. Tiempo de ejecución rápido.

2. Soportado sobre el kernel WSO2 Carbon 5.0.
3. Bajo consumo de memoria.
4. Modelo de desarrollo simple para su implementación y monitoreo.
5. Utilización de WSO2 Developer Studio para su desarrollo, incluye definición de su
API a través de Swagger.
WhitePaper

6. Integración con WSO2 Data Analytics Server para análisis de datos.

7. Seguimiento de las solicitudes mediante un identificador único.
8. Transporte basado en Netty 4.0.
9. 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:

14
Microservices. Microservices con WSo2 | Sunqu | 2016
 Anotación Propósito
@HTTPMonitoring Anotación que permitirá que el
microservice envie la información
detallada de su comportamiento en
tiempo de ejecución al WSO2 DAS, por
ejemplo: startNanoTime, serviceName,
serviceClass, responseTime, requestSize-
Bytes, 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
WhitePaper

negocio.

@Counted Anotación que permite establecer una

métrica para incrementar o disminuir un
contador.

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);
}

15
Microservices. Microservices con WSo2 | Sunqu | 2016
 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,

seguridad y métricas, entre otros. Por ejemplo:

.addInterceptor(new MetricsInterceptor(MetricReporter.CONSOLE,
WhitePaper

MetricReporter.JMX, MetricReporter.DAS))

WSO2 MSS está 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 con 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. El Gateway no puede esperar de forma
indefinida a que el servicio envíe una respuesta, sino que 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

endpoints en WSO2 ESB. Cuando la llamada a un microservice supere un umbral
establecido, se implementa un patrón denominado disyuntor o circuit-breaker,

16
Microservices. Microservices con WSo2 | Sunqu | 2016
 cancelando la espera innecesaria cuando un servicio no esté disponible o no responda.
Si la tasa de error para un servicio supera un umbral específico, 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 configuración adecuada de endpoints

en el WSO2 ESB. En la siguiente sección, se puede observar una configuración estándar
de Endpoints que permite implementar el patrón circuit-breaker.

<endpoint name="CircuitBreakerEP">
<address uri="http://localhost:9764/app/microservices/call">
<suspendOnFailure>
<initialDuration>60000</initialDuration>
</suspendOnFailure>
<markForSuspension>
<errorCodes>101507,101508</errorCodes>
<retriesBeforeSuspension>3</retriesBeforeSuspension>
WhitePaper

<retryDelay>400</retryDelay>
</markForSuspension>
<timeout>
<duration>300</duration>
<responseAction>fault</responseAction>
</timeout>
</address>
</endpoint>

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 espere de forma indefinida por la respuesta del servicio proveedor.

Para implementar este patrón, WSO2 ESB proporciona Endpoints. A su vez, 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 pueden invocar servicios de cache o responder datos temporales.

En esencia, un endpoint permite la interrupción de forma definitiva cuando ha alcanzado

una taza de timeouts establecida. Este patrón evita que la falla se propague y degrade

17
Microservices. Microservices con WSo2 | Sunqu | 2016
 los servicios de la solución.
En la siguiente sección, se puede observar una configuración estándar de Endpoints
que permite implementar el patrón timeout sobre WSO2 ESB.

<endpoint name="MicroService">
<address uri="http://localhost:8267/platform/microservice/func">
<timeout>
<duration>320</duration>
<responseAction>fault</responseAction>
</timeout>
</address>
</endpoint>

WSO2 Microservices Bulkheads

WhitePaper

WSO2 ESB permite el establecimiento de estrategias para evitar el fracaso en cascada

mediante endpoints configurados 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 y
circuit-breaker, entre otros.

WSO2 Microservices y Cache

WSO2 ESB permite el establecimiento de cache en memoria o el desarrollo de im-

plementaciones customizables para la utilización de bases 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, configurar y programar.

18
Microservices. Microservices con WSo2 | Sunqu | 2016
 WSO2 Microservices y descubrimiento de Endpoints

WSO2 Gateway necesitará conocer la ubicación (dirección IP y puerto) de cada

microService 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, un ambiente virtual basado
en Linux (LinuX Containers) que permite establecer contenedores para los microservices
o tecnologías como mysql y nginx.
WhitePaper

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 ambientes
virtualizados, recomendando la utilización de Vagrant para la administración de diversos
ambientes virtualizados. Tecnologías como Puppet y Chef pueden ser utilizados con
WSO2 para automatizar la infraestructura de WSO2 MicroService.

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
soportada de forma individual o centralizada.

19
Microservices. Microservices con WSo2 | Sunqu | 2016
 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.

1. Identifique el modelo de arquitectura WSO2 Microservice más ajustado a su

solución.
2. Establezca una estrategia para responder a la latencia y tolerancia a fallas para su
arquitectura de MicroServices. Utilice endpoints, y evite la fragilidad en esta área.
3. Establezca un API Gateway y un Messaje Gateway para su arquitectura de
MicroServices.
4. Desarrolle microservices mediante el stack actual de WSO2 o sobre el producto
WSO2 MSS.
WhitePaper

5. Establezca un Gateway mediante WSO2 ESB o WSO2 GW.

6. Implemente una estrategia basada en Event Store para publicación y suscrición de
eventos.
7. Incorpore una estrategia de garantía de entrega en su arquitectura de microservice.
8. Framework como vagrant, saboteur, wiremock, hixtrix, cucumber pueden ser
combinado para establecer un stack sólido para las pruebas de microservices.
9. Utilice marcos como Docker, Kubernetes y Vagrant para simplificar la administración
de contenedores y máquinas virtuales.

20
Microservices. Microservices con WSo2 | Sunqu | 2016
 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.
WhitePaper

- 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 configurados
utilizando eventos que pueden enriquecer una plataforma WSO2 DAS.
- Cada servicio puede contar con aspectos de logging, auditoría,
excepciones de forma independiente o pueden ser inyectados dentro de
un servicio Gateway (ESB o servicios sobre un servidor de aplicaciones).

21
Microservices. Microservices con WSo2 | Sunqu | 2016
 - 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 flexible.
WhitePaper

22
Microservices. Microservices con WSo2 | Sunqu | 2016
WhitePaper

23
Microservices. Microservices con WSo2 | Sunqu | 2016