Microservices.

Microservices con
WSO2

Julio Cejas
Arquitecto Chakray
El objetivo de este documento es describir como el enfoque ,
Microservicios, denominado SOA ligero puede ser implementado
mediante el WSO2 Lean Enterprise Middleware.

ndice

Introduccin

Una pequea historia

Que es un Microservice

Sobre las Aplicaciones Monolticas

Microservices y un API Gateway

Microservices en WSO2

Patrn WSO2 ESB como API Gateway Microservice

Patrn WSO2 ESB como Message Gateway Microservice

Patrn WSO2 ESB como API Gateway y Message Gateway

10

Patrn WSO2 Stack y soporte WS-Eventing para Microservice

11

Patron WSO2 Gateway con WSO2 GW para Microservices

12

Patrn WSO2 Microservice con WSO2 MSS

13

Patrones Generales WSO2 Microservices sobre ESB

15

WSO2 Microservices y el Fracaso Parcial

15

WSO2 Microservices y Timeouts

16

WSO2 Microservices Bulkheads

17

WSO2 Microservices y Cache

17

WSO2 Microservices y la Distribucin de Carga

17

WSO2 Microservices y descubrimiento de Endpoints

17

WSO2 Microservices Contenedores

17

WSO2 Microservices Mquinas Virtuales

18

WSO2 Microservices Monitoreo y Anlisis de Datos

18

Recomendaciones Generales

18

En esencia

19

Sobr el autor

20

www.chakray.com

Introduccin

Actualmente los microservicios (microservices en ingls), han estado

irrumpiendo dentro de la disciplina SOApor su enfoque pragmtico, gil; y

su ajustado enfoque al negocio y no enla tecnologa.El objetivo de este documento es describir como este enfoque denominado SOA ligero puede
ser implementado mediante el WSO2 Lean Enterprise Middleware. En las
siguientes secciones realizar una pequea inmersin en el concepto de microservice, algunas reflexiones y conclusiones.

www.chakray.com

Una pequea historia

Generalmente cuando iniciamos proyectos de software de gran envergadura comenzamos
con la identificacin del vocabulario asociado a un determinando contexto o dominio, los
convertimos en un modelo de informaciny abordamos sus relaciones posteriormente. Es
muy comn 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 informacin, 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, utilizamos un modelo subyacente con muchas relaciones
a otras tablas; sobre este modelo se establecen muchas dependencias; fcilmente reconocibles cuando un cambio pequeo en un atributo de una tabla implica el cambio de muchos
artefactos de software, o bajar y subir toda una solucin; en esencia un cambio pequeo
impacta atoda lasolucin.
Por aos se ha abordado el desarrollo de software con esteenfoque estndar: el establecimiento de un modelo de dominio que represente el vocabulario de un negocio y sus relaciones; representndola en toda su extensin. Microservice viene a plantear un enfoque
distinto.

www.chakray.com

Que es un Microservice
En esencia, un microservice esun artefacto de software que est diseado para evitar que
dependa de un modelo de relaciones extenso y pesado; el cual debecumplir con una funcin de negocio concreta; adems de contar conuna implementacin simple y pensada en
la integracin con otros. Su objetivoes propiciar eldesarrollo 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 creacin de soluciones frgiles y complejas.

En el diagrama anterior se puede observar como una aplicacin monoltica puede ser dividida en servicios independientes que cumplen con una funcin concreta de negocio. A
continuacin se enumeran las principales caractersticas 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 tecnologa.
04 Estn diseado bajo el principio de bajo acoplamiento.

www.chakray.com

05 Son desarrollados pensando en la coreografa y no en la orquestacin.

06 Son diseados para soportar el fracaso (tolerante a fallas).
07 Sus modelos de implementacin y su gobierno se realizan de forma descentralizada.
08 Sus modelos de implementacin 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 Monolticas

El desarrollo de arquitecturas monolticas seguir siendo una alternativa para el desarrollo de soluciones y depender del grado de distribucin, tamao, necesidades de integracin y mediacin de la solucin, para optar por una arquitectura microservice. En
esencia, es importante recalcar que no toda solucin debe ser abordada bajo un enfoque
de microservices.
Las aplicaciones monolticas pueden ser
construidas con una modularidad til, evitando las reas complejas que los microservices introducen en cualquier arquitectura. Si los lmites de la solucin pueden
ser gestionados, son pequeos y no existe
la necesidad de conformacin de una arquitectura distribuida; la solucin puede
abordarsebajo estrategias de aplicaciones
monolticas.. Inclusive, se puede combinar
una arquitectura monoltica y microservice
aprovechando lo mejor de ambos enfoques.
Una recomendacin concreta es comenzar
con una arquitectura monoltica para luego
romperla o dividirla en microservices, con
este enfoque se puede explorar, descubrir
y explotar los lmites y extensiones de la solucin, estableciendo un mapa de ruta ms
slido para el diseo y arquitectura de microservices.

