Spring cloude utilise l'interface d'appel à distance Fegin pour renvoyer le problème linkedHashMap

Description de la situation de l'auteur:
Récemment, lors de l'utilisation de microservices pour appeler entre services, le problème est survenu lors de l'appel via le client fegin

1. Paramètre de retour du serveur d'interface:
   l'objet renvoyé par l'encapsulation de la couche d'interface Objet Result renvoyé par la
   
   couche d'implémentation DeviceVo
   
2. L'appelant de l'interface remet le type de valeur: Résultat
   
   3. L'objet renvoyé après l'appel: Résultat, notez que l'objet de données à ce moment est LinkedHashMap
      
      et le message d'erreur s'affiche:

[java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to com.springboot.cloud.business.trade.service.entity.po.OrderDevice]

L'objet renvoyé ici est converti en LinkedHashMap. La raison spécifique est la suivante:
parce que l'appel distant rpc utilise toujours HTTPClient en bas, donc lors du passage de paramètres, il doit y avoir un ordre. Lorsque vous transmettez la carte, la valeur de la carte There doit également être une commande, sinon la couche de service aura un problème lorsqu'elle sera connectée, elle passera donc de map à linkedhashMap! Spring a une classe appelée ModelMap, qui hérite de la classe publique LinkedHashMap ModelMap étend LinkedHashMap, de sorte que le résultat renvoyé par une interface peut être directement connecté à ModelMap. Notez que ModelMap n'a pas de type générique, quel que soit le type de carte que vous renvoyez, générique Quelle est la complexité la carte est, vous pouvez directement créer une nouvelle Modelmap et l'utiliser pour recevoir le résultat renvoyé! ! !

• Par conséquent, lors de la modification, vous devez ajouter l'objet de retour générique lorsque l'appelant utilise Fegin pour appeler pour résoudre ce problème.

• La solution est la suivante:
  
  
  La valeur renvoyée ici est directement la valeur convertie de l'objet générique, ce qui est une solution parfaite! Mais portez une attention particulière à:

  Remarque: s'il existe un champ de type DATE, l'appelant doit utiliser String pour recevoir le champ d'heure
  s'il y a un décalage horaire dans votre heure . En effet: lorsque le
  client Feign communique, il convertit l'objet de type Date en type String. Si l'heure est 20h30 le 19 février 2019, heure de Beijing, le fuseau horaire de la Chine étant appelé CTS, la chaîne convertie est "Mar 19 février 20:30:00 CST 2019 ". Le serveur convertit la date de type String reçue en type Date. La conversion utilise le constructeur Date par défaut new Date ('Tue Feb 19 20:30:00 CST 2019'), voici le moment où l'erreur s'est produite, car il y a en fait quatre fuseaux horaires représentés par CTS (heure normale du centre (USA) UT-6: 00, heure normale du centre (Australie) UT + 9: 30, heure normale de la Chine UT + 8:00, heure normale de Cuba) UT-4: 00) et signifie l'heure standard des États-Unis, de l'Australie, de la Chine et de Cuba. Selon JavaDoc, jvm comprendra CTS comme le fuseau horaire du centre des États-Unis, provoquant ainsi une erreur de fuseau horaire.
  Solution:

• Utilisez le type String comme paramètre,

• La conversion de type sur le récepteur utilise LocalDate dans JDK8

• La troisième méthode consiste à augmenter la classe de configuration pour que Feign utilise la conversion de règle personnalisée

---

alors, devrais-je donner un coup de pouce comme un revers - "Hey hahaha--"