Les 8 erreurs de calcul distribué pour les développeurs PHP

Huit malentendus que les développeurs PHP doivent être vigilants dans la construction d'applications distribuées

Peter Deutsch ont proposé sept malentendus sur un autre distribution en 1997, et plus tard James Gosling (le père de Java) en a ajouté un autre. Ces malentendus sont cruciaux pour les développeurs PHP car nous créons chaque jour des applications distribuées: mashup, applications qui interagissent avec les services de savon et de repos, l'authentification des utilisateurs via Facebook, Google ou Twitter, récupérant des informations à partir de bases de données et de services de cache distantes, etc. Ce que nous construisons est une application informatique distribuée. Par conséquent, il est crucial de comprendre ces huit malentendus et leurs implications.

Points clés:

• Huit malentendus de calcul distribué proposés par Peter Deutsch et James Gosling sont cruciaux pour les développeurs de PHP: fiabilité du réseau, une latence zéro, un bandwidth illimité, une sécurité du réseau, une topologie non changée.
• Malgré des améliorations significatives de la fiabilité du réseau et de la bande passante, ces facteurs ne sont pas parfaits. Les développeurs doivent prévoir des échecs potentiels et intégrer des stratégies de traitement correspondantes dans la conception et le déploiement des applications.
• La cybersécurité est toujours un problème important, et les développeurs doivent hiérarchiser les bonnes pratiques de sécurité et évaluer les mesures de sécurité de leurs partenaires. Les développeurs
• doivent être prêts à faire face aux changements de topologie, à la possibilité de changer les fournisseurs et aux coûts associés à la transmission des données. Ils devraient également adopter une approche flexible capable de gérer plusieurs bases de données et sources de données sans supposer que le réseau est isomorphe.

1. Le réseau est fiable

Ceci est évidemment incorrect. Bien que la latence du réseau ait diminué et que la bande passante ait augmenté de manière significative depuis 1995, il est faux de dire que le réseau est fiable. Supposons que nous créons une application simple qui n'utilise pas trop de services - une application PHP qui utilise MySQL comme backend. Il ne semble pas y avoir de problème. Cependant, supposons que nous ayons décidé plus tard d'utiliser un fournisseur d'hébergement MySQL comme Xeround pour répondre à nos besoins de base de données. Même avec une bonne évolutivité et une grande disponibilité, que se passe-t-il s'il y a un problème avec leur système? Et si leur infrastructure est frappée par une attaque DDOS ou a des temps d'arrêt en raison de problèmes internes? Nous entendons souvent environ 99,999% de disponibilité, mais ce n'est toujours pas à 100%. Avec la surtension des services et la bande passante qui est généralement très disponible aujourd'hui, il est facile d'oublier que rien n'est parfait. Comment considérez-vous les échecs de service dans votre application?

2. Le retard est nul

Bien que le retard puisse être très faible, il est en effet beaucoup plus bas qu'il y a quelques années, il ne sera jamais nul. Pour citer Arnon Rotem-Gal-oz dans son article "Explication détaillée des malentendus de calcul distribué": à une vitesse d'environ 300 000 km / s (3,6 * 10e12 Teraangstrom / deux semaines), même si le traitement est effectué en temps réel, le ping d'Europe vers les États-Unis, puis les rendements prendront au moins 30 millierscondes.

Est-ce une mauvaise chose? Mixte. Selon la structure de notre application et les ressources disponibles, nous pouvons considérablement atténuer les problèmes de latence. Nous pouvons héberger nos applications à l'aide de services comme Amazon Web Services et profiter de S3 afin que nos données soient situées dans plusieurs régions du monde, en la rapprochant de nos utilisateurs finaux et en réduisant la latence pour les applications sur le Web. Mais même si nous pouvons réduire la latence, nous ne pouvons pas l'éliminer. Nous pouvons prendre une gamme de méthodes et d'architectures pour réduire son impact sur nous, mais peu importe ce que nous faisons, il sera toujours là. Avez-vous considéré cela lors de la conception de votre application?