www.chakray.com

Microservices y un API Gateway

En arquitecturas basadas en microservice es recomendable la utilizacin de una puerta
de enlace conocida como API Gateway. La puerta de enlace es responsable de la peticin,
encaminamiento, composicin y traduccin 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 mltiples microservices para agregar sus
resultados.

La recomendacin general es que los clientes no invoquen directamente los microservices,

sino a travs de un Gateway que permita simplificar y ajustar los requerimientos a las necesidades funcionales y especficas de la aplicacin. 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 autenticacin, control, distribucin
de carga, almacenamiento en cach, manipulacin respuestas, entre otros.
El API Gateway proporciona:
01 Un nico punto de acceso.
02 Oculta al cliente los detalles asociadas a la invocacin de microservices enlazados o
relacionados.
03 Disminuye las solicitudes o invocaciones a servicios a travs de la red.
04 Simplifica los clientes proxys de acceso.
05 Proporciona un api personalizado.

www.chakray.com

Microservices en WSO2
WSO2 es un stack maduro que proporciona modelos de implementacin flexibles y ligeros para soportar las caractersticas ms importantes y relevantes de microservices. En las
prximas secciones describir las estrategias y patrones que pueden ser incorporados en
sus iniciativas WSO2 para dar soporte a este enfoque.

Patrn WSO2 ESB como API Gateway Microservice

Un ESB (Enterprise Service Bus) es una infraestructura que puede realizar servicios de
mediacin, enrutamiento, enriquecimiento y la incorporacin de polticas sobre servicios
web y otros artefactos. Estas caractersticas pueden ser utilizadas para implementar un
Gateway para arquitecturas microservices. En esencia, en este patrn, utilizamos el WSO2
ESB y todas sus caractersticas para desplegar un Gateway para nuestra plataforma de microservices.

El WSO2 ESB Gateway puede ofrecer un mecanismo que permita el acceso a microservices individuales desde aplicaciones mediante la conformacin 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 continuacin se enumeran las
funciones que este ESB debe cumplir como Gateway:
01 Aislar a los clientes sobre la lgica de integracin, composicin, entres los microservicios.
02 Aislar al cliente de la ubicacin de microservices.
03 Proporcionar una API ptima para cada cliente.

www.chakray.com

04 Reducir el nmero de peticiones (ida y vuelta).

05 Simplificar la invocacin o llamada a mltiples microservices desde el cliente.
06 Incorporar polticas de cache, autenticacin, autorizacin, entre otros.
07 Exponer APIs adaptadas a las necesidades de los clientes.

WSO2 permite la conformacin 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.

Patrn 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 caractersticas de microservices es su capacidad de comunicacin sobre
mecanismos ligeros como HTTP o JMS. Un patrn de diseo recomendado es la conformacin de un Gateway de mensajera que pueda enriquecer e incluir polticas a los mensajes
que son intercambiados entre microservices cuando utilizamos JMS como norma de comunicacin. Sobre este enfoque podemos utilizar un WSO2 ESB como mediador de mensajes (messages JMS).

www.chakray.com

Bajo este patrn, podemos utilizar la capacidad del WSO2 ESB para la gestin 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 utilizacin de REDIS, entre otras tecnologas. Otro componente que puede ser
utilizado en este patrn 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 conformacin de un Gateway de mensajera 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.

Patrn WSO2 ESB como API Gateway y Message

Gateway
En la siguiente grafica se puede observar la inclusin de ambos enfoques:

Resumiendo, WSO2 ESB puede ser utilizado como componente para la conformacin de
API Gateways y message Gateways; estableciendo un nico punto de acceso para arquitecturas basada en microservices. Los gateways pueden desarrollar polticas para la validacin, seguridad, cache, garanta de entrega, tolerancia a fallas, logging, audit, entre otras.
Bajo este enfoque WSO2 ESB asume y desarrolla diversos roles, limitando y estandarizando su funcin en contextos de arquitectura.

www.chakray.com

10

Patrn WSO2 Stack y soporte WS-Eventing para

Microservice
WSO2 proporciona la capacidad para desarrollar servicios de datos, decisin y dominio
especfico 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 estndarWS-Eventingque 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 suscripcin que cualquier cliente puede utilizar para recibir notificaciones enviadas desde un tpico a una cola de mensajera o
incluso correo electrnico.
En esencia,WSO2 DSS, BRS, AS proporcionan soporte al estndar WS-Eventing, con lo
cual podemos habilitar la comunicacin entre servicios de forma asncrona. Este enfoque
permite que los servicios estn desacoplados utilizando un estilo de comunicacin 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.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 travs de una suscripcin establecida. De igual forma pueden ser
utilizados listener para el envi a otros queues/topics.

