Ruminations sur des architectures côté serveur distribuées hautement évolutives et modulaires

Question

La mienne n'est pas vraiment une question, c'est plutôt un appel à l'opinion - et ce n'est peut-être même pas le bon endroit pour le publier. Néanmoins, la communauté ici est très informée, et il n'y a pas de mal à essayer ...

Je pensais à des façons de créer une architecture back-end hautement modulaire et, surtout, hautement modulaire. Par exemple, un écosystème dorsal complet pour un grand site qui pouvait potentiellement évoluer dans un site massif. Cela impliquerait un très haut degré de séparation des préoccupations, dans la mesure où non seulement la base de données pourrait être remplacée (par exemple d'Oracle à MySQL), mais la base de données pourrait être remplacée (ed SQL à KV, ou vice versa).

J'envisage une situation où chaque sous-système expose sa propre API dans l'écosystème dorsal. De cette façon, l'API pourrait rester constante, tandis que la mise en œuvre pourrait changer (même radicalement) au fil du temps.

Le système doit être hétérogène en ce sens qu'il n'est pas lié à un langage spécifique. Il doit pouvoir accueillir des modules ou des sous-systèmes entiers utilisant des langues différentes.

Il m'est alors apparu que ce que j'imaginais était simplement l'architecture de la toile elle-même. Voici donc mon point de discussion: outre l'utilisation de protocoles (principalement) textuels, il existe une raison impérieuse pour laquelle une architecture back-end complexe ne devrait pas être implémentée de la manière que je décris, ou y a-t-il Pourquoi ne pas utiliser des protocoles de communication tels que Twisted, AMQP, Thrift, etc.? A la suite d'un commentaire de @meagar, je devrais peut-être reformuler la question: les avantages évidents d'utiliser une architecture très simple, flexible et bien comprise (c'est-à-dire toutes les fonctionnalités exposées en tant qu'API RESTful) suffisent-ils à compenser la baisse de performance évidente encourue lors de l'utilisation de cette architecture dans un contexte back-end?

Answer 1

[code] le type de base de données réelle pourrait être remplacé (ed SQL à KV, ou vice-versa). [/ Code]

Et tous ceux qui ont écrit une jointure entre deux tables sera triste. Si vous voulez que la "capacité" passe en KV, vous ne devriez pas exposer une API plus riche que ce que KV peut supporter.

La réponse à votre question dépend de ce que vous essayez d'accomplir. Vous voulez garder chaque module dans des limites raisonnables. Utilisez une superposition physique de code, utilisez des interfaces définies avec des contrats à effets secondaires, utilisez des scénarios de test pour chaque cas de réussite et d'échec de chaque interface. De cette façon, vous pouvez compter sur des choses comme "lorsque l'utilisateur entre dans la page blah, un fait utilisateur-blah est généré de sorte que tous les écouteurs de faits enregistrés seront invoqués." Cela vous permet d'étendre le système sans avoir d'appels directs du point A au point B, tout en conservant un certain contrôle sur les dépendances très disparates. (Je déteste les bases de code où vous ne pouvez pas trouver-tout pour trouver toutes références possibles à un symbole!)

Cependant, le fait que nous avons mis beaucoup de code et des classes en un seul système parce que l'appel entre les systèmes est souvent très, très cher. Vous voulez penser en termes de modules de code faisant des demandes de l'un l'autre où vous le pouvez. La différence de temps entre un appel de fonction et un appel REST est quelque chose comme un à un million (peut-être vous pouvez l'obtenir aussi bas que un à dix mille, si vous ne comptez que les cycles, pas le temps de l'horloge) sûr).En outre, tout ce qui se passe sur un fil dans un centre de données peut potentiellement souffrir d'une perte de paquets, car il n'existe pas de centre de données 100% sans perte, quel que soit le niveau de difficulté. La perte de paquets signifie des pointes de latence aléatoires dans le temps de réponse pour votre application.