Architecture d'une application Facebook pour Windows Azure
•Transferir como PPTX, PDF•
1 gostou•399 visualizações
Illustration concrète de l’apport de Windows Azure pour l’architecture d’une application Facebook, principalement du point de vue de sa montée en charge.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Architecture d'une application Facebook pour Windows Azure
Semelhante a Architecture d'une application Facebook pour Windows Azure (20)
Mais de Thomas Conté
Mais de Thomas Conté (13)
Architecture d'une application Facebook pour Windows Azure
- 1. Windows Azure Architecture d’une application Facebook Thomas Conté, tconte@microsoft.com twitter.com/tomconte Architecte Windows Azure
- 2. Les frameworks Facebook Le Facebook C# SDK sur CodePlex est régulièrement mis à jour Le Windows Azure Toolkit for Social Games est spécifiquement dédié aux développeur de jeux sociaux, très populaires bien sûr sur Facebook Le concours “Pitch Your Social App” a permis à 5 startup françaises de pitcher leurs Social Apps lors du « Facebook Start Up Day »
- 3. Le cas d’usage Une application Facebook est généralement constituée de deux grandes parties: une interface Web intégrée au sein d’une Fan Page une partie applicative fournissant effectivement un service ou un traitement. L’application va identifier l’utilisateur, puis effectuer un traitement long à l’aide de l’Open Graph (i.e. récupérer une liste des Likes ou autres informations, et produire quelque chose d’intéressant comme une animation, une visualisation, etc.) Typiquement le principe d’applications comme Museum of Me, par exemple.
- 4. L’architecture L’on va séparer le rôle “Web” et le rôle “applicatif” (appelé “Worker” dans Windows Azure). Cela permettra de les faire évoluer indépendamment par ajout d’instances lors de la montée en charge. L’on va orchestrer les traitements de façon asynchrone à l’aide d’une file d’attente (les Queues, fournies par Windows Azure). Le navigateur va lui aussi adopter ce même modèle asynchrone: il ne va pas attendre du serveur Web une réponse immédiate, il va aller chercher son résultat (typiquement par polling) dans un stockage lui aussi fourni par Windows Azure. L’on pourrait bien entendu utiliser des Tables pour ce dernier point, mais étant donné que la partie asynchrone côté navigateur sera implémentée en JavaScript, il paraît encore plus naturel d’utiliser le Blob Storage, dans lequel la réponse prendra la forme d’un bloc JSON directement utilisable.
- 5. ② Web Role Web Role queue ① WorkerRole WorkerRole ④ ⑤ ⑥ ③ Blob Storage
- 6. Polling & Blob Storage Une remarque qui revient souvent est que les “transactions”, autrement dit les accès au Blob Storage sont payants, et qu’il conviendrait donc d’éviter une stratégie à base de polling qui risque de coûter cher… Exemple sur un traitement de 3 minutes: intervalle de polling de 1 seconde Donc 180 accès au Blob Storage. En mode “pay-as-you-go”, les transactions de Storage sont facturées 0,01 dollars pour 10.000 transactions. Nos 180 accès vont donc nous coûter 0.00018 dollars, ce qui ne paraît pas onéreux. Si l’on multiplie par 1 million d’utilisateurs par jour, le coût total arrive à 180 dollars par jour. L’expérience montre que ce coût est et restera proportionnellement très inférieur aux autres coûts liés au succès de l’application, typiquement la bande passante.
- 7. Merci!
Notas do Editor
- 1 – Le navigateur demande la page.Le Web Rôle va typiquement pouvoir délivrer plusieurs pages de pur contenu, et va utiliser par exemple le Facebook C# SDK pour demander l’autorisation à l’utilisateur d’accéder à ses informations de profil.2 – Le Web Role écrit la requête dans une file d’attente, puis retourne immédiatement une page d’attente au navigateur.Lorsque le navigateur requête l’action ou la page nécessitant un traitement, le Web Rôle se contente d’écrire cette requête (par exemple accompagnée de l’ID de l’utilisateur ainsi que son token permettant d’accéder à la Graph API) dans une file d’attente, fournie par Windows Azure sous la forme de Queue.A partir de ce moment, le Web Role est complètement déchargé de toute responsabilité, et peut donc continuer à servir le reste de l’expérience Facebook (les autres pages, les contenus, etc.)3 – Le navigateur polle le Blob Storage en attente d'un résultat (typiquement un bloc JSON).Le Web Rôle envoie au navigateur une page d’attente avec une jolie animation et un petit bout de JavaScript qui va régulièrement essayer d’aller chercher le résultat du traitement directement dans le Blob Storage, à l’aide du clef commune (par exemple l’ID de l’utilisateur).4 – C’est maintenant les WorkerRoles qui prennent la main; ils pollent la file d’attente et trouvent une unité de travail à effectuer.Le message doit contenir toutes les informations dont a besoin le WorkerRole (dans notre cas, le tokenOAuth provenant de l’authentification).5 – Un WorkerRole prend possession du message et effectue un traitement long (utilisation de la Graph API, etc.)Dans notre exemple, les Workers accèdent à la Graph API de Facebook au nom de l’utilisateur, récupèrent les données dont ils ont besoin, puis effectuent un traitement, si nécessaire en utilisant du stockage comme les Tables ou SQL Azure.6 – Une fois le traitement terminé, le WorkerRole écrit un résultat final sous la forme d’un fichier JSON directement dans le Blob Storage.Cet objet JavaScript peut soit contenir l’ensemble des informations nécessaires à l’affichage, soit un pointeur vers d’autres ressources (images, etc.)7 – Le navigateur récupère le traitement et peut afficher le résultat final.Pendant ce temps, notre brave navigateur a continué d’accéder au Blob Storage en attendant sa réponse; dès qu’il a récupéré le Blob JSON, il peut lancer l’affichage.