Twitter

Résumé
Trois développeurs Twitter, Steve Jenson, Alex Payne, et Robey Pointer, parlent avec le projet de loi Venners sur leur utilisation de Scala dans la production sur Twitter.
Twitter est un site à croissance rapide qui fournit un service de micro-blogging. Il a commencé sa vie comme une application Ruby on Rails, et utilise encore Ruby on Rails pour fournir la plupart des pages Web faisant face à l'utilisateur. Mais il ya environ un an, ils ont commencé à remplacer certains de l'arrière-plan des services de Ruby avec des applications fonctionnant sur la JVM et écrit en Scala. Dans cette interview, trois développeurs de Twitter-Steve Jenson, ingénieur système; Alex Payne, API plomb; et Robey Pointer, membre de l'équipe service-asseoir avec le projet de loi Venners pour discuter du monde réel l'utilisation de Twitter de Scala. Ils décrivent les problèmes de production qui les ont amenés à considérer Scala en premier lieu, sur quelles questions ils se heurtèrent à l'aide de Scala dans la production, et comment Scala affecté leur style de programmation.

Un rapide regard sur Twitter

Bill Venners: Qu'est-ce que Twitter, et ce dans son histoire technique qui vous a amené à considérer Scala?

Alex Payne: Twitter est un service de communication qui permet aux gens de partager des informations en 140 caractères ou moins. Vous pouvez partager des informations à partir de votre téléphone, à partir d'un navigateur Web, ou à partir de l'un des nombreux clients de l'API qui sont là, pour à peu près tous les systèmes d'exploitation, plate-forme mobile, ou plate-forme web. Fondamentalement, si vous voulez partager une courte pensée, un à plusieurs, Twitter est un moyen de transport indépendant de le faire. Dans un sens technique plus large, nous nous considérons comme une couche de messages courts pour l'Internet. Nous avons été décrit comme un "télégraphe pour le Web 2.0."

Une des choses qui est au cœur de notre entreprise fournit des API ouvertes pour tout ce que vous pouvez faire sur le site. Donc toutes les fonctionnalités qui est disponible pour les utilisateurs, il est également disponible pour les développeurs d'accéder par programmation. Voilà Twitter en un mot.

Twitter a commencé comme un projet de hack à une société appelée ODEO, qui a été porté sur le podcasting. Comme ODEO était d'avoir quelques problèmes dans ses derniers jours en tant que société, ils ont commencé à expérimenter, à garder ingénieurs impliqués en leur permettant de jouer avec les idées qu'ils avaient sur le côté. Un des ingénieurs, Jack Dorsey, avait été vraiment intéressé par le statut. Il regardait sa liste de contacts AIM, et de voir que tous ces gars disaient: «Je marche le chien", "Je travaille sur cette", "je vais à cela.» Il se demanda si il était d'une certaine façon à la rendre plus facile pour les gens à partager ce statut. Ainsi, lui et un couple d'autres ingénieurs a commencé ce qui est devenu le prototypage Twitter sur Ruby on Rails, qui était la pile qui a été construit sur ODEO. Et Twitter continue aujourd'hui à être principalement une application Rails, avec un tas de démons qui font Ruby traitement asynchrone sur le backend.
Au fil du temps, nous avons constaté que, bien que Rails fonctionne très bien pour faire du développement web front-end, pour faire des poids lourds de traitement back-end, Rails eu quelques limitations de performances lors de l'exécution. Et je pense que, et cela est plus mon opinion-le langage Ruby personnelle manque certaines choses qui contribuent à des informations fiables, le code de haute performance, qui est quelque chose que nous sommes très intéressés à nous sommes de plus en plus comme une entreprise. Nous voulons que le code que nous écrivons pour être correcte et maintenable. Nous voulons garder nos coûts bas-toutes les choses que la plupart des entreprises veulent sortir de leur pile. Voilà pourquoi nous avons commencé à regarder Scala.