Es importante destacar que se recomienda la utilizacin de una capa Facade(Gateway)

para evitar la proliferacin 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 ms enfocado y dirigido
para el soporte del patrn Facade y microservices. Sobre este escenario, no se utilizara 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 implementacin de patrn Gateway/Facade. Su objetivo es encapsular mensajes entre
sistemas heterogneos con tecnologas, protocolos y normas diversas.
WSO2 GW ser la puerta de enlace de mensajera que servir de Gateway para productos
como WSO2 Enterprise Service Bus, WSO2 Security Gateway, entre otros.

Entre las caractersticas ms relevantes:

01 Gateway de alto rendimiento y baja latencia.
02 10 veces ms rpido 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 conmutacin por error (Circuit Breaker / Kill Switch).
06 Soporte mejorado para gestin de errores.
07 REST/APIs basadas en DSL Camel RESTful.
08 Estadsticas de enrutamiento a travs de JMX.

www.chakray.com

12

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>

Adems, incluir un modelo de enrutamiento, por ejemplo:

<route>
<from uri= direct:getDispositivosById />
<recipientList>
<simple>iot:http://iot/posts/${header.id}</simple>
</recipientList>
</route>

Patrn WSO2 Microservice con WSO2 MSS

WSO2 se encuentra desarrollando un modelo ms aislado del ESB para aquellas implementaciones que requieran la implementacin del paradigma microservice mediante estrategias como el Non-blocking IO, procesamiento y programacin concurrente basada en
Netty, Patrn Disruptor, Java 8, Programacin 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 construccin y entrega de aplicaciones orientadas en microservices

sobre servicios REST, ofreciendo una arquitectura de alto rendimiento (tiempo de ejecucin y arranque) y la garanta del bajo consumo de recursos. WSO2 MSS ha incorporado la
gestin de mtricas y anlisis a travs de la integracin con WSO2 Data Analytics Server
(WSO2 DAS), que ofrece una solucin completa para el anlisis de datos. Cada microservice se desarrolla para un solo propsito y es desplegado de forma independiente, lo cual
garantizar su escalabilidad y fiabilidad.
Entre sus caractersticas ms relevantes:
01 Tiempo de ejecucin rpido.
02 Soportado sobre el kernel WSO2 Carbon 5.0.
03 Bajo consumo de memoria.
04 Modelo de desarrollo simple para su implementacin y monitoreo.
05 Utilizacin de WSO2 Developer Studio para su desarrollo, incluye definicin de su
API a travs de Swagger.
06 Integracin con WSO2 Data Analytics Server para anlisis de datos.
07 Seguimiento de las solicitudes mediante un identificador 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 ms relevantes:

ANOTACIN

PROPSITO

@HTTPMonitoring

Anotacin que permitir que el microservice envi la informacin detallada

de su comportamiento en tiempo de ejecucin al WSO2 DAS, por ejemplo:
startNanoTime, serviceName, serviceClass, responseTime, requestSizeBytes,
httpMethod, requestUri, entre otros.

@Metered

Anotacin que permite establecer una mtrica para medir la tasa de eventos
en un tiempo determinado.

@Timed

Anotacin que permite establecer una mtrica para medir la duracin de

ejecucin de una determinada funcin de negocio.

@Counted

Anotacin que permite establecer una mtrica para incrementar o

decrementar un contador.

www.chakray.com

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 polticas de validacin, seguridad, mtricas entre otros; por ejemplo:
.addInterceptor(new MetricsInterceptor(MetricReporter.CONSOLE,
MetricReporter.JMX, MetricReporter.DAS))

WSO2 MSS esta soportada por las siguientes tecnologas: 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 estn
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 indefinida a que el servicio envi una respuesta. El Gateway debe decidir si
retornar un error al cliente o proporcionar informacin 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 patrn 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 especifico, WSO2 puede disparar un interruptor y todas las
peticiones fallarn inmediatamente por un perodo de tiempo.
Este patrn puede ser implementado mediante la configuracin adecuada de endpoints en
el WSO2 ESB. En la siguiente seccin, se puede observar una configuracin estndar de
Endpoints que permite implementar el patrn 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>
<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 funcin 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 patrn, WSO2 ESB proporciona Endpoints; los endpoints proporcionan propiedades como la duracin del timeout y la accin si el timeout ha superado un
determinado umbral. De igual forma se pueden utilizar secuencias de excepcin que pueden invocar servicios de cache o responder datos temporales.
En esencia, un endpoint permite la interrupcin de forma definitiva cuando ha alcanzado
una taza de timeouts establecida. Este patrn evita que la falla se propague y degrade los
servicios de la solucin. En la siguiente seccin, se puede observar una configuracin estndar de Endpoints que permite implementar el patrn 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>

