Herkunft
Ich habe vom Projektteam auf ZenTao eine Fehlermeldung erhalten: Es gibt eine Geschäftsschnittstelle und gelegentlich können keine Daten gefunden werden. Die Daten in anderen Schnittstellen sind normal und die Ursache kann nicht gefunden werden. Ich habe die Plattform um Hilfe bei der Fehlerbehebung gebeten.
Einführung in die Projektstruktur
Springcloud-Microservice-Projekt
Anmeldezentrum: eureka
Datenbank: Orakel
Cache: redis
orm:springJPA
Reverse-Proxy: Nginx
Tor: zuul
Containerisierungstechnologie: Docker
Verwaltung der Container-Orchestrierung: k8s
CD/CI-Pipeline: Jenkins
Fehlerbehebungsprozess
1. Zuerst habe ich die Protokollinformationen des Servers überprüft und festgestellt, dass keine Unregelmäßigkeiten festgestellt wurden.
2. Nach dem lokalen Starten des Dienstes wurde beim lokalen Debuggen festgestellt, dass das Problem nicht reproduziert werden konnte. (Es ist sehr unangenehm, wenn es nicht lokal reproduziert werden kann. Jeder, der es versteht, versteht es.)
3. Es besteht der Verdacht, dass das Registrierungszentrum illegale Dienste registriert hat, was dazu führte, dass die illegalen Dienste abgefragt und bei Abfrageanfragen andere Datenbanken abgefragt wurden. Die Überprüfung ergab, dass keine anderen illegalen Dienste registriert wurden.
4. Überprüfen Sie, ob die für jeden Dienst konfigurierten Datenbankinformationen konsistent sind. Die Datenbank mit den Prüfergebnissen ist konsistent. (In diesem Schritt der Untersuchung wurden keine Auffälligkeiten festgestellt, was mich ein wenig frustriert)
5. Beim Beobachten des Codes habe ich versehentlich festgestellt, dass die Geschäftsschnittstelle Multithreading verwendet und es im Projekt zwei Thread-Pools gibt, einen Thread-Pool für Geschäftstextnachrichten (gekennzeichnet mit der Annotation @Primary) und einen Thread-Pool, der speziell dafür verwendet wird Prozesse (nicht markiert) @Primary-Annotation). Bei der Einführung von TaskExecutor wurde der Name jedoch nicht angegeben, was dazu führte, dass alle Unternehmen im System denselben Thread-Pool verwendeten. Die maximale Anzahl der im Thread-Pool konfigurierten Threads beträgt 16, die maximale Anzahl der Warteschlangen beträgt 64 und die Ablehnungsrichtlinie Der Thread-Pool ist CallerRunsPolicy (bereitgestellt vom Aufrufer, weshalb das Protokoll keinen Fehler meldet).
Folgen Sie der Idee, gehen Sie zum Server und verwenden Sie den Befehl jps (ps -ef funktioniert auch), um die Prozess-PID des Unternehmens zu ermitteln. Verwenden Sie dann top -Hp pid, um zu sehen, dass eine große Anzahl von GC-Threads und SMS-Threads ausgeführt wurde . Die Gesamtzahl der Threads hat 80 überschritten. Daher führen später gestartete neue Threads keine Verarbeitung durch.
6. Bitten Sie das Projektteam, die Probleme mit der Codequalität zu überprüfen und dann das Problem zu überprüfen, dass keine Textnachrichten gesendet werden. Schließlich ist das Problem gelöst.