L'autre grande raison pour laquelle nous avons regardé Scala était que, même si nous avons un problème avec Ruby, nous aimons la flexibilité de la langue. Nous aimons qu'il est un tel langage très complet, qu'il est amusant de code dans. Il est la même raison tant de gens finissent par écrire Java Ruby après qu'ils laissent une certaine grande entreprise de l'entreprise. Ils veulent avoir amusement jour en jour. Nous ne voulons pas laisser cela derrière et aller à une langue avec une communauté très sec, pragmatique, comme le C ++, par exemple. Nous savons que les gens écrivent du code de la performance très élevée en C ++, et les ingénieurs comme Steve Robey et avons eu l'expérience avec cela. Mais nous voulions être en utilisant un langage que nous sommes vraiment passionné, et il semblait la peine de prendre un pari sur Scala.
Fiable, le code de haute performance

Bill Venners: Je suis curieux, et les gens Ruby voulez qu'il énoncé: Pouvez-vous préciser ce que vous avez ressenti le langage Ruby manquait dans le domaine de la fiabilité, le code de haute performance?

Steve Jenson: Une des choses que je ai trouvé tout au long de ma carrière est la nécessité de disposer de processus à long terme. Et Ruby, comme de nombreux langages de script, a du mal à être un environnement pour les processus à vie longue. Mais la JVM est très bon à cela, parce qu'il a été optimisé pour qu'au cours des dix dernières années. Donc Scala fournit une base pour la rédaction de serveurs à long terme, et qui est essentiellement ce que nous utilisons pour sur Twitter dès maintenant. Une autre chose que nous aimons vraiment de Scala est le typage statique qui est pas douloureux. Parfois, il serait vraiment bien en Ruby à dire des choses comme, voici une annotation de type option. Ceci est le type nous vraiment nous attendre à voir ici. Et nous constatons que vraiment utile à Scala, pour être en mesure de préciser les informations de type.

Robey Pointer: Aussi, Ruby n'a pas encore vraiment bon support de fil. Il est de mieux en mieux, mais quand nous écrivions ces serveurs, fils verts étaient la seule chose disponible. Fils verts ne pas utiliser les threads noyau de l'actuel système d'exploitation. Ils sorte d'émuler les discussions en arrêtant périodiquement ce qu'ils font et de vérifier si un autre «fil» veut courir. Donc Ruby émule les discussions au sein d'un seul noyau ou d'un processeur. Nous voulions tourner sur des serveurs multi-core qui ne possèdent pas une quantité infinie de mémoire. Et si vous ne disposez pas d'un bon soutien de filetage, vous avez vraiment besoin de plusieurs processus. Et parce que le ramasse-miettes de Ruby est pas tout à fait aussi bon que de Java, chaque processus utilise beaucoup de mémoire. Nous ne pouvons pas vraiment courir très nombreux processus démon Ruby sur une seule machine sans consommer de grandes quantités de mémoire. Considérant que, avec l'exécution de choses sur la JVM, nous pouvons fonctionner de nombreux threads dans le même tas, et laisser qu'un processus prend toute la mémoire de la machine pour son aire de jeux.

Alex Payne: Je voudrais certainement envie de marteler ce que Steve a dit à propos de la saisie. Comme notre système a augmenté, beaucoup de la logique dans notre système Ruby sorte de réplique un système de type, soit dans nos tests unitaires ou des validations sur les modèles. Je pense que ce peut juste être une propriété de grands systèmes dans les langages dynamiques, que finalement vous finissez par la réécriture de votre propre système de type, et vous sorte de faire mal. Vous vérifiez les valeurs NULL dans tous les sens. Il ya beaucoup d'appels à Ruby kind_of? Méthode, qui demande: «Est-ce une sorte de l'utilisateur objet? Parce que ce que nous attendons. Si nous ne recevons pas que, cela va exploser. "Il est une honte d'avoir à écrire tout ce que quand il ya une solution qui a existé dans le monde des langages de programmation depuis des décennies.

En complément de Ruby avec Scala

Steve Jenson: Nous trouvons Ruby et Scala sont très complémentaires. Nous utilisons Ruby, Rails fait spécifiquement, pour des choses qu'il est très forte au. Tout à la fin des choses avant qu'il fait très bien.

Bill Venners: Qu'est-ce que vous utilisez pour Scala?

