L’image ci-dessus montre la version en niveaux de gris de Tencent, les utilisateurs ordinaires y peuvent y accéder, le serveur Alibaba Cloud est inaccessible, le ping est normal, et l’IP de résolution est également normale
C’est juste inaccessible, on voit que Tencent aime aussi jouer avec la libération en niveaux de gris...
1. Pourquoi la sortie en niveaux de gris
- Les services Internet changent fréquemment et les cycles de lancement sont courts. La rapidité et la qualité sont toujours difficiles à combiner.
- L’édition en niveaux de gris peut réduire le risque lié à la publication et diminuer l’ampleur de l’impact.
- Réduire la dépendance aux tests et diminuer le coût de construction des données pour l’auto-test hors ligne.
- Il est pratique de surveiller centralisément les journaux et de les publier en intégralité. En raison du rôle de l’équilibrage de charge à chaque couche, il est difficile de suivre un lien d’appel complet.
- Vous pouvez utiliser des comptes de test en niveaux de gris, puis des comptes utilisateurs réels en niveaux de gris une fois le compte test réussi pour réduire encore les risques et l’impact de la publication.
- Retour en arrière facile.
Problèmes qui ne peuvent pas être résolus par des versions en niveaux de gris
Il convient de souligner que « l’impact tolérable » mentionné ci-dessus doit être récupérable, par exemple, l’API ne peut pas être appelée pendant un certain temps, mais après réparation, elle peut être appelée avec succès. La perte ou la destruction permanente des données utilisateur (telles que les informations sur les produits, les commandes, etc.) est intolérable. Il incombe donc aux architectes des entreprises Internet de réparer les données utilisateur perdues à un état récent (comme il y a une heure à une semaine) par une intervention manuelle en cas de perte de données utilisateur dues à des troubles du système de production (comme une sauvegarde régulière des données utilisateur, l’écriture de journaux d’opérations, etc.).
CONSEILS : Testez d’abord la politique en niveaux de gris de votre compte afin de réduire le risque d’endommager ou de perdre les données des utilisateurs réels.
2. Quel effet est attendu ?
Quel que soit le changement, nous souhaitons que des requêtes spécifiques soient acheminées vers notre version du changement (version en niveaux de gris) pour observation et validation.
3. Stratégie en niveaux de gris
En fait, c’est ce qui doit être acheminé vers notre version en niveaux de gris (machine en niveaux de gris). Cela est souvent fortement lié au monde des affaires. Par exemple, pour les API, il existe généralement les exigences suivantes :
Utilisateurs spécifiques (par exemple, comptes test)
Applications spécifiques (par exemple, applications de test ou applications partenaires)
Modules et interfaces spécifiques (seules certaines interfaces nécessitent le niveau de gris, qui est généralement une modification des conteneurs API, et certaines API peu importantes sont utilisées pour le test en niveaux de gris). ）
Machine spécifique (certaines IP de requête sont transmises à la machine en niveaux de gris)
4. Discussion des schémas en niveaux de gris
Solution 1 : Le niveau de code est jugé selon le drapeau convenu, et l’ancien et le nouveau sont commutés dynamiquement - approche d’Amazon
Mise en œuvre :
Enterrez l’interrupteur dans le code, faites un jugement if-else, et activez l’interrupteur pour les machines nécessitant le niveaux de gris, sinon il est désactivé. Il existe deux versions pour chaque version.
mérite
Retour en arrière rapide, pas besoin de republier et de redémarrer le système.
défaut
Soyez porté sur le code.
La logique de branchement apporte de la complexité.
Cette méthode a été utilisée par l’auteur lorsque j’étais sur Alibaba, en basculant la base de données des marchandises d’Oracle vers MySql, et en utilisant une variable d’état pour le contrôle. Obtenant ainsi l’effet d’une migration fluide.
Option 2 : Machine pré-sortie - Pratique d’Alibaba
En fait, ce n’est pas un nuage de gris au sens propre. Parce que cette machine de pré-lancement est une IP interne et n’a pas de service externe. La liaison de domaine est nécessaire pour la vérification. Mais les données sont entièrement en ligne. C’est donc essentiellement une approche simple pour certains utilisateurs spécifiques de Grayscale (utilisateurs ayant accès à la machine Grayscale, utilisateurs de test internes). En fait, il existe une approche similaire côté API, qui est notre environnement Gamma, et nous fournissons également le nom de domaine de la machine Gamma pour faciliter la coopération des utilisateurs coopératifs externes aux tests.
mérite
Simple
défaut
Gaspiller une machine (cela peut être mis en production après la pré-libération, puis retiré de nginx lors de la pré-sortie, mais le support O&M est requis.) ）
Pas assez flexible
Les services IDL ne peuvent être utilisés que pour les machines de couche accès, et les services IDL doivent être considérés séparément.
Option 3 : déploiement SET
1. Déployer isolément selon les services
Par exemple, dans la pratique actuelle des conteneurs API, la granularité du déploiement peut être atteinte au niveau de l’API, et le front-end est redirigé selon nginx. Comme quoi:
Conteneur API Micro Shopping : api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API Container : api.yixun.com
API de shopping en ligne Container:api.buy.qq.com
Ce qui précède est un déploiement isolé au niveau des grandes entreprises. Elle peut également être affinée au niveau du module, comme l’API du e-commerce de services virtuels, qui est un module sous-business suspendu sous Paipai, mais comme ils sont connectés à WeChat, le nombre de visites a considérablement augmenté, afin d’éviter d’affecter les autres activités de Paipai, et pour éviter d’être affecté par d’autres entreprises, l’API ici consiste à déployer deux machines séparément pour celles-ci, nginx peut être configuré pour drainer l’accès à l’API virtuelle :
Conteneur API virtuel : http://api.paipai.com/v2/virbiz
Ainsi, lorsque nous publions une version, nous pouvons d’abord choisir Yixun avec le plus petit volume d’entreprise à publier, puis observer qu’il n’y a aucun problème avant d’utiliser toutes les autres plateformes.
2. Déploiement par isolement utilisateur
Ce n’est pas très adapté aux plateformes ouvertes, mais c’est très adapté à des scénarios d’application comme SNS. Par exemple, le système QQ est divisé en plusieurs ensembles selon les segments de nombre d’utilisateurs, et chaque ensemble contient 100 millions de numéros consécutifs. En supposant que le dernier chiffre QQ soit proche de 1 milliard, il y a un total de 10 ensembles (de l’ensemble 1 à l’ensemble 10). Ainsi, vous pouvez choisir l’un des SETS à publier à chaque fois, et QQ de haut niveau n’est souvent pas un utilisateur très important, donc SET10 sera publié en premier.
mérite
Déploiement isolé avec un impact minimal à travers les lignes métier. Prendre en charge automatiquement la publication en niveaux de gris.
défaut
La granularité de la gamme de gris dépend de la granularité du déploiement isolé, qui est généralement importante.
Gaspillage de machines comparé au déploiement centralisé.
Les versions de chaque ligne métier peuvent être incohérentes, ce qui n’est pas propice à une gestion unifiée.
Il existe certains coûts de mise en œuvre et de déploiement
Schéma 4 : Routage dynamique
Méthode : Utiliser une politique en niveaux de gris qui peut être configurée de manière flexible pour influencer le comportement de la balance de charge et lui permettre de renvoyer l’IP et le port du service en niveaux de gris selon la politique en niveaux de gris.
Adapté au service en niveaux de gris avec IDL back-office.
mérite
Flexible, contrôlable.
défaut
Le centre de configuration actuel et L5 lui-même ne prennent pas en compte des politiques de routage spécifiées, et ne sont pas évolutives, ils doivent donc être développés en dehors de celles-ci.
Les sources de métadonnées des API sont relativement dispersées, et actuellement, les métadonnées API et IDL, les niveaux d’API et les limites de fréquence sont répartis entre différentes sources de données, il est désormais nécessaire d’ajouter une source de données de routage en niveaux de gris.
Il existe généralement trois façons de publier nginx+lua en niveaux de gris : nginx est distribué selon les cookies, et nginx est attribué selon le poids :
nginx+lua distingue selon l’adresse IP du visiteur, car l’entreprise exporte une adresse IP, et le site web sera accessible soit à l’ancienne version, soit à la nouvelle, ce qui n’est pas adapté à cette méthode
Nginx attribue des poids en fonction des poids, ce qui est simple à implémenter et peut être essayé
nginx se divise en fonction des cookies, et Grayscale publie en fonction des utilisateurs
|
Publié sur 09/03/2017 15:48:27
|
|
|
|
