Préface
Afin de résoudre les divers problèmes abordés par le modèle de développement Web traditionnel, nous avons fait de nombreuses tentatives, mais en raison de l'écart physique entre les extrémités avant et arrière, les solutions que nous avons essayées sont similaires. Apprenant de la douleur, nous repensons aujourd'hui la définition de "avant et arrière" et introduisons les Nodejs, qui sont familiers aux étudiants frontaux, essayant d'explorer un tout nouveau mode de séparation frontale.
Avec la montée en puissance de différents terminaux (PAD / Mobile / PC), les développeurs ont des exigences de plus en plus élevées. La réactivité du côté du navigateur pur ne peut plus répondre aux exigences élevées de l'expérience utilisateur. Nous devons souvent développer des versions personnalisées pour différents terminaux. Afin d'améliorer l'efficacité du développement, la nécessité de séparation des extrémités avant et arrière est de plus en plus valorisée. Le back-end est responsable des interfaces commerciales / données, le frontal est responsable de la logique d'affichage / d'interaction, et nous pouvons personnaliser et développer plusieurs versions de la même interface de données.
Ce sujet a beaucoup été discuté récemment, et certains bus Alibaba font également des tentatives. Après une longue discussion, notre équipe a décidé d'explorer un ensemble de schéma de séparation frontale et de back-end basé sur NodeJS. Il y avait des compréhensions et des pensées changeantes dans le processus. Je l'ai enregistré ici. J'espère également que les étudiants que j'ai vus ont participé à la discussion et nous ont aidés à l'améliorer.
1. Qu'est-ce que la séparation frontale?
Au cours de la discussion initiale au sein du groupe, j'ai constaté que tout le monde avait une compréhension différente de la séparation frontale. Afin de s'assurer qu'ils peuvent discuter sur le même canal, nous parviendrons d'abord à un accord sur la "séparation du front-back".
Un exemple de séparation frontale avec laquelle tout le monde est d'accord est Spa (application à une page). Toutes les données de présentation utilisées sont fournies par le backend via l'interface asynchrone (AJAX / JSONP), et le frontal l'affiche uniquement.
Dans un sens, SPA atteint la séparation frontale, mais il y a deux problèmes avec cette méthode:
Parmi les services Web, SPA représente une très faible proportion. Dans de nombreux scénarios, il existe également un mode hybride synchrone / synchrone + asynchrone, et SPA ne peut pas être utilisé comme solution générale.
Dans le modèle actuel de développement de SPA, l'interface est généralement fournie en fonction de la logique de présentation. Parfois, afin d'améliorer l'efficacité, le backend nous aidera à gérer une logique de présentation, ce qui signifie que le backend est toujours impliqué dans le travail de la couche de vue, et non la véritable séparation des avant-fonds.
La séparation frontale de style spa se distingue de la couche physique (pensez que tant qu'elle est le client, le front-end et le back-end est le serveur). Cette classification ne peut plus répondre à nos besoins de séparation frontale. Nous pensons que ce n'est qu'en divisant les responsabilités que nous pouvons répondre à nos scénarios d'utilisation actuels:
Front-end: responsable des couches de vue et de contrôleur.
Backend: uniquement responsable de la couche de modèle, du traitement des entreprises / données, etc.
Pourquoi cette division des responsabilités sera-t-elle discutée plus tard.
2. Pourquoi devrions-nous séparer les extrémités avant et arrière?
En ce qui concerne ce problème, l'article de Yu Bo l'explique de manière très globale dans l'évolution du modèle de R&D Web. Prenons brièvement le réviser:
2.1 Scénarios applicables pour les modèles de développement existants
Les modèles de développement mentionnés par Yu Bo ont chacun leurs propres scénarios applicables, et aucun d'entre eux ne remplace complètement l'autre.
Par exemple, pour MVC, qui est principalement basé sur le backend, il est très efficace d'effectuer une entreprise d'affichage synchrone, mais lors de la rencontre d'une page synchrone et asynchrone, il sera plus difficile de communiquer avec le développement du backend.
AJAX est le principal modèle de développement de spa, qui convient plus pour développer des scénarios de type application, mais il est uniquement adapté à la création d'applications, car le référencement et d'autres problèmes sont difficiles à résoudre. Pour de nombreux types de systèmes, cette méthode de développement est également trop lourde.
2.2 Les responsabilités avant et arrière ne sont pas claires
Dans les systèmes avec une logique métier complexe, nous avons le plus peur de maintenir le code mélangé aux extrémités avant et arrière. Parce qu'il n'y a pas de contrainte, le code des autres couches de MVC peut apparaître dans chaque couche. Au fil du temps, il n'y a aucun entretien.
Bien que la séparation des extrémités avant et arrière ne puisse pas résoudre ce problème, elle peut être grandement atténuée. Parce qu'il est garanti d'un niveau physique que vous ne pouvez pas le faire.
2.3 Problèmes d'efficacité de développement
Le Web de Taobao est essentiellement basé sur le MVC Framework WebX, et l'architecture détermine que le frontal ne peut s'appuyer que sur le back-end.
Notre modèle de développement est donc toujours que le front-end écrit des démos statiques et que le back-end les traduit en modèles VM. Je ne parlerai pas du problème avec ce modèle, et je suis critiqué depuis longtemps.
Il est également douloureux de se développer directement en fonction de l'environnement back-end, et il est difficile de configurer, d'installer et d'utiliser. Afin de résoudre ce problème, nous avons inventé divers outils, tels que VMarket, mais le front-end doit toujours écrire des machines virtuelles et compter sur des données arrière, donc l'efficacité n'est toujours pas élevée.
De plus, le backend ne peut pas se débarrasser de la forte focalisation sur l'affichage et donc la concentration sur le développement de la couche logique métier.
2.4 Limites des performances frontales
Si l'optimisation des performances ne se fait que sur l'avant, nous avons souvent besoin d'une coopération backend pour créer des étincelles. Cependant, en raison des limites du cadre backend, il est difficile pour nous d'utiliser la comète, le bigpipe et d'autres solutions techniques pour optimiser les performances.
Afin de résoudre certains des problèmes mentionnés ci-dessus, nous avons fait de nombreuses tentatives et développé divers outils, mais il n'y a jamais eu beaucoup d'amélioration, principalement parce que nous ne pouvons utiliser le petit morceau d'espace divisé par nous dans le backend. Ce n'est qu'en séparant vraiment les extrémités avant et arrière que nous pouvons résoudre complètement les problèmes ci-dessus.
3. Comment séparer les extrémités avant et arrière?
Comment séparer les extrémités avant et arrière? En fait, il y a une réponse dans la première section:
Front-end: responsable des couches de vue et de contrôleur.
Backend: responsable de la couche de modèle, du traitement des entreprises / données, etc.
Imaginez simplement, si le front-end maîtrise le contrôleur, nous pouvons faire la conception d'URL, nous pouvons décider de synchroniser le rendu sur le serveur en fonction de la scène ou de produire des données JSON en fonction des données de la couche de vue, et nous pouvons également facilement faire BigPipe, comète, socket, etc. Selon les besoins de la couche de présentation. Il s'agit entièrement de la méthode d'utilisation déterminée par les exigences.
3.1 Développement de "pile complète" basé sur les nodejs
Si vous souhaitez implémenter la superposition de la figure ci-dessus, vous aurez inévitablement besoin d'un service Web pour nous aider à réaliser ce que nous faisons avant et après le backend, il y a donc le titre de "développement complet basé sur Nodejs"
Cette image semble simple et facile à comprendre, mais ne l'a pas essayée et il y aura beaucoup de questions.
En mode SPA, le backend a fourni l'interface de données requise et le frontend de vue peut déjà être contrôlé. Pourquoi ajouter la couche NodeJS?
Que diriez-vous d'ajouter une couche de plus?
L'ajout d'une couche supplémentaire augmentera la charge de travail de la fin frontale?
L'ajout d'une couche supplémentaire entraînera une autre couche de risque. Comment le casser?
Nodejs peut faire n'importe quoi, pourquoi avez-vous toujours besoin de Java?
Il n'est pas facile d'expliquer clairement ces problèmes. Permettez-moi de parler de mon processus de compréhension ci-dessous.
3.2 Pourquoi ajouter une couche de nodejs?
À ce stade, nous développons principalement le modèle MVC backend. Ce modèle entrave sérieusement l'efficacité du développement frontal et empêche le back-end de se concentrer sur le développement commercial.
La solution consiste à permettre au frontal de contrôler la couche de contrôleur, mais il est difficile de le faire sous le système technologique existant, car il est impossible de laisser tous les frontaux apprendre Java, d'installer l'environnement de développement back-end et d'écrire des machines virtuelles.
NodeJS peut très bien résoudre ce problème. Nous pouvons faire ce que le développement nous a aidés auparavant, et tout semble si naturel.
3.3 Problèmes de performance
La superposition implique une communication entre chaque couche et il y aura certainement certaines pertes de performances. Cependant, une stratification raisonnable peut rendre les responsabilités claires et collaboratives, ce qui améliorera considérablement l'efficacité du développement. Les pertes causées par la stratification seront certainement compensées dans d'autres aspects.
De plus, une fois que nous décidons de nous attacher, nous pouvons minimiser les pertes en optimisant des méthodes de communication et des protocoles de communication.
Par exemple:
Une fois que la page Taobao Baby Détails est statique, il y a encore beaucoup d'informations qui doivent être obtenues en temps réel, telles que la logistique, les promotions, etc. Parce que ces informations se trouvent dans différents systèmes commerciaux, le front-end doit envoyer 5 ou 6 demandes asynchrones pour rembourser ces contenus.
Avec les nodejs, le front-end peut proxy ces 5 demandes asynchrones dans NodeJS et peut facilement faire BigPipe. Cette optimisation peut améliorer beaucoup l'efficacité du rendu.
Vous pouvez penser qu'il est normal d'envoyer 5 ou 6 demandes asynchrones sur le PC, mais du côté sans fil, il est très coûteux d'établir une demande HTTP sur le téléphone mobile du client. Avec cette optimisation, les performances sont plusieurs fois améliorées.
Les détails de Taobao sont basés sur l'optimisation de NodeJS. Nous sommes en cours. Après son lancement, je partagerai le processus d'optimisation.
3.4 La charge de travail frontale a-t-elle augmenté?
Par rapport à la simple coupe des pages / démos, ce doit être un peu plus, mais il y a des liens et des communications dans le mode actuel. Ce processus prend beaucoup de temps, est sujet aux bugs et est difficile à maintenir.
Par conséquent, bien que la charge de travail augmente un peu, l'efficacité globale de développement sera considérablement améliorée.
De plus, les coûts de test peuvent être beaucoup économisés. Les interfaces développées dans le passé sont toutes destinées à la couche de présentation, et il est difficile d'écrire des cas de test. Si la séparation avant et arrière est effectuée, même le test peut être séparé. Un groupe de personnes se spécialise dans le test de l'interface et l'autre groupe de personnes se concentre sur le test de l'interface utilisateur (cette partie du travail peut même être remplacée par des outils).
3.5 Comment contrôler les risques apportés en ajoutant la couche de nœud?
Avec l'utilisation à grande échelle du nœud, les étudiants du service du système / de l'opération et de la maintenance / de la sécurité se joindront certainement à la construction de l'infrastructure. Ils nous aideront à améliorer les problèmes possibles dans chaque lien et à assurer la stabilité du département.
3.6 Le nœud peut faire n'importe quoi, pourquoi avez-vous toujours besoin de Java?
Notre intention d'origine est de séparer les extrémités avant et arrière. Si nous considérons ce problème, il sera un peu contraire à notre intention initiale. Même si nous utilisons le nœud pour remplacer Java, nous ne pouvons garantir que nous ne rencontrerons aucun problème que nous rencontrons aujourd'hui, comme des responsabilités peu claires. Notre objectif est de se développer de manière en couches, de professionnels et de se concentrer sur les choses professionnelles. L'infrastructure basée sur Java est déjà très puissante et stable, et est plus adaptée à faire ce qui est maintenant l'architecture.
4. Séparation frontale basée sur le nœud de Taobao
L'image ci-dessus est ce que je comprends sur la séparation et la superposition frontale de Taobao et la superposition en fonction du nœud, ainsi que la portée des responsabilités du nœud. Une brève explication:
Le haut de gamme est le serveur, ce que nous appelons souvent le backend. Pour nous, le backend est une collection d'interfaces et le serveur fournit diverses interfaces à utiliser. Parce qu'il y a une couche de nœud, il n'est pas nécessaire de limiter quelle forme de service il s'agit. Pour le développement du backend, ils n'utilisent que des interfaces qui se soucient du code commercial.
Le serveur est sous l'application de nœud.
Il existe une couche de proxy modèle dans l'application de nœud qui communique avec le serveur. Cette couche est principalement utilisée pour lisser la façon dont nous appelons différentes interfaces et encapsulez certains modèles nécessaires à la couche de vue.
La couche de nœud peut également facilement réaliser le VMCommon d'origine, TMS (citant le système de gestion de contenu Taobao) et d'autres exigences.
Quel framework à utiliser pour la couche de nœud appartient au développeur pour décider. Cependant, il est recommandé d'utiliser une combinaison d'Express + XTemplate, qui peut être utilisée pour les extrémités avant et arrière.
Tout le monde décide comment utiliser le nœud, mais ce qui est excitant, c'est que nous pouvons enfin utiliser Node pour implémenter facilement la méthode de sortie que nous voulons: JSON / JSONP / RESTFUL / HTML / BIGPIPE / COMET / SOCKET / SYNCHRONED ET ASYNCHRONE. Cela peut être fait ce que vous voulez, et il est entièrement décidé en fonction de votre scénario.
La couche de navigateur n'a pas changé dans notre architecture, et nous ne voulons pas changer votre compréhension antérieure du développement dans le navigateur en raison de l'introduction du nœud.
L'introduction du nœud est juste pour remettre la pièce de contrôle frontal qui doit être contrôlée par le frontal.
Nous avons deux projets en développement dans ce modèle. Bien qu'ils n'aient pas encore été lancés, nous avons déjà goûté la douceur en termes d'efficacité de développement et d'optimisation des performances.
5. Que devons-nous faire d'autre?
Intégrez le processus de développement de Node dans le processus SCM existant de Taobao.
Construction des infrastructures, telles que la session, l'enregistrement et d'autres modules généraux.
Meilleures pratiques de développement
Réussite en ligne
La compréhension de chacun du concept de séparation des nœuds avant et arrière
Sécurité
performance
…
Il n'y aura pas trop de technologie qui nécessitera de l'innovation et de la recherche, et il y a eu beaucoup d'accumulation prête à l'emploi. En fait, la clé est l'ouverture de certains processus et l'accumulation de solutions générales. Je crois qu'avec plus de pratiques de projet, ce domaine deviendra progressivement un processus stable.
6. "Island Midway"
Bien que le modèle de «développement complet basé sur NodeJS» soit passionnant, il y a encore beaucoup à aller pour transformer le développement complet en fonction du nœud en quelque chose que tout le monde peut accepter. Notre projet "Midway" en cours est de résoudre ce problème. Bien que nous ne soyons pas longtemps auparavant, nous nous rapprochons de plus en plus de notre objectif! !