Etiquetas

,

Antes de comenzar a desarrollar microservicios debemos tener instalado el SDK de Service Fabric, podemos encontrar los pre requisitos en el siguiente link.

Para comenzar vamos a iniciar con un servicio stateless, para lo cual vamos a iniciar Visual Studio en modo Administración dado que es requerido para el host del servicio.

Posteriormente vamos a iniciar un nuevo proyecto del tipo Service Fabric Application.

image

Posteriormente vamos a seleccionar la plantilla de proyecto Stateless Service

image

Dentro de la solución vamos a encontrar dos proyectos.

image

El primer proyecto Applcation no contiene código de la implementación, el mismo hace referencia al proyecto del Servicio y contiene distintos archivos de configuración del proyecto.

  • Perfiles de publicación: se usa para administrar las herramientas preferidas para los distintos entornos.
  • Scripts: incluye un script de PowerShell para implementar o actualizar aplicaciones. Visual Studio usa este script en segundo plano y se puede invocar directamente desde la línea de comandos.
  • Definición de aplicación: incluye el manifiesto de la aplicación en ApplicationPackageRoot y los archivos de parámetros de la aplicación asociados a ApplicationParameters que definen la aplicación y permiten configurarla específicamente para un entorno determinado.

Dentro del proyecto del servicio encontraremos 3 archivos CS.

Program

El servicio se ejecuta en un proceso de host de servicio (un archivo ejecutable que ejecuta el código del servicio). El punto de entrada es una aplicación de consola en donde se hace el registro del nombre y el tipo del servicio.

image 

ServiceEventSource

Esta clase nos facilita el registro de eventos de la aplicación para el ETW Event Tracking Windows. Dentro de esta clase encontraremos una serie de métodos que nos permiten publicar información sobre el estado de la aplicación en cada paso.

image

Encontraremos algunos métodos que poseen el atributo NonEvent, el cual indica que no genera un evento. Sin embargo, estos métodos utilizan otros que generan eventos registrándose finalmente el evento.

finalmente encontraremos el código que implementa el servicio propiamente dicho. Stateless1, debido al nombre que le di al servicio.

image

En Service Fabric, un servicio puede ejecutar cualquier lógica de negocios. La API de servicios proporciona dos puntos de entrada para el código:

  • El método “RunAsync” el cual es un punto de entrada donde se puede realizar la ejecución de cualquier lógica de negocio que queramos. En general se utiliza para actividades del tipo long running. Por ejemplo en este punto de entrada podríamos realizar la lectura de items dentro de una cola que deban ser procesados por nuestro servicio.
  • Un punto de entrada de comunicación el cual se puede conectar con la API web de ASP.NET, por ejemplo. Aquí es donde podemos recibir los request hacia nuestro servicio.

Cuando iniciamos un proyecto utilizando la plantilla que seleccionamos para este ejemplo, el código que encontraremos dentro del método RunAsync será el siguiente:

image

En este ejemplo solo se posee un contador, el cual es incrementado en cada paso y se visualiza el resultado de cada iteración mediante el EventSource.

Si ejecutamos el código hasta este momento podremos visualizar lo siguiente:

image

En el visor de eventos de diagnóstico podremos visualizar los distintos eventos que fueron impresos en las iteraciones. Si entramos al detalle de alguno de ellos podremos visualizar lo siguiente:

image

En mi caso particular el nodo que está respondiendo al procesamiento es el _Node_0. Ahora bien, si abrimos la consola de cluster podremos visualizar el estado de cada uno de los nodos de procesamiento y cuales están asignados a nuestro servicio.

image

El detalle de mis nodos indica cuál contiene la implementación del servicio que acabamos de realizar.

image

image

Ahora bien, si queremos que el servicio responda a solicitudes podemos partir de la implementación que tenemos hasta el momento y agregar el paquete Nuget de OWIN Self Host.

Dado que el código de aplicación de Web API se hospeda en su propio proceso, ¿cómo se conecta a un servidor web?. OWIN es simplemente un contrato entre las aplicaciones web .NET y servidores web. Tradicionalmente, cuando se usa ASP.NET (hasta MVC 5), la aplicación web se acoplaba con IIS a través de System.Web. Sin embargo, Web API implementa OWIN, lo que le permite escribir una aplicación web que se separa del servidor web que la hospeda. Por este motivo, puede usar un servidor web OWIN selfhost que puede iniciar en su propio proceso. Esto encaja perfectamente con el modelo de hospedaje de Service Fabric.

image

Una vez agregadas las dependencias podemos continuar con la estructura de proyecto de Web Api.

image

Posteriormente crearemos un Controller, en mi caso SampleController.

image