www.chakray.com

16

WSO2 Microservices Bulkheads

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 solucin. El Bulkheads es un patrn que establece
prcticas para reducir el riesgo de fracaso y as evitar la degradacin y sus consecuencias
mediante barreras como la implementacin del patrn 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 utilizacin 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 Distribucin de Carga

NGINX es una alternativa escalable para microservices, que proporciona un servidor web
de alto rendimiento, fcil de desplegar, configurar y programar.

WSO2 Microservices y descubrimiento de Endpoints

WSO2 Gateway necesitar conocer la ubicacin (direccin IP y puerto) de cada microservice con el que se comunicar; su localizacin puede realizarse mediante un proceso de
descubrimiento contra un registro (WSO2 Governance Registry), permitiendo que los endpoints puedan establecerse dinmicamente en tiempo de ejecucin.

WSO2 Microservices Contenedores

La gestin operativa de microservicios puede convertirse fcilmente en una tarea muy
compleja en la medida que estos van creciendo; para facilitar su administracin es recomendable la utilizacin de contenedores como Docker. Docker es un ambiente virtual basado en Linux (LinuX Containers) que permite establecer contenedores para los microservices o tecnologas como mysql, nginx, entre otros.

WSO2 Microservices Mquinas Virtuales

Generalmente las plataformas para microservices son virtualizadas mediante tecnologas
VM (virtual machines) como VirtualBox, VMWare, AWS, entre otros. En algunos casos podemos tener diversos entornos de virtualizacin para plataforma de microservices. WSO2
y todo su stack puede ser gestionado sobre ambiente virtualizados, recomendando la utilizacin de Vagrant para la administracin de diversos ambiente virtualizado. Tecnologas
como Puppet y Chef pueden ser utilizados con WSO2 para automatizar la infraestructura
de WSO2 Microservice.

www.chakray.com

17

WSO2 Microservices Monitoreo y Anlisis de Datos

WSO2 ESB y WSO2 MSS permiten la integracin con el producto de anlisis de datos
WSO2 DAS que soporta anlisis 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.

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 desafos de implementaciones sobre ambientes distribuidos.
01 Identifique el modelo de arquitectura WSO2 Microservice ms ajustado a su solucin.
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 publicacin y suscricin de
eventos.
07 Incorpore una estrategia de garanta de entrega en su arquitectura de microservice.
08 Framework como vagrant, saboteur, wiremock, hixtrix, cucumber pueden ser combinado para establecer un stack slido para las pruebas de microservices.
09 Utilice marcos como Docker, Kubernetes y Vagrant para simplificar la administracin de contenedores ymquinas virtuales.

www.chakray.com

18

En esencia
Dentro de una arquitectura Microservices el WSO2 ESB puede desarrollar funciones asociadas a la conformacin de un API Gateway y un Message Gateway.
Los productos del stack WSO2 pueden utilizar el estndar ws-eventing para establecer mecanismos de comunicacin 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 administracin.
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 polticas de cache, seguridad, logging, audit,
validacin, garanta de entrega, entre otros.
La plataforma WSO2 ya incluye microservices especializados en servicios de gestin
de identidades para autenticacin y autorizacin.
Cada servicio esAutoMonitoreable, es decir informa constantemente su estadoen
tiempo de ejecucin.
Cada servicio cuenta con un dashboard que permite ver su comportamiento en
tiempo de ejecucin de forma individual.
Si es necesaria la integracin de indicadores del comportamiento de servicios en
tiempo de ejecucin, estos pueden ser configurados utilizando eventos que pueden
enriquecer una plataforma WSO2 DAS.
Cada servicio puede contar con aspectosde 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, proporcionandoservicios con interfaces uniformes como
la forma primaria de encapsulacin.
WSO2 es un stack Open Source que puede ser utilizado para implementar en toda su
extensin una arquitectura de MicroService. Espero que estos modelos de implementacin y recomendaciones fortalezcan su iniciativa y proporcionen una arquitectura ms
slida, gil y flexible.

www.chakray.com

19

Muchas gracias!
Sobre el autor:

Julio Cejas
Arquitecto Chakray / julio.cejas@chakray.com

Especialista con ms de 15 aos de experiencia como Consultor y Arquitecto

en la construccin de Sistemas Crticos basados en productos free y open
source. Combina su experiencia en Computer Security y su pasin tecnologa 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 MS

www.chakray.com

20

info@chakray.com

www.chakray.com

www.chakray.com

21