3. Bande passante illimitée

La bande passante est-elle vraiment illimitée? Si oui, quel est le prix de l'infini? Lorsque nous considérons que le réseau évolue de plus en plus vers le mobile, tout ce qui est vieux est renaissant. Je ne dis pas que nous avons recommencé avec la vitesse de l'accès à Dial-Up, le réseau 4G mis à jour est beaucoup plus rapide que les réseaux 2G et 3G précédents. Cependant, même leurs débits de données de pointe sont actuellement inférieurs aux connexions à large bande standard. En outre, avec la popularité du haut débit mobile, le nombre d'utilisateurs potentiels cherchant à utiliser nos services (nous voulons tous être populaires, au moins une partie du succès de Facebook) se développe à un rythme alarmant. Considérez ces statistiques de Mobithink:

• Il y a 5,9 milliards d'utilisateurs mobiles.
• 1,2 milliard d'utilisateurs de réseaux mobiles avec couverture 3G.
• Les appareils mobiles représentent 8,49% des clics mondiaux.

Compte tenu de cela, il est juste de dire que si les taux de bande passante et leur pénétration dans le monde augmentent, les taux de croissance des utilisateurs compensent cela. De plus, avec l'énorme flexibilité fournie par le haut débit mobile, la consommation de services temporaires claire a naturellement émergé. Êtes-vous prêt pour une charge potentiellement énorme sur le service? Pouvez-vous gérer les pics causés par cette disponibilité?

4. cybersécurité

Je pense qu'il est juste de dire que c'est, et que ce sera toujours faux, sans trop de détails. Si vous avez des questions, vous devriez peut-être parler à un membre de LinkedIn ou d'Eharmony. Lorsque nous concevons et déployons nos applications, combien d'efforts mettons-nous dans la sécurité dans les emplacements hébergés de l'application (tels que Rackspace, Pagodabox ou CloudControl) et dans la conception de l'application elle-même? Selon SecurityAffairs, reproduction proloxique:

• Le trafic de paquets malveillants ciblant l'industrie des services financiers a augmenté de 3 000% par mois.
• Le nombre de données de trafic malveillant pour l'industrie des services financiers au quatrième trimestre de 2011 était de 19,1 To et 14 milliards de paquets, une augmentation en 2012.
• En 2012, la quantité de données identifiées et atténuées était de 65 To et les paquets de données étaient de 1,1 billion, 80 fois celui de 2011.

Étant donné que le réseau n'est pas sécurisé, nous devons nous assurer que nous utilisons de bonnes pratiques de sécurité en cas de cours. Étant donné la grande quantité de bons conseils du blog de Chris Shiflett, Essential PHP Security, PHP Security Alliance, et plus encore, il est difficile de ne pas savoir comment intégrer la sécurité dans notre noyau d'application et pourquoi. Quelle est votre pratique de sécurité? Avez-vous évalué les fournisseurs que vous avez déployés?

5. La topologie reste inchangée

pas? Vraiment? Cela ne changera pas, ou ne savons-nous tout simplement pas? Lorsque nous hébergeons l'application aux autres, nous ne savons tout simplement pas. Si les fournisseurs reconfigurent leur centre de données, améliorez-le, modifiez-le, la topologie change pour une raison quelconque. Compte tenu de l'augmentation susmentionnée de l'utilisation des smartphones, la topologie change fréquemment. Du point de vue de l'utilisateur et du fournisseur, la topologie change presque tous les jours! Si la topologie change et les services externes dont il dépend ne peut plus accéder, ce qui entraîne, par exemple, l'incapacité d'accéder à la base de données, c'est certainement un problème. Cependant, s'il y a un changement au sein de notre fournisseur et que l'application continue de s'exécuter, ce n'est peut-être pas un problème. Bien sûr, il est facile d'écrire une petite application hébergée en configuration simple. Mais les applications changeront, en particulier celles qui sont de plus en plus populaires. Avez-vous envisagé des changements topologiques dans votre conception? Comment expliquez-vous ou gérez-vous les échecs dans la conception des applications et la conception du déploiement?

