Ich habe am JJUG CCC 2019 Spring am 18. Mai 2019 teilgenommen. Dies ist eine Zusammenfassung der Sitzungen, die ich dort gehört habe, und ihrer Eindrücke.
Es mag schwer in den Kugeln zu sehen sein, aber bitte vergib mir.
Ich würde mich freuen, wenn Sie auf Fehler hinweisen könnten.
Umriss und Eindrücke der Teilnahmesitzung
Jakarta EE Update -May 2019-
Briefing-Papier
Überblick
- Die Geschichte von Jakarta EE
- Java EE ist eine Marke von Oracle und wird nicht mehr verfügbar sein
- Der Standard wurde von Java EE nach Jakarta EE übernommen
- Änderungen beim Wechsel von Java EE zu Jakarta EE
- Owner: Oracle -> Eclipse Foundation
--Standardisierung: JCP-> JESP
- Spezifikationen: JSR-> EE4J-Projekt
--Paketname: javax. * -> Jakarta. *
- Die alte Javax. * API kann auch verwendet werden, nachdem sie zu Jakarta geworden ist. *
- Jakarta EE 8 ist fast das gleiche wie Java EE 8
- Mehrere API-Änderungen in Jakarta EE 9
- Altes Javax. * API bleibt aus Kompatibilitätsgründen erhalten
- Wenn Sie nach Jakarta EE wechseln, ist die Entwicklungsgeschwindigkeit schneller als in Java EE.
――Dieser Blog wird hilfreich sein
Impressionen
- Da der Javax nicht mehr verfügbar ist. * Die Benennung wird in Zukunft nicht mehr verfügbar sein. Das Ändern des vorhandenen Codes kann etwas mühsam sein.
- Die Entwicklungsgeschwindigkeit wird höher sein als in der Java EE-Ära. Erwarten Sie es also
CI die Architektur von Java / Kotlin-Anwendungen mit ArchUnit
Briefing-Papier
Überblick
- Eine Geschichte über das Testen der internen Architektur
--ArchUnit ist ein Testframework, das Paketabhängigkeiten als JUnit-Testcode ausdrücken kann.
―― Bis jetzt wurde das Wissen über Architektur personalisiert und implizit informiert, und nur diejenigen, die es kennen, konnten es überprüfen.
- Vorteile der Einführung von ArchUnit
- Die Überprüfung der Architektur kann automatisiert werden
- Kann das implizite Wissen über die Architektur formalisieren
- Sie können auch anwendungsspezifische Implementierungsregeln testen
- Zum Beispiel können Sie einen Test schreiben, der garantiert, dass Sie die Zertifizierung bestehen.
Impressionen
――Wenn die Architektur nicht befolgt wird, kann dies zu Schulden führen. Es ist also wunderbar, dies garantieren zu können!
――Nachdem die Paketstruktur festgelegt ist, kann der Paketabhängigkeitstest nach seiner Integration noch lange verwendet werden. Daher hatte ich das Gefühl, dass beim Schreiben des Tests keine großen Probleme aufgetreten sind.
--Springs @ PreAuthorized kann verwendet werden, um zu verhindern, dass das Kommentieren vergessen wird
Entwicklungsumgebung und Anwendungsinfrastruktur in der Cloud Native-Ära
Briefing-Papier
Überblick
- Einführung in Eclipse Che
--Browser-basierte IDE
- Bietet eine Containerumgebung für Docker und Kuebernetes
- Bereitstellung von IDE, Dateien und Umgebung als Pods
―― "Es funktioniert auf meinem PC ..." verschwindet
――Wenn Sie es berühren möchten, ist Folgendes gut
- Che on OpenShift Online
- Minishift
--Minikube-basiertes OpenShift
--Wählen und entwickeln Sie eine bereits vorbereitete Umgebung namens Stack
- Laufzeit, Compiler, Tools usw.
- Sie können einen vorhandenen Arbeitsbereich unter Verwendung einer durch Gefriertrocknung ausgegebenen URL freigeben.
- Red Hat stellt aktiv VS Code-Plug-Ins zur Verfügung, um die IDE zu verbessern
Impressionen
――Eindruck, dass das Erscheinungsbild fast dem einer allgemeinen IDE entspricht
――Ich fand es großartig, wenn ich es verwenden könnte, weil ich die Zeit für die Erstellung der Entwicklungsumgebung verkürzen könnte.
――Da Sie nicht beim Aufbau einer Umgebung hängen bleiben, wird diese Art von Stress verschwinden.
Weiterentwicklung! Saubere Architektur mit Java - Neue Entwicklung von vorne
Dokument
Überblick
- Saubere Architekturgeschichte
- Das Problem, dass bei der Neuentwicklung ein Front-Prototyp erstellt werden musste, wurde durch die Einführung einer sauberen Architektur gelöst, sodass Logik und Seite leicht ausgetauscht werden können.
--Vor sauberer Architektur Über hexagonale Architektur
--Hexagonal
- Nicht-Geschäftslogik austauschbar machen (Pragapuru)
- Verteilen Sie die Geschäftslogik nicht
- Die saubere Architektur ist eine detaillierte Version der konkreten Implementierung außerhalb der hexagonalen Architektur.
――Onion-Architektur spricht über das Innere (Anwendung) der hexagonalen Architektur.
- Saubere Architekturebenen
- Enterprise Business Rules
- Application Business Rules
- Interface Adapters
- Controllers
- Presenters
- Gateways
- Frameworks & Drivers
- Die Richtung der Abhängigkeit ist nach innen gerichtet, daher darf sich der innere Code nicht auf den äußeren Code beziehen
- Probleme mit sauberer Architektur
--Problem, dass Presenter nicht mit MVC Framework verwendet werden kann
--Presenter kann nicht verwendet werden, da der Controller einen Wert zurückgeben muss
- Am Ende habe ich Presenter verlassen (gibt den Wert in Controller gehorsam zurück)
--Controller wird für die Ansicht fett, ist jedoch in Ordnung, da die Domänenlogik geschützt ist
- Zu viele Felder Problem
- Da die Felder für jeden Interator eingefügt werden, gibt es mehr Felder.
- Aufgelöst nach Nachrichtenbusmuster
- Registrieren Sie den Prozess im Voraus und der entsprechende Prozess wird gemäß den übergebenen Daten ausgeführt.
- Zu viele Definitionen Problem
- Zu viele Dinge zu definieren
--Erstellen Sie Ihr eigenes Gerüstwerkzeug und lösen Sie es (ein Werkzeug namens NORIO).
Impressionen
- Die saubere Architektur wird im Detail festgelegt. Wenn Sie sie befolgen, können Sie sauberen Code schreiben.
――Es scheint, dass der Freiheitsgrad etwas niedrig ist, weil er fest entschieden zu sein scheint
- Eindruck, dass die Anzahl der zu erstellenden Klassen bei der Implementierung wahrscheinlich zunimmt
――Es gibt einige Teile, die mit DDD zusammenhängen, also muss ich studieren. ..
BFF / Backend-Aufteilung der API für mobile Apps in Hot Pepper Beauty
Überblick
- Die Geschichte der Trennung zwischen BFF und Backend
- BFF = Backends For Frontends
--Backend-Server zwischen Frontend und API
- Wenn die Zugriffsquelle ein Browser ist, kann sie in HTML unterteilt werden. Wenn es sich um eine Anwendung handelt, kann sie in JSON unterteilt werden.
- Die API-Entwicklungsgeschwindigkeit des Backend-Teams war langsam und das App-Team war in Schwierigkeiten.
- Erhöhen Sie die Geschwindigkeit der API-Entwicklung, indem Sie BFF erstellen
- Die BFF-Ebene liegt in der Verantwortung des App-Teams
- Bündeln und Zurückgeben mehrerer APIs in der BFF-Schicht
- Derzeit können 6 von 24 Backend-APIs in der BFF-Schicht wiederverwendet werden.
--Wenn die Leistung der gesamten API hoch ist, tritt das N + 1-Problem der API-Version nicht auf.
--API-Design
- Für jeden Anwendungsfall der App erstellt
- Mit Versionierung
- Sofern die App nicht aktualisiert wird, bleibt keine andere Wahl, als sie zu versionieren, da sie die alte API verwendet.
- Mit REST erstellt
- Keine Versionierung
――Weil es nur aus dem Unternehmen heraus aufgerufen wird
--Wenn die Abwärtskompatibilität unterbrochen ist, antworten Sie in Zusammenarbeit mit der BFF
--Technologie
- BFF
- Kotlin
- Spring Boot 2(Spring WebFlux)
--Adopted WebFlux, das nicht blockierende E / A unterstützt, sodass keine E / A-Wartezeit auftritt, da mehrere APIs aufgerufen werden.
- Backend
- AdoptOpenJDk11
- Spring Boot 2(Spring Mvc)
--Die Architektur
- BFF
- Nur Anwendungsschicht und Domänenschicht
- Beurteilung, dass BFF kein Domain-Modell benötigt
- Domänenmodell Anfällig für Anämie
- Rufen Sie die Backend-API auf der Domain-Ebene der BFF auf
- Anwendungsschicht, Domänenschicht, Infrastrukturschicht
- Da die Präsentationsschicht durch Trennen von BFF dünner wird, wird sie in die Anwendungsschicht integriert.
- Aufgabe
- Hohe Belastung des Backends
- Wenn sich etwas ändert, muss es von BFF zu Backend geteilt werden.
Impressionen
――Ich dachte, dass es effektiv sein könnte, wenn mehrere Anzeigequellen wie Apps und das Web vorhanden sind und das App-Team und das Backend-Team getrennt sind.
――Wenn nicht, besteht der Eindruck, dass die Kosten für die Herstellung einer BFF hoch sind und Sie möglicherweise leiden.
――Es hat nichts mit BFF zu tun, aber die verwendete Technologie ist relativ neu und beneidenswert.
Schlüsselpunkte der Migration von Mikrodiensten nach fremdem Muster
Briefing-Papier
Überblick
- Eine Geschichte über das schrittweise Ersetzen des Legacy-Systems durch ein fremdes Muster
- Bis jetzt (Vermächtnis)
- Java ist auf der VM
- Vor Oracle
--Verwenden Sie das ursprüngliche Framework
- Nach Erneuerung
- Service aufgeteilt nach Micro Service
- Das API-Gateway befindet sich zwischen der Azure-API-Verwaltung
- Erstellen Sie zunächst nach der Erneuerung in Azure einen Dienst, leiten Sie dann den vorhandenen Dienst für jede Funktion an den erneuerten Dienst weiter und verschieben Sie die Datenbank schließlich von On-Pre auf die Azure-Seite
--Technologie
- Open API
- Spring Boot
- Azure Kubernetes Service
- Azure API Management
--Swagger Codegen generiert automatisch API-Aufrufbibliotheken für Legacy-Systeme und erneuerte Systeme.
- Protokollaggregation mit Papertrail
- Verteilte Verfolgung mit Spring Cloud Sleuth
Impressionen
――Ich dachte, das Strangler-Muster sei sehr effektiv für die Erneuerung vom Vermächtnis zur Moderne.
――Ich sympathisiere mit dem allmählichen Übergang
- Es ist erstaunlich, dass Swagger automatisch eine Bibliothek generiert.
- Es gibt verschiedene Tools zur Protokollaggregation. Schauen wir sie uns also beim nächsten Mal an.
Functional Spring Cookbook
Briefing-Papier
Überblick
- Die Geschichte, die ich im Frühling wie ein Funktionstyp geschrieben habe
- Mit Spring WebFlux können Sie Webanwendungen in ** Easy ** auf Annotationsbasis schreiben
- Mit Spring WebFlux.fn können Sie Web-Apps in ** Simple ** auf funktionale Weise schreiben
--Spring WebMvc.fn kann in einer funktionalen Form wie Spring WebFlux.fn geschrieben werden, die Verarbeitung wird jedoch synchron.
- Einführung verschiedener Möglichkeiten zum Schreiben von Bean-Definitionen, HTTP-Client usw. in Spring WebFlux.fn und Spring WebMvc.fn
- Einführung in das Ersetzen von "@ SpringBootApplication" durch eine Scratch-Implementierung von Spring WebFlux.fn oder Spring Fu
Impressionen
――Da Sie in einem funktionalen Stil schreiben können, fand ich es wunderbar, einfach mit einer kleinen Menge an Beschreibung schreiben zu können.
――Bei einem umfangreichen Dienst, der eine saubere Architektur usw. einführt, gibt es einen Prozess zum Aufrufen der Anwendungsschicht. Daher hatte ich das Gefühl, dass die Routing-Methode fett werden würde und es schwierig zu sehen und einfach wäre.
(Aktualisiert am 20. Mai 2019 ↓)
――Wir haben einen direkten Kommentar von @making @ github erhalten und er sagte, dass er keine Probleme haben würde, weil er Routen synthetisieren könnte.
-Wenn Sie [Dokumentation] lesen (https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-fn-running), werden Sie feststellen, dass RouterFunction Mapping mehrere RouterFunction <ist Es scheint Bohnen vom Typ?> Zu synthetisieren. Sie können also die Routing-Methode aufteilen.
- Der Implementierer muss nur mehrere RouterFunction <?> Type Beans definieren, ohne sich dessen bewusst zu sein.
――Wenn dies der Fall ist, lassen Sie es uns einfach halten, ohne fett zu werden