Qu'est-ce que Razor ?

Razor est un ensemble de composants logiques Ruby résolvant des contraintes de haute performance et de scalabilité horizontale

De part sa conception, le framework Razor repose sur une architecture facilitant la distribution de taches sur plusieurs machines. En effet, chaque requête est traitée par un serveur appelé le frontend (Middleware Rack). Le Frontend, après une analyse de sécurité et un traitement minimaliste afin d'absorber le maximum de charge sur de très cours instants, pousse les requêtes dans une queue partagée par différents autres systèmes (les workers).

Au niveau du backend, des Workers animés par le code utile (c'est à dire votre application) prennent en charge à leur tour les requêtes afin de générer les responses. Chaque worker est indépendant et peut être positionné sur une même machine ou sur plusieurs.
Le développement des workers est facilité par l'intermédiaire d'un framework événementiel (un peu comme Sinatra) et MVC (proche de Rails).

Pour l'instant nous considérons Razor au stade de PoC (Proof of Concept).
En effet, il est encore nécessaire d'apporter des enrichissements techniques ainsi que de durcir le code, notamment au niveau des tests. Nous ne conseillons pas de l'utiliser en production.

Architecture globale de Razor

Avantages

Le principal avantage de cette approche réside dans la capacité du système global à pouvoir évoluer de manière horizontale en augmentant le nombre de machines destinées à traiter les requêtes. Ces machines peuvent être relativement « petites » car plus économiques.

De plus, la gestion de la charge peut être très facilement gérée au niveau des workers.
Par exemple, pour un site e-commerce, si certaines actions sont plus demandées et plus groumandes que d'autres, il est possible d'assigner, temporairement ou non, plus ou moins de workers à ces taches.

Au niveau du développement, Razor repose sur des principes MVC et événementiels ainsi que des tests unitaires. Chaque Worker charge l'application conçue par ces approches.

Razor est principalement destiné au développement d'applications web modernes nécessitant une montée en charge progressive ou explonentielle grâce à l'ajout de marchines ayant des performances limitées. Cette solution est à l'opposée de l'approche traditionnelle visant à assurer le maintien de la charge par le gonflement de capacités matérielles (augmentation de la RAM, disque dure SSD, etc.).

Razor peut aussi être très utile pour le développement d'applications web reposant sur des API et des approches REST.

Exemple de code

# un controlleur et ses actions
class SayController
  def index
    "Hello World !"
  end
  def hello
    name = params[:name] || 'World'
    haml 'say/hello', {name: name} # les vues peuvent être du Haml
  end
end

Installation

# gem install razor

Fonctionnement logique

  1. Le flux HTTP arrive sur le serveur Rack qui transmet chaque requête à la chaine de Middleware
  2. Le middleware « RequestsProcessor » prend en charge la requête. Celui-ci traite la requête afin de la traduit en JSON puis la pousse dans la Queue correspondante. En paralèlle, la main est donnée au middleware suivant. Le ResponsesProcessor va se mettre en attende de la réponse par l'écoute de la queue des réponses.
  3. Les Workers écoutent la Queue des requêtes. Un Worker disponible va recevoire une requête envoyée par le RequestsProcessor puis la déléguer à l'Application par l'intermédiaire d'une table de routage. L'application fait ce qui est nécessaire pour renvoyer la réponse.
  4. La réponse est transmise au Worker qui la pousse dans la Queue des réponses.
  5. Le ResponsesProcessor, en écoute d'une réponse, la transmet à la chaine de middleware. Sinon, un timeout est déclanché si aucun worker n'a su répondre dans les temps.

Technologies

Le frontend de Razor repose sur un serveur Rack. La puissance de Rack facile l'intégration des applications au sein de technologies du standardisées (apache, ngnix, etc.).
Redis facilite le partage d'informations entre les différents systèmes en prenant en charge par exemple la queue et les sessions http.