6. Un seul administrateur

"Mais mon application est hébergée par un seul fournisseur de services. Ils fournissent une prise en charge du système d'exploitation, de la base de données et du serveur Web", avez-vous déclaré. OK, en supposant que c'est votre application, est-ce vraiment un seul administrateur? S'il n'y avait vraiment qu'un seul administrateur, croyez-vous vraiment que le fournisseur gérerait votre demande? S'ils sont malades ou en vacances, je déteste penser à ce qui se passera. Souvent, il y aura au moins quelques administrateurs, bien que le sens technique et plus large de chaque administrateur puisse varier. Des stratégies, telles que la détection des intrusions de réseau et d'autres politiques de sécurité, doivent être élaborées, mais rien ne garantit qu'elles se conformeront toutes à la même minutie et la même diligence raisonnable. Compte tenu des nombreux fournisseurs d'hébergement disponibles aujourd'hui et du peu de temps qu'il faut pour mettre à jour les enregistrements DNS, nous avons beaucoup d'options et de flexibilité, si un fournisseur ne répond pas à nos besoins et attentes, nous pouvons nous tourner vers un autre. Avez-vous réfléchi à la façon dont cela vous affectera? Et si vous ne pouvez pas facilement changer de fournisseurs? Et si vous avez un grand nombre de verrouillage des fournisseurs ou si le coût mobile est élevé? Et si votre architecture d'application n'est pas assez flexible? Quelles étapes pouvez-vous faire pour atténuer ce type de risque?

7. Le coût de transmission est nul

Comme pour toutes les déclarations jusqu'à présent, la validité de ceci est peu probable. Si les serveurs qui soutiennent nos applications sont situés dans le même rack dans le même centre de données, le coût de transfert peut être considérablement réduit, mais en termes de coûts de temps. Qu'en est-il du coût de l'argent? Oui, nous pouvons évoluer de haut en bas infiniment de manière résiliente selon les besoins, et nous pouvons stocker nos données d'application entre les centres de données géo-dispersés afin qu'il soit aussi proche que possible de nos utilisateurs finaux, mais à quel point est le prix? Quelle est la composition architecturale de votre application ou service? Est-ce proche de zéro en termes de coût ou de temps? Si vous pouvez en réduire un, cela en ajoutera-t-il un autre?

8. Isomorphisme du réseau

Contrairement à d'autres malentendus, je pense qu'en tant que développeurs PHP, nous sommes nés pour comprendre cela. Nous hébergeons nos applications sur les serveurs Windows, Linux, Solaris, BSD et Mac OS X. Nous utilisons MySQL, SQLServer, SQLite, PostgreSQL, MongoDB, Hadoop et Oracle pour stocker des données. Nous utilisons des services externes via XML ou JSON qui nécessitent des interfaces différentes. En tant que système multi-opérant et communauté multi-services, nous pouvons dire que depuis les débuts, nous ne nous sommes jamais attendus d'un réseau isomorphe. Mais la question doit encore être posée, votre méthode est-elle flexible? Pouvez-vous gérer plusieurs bases de données et sources de données? Utilisez-vous des modèles de conception pertinents, tels que des usines abstraites, pour consommer des données provenant de diverses sources et types à l'aide d'interfaces de code transparent? Ou si vous avez besoin de faire quelque chose d'aussi simple que de passer de XML à JSON, votre code se cassera-t-il?

Conclusion

Je pense qu'en tant que développeur PHP, les huit malentendus de l'informatique distribuée sont aussi importants qu'auparavant. Compte tenu de la grande quantité d'informations et de ressources disponibles, nous sommes dans une position très avantageuse pour les comprendre et atténuer les risques qui surviennent. Qu'en penses-tu? Les considérez-vous lors du développement d'applications et de services? Comment pensez-vous que ces huit malentendus affectent votre demande?

(l'image reste inchangée)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!