Etude de l'architecture microservice¶

• Table of contents
• Etude de l'architecture microservice
  • Architecture
    • Routeur
    • Pattern de Circuit Breaker
    • Centralisation de la configuration
  • Dialogue REST avec les microservices
    • Obtenir la client d'authentification cliente
    • Demander un token JWT
    • Utiliser systématiquement le token oauth

Architecture¶

Gestion comme un cloud de service.

Gestion de plusieurs service cloud : https://github.com/RegardsOss/regards-cloud

• System gateway (relying on Netflix Zuul),
• System authentication (relying on Spring OAuth2),
• Microservice registry for load balancing (relying on Netflix Eureka),
• Configuration (relying on Spring Cloud Config).

Routeur¶

Avec ce type d’architecture, une seule URL par microservice est visible de l’extérieur, celle du routeur. Plusieurs instances de microservices peuvent cohabiter de manière transparente.

Pattern de Circuit Breaker¶

https://blog.octo.com/circuit-breaker-un-pattern-pour-fiabiliser-vos-systemes-distribues-ou-microservices-partie-1/

nous sommes passés de « prévenir toutes les défaillances » à « les défaillances font partie du jeu ».
Octo

Centralisation de la configuration¶

Extrait:
Le service de centralisation de la configuration des microservices permet d’assurer une externalisation de la configuration dans une architecture distribuée. A partir d’un dépôt de configuration géré par le serveur de configuration centralisée, il est possible d’appliquer les éléments de configuration communs à chaque instance d’un même microservice. Si une modification de configuration est apportée à un microservice, elle est stockée sur le serveur de configuration centralisée et diffusée pour être appliquée aux instances du même microservice.
__

Dialogue REST avec les microservices¶

1. Pour dialoguer avec les microservices sans passer par l'interface, il faut utiliser un client REST ( Advanced REST client, Restlet Client, etc...)
2. Obtenir la client d'authentification cliente (authorization: Basic Y2xpZW50OnNlY3JldA==)
3. Demander un token oauth
4. Utiliser systématiquement le token oauth (authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....)

Obtenir la client d'authentification cliente¶

1. Retrouver la valeur de la clef, elle est constante (mais à quel horizon ? )
2. La clef d'authentification cliente est visible dans les header Authorization de la requête de login
   

   Authorization: Basic Y2xpZW50OnNlY3JldA==
   

3. Pour la voir, ouvrir les outils développeur de votre navigateur (touche F12), onglet réseau

Demander un token JWT¶

Pour obtenir un jeton JsonWebToken (JWT), il faut faire

    POST  /api/v1/rs-authentication/oauth/token

avec pour paramètres

grant_type=password
username=regards_projet@ias.u-psud.fr
password=XXXXXXX
scope=spire_fts
origineUrl=http://idoc-regards.ias.u-psud.fr/user/spire_fts/modules/52
requestLink=http://idoc-regards.ias.u-psud.fr/user/spire_fts/modules/52?external_auth_action=verify_email

et dans les headers la clef d'authentification cliente

Authorization: Basic Y2xpZW50OnNlY3JldA==

En curl

curl -X POST 'http://idoc-regards.ias.u-psud.fr/api/v1/rs-authentication/oauth/token?grant_type=password&username=regards-admin@c-s.fr&password=root_admin&scope=project1' -H 'Authorization: Basic Y2xpZW50OnNlY3JldA=='

La réponse contient le token access_token

{"access_token":"eyJhbGciOiJIUzI1NiIsInR<....couic...>HHy722UclsY",
"token_type":"bearer",
"expires_in":43199,
"scope":"spire_fts",
"sub":"regards_projet@ias.u-psud.fr",
"role":"PROJECT_ADMIN",
"tenant":"spire_fts",
"jti":"dc68ccbc-ff41-4d47-9eb1-e117d9a7d269"}

Utiliser systématiquement le token oauth¶

Chaque appel REST devra par la suite contenir le header avec la valeur précédente

"Authorization: Bearer ${access_token}" 

dans notre cas

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6Ik....

En curl

curl -i -X GET \
   -H "Authorization:Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6Ik<...couic..>OIvQAk" \
 'http://idoc-regards.ias.u-psud.fr/api/v1/rs-dam/models/attributes/1'

La réponse est de type

{
  "id": 1,
  "name": "dec",
  "description": "dec",
  "defaultValue": null,
  "type": "DOUBLE",
  "unit": "unitless",
  "precision": null,
  "arraysize": null,
  "fragment": {
    "id": 1,
    "name": "default",
    "description": "Default fragment",
    "version": null,
    "defaultFragment": true,
    "identifiable": true
  },
  "alterable": true,
  "optional": true,
  "label": "dec",
  "restriction": null,
  "group": null,
  "properties": [

  ],
  "dynamic": true,
  "jsonPath": "properties.dec",
  "identifiable": true,
  "_links": {
    "self": {
      "href": "http:\/\/idoc-regards.ias.u-psud.fr:80\/api\/v1\/rs-dam\/models\/attributes\/1" 
    },
    "update": {
      "href": "http:\/\/idoc-regards.ias.u-psud.fr:80\/api\/v1\/rs-dam\/models\/attributes\/1" 
    },
    "list": {
      "href": "http:\/\/idoc-regards.ias.u-psud.fr:80\/api\/v1\/rs-dam\/models\/attributes" 
    }
  }
}

Il n'est pas nécessaire de préfixer par le module: il semblerait que
http://idoc-regards.ias.u-psud.fr:4444
permet d'utiliser toutes les APIS