Robey Pointer: Nous avons eu un système de file d'attente basé sur Ruby que nous avons utilisé pour la communication entre les extrémités des rails avant et les démons, et nous avons fini par remplacer que par un écrit en Scala. La seule Ruby a effectivement travaillé assez décemment dans un état ​​stable normal, mais le temps de démarrage et le comportement de l'accident était indésirable. Il était un peu trop lent et gourmand en mémoire. Parfois, nos charges de pointe seraient assommer. Et quand il se est assommé, il était très lent à récupérer, ce qui est ce que nous voulions. Nous voulions quelque chose qui pourrait traiter les cas de pointe et la charge élevée, peut-être pas aussi facilement que d'une charge régulière, mais avec une relative facilité.

Bill Venners: Qu'est-ce que les démons font?

Robey Pointer: Une grande partie de notre architecture est basée sur Rails laissant faire ce qu'il fait le mieux, ce qui est l'AJAX, l'interface web se termine, le site-ce que l'utilisateur voit. Tout ce que nous pouvons décharger sur le cycle de requête / réponse, nous le faisons. Nous avons donc la file d'attente de ces tâches dans un système de messagerie et d'avoir d'arrière-démons gèrent eux.

Steve Jenson: Par exemple, si vous faites un changement à votre graphe social;-à-dire, vous suivez ou désabonner quelqu'un sur Twitter. Tout ce travail et les invalidations de cache associées sont faits de manière asynchrone par un démon.

Bill Venners: Avez-vous envisagé JRuby?

Alex Payne: Nous avons fait. A l'époque nous avons examiné, nous ne pouvions tout simplement pas démarrer notre application Rails sur JRuby. Trop de Gems Ruby que nous faisons usage de exigent extensions C, et n'a pas été porté sur les versions de la JVM de l'environnement. La performance de JRuby était pas non plus, même à égalité avec l'IRM (la mise en œuvre de C de Ruby), beaucoup moins une langue comme Scala. Nous sommes ouverts à essayer JRuby nouveau dans l'avenir, mais nous espérons aussi que certains correctifs Ruby aideront dans l'intervalle.

Compromis avec Scala

Bill Venners: Vous avez eu l'expérience réelle d'Scala, de l'utiliser pour résoudre des problèmes réels. Quels sont les compromis avez-vous avec elle? Quels étaient les problèmes? Quels ont été les bonnes choses? Quels ont été les mauvaises choses?

Steve Jenson: Je pense que cela a fonctionné remarquablement bien pour nous. Beaucoup d'entre nous ont eu la programmation de l'expérience dans les langues qui étaient plus orientés vers la recherche, et ceux qui ont tendance à avoir beaucoup de problèmes en essayant de productionize systèmes. Mais nous ne courons pas vraiment dans un grand nombre de ces questions avec Scala. Nous aimerions rencontrer quelques problèmes, avec les nouveaux éléments du système. Je sais que nous avons rencontré des problèmes avec des acteurs et une grande évolutivité, mais nous étions en mesure de contourner ceux-ci. En règle générale, il a été un système très performant et stable pour nous.

Robey Pointer: Je suis d'accord que les problèmes ont été très minime jusqu'à présent. Certains d'entre elle était juste la nouveauté de la langue et du compilateur. Nous courons parfois dans des erreurs de compilation qui sont mystifier une minute, qui a pris un peu de temps pour comprendre ce que l'erreur réelle était. Certains des bibliothèques de collecte de base à Scala sont pas tout à fait à la hauteur encore. Et apparemment, ils travaillent sur ​​ce droit maintenant.

Bill Venners: pas à la hauteur de quelle manière? Ils ne travaillent pas? Ils ne sont pas rapidement?

Robey Pointer: Je n'a jamais eu de problème avec eux ne fonctionne pas, mais un couple de méthodes n'a pas été écrit d'une manière particulièrement performant, ou il y avait des lacunes dans l'API. Dans certains cas, nous avons juste décidé de creuser vers le bas et utiliser les collections Java de Scala, qui est un grand avantage de Scala, que nous avons cette option.

Alex Payne: Une des premières choses que je travaillais dans Scala ici était un harnais de test pour nos API. Elle enveloppe la bibliothèque Apache HTTP communes et fournit un ensemble d'objets qui représente les ressources reposant sur ​​notre système. La partie la plus difficile a été la commutation juste au-dessus de la mentalité Ruby à la mentalité Scala. Essayer de penser de façon plus fonctionnelle. Essayer de penser plus immuablement. Penser à typage statique pour la première fois depuis plusieurs années. Donc, pour les personnes qui peuvent ne pas avoir autant d'un fond Java et avoir plus d'un arrière-plan dans les langages dynamiques, la période de transition pourrait être un peu plus longtemps pour eux, mais après avoir obtenu de l'autre côté de cela, il est génial. Maintenant, je pense à Scala par défaut plutôt que de penser en Ruby par défaut lorsque je esquissant code.

