Desenvolupament de servicis REST a l’estil devops

8 de de maig de 2019

Continguts

Introducció
Documentar l’API
Incloure mètriques (capa de observabilitat)
Incloure tolerància a errors (capa d’escalabilitat)
Conclusions
Enllaços

1 Introducció

Suposem que anem a desenvolupar un servici en un contexts devops. Haurem de pensar tant en la lògica d’un negoci que ofereix el servici (la part dev) com en la execució del servici (la part ops). En aquesta segona part intervenen, entre altres elements, l’escalabilitat i l’observabilitat.

Per a la part dev, des del llenguatge Java, podem utilitzar per exemple Spring Boot o l’Eclipse MicroProfile. Aquest últim ofereix un subconjunt del API de Java EE orientat al desenvolupament de servicis que ofereixen un API REST.

Per a la part ops, hi ha que afegir servicis addicionals orientats al pla del control. Per a açò, tenim diferents aproximacions:

Proporcionar-los des de fora del codi com per exemple ocorre amb Istio sobre Kubernetes.
Proporcionar-los des del codi si disposem d’un API que ens permet especificar de forma declarativa el comportament desitjat, per exemple davant un error, el contenidor que gestiona el nostre servici s’encarrega de realitzar el treball especificat.

El MicroProfile és un exemple d’aquesta segona aproximació i ofereix un conjunt d’APIs que permeten:

Desenvolupar el servici
Facilitar l’escalada dels servicis
Facilitar l’observabilitat dels servicis

Figura 1: Capes del API microprofile

La capa inferior és un subconjunt dels APIs de Java EE. La segona capa d’APIs està orientada a la escalabilitat i la capa superior permet observar l’estat dels servicis i recollir informació que pot ajudar a optimitzar-los o a corregir errors.

Anem a revisar breument tres dels APIs que ofereix.

2 Documentar l’API

Quan s’està desenvolupant una arquitectura basada en servicis és necessari documentar els APIs. Açò pot realitzar-se des de el propi codi mitjançant l’ús d’anotacions.

A partir d’aquestes anotacions es crea un nou endpoint en la URL http://HOST:PORT/openapi/ui que conté la documentació del API. Açò ens permet obtindre una visió general del API que ofereix el servici, o els detalls de les operacions des de d’on podem enviar peticions tal i com es mostra en les dos figures següents:

Figura 2: Vista general del API que ofereix un servici

Figura 3: Descripció detallada d’una operació des d’on podem realitzar peticions.

3 Incloure mètriques (capa d’observabilitat)

És molt important poder obtindre mètriques que permetin observar l’estat del servici i de la màquina virtual- Per a açò, es pot utilitzar els API MicroProfile Metrics. Utilitzant aquesta API, el servei proporcionarà un API REST per a la consulta de les mètriques.

Aquest API ens proporciona anotacions com: @Counted que permet contar el número de vegades que es crida a un mètode determinat; @Timed que permet mesurar el temps que tarda en executar-se un mètode; o @Gauge que permet mostrar un valor qualsevol.

Les mètriques estan disponible en les URLs http://HOST:PORT/metrics o http://HOST:PORT/metrics/application per visualitzar únicament les mètriques que ofereix la aplicació.

Figura 4: Exemple de mètriques abans de realitzar peticions.

Figura 5: Exemple de mètriques després de realitzar diferents peticions.

Podrem configurar un servici com Prometheus per a què consulte periòdicament esta informació i obtindre gràfiques d’aquelles mètriques que ens interessen.

Figura 6: Prometheus: exemple de la gràfica d’una mètrica proporcionada per la aplicació.

4 Incloure tolerància a errors (capa d’escalabilitat)

Hi ha diferents patrons que ajuden a fer més robusta una aplicació:

fail fast serveix per a notificar de la manera més ràpida possible al client que realitza la cridada que l’execució tarda més de l’acceptable,
retry serveix per a realitzar un nombre de reintents quan es produeix un error abans de retornar una fallada al client,
circuit breaker serveix per a no realitzar cridades als serveis que estan fallant, o
buckhead per a limitar el nombre de peticions que poden executar concurrentment un servei.

L’API MicroProfile Fault Tolerance ofereix un conjunt d’anotacions que permeten configurar com s’ha de comportar el servei quan hi ha fallades.

Es pot configurar un temps d'espera màxim mitjançant l’anotació @Timeout de tal forma que si l'execució del mètode no finalitza en el temps especificat es detindrà l'execució del mètode, que finalitzarà amb una excepció del tipus TimeoutException.

Per a especificar el nombre de reintents s’usa l’anotació @Retry. Si es supera el nombre d’intents, l’execució finalitzarà amb una excepció.

5 conclusions

En un context devops cal centrar-se en el desenvolupament, en com aconseguir la funcionalitat que ha d'oferir el servei, i també en el seu comportament en execució, en com s'ha de comportar en cas de fallada pròpia o d'altres serveis amb els quals interacciona. Hem mostrat que l’API que ofereix Eclipsi MicroProfile incorpora alguns d'aquests elements del pla de control i ens ofereix una sèrie d'anotacions per a informar el contenidor que executa el servei sobre què ha de fer en cas de fallades. En dos tallers de l'assignatura Computació en el Núvol s'ha desenvolupat el servei, s'ha encapsulat en una imatge i s'ha generat un servei amb docker-compose que integra també el contenidor Prometheus.

6 Enllaços

Etiquetes

Publicat per:
Juan Gutierrez Aguado