Luego debemos agregar una clase de inicio en la raíz del proyecto para registrar el enrutamiento, los formateadores y cualquier otro programa de configuración. Aquí también es donde el Web API se conecta al host.

image

Para realizar el Host de Web API utilizaremos Katana como host de OWIN.

La API de Reliable Services ofrece un punto de entrada de comunicación en el que puede conectar pilas de comunicación para permitir a los usuarios y a los clientes conectarse al servicio.

image

El servidor web (y cualquier otra estructura de comunicación que utilice en el futuro, como WebSockets) debe utilizar la interfaz ICommunicationListener para integrarse correctamente en el sistema.

Por tal motivo en primero lugar debemos crear una clase denominada OwinCommunicationListener que implemente ICommunicationListener:

image

La interfaz de ICommunicationListener contiene tres métodos para administrar un agente de escucha de comunicación para el servicio:

  • OpenAsync. Empezar a escuchar las solicitudes.
  • CloseAsync. Dejar de escuchar las solicitudes, finalizar las solicitudes en curso y cerrar correctamente.
  • Abort. Cancelar todo y detener inmediatamente.

Primero agregaremos los miembros el agente requiere para funcionar. Estos se inicializarán a través del constructor y se usarán más adelante cuando configure la dirección URL.

image

image

image

Antes de obtener un puerto para el servidor web, es importante comprender que Service Fabric proporciona una capa de aplicación que actúa como un búfer entre la aplicación y el sistema operativo en el que se ejecuta. Como tal, Service Fabric proporciona una manera de configurar extremos para los servicios. Service Fabric garantiza que los puntos de conexión están disponibles para que el servicio los utilice. De este modo, no tiene que configurarlos por su cuenta en el entorno de sistema operativo. Puede hospedar fácilmente su aplicación de Service Fabric en diferentes entornos sin tener que realizar cambios en la aplicación. (Por ejemplo, puede hospedar la misma aplicación en Azure o en su propio centro de datos).

Para realizar este paso abriremos el archivo ServiceManifest.xml

image

Este paso es importante porque el proceso de host de servicio se ejecuta con credenciales restringidas (servicio de red en Windows). Esto significa que el servicio no tendrá acceso para configurar un punto de conexión HTTP por sí mismo. Mediante la configuración del punto de conexión, Service Fabric sabe configurar la lista de control de acceso (ACL) adecuada para la dirección URL que el servicio escuchará. Service Fabric también proporciona un lugar estándar para configurar puntos de conexión.

Ahora si, podemos continuar con la implementación de nuestra clase, en primera medida implementaremos el método OpenAsync

image

El primer paso es obtener los elementos para construir la URL donde se hospedará nuestro servicio, para la cuál debemos acceder a los parámetros anteriormente configurados.

image

La dirección URL será diferente dependiendo de si se utiliza el agente de escucha en un servicio sin o con estado. Para los servicios con estado, el agente de escucha debe crear una dirección única para cada réplica de servicio con estado en la que el agente realiza la escucha. Para los servicios sin estado, la dirección puede ser mucho más sencilla.

image

La implementación de OpenAsync es una de las razones más importantes por las que el servidor web se implementa como una interfaz ICommunicationListener en lugar de simplemente abrirse directamente desde RunAsync() en el servicio. El valor devuelto de OpenAsync es la dirección que está escuchando el servidor web. Cuando se devuelve esta dirección al sistema, registra la dirección con el servicio. Service Fabric proporciona una API que permite a los clientes y otros servicios pedir esta dirección por nombre de servicio. Esto es importante porque la dirección del servicio no es estática. Los servicios se mueven en el clúster para fines de disponibilidad y equilibrio de recursos. Este es el mecanismo que permite a los clientes resolver la dirección de escucha de un servicio.

OpenAsync inicia el servidor web y devuelve la dirección en que está escuchando. Tenga en cuenta que realiza escuchas en ‘http://+’, pero antes de que OpenAsync devuelva la dirección, el “+” se sustituye por la dirección IP o FQDN del nodo en el que está actualmente. La dirección que este método devuelve es la que se registra con el sistema. También es lo que los clientes y otros servicios ven cuando solicitan la dirección de un servicio. Para que los clientes se conecten correctamente a ella, necesitan un IP o FQDN real en la dirección.

image

Si hemos utilizado la plantilla de Stateless debemos realizar algunos cambios en nuestra clase de Event Source

image

image

Posteriormente continuamos implementando los métodos de OwinCommunicationListener

image

image

Ahora, en nuestra clase de servicio, debemos implementar el método CreateServiceInstanceListeners y eliminamos el método RunAsync.

image

image

Para descargarse el código del ejemplo puede ir al link de descarga.