2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Les microservices sont unstyle architectural(À la différence de l'architecture monolithique, de l'architecture verticale, de l'architecture distribuée et de l'architecture SOA), les applications sont divisées en services plus petits et axés sur les processus.
Spring Cloud est unCadre de microservices , qui fournit une gamme de solutions de systèmes distribués. Fournit des fonctionnalités telles que le développement et le déploiement de microservices, l'enregistrement et la découverte de services, la gouvernance des services, ainsi que l'exploitation et la maintenance des services via la composantisation.
1）Nuage de printemps Netflix :
Eurêka : centre d'inscription
Ruban : équilibrage de charge
Feindre : appel à distance
Hystrix : disjoncteur de service
Zuul/Passerelle：Passerelle
2）Spring Cloud Config : outil de gestion de configuration centralisé, stockage externe de la configuration des applications, peut être utilisé pour les applications Spring ou non Spring.
3）Spring Cloud Bus : bus d'événements et de messages, utilisé pour propager les changements d'état ou les événements de changement de configuration dans le cluster.
4）Spring Cloud Consul : outil de découverte et de configuration de services, parfaitement intégré aux conteneurs Docker.
5）Spring Cloud Security : une boîte à outils de sécurité qui prend en charge la sécurité et l'authentification des applications.
6）Spring Cloud Sleuth : traçage de chaîne d'appels distribué, compatible avec le traçage Zipkin, HTrace et ELK.
7）Spring Cloud Cluster : élection du leader, mise en œuvre via l'abstraction de Zookeeper, Redis et Consul.
8）Spring Cloud Data Flow : orchestration de microservices, facile à utiliser via une interface glisser-déposer ou une API REST.
9）Spring Cloud Stream : un cadre de microservices léger basé sur les événements pour créer rapidement des applications qui se connectent à des systèmes externes.
10）Spring Cloud Task : un cadre de microservices à court terme pour créer rapidement des applications qui effectuent des tâches de traitement de données par lots.
existerdans les systèmes distribués , si un nœud de service tombe en panne ou si une anomalie du réseau se produit, l'appelant peut être bloqué et attendre. Si le délai d'attente est défini sur une longue période, les ressources de l'appelant peuvent être épuisées.Cela conduit à son tour à un épuisement des ressources dans le système en amont de l'appelant, ce qui aboutit finalement àsystème d'avalanche . Les disjoncteurs peuvent prévenir efficacement les avalanches de service.
Si vous constatez une augmentation soudaine du trafic, l'approche générale consiste àFonctions commerciales non essentiellesDes mesures de dégradation des services sont adoptées pour protéger le service normal des fonctions commerciales essentielles, tandis que pour les services fonctionnels essentiels, les mesures de limitation actuelles doivent être adoptées.
Disjoncteur de service :en général Cela se produit côté serveur (le but est de permettre à l'appelant d'échouer rapidement). Lorsqu'un service expire ou devient anormal, cela provoque un fusible, similaire à un fusible dans la vraie vie. (Parfois, il peut également être configuré sur le client pour échouer rapidement lorsqu'une exception est trouvée lors de l'appel d'un certain service) ;
Dégradation du service : se produit généralement côté client Compte tenu de la charge globale des requêtes du site Web, lorsqu'un service est déconnecté ou arrêté, le service ne sera plus appelé (parfois il peut également être configuré côté serveur, lorsque le système l'a fait). trafic soudain, les fonctions principales seront déclassées pour protéger les fonctions principales) ;
Limitation de courant : se produit généralement côté serveur ;
@EnableCircuitBreaker : activé sur l'applicationfusible
@HistrixCommand(fallbackMethod="xxxFallback",commandProperties = {
}) : L'annotation de fusion est ajoutée à l'annotation de rétrogradation. Remplissez les conditions de fusion dans commandProperties = {}.Gestionnaire de propriétés HystrixVérifier.
- @HystrixCommand(fallbackMethod = "xxxFallback",commandProperties = {
- //20秒内出现3个请求,失败率为30%,就会触发熔断,30秒内不再发送调用
- // 条件一: 请求数量达到3个
- @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD, value = "3"),
- // 条件二: 每20秒一个判断单位
- @HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_THREAD_INTERRUPT_ON_TIMEOUT,value = "20000"),
- // 条件三: 失败率30%
- @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE, value = "30"),
- // 结果: 熔断后, 30秒内不再请求远程服务
- @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS, value = "30000")
- })
Créez une nouvelle classe xxxFallbackFactory pour implémenter FallbackFactory et remplacez la méthode create. La méthode de rétrogradation est définie dans create.
@FeignCliend(fallbackFactory=xxxFallbackFactory.class) : Histrix est intégré à Feign
Ou précisez la méthode de repli directement sur la méthode : @HistrixCommand(fallbackMethod="xxxFallback")
1、Stratégie de limitation actuelle :
1), limite de courant du sémaphore
Le sémaphore est utilisé pour contrôler le nombre de threads simultanés. Précisez le nombre de licences virtuelles internes via le constructeur.
Si la technologie d'isolation des sémaphores est utilisée, chaque fois qu'une requête est reçue, le propre thread du service appelle directement le service dépendant. Le sémaphore équivaut à un point de contrôle. Après que chaque thread passe le point de contrôle, le nombre de sémaphores est réduit de 1. est 0, ce n'est plus le cas. Le thread est autorisé à passer, mais la logique de repli est directement exécutée et renvoyée. Pour le dire franchement, ce n'est qu'une limite actuelle.
Un sémaphore peut être compris comme uncomptoir, le compteur compte le nombre de requêtes en cours de traitement. Lorsque la valeur du compteur atteint la valeur définie, les requêtes suivantes ne seront pas acceptées (ou rétrogradées) et vous devez attendre que la valeur du compteur soit inférieure à la valeur définie avant de pouvoir effectuer des requêtes ultérieures. en traitement.
- @HystrixCommand(
- commandProperties= {
- @HystrixProperty(name="execution.isolation.strategy", value="SEMAPHORE"),
- @HystrixProperty(name="execution.isolation.semaphore.maxConcurrentRequests", value="20")
- },
- fallbackMethod = "errMethod"
- )
2), limite actuelle du pool de threads
- @HystrixCommand(
- commandProperties = {
- @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD")
- },
- threadPoolKey = "createOrderThreadPool",
- threadPoolProperties = {
- @HystrixProperty(name = "coreSize", value = "20"),
- @HystrixProperty(name = "maxQueueSize", value = "100"),
- @HystrixProperty(name = "maximumSize", value = "30"),
- @HystrixProperty(name = "queueSizeRejectionThreshold", value = "120")
- },
- fallbackMethod = "errMethod"
- )
Notez ici : dansjavaDans le pool de threads, si le nombre de threads dépassecoreSize, les demandes de création de threads entreront en premier dans la file d'attente. Si la file d'attente est pleine, les threads continueront à être créés jusqu'à ce que le nombre de threads atteigne.maximumSize , puis adoptez la stratégie de rejet.Mais il existe un paramètre supplémentaire dans le pool de threads configuré par hystrixqueueSizeRejectionThreshold,siqueueSizeRejectionThreshold < maxQueueSize, le nombre de files d'attente atteintqueueSizeRejectionThresholdadoptera la stratégie de rejet, doncmaximumSize échoué.siqueueSizeRejectionThreshold > maxQueueSize, le nombre de files d'attente atteintmaxQueueSizeheure,maximumSizeest valide, le système continuera à créer des fils de discussion jusqu'à ce que le nombre atteignemaximumSize。
2. La différence entre la limitation du courant du sémaphore et la limitation du courant du pool de threads :
1) Niveau de performance : le sémaphore utilise le thread d'origine et a une faible consommation de performances ;
2) Niveau de stabilité du système : les pools de threads sont isolés et les problèmes en eux-mêmes n'affecteront pas les autres pools de threads ;
3) Synchrone et asynchrone : le sémaphore étant le thread d'origine utilisé, il est synchrone et bloquant.
3. Scénarios d’utilisation actuels de la stratégie de limitation :
Lorsque le nombre de requêtes est très intensif et que la surcharge d'isolation des threads est relativement élevée, il est recommandé d'utiliser des sémaphores pour réduire la charge. Cette situation est généralement utilisée pour traiter les requêtes hors réseau (sans appeler de services externes). Il est recommandé d'utiliser la méthode du pool de threads dans d'autres scénarios.
La limitation de courant n'est qu'une limitation de courant. Tant que la limite de trafic n'est pas dépassée, le service est toujours disponible (différent du disjoncteur) et n'a pas besoin d'être dégradé (l'exception de dépassement de limite de trafic peut également être levée pour que l'appelant puisse la gérer. seul). Parlons donc simplement de la différence entre un disjoncteur et un déclassement :
Le disjoncteur signifie que le service dans son ensemble n'est pas disponible (en se concentrant sur l'autoprotection), le déclassement signifie choisir la meilleure option suivante (en se concentrant sur la protection des résultats) et la limitation de courant fait référence à la quantité de trafic qui ne peut pas être dépassée.
Par défaut, si hystrix détecte que le taux d'échec des requêtes dépasse 50 % dans les 10 secondes, il déclenchera le mécanisme du disjoncteur. Après cela, la demande au microservice est réessayée toutes les 5 secondes. Si le microservice ne peut pas répondre, le mécanisme du disjoncteur continue. Si le microservice est accessible, le mécanisme du disjoncteur est désactivé et les demandes normales sont rétablies.
Par défaut, hystrix déclenchera le mécanisme de downgrade dans les 4 conditions suivantes :
Le mécanisme de déclassement peut être appelé lors du déclenchement du disjoncteur, mais le mécanisme du disjoncteur n'est généralement pas appelé lors du déclassement.Parce que le disjoncteur commence dans une perspective globale et désactive les services afin d'assurer la stabilité du système, tandis que le déclassement est la deuxième meilleure chose et fournit une solution garantie, leurs relations de propriété sont donc différentes (disjoncteur > déclassement).
Résumé du contenu du lien :
@FeignClient(nom="eureka-HA",fallbackFactory=DeptClientServiceFallbackFactory.class)
faire référence à:
Implémentation pratique de l'architecture du projet SpringBoot "Gateway zuul construction"-CSDN Blog
faire référence à:
Enregistrement du service : lorsque le fournisseur de services démarre, il enverra une demande d'enregistrement au serveur Eureka, comprenant l'adresse IP du service, le numéro de port, le nom du service et d'autres informations. Après avoir reçu la demande d'enregistrement, le serveur Eureka enregistrera les informations de service dans la mémoire et fournira une fonction de requête d'informations d'enregistrement de service externe.
Découverte de services : lorsqu'un consommateur de service a besoin d'appeler d'autres services, il enverra une demande de découverte de service au serveur Eureka pour obtenir une liste d'instances des services requis. Après avoir reçu la demande, le serveur Eureka renverra une liste d'instances du service correspondant, comprenant l'adresse IP, le numéro de port et d'autres informations du service. Le consommateur de service sélectionne l'une des instances de service à appeler (équilibrage de charge) en fonction de la liste d'instances renvoyée.
Bilan de santé Heartbeat : le fournisseur de services enverra régulièrement des paquets de battements de cœur au serveur Eureka pour prouver que son service fonctionne normalement. Si le serveur Eureka ne reçoit pas de paquet de pulsation d'une instance de service dans un délai donné, il considérera l'instance de service comme étant en panne et la supprimera de la liste de services.
Pratique du mode Seata TCC (Partie 2) - Communauté de développeurs Alibaba CloudCombat réel en mode Seata TCC (Partie 2)
https://developer.aliyun.com/article/1053737?spm=5176.26934562.main.1.799c6a03T45SJ9Le billet de blog ci-dessus ne résout pas le problème de suspension, qui peut être jugé par différents indicateurs d'état.
https://www.cnblogs.com/lilpig/p/16613226.htmlhttps://www.cnblogs.com/lilpig/p/16613226.html
TM : Gestionnaire de transactions, généré avec l'annotation @GlobalTransaction.
TC : Coordinateur
RM : Participant
L'ensemble du processus est :
TM proxy vos transactions globales et s'enregistre auprès de TC avant de commencer l'exécution
TM commence à exécuter chaque transaction de branche dans la transaction globale, et RM enregistre et rapporte les transactions de branche et l'état d'exécution à TC.
Une fois l'exécution de la transaction de branchement terminée, TM lance une demande à TC pour valider ou annuler la transaction globale.
La réservation signifie verrouiller et mettre à jour la ressource de base de données dans un état intermédiaire, puis la faire passer à l'état effectif lorsque la validation de deuxième étape est effectuée après confirmation.Donc la phase de réservation et la phase de rollback de commitTous impliquent l’exploitation de bases de données, il peut donc également y avoir des échecs de confirmation et d'annulation qui nécessitent un traitement manuel, qui peuvent être résolus en enregistrant des journaux, en compensant les tentatives, etc.
Avantages du mode TCC：
Inconvénients du mode TCC：
ConfirmetCancelCela peut également échouer et vous devez gérer ce processus.Forte cohérence, en coordonnant le moment où les transactions locales de chaque participant sont validées et annulées.
Avantages du mode XA：
Inconvénients du mode XA：
consistance faible
Il se consacre à la recherche technologique depuis plus de 30 ans et maîtrise divers langages tels que java, linux, javascript, php, css, etc. Il a apporté de nombreuses contributions dans le domaine de l'open source. station de documentation pour les développeurs pour partager certains problèmes de développement technologique pour référence future.