Bill Venners: Comment avez-apprentissage Scala changer la façon dont vous pensez à la programmation?

Robey Pointer: Je avait aucune expérience fonctionnelle avant d'apprendre Scala autre que Python. Je suis assez familier avec Python. Comme je l'ai appris plus Scala je l'ai commencé à penser de façon plus fonctionnelle que je faisais avant. Quand je commencé, je voudrais utiliser la pour l'expression, qui est très semblable à Python. Maintenant, le plus souvent je me trouve en invoquant la carte ou foreach directement sur ​​itérateurs.

Alex Payne: Je suppose pensais à la concurrence en termes d'acteurs était certainement un commutateur. Je l'avais programmé un peu dans la langue IO. Mais je vraiment comme la mise en œuvre d'acteur de Scala, qui est un peu plus proche de Erlang de d'OI. Cela a été un changement positif.

Steve Jenson: Je suis venu à partir d'un fond de Java, mais je a été également connu en Common Lisp et ML, et il était merveilleux d'utiliser un runtime je connaissais et être en mesure d'utiliser combinators fonctionnels et les bouclages et les fonctions d'ordre supérieur, toutes ces choses que je voulais utiliser davantage dans les systèmes de production. Je suis vraiment heureux avec la façon dont ils travaillent à Scala.

Préoccupations avec Scala

Bill Venners: Si je pense à l'aide de Scala dans un système de production, que dois-je inquiéter? Quelles sont les choses que je dois faire en sorte de travail? Que devrais-je peur?

Alex Payne: Je suis prêt pour quelques heures de bricoler avec votre IDE ou votre éditeur. Il semble encore comme IDE et le soutien de l'éditeur est, peut-être pas à ses premiers balbutiements, mais dans son adolescence difficiles années. Plusieurs d'entre nous utilisent IntelliJ, IntelliJ et 8.1 semble être assez bon quand il vient à l'appui Scala. Le mode Emacs, je sais que Steve utilise, mais l'indentation est un peu bizarre. Soutien TextMate est assez terrible, mais il y avait une discussion sur la liste Scala outils de diffusion sur l'amélioration de cela. Mais cela est une barrière à l'entrée.

Robey Pointer: Si vous n'êtes pas venant du monde Java, si vous venez du monde Ruby ou Python, le cycle de la compilation-déploiement peut être un peu irritant. Il est un monde très différent de mettre en place un environnement de compilation et de déployer les fichiers jar avec de grands scripts qu'elle ne l'est avec Ruby ou Python.

Alex Payne: Le JavaRebel genre d'aide à ce que, une fois que vous obtenez ce que mis en place, il est un peu plus de la, écrire du code, a frappé sauver, exécuté à nouveau certains tests. Vous pouvez vous rapprocher de cela, mais il ya encore une partie du bagage du monde Java, où vous avez à faire tout un tas de configuration avant sur ​​chaque projet. Mais vous avez un ensemble de bonnes conventions, et il devient très facile d'apporter de nouvelles bibliothèques. Vous avez beaucoup de déployer des trucs cuit dans. Il est juste un compromis.

Steve Jenson: Faire en sorte que vous utilisez la mutabilité dans les bons endroits. Commencez avec l'immutabilité, puis utilisez la mutabilité où vous trouverez appropriée. Cela a été une bonne leçon pour nous. La raison pour laquelle vous devriez soucier immuabilité est que si vous utilisez des fils et vos objets sont immuables, vous ne devez pas vous inquiéter à propos de l'évolution des choses ci-dessous vous. Pour nous, ça a été une grande victoire. Nous avons vraiment ne jamais aller à la mutabilité si nous sentons que nous devons un gain de performance supplémentaire.

Robey Pointer: Et le compilateur JIT peuvent apparemment donner quelques avantages de performance importantes aux objets immuables.

