Conception de l'architecture de microservice Cloudtop

Appliquer la scène

La capacité de couplage organisationnel et technique des applications monomères traditionnelles peut être réduite de façon significative à mesure que l'entreprise évolue d'une seule ligne de produits + monostructure à une ligne multi-produits + phase de développement multi-équipes.Plus le cycle de déploiement est long, plus les coûts des essais de régression sont élevés, plus il est nécessaire de réémettre des modifications mineures à un module autre que le module de base pour l'ensemble de l'application.— Ces signaux suggèrent que l'introduction de structures de micro-services n'est plus une condition nécessaire à la poursuite de l'efficacité de la prestation par les équipes.

Les signaux de point de retournement typiques comprennent : les temps de démarrage de l'application de plus de 30 secondes conduisant à une détérioration de l'expérience de mise à jour en continu; des variations importantes de la fréquence des changements dans différents modules d'affaires (les modules de transaction de base sont mis à jour une fois par semaine et les modules de gestion back-office ne sont susceptibles de se déplacer qu'une fois par mois), mais un seul organisme oblige tous les modules à maintenir le même rythme de sortie; plusieurs équipes de développement collaborent sur le même entrepôt de codes pour consolider les conflits et les risques de retour avec la croissance de l'indice de taille de l'équipe; et la fuite de mémoire ou le cycle de mort d'un module peut ralentir l'application dans son ensemble, et le manque d'isolement des ressources rend le rayon de défaillance égal à l'ensemble du système.

Les scénarios décrits ici s'appliquent aux entreprises qui ont des taux élevés de développement des entreprises, de collaboration entre équipes multiples, de forte demande de résilience du système et d'efficacité de la prestation.ZhiHua TechFournir des services complets de transformation des microservices, depuis le counseling structuré jusqu'à la mise en oeuvre de l'impromation, sans représenter les données spécifiques des clients.

Problèmes opérationnels typiques

1. Goulets d ' étranglement dans les structures monoformulaires

• Relâchez un couplage:30 développeurs partagent un entrepôt de code et une ligne de streaming CI/CD. Toute combinaison de codes peut bloquer la libération d'autres. Corrections urgentes pour un bogue de paiement, qui doit attendre que l'arriéré précédent de 5 MRs soient tous consolidés et retournés au test est terminé -- ces MRs n'ont rien à voir avec le module de paiement.
• Des explosions d'essai.: La plage de test de régression pour une application unique est de "application complète". Même si SQL est modifié avec une seule interface de requête, il faut 40 minutes à 2 heures pour exécuter le paquet de test complet de bout en bout. La durée du cycle de retour d'essai ralentit la vitesse itérative.
• Verrouillage techniqueL'application est liée à un entrepôt technologique (comme Java 8+ Spring), un nouveau scénario d'affaires qui est plus approprié pour Go ou Node.js, mais l'introduction d'une nouvelle langue signifie un nouveau système de construction, de déploiement et de surveillance, et les équipes choisissent souvent de « travailler ensemble ».

2. Complexité induite par la distribution

