Réduisez le nombre de couches d'architecture de 5 à 2

En travaillant sur plusieurs projets open-source, j'ai décidé un jour de simplifier ma vie et j'ai développé le module Upstream pour nginx, ce qui m'a aidé à supprimer les couches volumineuses de l'architecture multicouche. Ce fut une expérience amusante que je veux partager dans cet article. Mon code est accessible au public ici: github.com/tarantool/nginx_upstream_module . Vous pouvez le récupérer à partir de zéro ou télécharger l'image Docker à partir de ce lien: hub.docker.com/r/tarantool/tarantool-nginx .

Au programme:

• Introduction et théorie.
• Comment utiliser ces technologies.
• Évaluation des performances.
• Liens utiles.

Introduction et théorie

Voici à quoi ressemble l'architecture de microservice standard. Les demandes des utilisateurs parviennent via nginx au serveur d'applications. Il existe une logique métier sur le serveur avec laquelle les utilisateurs interagissent.

Le serveur d'applications ne stocke pas l'état des objets, ils doivent donc être stockés ailleurs. Vous pouvez utiliser des bases de données pour cela. Et n'oubliez pas le cache, qui réduira la latence et accélérera la livraison du contenu.

Divisez-le en couches:

1ère couche - nginx.
2e couche - serveur d'applications.
3ème couche - cache.
4ème couche - proxy de base de données. Ce proxy est nécessaire pour garantir la tolérance aux pannes et maintenir une connexion constante à la base de données.
La 5ème couche est le serveur de base de données.

En pensant à ces couches, j'ai compris comment en exclure certaines. Pourquoi? Il y a plusieurs raisons. J'aime les choses simples et compréhensibles; Je n'aime pas supporter un grand nombre de systèmes différents en production; et enfin et surtout, moins il y a de couches, moins il y a de points de défaillance. En conséquence, j'ai créé le module Tarantool Upstream sous nginx, ce qui a permis de réduire le nombre de couches à deux.



Comment Tarantool aide-t-il à réduire le nombre de couches? La première couche est nginx, les deuxième, troisième et cinquième couches remplacent Tarantool. La quatrième couche, le proxy de base de données, est maintenant dans nginx. L'astuce est que Tarantool est une base de données, un cache et un serveur d'applications, trois en un. Mon module en amont connecte nginx et Tarantool l'un à l'autre et leur permet de fonctionner de manière transparente sans les trois autres couches.



Voici à quoi ressemble le nouveau microservice. L'utilisateur envoie une demande à REST ou JSON RPC dans nginx avec le module Tarantool Upstream. Le module peut être connecté directement à Tarantool, ou la charge peut être équilibrée sur plusieurs serveurs Tarantool. Entre nginx et Tarantool, nous utilisons un protocole efficace basé sur MSGPack. Vous trouverez plus d'informations dans cet article .

Vous pouvez également suivre ces liens pour télécharger Tarantool et le module nginx. Mais je vous conseille de les installer via le gestionnaire de paquets de votre distribution ou d'utiliser l'image Docker ( docker pull tarantool/tarantool-nginx ).

Images Docker: hub.docker.com/r/tarantool/tarantool

Module amont Tarantool NginX

Packages binaires: Tarantool - Télécharger

Code source: Tarantool

tarantool / nginx_upstream_module

Comment utiliser ces technologies

Voici un exemple de fichier nginx.conf. Comme vous pouvez le voir, il s'agit d'un nginx régulier en amont. Ici, nous avons tnt_pass , qui tnt_pass directement tnt_pass nginx dans quel chemin mettre tarantool en amont.

nginx-tnt.conf

 http { # upstream upstream tnt { server 127.0.0.1:3301; keepalive 1000; } server { listen 8081; # gateway location /api/do { tnt_pass_http_request parse_args; tnt_pass tnt; } } } 

Voici les liens vers la documentation:

nginx.org/en/docs/http/ngx_http_upstream_module.html
github.com/tarantool/nginx_upstream_module/blob/master/README.md

Configuré un tas de nginx et Tarantool, alors quoi? Nous devons maintenant enregistrer une fonction de gestionnaire pour notre service et la placer dans un fichier. Je l'ai mis dans le fichier «app.lua».

Voici un lien vers la documentation Tarantool : tarantool.io/en/doc/1.9/book/box/data_model/#index

 -- Bootstrap Tarantool box.cfg { listen='*:3301' } -- Grants box.once('grants', function() box.schema.user.grant('guest', 'read,write,execute', 'universe') end) -- Global variable hello_str = 'Hello' -- function function api(http_request) local str = hello_str if http_request.method == 'GET' then str = 'Goodbye' end return 'first', 2, { str .. 'world!' }, http_request.args end 

Considérez maintenant le code Lua.

Notre Box.cfg {} indique à Tarantool de commencer à écouter sur le port 3301, mais il peut accepter d'autres paramètres.

Box.once dit à Tarantool d'appeler une fonction une fois.

function api () est une fonction que j'appellerai bientôt. Il prend une requête HTTP comme premier argument et renvoie un tableau de valeurs.

J'ai enregistré ce code dans un fichier et l'ai nommé «app.lua». Vous pouvez l'exécuter en lançant simplement l'application Tarantool.

$> tarantool app.lua

Nous appelons notre fonction à l'aide d'une requête GET. J'utilise «wget» pour cela. Par défaut, «wget» enregistre la réponse dans un fichier. Et pour lire les données du fichier, j'utilise «chat».

 $ wget '0.0.0.0:8081/api/do?arg_1=1&arg_2=2' $ cat do* { “id”:0, # — unique identifier of the request “result”: [ # — is what our Tarantool function returns [“first”], [2], [{ “request”:{“arg_2”:”2",”arg_1":”1"} “1”:”Goodbye world!” }] ]} 

Évaluation des performances

L'évaluation a été réalisée sur des données de production. L'entrée est un grand objet JSON. La taille moyenne d'un tel objet est de 2 Ko. Serveur unique, processeur 4 cœurs, 90 Go de RAM, OS Ubuntu 14.04.1 LTS.

Pour ce test, nous utilisons un seul travailleur nginx. Ce travailleur est un équilibreur avec un algorithme ROUND-ROBIN simple. Il équilibre la charge entre les deux nœuds Tarantool. La charge est mise à l'échelle à l'aide du partage.

Ces graphiques montrent le nombre de lectures par seconde. Le graphique supérieur montre les retards (en millisecondes).



Et ces graphiques montrent le nombre d'opérations d'écriture par seconde. Le graphique supérieur montre les retards (en millisecondes)



Impressionnant!

Dans le prochain article, je parlerai en détail de REST et JSON RPC.

Version anglaise de l'article: hackernoon.com/shrink-the-number-of-tiers-in-a-multitier-architecture-from-5-to-2-c59b7bf46c86