Alex Payne: Une autre chose que nous sommes heurtés. Il est certainement un cas particulier, et je ne pense pas qu'il devrait jeter les gens hors, mais nous avons été la construction d'un serveur, appelé Hosebird, pour envoyer la totalité du flux de tweets publics en temps quasi réel à une variété de partenaires sur Internet . Il est donc un système spécialisé. Nous avons intégré dans Scala emballage Jetty, et d'abord nous avons eu un certain nombre d'acteurs à l'intérieur du système: l'un pour tirer des messages hors de notre file d'attente de messagerie interne, et un certain nombre d'autres acteurs qui a représenté des clients. Et au fil du temps que nous avons eu de plus en plus des tests système sur elle, nous avons constaté que les acteurs ne sont pas nécessairement le modèle de concurrence idéale pour toutes les parties de ce système. Certaines parties du modèle de la concomitance de ce système sont encore acteur base. Par exemple, il utilise une bibliothèque memcache que Robey écrit, qui est basé acteur. Mais pour d'autres pièces que nous venons de faire revenir à un modèle traditionnel de filetage Java. L'ingénieur travaillant sur ​​cette question, John Kalucki, juste trouvé qu'il était un peu plus facile à tester, un peu plus prévisible. La bonne chose est, il a fallu minutes pour passer le code qui a été l'acteur basé sur quelque chose de fil basée. Il avait un couple de la recherche et remplace. Donc, il est pas si mal si vous ne les acteurs pour une raison quelconque.

Steve Jenson: Juste pour clarifier, vous parlez récemment sur ​​le déplacement des acteurs à plus du modèle Java 5 de concurrence, comme java.util.concurrent, exécuteurs, des pools de threads?

Alex Payne: Je ne sais même pas si John utilisait des pools de threads sur ce nécessairement. Je pense qu'il faisait toujours un peu la gestion manuelle de fil. Fondamentalement, il était juste en mouvement des acteurs à l'exécution explicitement de nouvelles discussions.

Robey Pointer: je suis tombé sur la même chose dans Kestrel, le système de file d'attente. Je ai commencé avec un acteur pour chaque file d'attente unique. Je trouvais que le travail est si fine grain là qu'il était meilleur à ce petit niveau de simplement utiliser les verrous Java. Acteurs grand travail pour avoir des connexions client, là où il ya un peu de surcharge de travail pour ce que l'acteur est en train de faire, et le code de traitement des demandes des clients est très simple et direct.

Bill Venners: Autre chose que quelqu'un envisage d'utiliser Scala dans le monde réel doit être au courant?

Alex Payne: Je pense que les programmeurs qui avez jamais travaillé avec une langue avec un motif correspondant avant doivent être prêts à faire que cette modification de leurs perceptions sur la programmation. Je parlais à un groupe de la plupart des programmeurs Mac, essentiellement des développeurs Objective-C. Je tentais de leur transmettre ce que une fois que vous commencez à travailler avec pattern matching, vous ne voudrez plus jamais utiliser un langage sans nouveau. Il est une chose commune que le programmeur fait tous les jours. Je dois une collection de choses. Permettez-moi de reprendre certaines aiguilles de cette botte de foin, si son basé sur une classe ou leur contenu, il est un outil puissant. C'est tellement génial.

Robey Pointer: Je voulais parler un peu plus sur le démarrage d'utiliser Scala. Il était certainement pas un choix désinvolte nous avons fait autour de quelques bières une nuit. Nous avons en fait agonisé sur elle pendant un certain temps. Peut-être pas angoissée, mais certainement discuté pendant une longue période. Un des plus gros tirages pour nous de Scala par opposition à une autre langue, était que, une fois que vous commencé à écrire dans un langage de très haut niveau comme Ruby, il peut être difficile et assez ennuyeux pour revenir à un langage de niveau moyen comme Java , où vous devez taper beaucoup de code pour obtenir le même effet. Ce fut vraiment un grand tirage pour nous. Avec Scala nous pourrions encore écrire ce code de très haut niveau, mais être sur la JVM.

Bill Venners: Pourriez-vous préciser ce que vous entendez par la haute et moyenne activité?

