Eine SpringBoot-Timing-Aufgabenoptimierung

Vorwort

Einige Blog-Beiträge, die ich zuvor bei der Arbeit geschrieben habe, wurden nicht mit dem Blog synchronisiert. Dieser Artikel wurde möglicherweise vor mehr als einem Jahr geschrieben und hofft, den Lesern etwas Inspiration zu geben.

Wir teilen einen Datenhintergrund für mehrere Spiele und unterscheiden verschiedene Spiele und Umgebungen durch unterschiedliche Konfigurationen. Bestimmen Sie, welcher Konfigurationssatz gelesen werden soll, indem Sie angeben application.properties.spring.profiles.active

Wenn wir beispielsweise in der PRD-Umgebung mit dem Codenamen „sfish“ veröffentlichen müssen, können wir spring.profiles.active=sfishlyprdes auswählen und unsere Konfigurationsdatei befindet sich in „resources/config 下有application-sfishlyprd.properites“.

Die Datei wird durch die GameID unterschieden:
gameid=sfishlyprd

Text

Die ursprünglich geplante Aufgabe hat nur eine Klasse, und diese Klasse enthält viele Methoden, und jede Methode gehört zu einem bestimmten Projekt. Beurteilen Sie dann anhand einer Logik, die der folgenden ähnelt:

Der erste Schritt , den ich zur Optimierung unternommen habe , besteht darin, die Methoden nach Projekten zu klassifizieren, und die proprietären Klassen entsprechen den entsprechenden Projekten. Ähnlich zu:

Dies ist nur eine einfache logische Unterteilung und hat keine großen Auswirkungen auf den tatsächlichen Betrieb, das heißt, selbst wenn das aktuelle Sfish-Projekt läuft, werden die geplanten Aufgaben des lytj-Projekts noch ausgeführt.

Die geplanten Aufgaben von SpringBoot werden zur Ausführung einem Betriebssystem-Thread zugeordnet, daher müssen wir weitere Optimierungen durchführen.

1. Zuerst definieren wir eine übergeordnete Klasse und lassen die Planklassen dieser Projekte diese übergeordnete Klasse erben.

public class GameSchedule {
    
    }

public class SfishSchedule extends GameSchedule{
    
    }

2. Kommentieren Sie diese Projektplanklassen aus, @Componetdamit SpringBoot diese Klassen nicht automatisch lädt.

3. Schreiben Sie eine Konfigurationsklasse. Die Logik besteht darin, die Konfigurationsdatei des aktuellen Projekts zu lesen, um die Spiel-ID zu erhalten, und anhand der Spiel-ID zu bestimmen, welche Unterklasse wir aktivieren. Die aktuell geplanten Aufgaben beziehen sich alle auf ein bestimmtes Projekt. Wenn es in Zukunft öffentliche Aufgaben gibt, können Sie der GameSchedule-Klasse direkt Methoden hinzufügen.

@Configuration
public class ScheduleConfig {
    
    

    @Value("${gameid}")
    private String gameid;

    @Bean
    public GameSchedule createSchedule(){
    
    
        if (gameid.startsWith("sfish") || gameid.startsWith("zfsfish")) {
    
    
            return new SfishSchedule();
        } else if (gameid.startsWith("lytj")) {
    
    
            return new LytjSchedule();
        }
        return new GameSchedule();
    }
}

Wenn wir in Zukunft neue Methoden hinzufügen, müssen wir kein Gameid-Urteil mehr schreiben.

Zurückschauen

Nun scheint es, dass der Code der oben genannten Konfigurationsklasse weiter optimiert werden kann, aber die Prämisse besteht darin, die Benennung verschiedener Game-IDs zu vereinheitlichen oder neue Attribute zu verwenden, um sie zu unterscheiden, z. B. nach dem Parsen von lytj, finden, finden, finden und Verwenden Sie LytjScheduledann die Reflexion, um die zugehörige Klasse zu instanziieren.sfishSfishSchedule