• Le réseau n'est pas fiable.: Le monocorps est appelé par méthode, et les microservices sont connectés au réseau. Les réseaux sont en prolongation, déballés, cloisonnés -- ces modèles de défaillance qui n'existent pas dans un seul corps sont routiniers sous des structures microservice. Sans délai raisonnable, ré-test et stratégies de fusion, un service vibre comme un domino.
• Cohérence des donnéesSous les microservices, chaque service possède sa propre base de données, et les opérations interservices (les suivantes sont = service de commande + service d'inventaire + service de paiement) doivent s'appuyer sur des programmes de services distribués tels que Saga ou la STC pour assurer la cohérence finale. Ce changement de pensée – de « l'achèvement des activités » à « l'indemnisation peut être possible pour chaque étape » – est le seuil cognitif le plus difficile à franchir pour une équipe.
• Débogue et dissuasion: Une demande peut croiser 5-8 micro-services. Lorsqu'un utilisateur signale un « ordre de retrait » échoué, vous devez entrer en contact avec une chaîne d'appels complète à partir d'un journal de passerelle, d'un journal de service de commande, d'un journal de service d'inventaire, d'un journal de service de paiement, sans suivi distribué (par exemple Jaeger, SkyWalking), le problème de positionnement est comme une aiguille.

3. Manque d ' infrastructures et de mobilité

• Conteneurisation et organisationLes microservices sont naturels pour le déploiement de la conteneurisation, mais Kubernetes lui-même a une courbe d'apprentissage raide. Pod Network, Service Discovery, Ingress Route, ConfigMap, Secret Management, HPA Resilient sprawl - concepts qui sont zéro pour les équipes traditionnelles.
• Complexité IC/CD: D'une ligne de flux à une ligne N (une pour chaque service), la construction miroir, la poussée, le déploiement, le renversement nécessite une normalisation. Sans modèle uniforme de ligne de flux et de gestion de produit, la fragmentation du processus de livraison peut être causée par des équipes séparées.
• ObservabilitéL'exploitation forestière, les indicateurs et le suivi – les trois piliers sont un. Sous les structures de microservice, l'absence de l'un quelconque des piliers peut entraîner une réduction significative de la capacité à s'extirper.

Conception des programmes

1. Sciage progressif au lieu de réécrire Big Bang

ZhiHua Tech a insisté sur la transformation des micro-servicesFig. de cintre Patterson• Progressivement en direction de modules fonctionnels dans la nouvelle architecture tout en maintenant le fonctionnement normal de l'ancien système, qui coexiste à travers les couches de route jusqu'à ce que l'ancien système soit complètement remplacé:

• Premièrement, nous supprimons le module de changement de HF.La priorité est donnée à la séparation des modules les plus fréquents et les plus indépendants de l'entreprise (par exemple, les centres utilisateurs, les centres de produits de base). Une fois démontés, ils bénéficient des dividendes d'un déploiement indépendant – les changements ne sont plus limités par le rythme de sortie d'autres modules.
• Entrée unifiée de la passerelle APILa passerelle est responsable de la distribution de l'itinéraire, de l'authentification de l'autorisation, de la restriction de flux et des enregistrements de log. Demande de faire suivre la passerelle vers le mono ou le microservice correspondant en préfixant le chemin, sans sens de l'extrémité avant.
• Base de données: Chaque microservice détaché possède une base de données indépendante, Schema (même un exemple de base de données autonome), qui est en fin de compte compatible avec la base de données unique en synchronisant les données ou en appelant API. Le démantèlement par étapes réduit les risques en utilisant la stratégie « Dub-Book +-Top-Top-Read ».

2. Gouvernance de la communication par réseau de services

Lorsque le nombre de microservices dépasse 10, la gouvernance traditionnelle des services SDK (SDK pour chaque service introduit dans le cadre du RPC) commence à exposer les coûts de maintenance - la mise à niveau de SDK exige que tous les services soient restructurés et publiés, différents services SSDK ont besoin de services différents et la stratégie de changement de gouvernance nécessite des changements de code.

ZhiHua Tech recommande l'introduction après que l'échelle de service a atteint un certain niveau Mesh de service (par exemple Istio + Envoyé), capacité de gouvernance de service à la baisse à l'agent Sidecar:

• Gestion des fluxRelease à l'échelle grise (par poids/tête/divertissement de cookies), test d'injection par échec, miroirs de requête - ces capacités peuvent être obtenues par le biais de la règle de conception d'Istio et des configurations de services vitaux sans avoir à modifier les codes d'affaires.
• Sécurité des communications: MTLS (authentification TLS bidirectionnelle) est automatiquement activé pour les communications interservices, la délivrance, la rotation et la révocation des certificats est automatiquement gérée par Citadel, et les développeurs d'entreprise n'ont pas besoin de percevoir le mécanisme de sécurité ascendant.
• Observabilité: Sidecar collecte automatiquement les données de télémétrie (délais, succès, taux d'erreur) pour toutes les stations entrantes et sortantes, et la sortie vers Prométhée (indicateur) + Jaeger (lien) + ELK (log), formant un triangle observable complet.

Ligne de livraison CI/CD et Gitoops

ZhiHua Tech aide les clients à construire un système de CI/CD normalisé, le principe fondamental étantUn modèle pour la construction et le déploiement de tous les services：

• Modèle de ligne d'eau: Tous les microservices partagent le même ensemble de modèles CI/CD (Jenkinsfile ou GitHub Actions workwork template), qui ne nécessitent que quelques variables (langue, port, quotas de ressources) à accéder.
• Déploiement des Gitops: Une déclaration de toutes les ressources Kubernetes (Déployment, Service, Ingress, ConfigMap) est stockée dans le dépôt Git, où l'ArgoCD surveille en permanence les changements dans le dépôt Git et les synchronise automatiquement en clusters. Toute modification manuelle d'un cluster est retournée par le contrôleur GitOps pour s'assurer que « Git Repository = Group Real ».
• Libération des Canaries: Livraison progressive par Argo Rollouts - nouvelle version de Pod déployé 5% en premier, taux d'erreur d'observation et de retard 5 minutes, et l'expansion normale de l'indicateur à 25% 50% et 100%.

Portée des capacités du système

Zip, base containerizzato.

• Kubernetes Planification des grappesConception d'architecture multi-environnementale (développement/essai/préproduction/production), sélection des spécifications des nœuds, sélection des plugins réseau (Calico/Cilium), conception du programme de stockage (CSI).
• Gestion des miroirs de portierVoici quelques exemples des récents développements dans le domaine du miroir : Harbor construction d'entrepôts de miroirs privés, balayage de sécurité de miroir (Trivy), stratégie de minceur de miroir (construction à plusieurs étages, miroir de base dissolate).
• Étendage flexible: HPA (basé sur l'échaudage horizontal CPU/RAM Pod) + Cluster Autoscaler (échaudage au niveau des nœuds) + KEDA (basé sur l'échaudage à l'occasion d'un événement d'indicateurs personnalisés tels que la profondeur de la file d'attente des messages).

Gouvernance des services et communications

• API Passerelle: Harmoniser la route, le flux limite, l'authentification, le log, le traitement de domaine.
• Inscription et découverte des services: Découverte de services basée sur Kubernetes DNS + Service, gestion des métadonnées de services externes en collaboration avec Consul/Nacos.
• Configurer le centreNacos/Apollo gère centralement les configurations d'environnement, les modifications de configuration sont envoyées en temps réel, supportant la distribution à échelle grise et le retour.

• Système d'observation

• Loger: Fluentd/Filebeat collecte →Kafka buffer → Elasticsearch store → Kibana display. Les journaux sont associés par TraceID.
• IndicateursProméthée + Grafana, couvrant les indicateurs d'infrastructure (node/container/Pod) et les indicateurs d'application (QPS/retardé/mauvaise/indicateurs opérationnels).
• Suivi des liens: OpenTelemetry + Jaeger, affichant la chaîne d'appel complète et le temps par saut entre les services demandés.
• Appelez la police.: Alerte de gestion d'alerte (urgence/avertissement/notification), envoyée via Enterprise Micro-Credits/Pertification/Livre volant, avec une capture d'écran de panneau de Grafana.

Livraison CI/CD

• Normalisation des référentiels de codes (politique de branche, CODEOWNERS, modèle de demande de fusion)
• Automatisation, test unitaire, analyse de code (SonarQube), livraison de construction miroir
• Déploiement des gitoops (ArgoCD)+Stratégie de libération verte des cyancant/bleu

Architecture de données de distribution

• Politique de partage des bases de données: Séparer verticalement par champ + Séparer horizontalement par temps/ID (SharingSphere). Lire et écrire séparément (écriture principale de la bibliothèque, lecture à partir de la bibliothèque).
• Services de distributionIl s'agit d'un petit nombre de fiches d'information locales basées sur les informations reçues et les fiches d'information locales.
• Structure de la cache: Redis Cluster Cache multi-niveaux (local Cafsee + Distribution Cache + Base de données), Cache Aside / Writer Behind.

Produits livrables

Orientation de la valeur prévue

• Des gains d ' efficacité importants dans la prestation des servicesLe service est construit, testé et déployé de façon indépendante, et le cycle de déblocage unique est réduit d'un niveau « hebdomadaire » à un niveau « horaire ».
• Isolation et élasticité des défautsL'amplification automatique (HPA/KEDA) garantit que les ressources disponibles sont suffisantes pour réduire le coût de la récupération automatique des ressources dans les vallées basses.
• Liberté d'entrepôt technologique: Différents services peuvent sélectionner les meilleurs compartiments technologiques de la scène, et l'introduction de nouvelles technologies ne nécessitera plus une restructuration complète.
• Couverture observableLe blogueur dit que le gouvernement a été en mesure de montrer le problème de