Robey Pointer: Je pense comme, plus le niveau de la langue de programmation, moins vous avez à taper pour faire plus. Pour moi, langages comme Ruby, Scala, et Python sont de très haut niveau, parce que vous pouvez écrire quelques lignes de code pour faire ce qui pourrait prendre dix ou vingt lignes de Java, ou 250 lignes en C.

Premiers pas avec Scala

Bill Venners: Que suggérez-vous les gens à commencer avec Scala?

Steve Jenson: Il faut l'essayer. Faire un projet de démarrage. Allez-y.

Alex Payne: Il est grand code sur GitHub. Il ya une communauté grandissante Scala là. David Pollak et le reste des committers de levage ont mis Ascenseur sur GitHub. Cela a été une sorte de catalyseur. Jonas Boner, qui a travaillé sur un tas de systèmes transactionnels de mémoire, une très grande concurrence, des trucs entreprise de back-end, a été la libération de certains de ces trucs sur GitHub. Et je pense que d'ici la fin de l'année, il y aura quelque chose comme cinq livres.

Bill Venners: La semaine dernière, à la rafle les gens JavaPosse parlions de la façon dont ils ont essayé quelque chose de nouveau, et un thème a émergé. Le conseil était d'essayer sur quelque chose que vous aimez, mais pas quelque chose nécessairement critiques de l'entreprise. Quelque chose que vous vous souciez assez sur ce que vous continuez à aller, mais pas quelque chose que si elle échoue, vous pourrez sortir de l'entreprise.

Steve Jenson: Nous l'avons fait sur ​​Twitter. Nous avons commencé par faire une petite expérience, où nous avons servi notre calendrier publique sur Scala. Et cela a fonctionné très bien. Nous avons appris beaucoup de leçons, avons découvert ce que nous avons aimé et ce que nous ne avons pas aimé. Il fonctionne toujours. Il a fonctionné pendant près d'un an.

Alex Payne: Oui, la seule fois où nous avons des problèmes avec elle est lorsque les bases de données sous-jacentes ont réplication horaire. Autre que cela, il ne cesse de fredonner. Et il a été un tel succès que notre plan pour le long terme est de se déplacer de plus en plus de notre architecture en Scala. La grande majorité de notre trafic est demandes de l'API, et nous voulons que la plupart de ceux à être servis par Scala, soit à une couche de cache de bord ou une couche d'applications Web. Espérons que d'ici la fin de 2009, la majorité des des interactions des utilisateurs avec Twitter vont être Scala-alimenté.

Donnez votre avis

Avoir une opinion sur les idées présentées dans cet article? Vous pouvez discuter de cet article dans les articles Forum Sujet, Twitter sur Scala.

Ressources

Twitter est ici:
http://twitter.com

La page d'accueil de Ruby: http://www.ruby-lang.org

La page d'accueil de Scala: http://www.scala-lang.org

Alex Payne est co-auteur avec Dean Wampler du livre de programmation Scala, qui devrait être publié sous forme imprimée en Août 2009, et disponible dès maintenant comme un O'Reilly "Rough Cut" PDF ici: http://oreilly.com/catalog/9780596157746 /

Le seul livre Scala aujourd'hui disponible sous forme imprimée est de programmation Scala, coécrit par Martin Odersky (le concepteur de Scala), Lex Spoon, et Bill Venners: http://www.artima.com/shop/programming_in_scala

Pour un bon aperçu de ce que la programmation Scala est tout au sujet, regarder la sensation de Scala vidéo Parleys.com: http://tinyurl.com/dcfm4c

A propos de l'auteur

Bill Venners est président d'Artima, Inc., éditeur de Artima développeur (www.artima.com). Il est l'auteur du livre, l'intérieur de la machine virtuelle Java, une enquête axée sur le programmeur de l'architecture et internes du plate-forme Java. Ses colonnes populaires dans le magazine JavaWorld couverts internes Java, conception orientée objet, et Jini. Active dans la communauté Jini depuis sa création, le projet de loi a conduit le projet de ServiceUI de la Communauté Jini, dont l'API ServiceUI est devenu le moyen standard de facto pour associer des interfaces utilisateur aux services Jini. Le projet de loi est également le développeur principal et concepteur de ScalaTest, un outil open source de test pour les développeurs Java et Scala, et co-auteur avec Martin Odersky et Lex Spoon du livre, Programmation en Scala.