Je cherchais une explication sur la raison pour laquelle twitter devait migrer une partie de son middleware de Rails vers Scala. Ce qui les a empêchés de s’adapter à la stratégie de Facebook en ajoutant des serveurs au fur et à mesure de l’élargissement de sa base d’utilisateurs. Plus précisément, qu’en est-il de la technologie Ruby / Rails qui a empêché l’équipe de twitter d’adopter cette approche?
Réponses
Trop de publicités?
Ce n'est pas que les Rails ne sont pas à l'échelle, mais plutôt, de demandes de "vivre" en Ruby (ou de tout langage interprété) ne sont pas à l'échelle, car ils sont comparativement beaucoup plus cher à la fois en termes de PROCESSEUR et l'utilisation de la mémoire de leur langage compilé homologues.
Maintenant, étaient Twitter un autre type de service, celui qui a eu le même énorme base d'utilisateurs, mais a servi de données qui a changé moins souvent, Rails de pourrait être une option viable via la mise en cache; c'est à dire en évitant les demandes en direct à la pile Rails entièrement et de déchargement de serveur frontal et/ou en mémoire DB cache. Un excellent article sur ce sujet:
Comment Basecamp Prochaine obtenu d'être si sacrément rapide
Cependant, Twitter n'a pas de fossé Rails pour des questions d'échelle seul, ils ont fait le changement, car Scala, comme une langue, fournit un certain nombre de garanties sur l'état de votre application que les langages ne peuvent pas fournir: si il compile, le temps de gaspiller des bugs tels que les lipides-les doigts de fautes de frappe, incorrect appels de méthode, de type incorrect déclarations, etc. ne peut tout simplement pas exister.
Pour Twitter TDD n'était pas assez. Une citation de Dijkstra dans la Programmation Scala illustre ce point: "le test ne peut prouver la présence d'erreurs, de ne jamais leur absence". Que leur demande a augmenté, ils ont couru de plus en plus difficile à traquer les bugs. Le magical mystery tour était en train de devenir un obstacle au-delà de la performance, de sorte qu'ils fait le commutateur. Par tous les comptes, un immense succès, Twitter est à la Scala de ce que Facebook est à PHP (bien que Facebook utilise leurs propres ultra-rapide de C++ préprocesseur donc tricher un peu ;-))
Pour résumer, Twitter fait le passage pour les performances et la fiabilité. Bien sûr, les Rails a tendance à être à l'avant-garde de l'innovation, de sorte que le 99% des non-Twitter niveau de victimes de la traite des applications du monde peut s'en sortir très bien avec un langage interprété (même si, je suis maintenant solidement sur le langage compilé côté de la barrière, la Scala est juste trop bon!)
Will Hughes
Points
5058
Pas de plate-forme de l'infini à l'échelle tout en traitant avec des ensembles complexes de données qui changent d'instant en instant. La langue et les questions liées aux infrastructures, mais la façon dont vous construisez votre site et l'accès aux données des modèles plus d'importance.
Si vous avez déjà joué à des jeux comme le Transport Tycoon ou des Colons où vous devez transporter les ressources autour de vous, vous savez combien vous avez besoin pour rester au top de mise à niveau des infrastructures que l'utilisation augmente.
Mise à l'échelle des plates-formes comme Facebook et Twitter est une tâche constante. Vous avez un nombre toujours croissant d'utilisateurs, et vous êtes poussé à ajouter plus de fonctionnalités et de fonctionnalités. C'est un processus continu de mise à niveau d'un bit, ce qui provoque plus de stress sur un autre bit.
Jeter des serveurs sur le problème n'est pas toujours la réponse, et peut parfois causer plus de problèmes.
Daniel Pittman
Points
7394
http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster des liens vers un ensemble de postes sur les changements, y compris un décent de l'histoire des mesures prises au fil du temps.
La version courte est que Ruby et Rails de ne pas offrir les performances et la fiabilité requises pour le service. Compte tenu de l'échelle, ce n'est pas étonnant; la plupart des LITS solutions ne sont pas satisfaisantes à la super-grande extrémité de l'échelle.
Une grande Évolutivité, couvre beaucoup de questions à propos de l'architecture à l'extrémité supérieure, pour les autres sites, ce qui permet de répondre à des questions plus vastes dans le domaine de trop.
sosborn
Points
11273
Ils auraient pu utiliser plus de matériel, mais c’est beaucoup plus cher que d’écrire du code plus efficace. Comme beaucoup de frameworks de haut niveau, Ruby on Rails est excellent à bien des égards, mais la haute performance n'en fait pas partie. Les langages compilés seront toujours plus rapides que les langages interprétés.
Blankman
Points
35697
Facebook (et Google) à l'échelle par l'ajout de serveurs, mais en même temps, ils cassent leur application dans les différents services. Ces services communiquent via un accord sur l'interface et le type, et ils sont maintenant libres de construire ces services dans n'importe quelle technologie ils l'entendent. Juste parce que vous avez lu que facebook utilise php ne veut pas dire que tous les services principaux sont servis par php (et ça n'a pas de sens puisque, dans SOA vous pouvez choisir n'importe quelle technologie de la pile).
Je pense que cette vidéo est la meilleure réponse à votre question:
"De Ruby à la JVM" https://www.youtube.com/watch?v=ohHdZXnsNi8
