Hej alle! Her er det - vores sidste indlæg i Quarkus-serien! (Se i øvrigt vores webinar . Vi viser dig, hvordan du starter fra bunden eller overfører færdige løsninger)
В I dette indlæg har vi set på de relevante værktøjer, der kan bruges til at kvantificere de forbedringer, der opnås som følge af modernisering af Java-applikationer.
Siden version 0.17.0, understøtter brugen af Advanced Message Queuing Protocol (), som er en åben standard til overførsel af forretningsmeddelelser mellem applikationer eller organisationer.
er en service bygget på baggrund af et open source-projekt og implementering af en platformsbaseret meddelelsesmekanisme . For flere detaljer om, hvordan det virker, se . I dag viser vi dig, hvordan du kombinerer AMQ Online og Quarkus for at bygge et moderne OpenShift-baseret meddelelsessystem ved hjælp af to nye meddelelsesteknologier.
Det antages, at du allerede har implementeret AMQ Online på OpenShift-platformen (hvis ikke, så se ).
Til at starte med vil vi oprette en Quarkus-applikation, der vil være et simpelt ordrebehandlingssystem, der bruger reaktive beskeder. Denne applikation vil inkludere en ordregenerator, der sender ordrer til en beskedkø med et fast interval, samt en ordreprocessor, der behandler beskeder fra køen og genererer bekræftelser, der kan ses i browseren.
Når vi har oprettet applikationen, viser vi dig, hvordan du indlejrer meddelelsessystemets konfiguration i applikationen og bruger AMQ Online til at levere de ressourcer, vi har brug for på systemet.
Quarkus app
Vores Quarkus-applikation kører på OpenShift og er en modificeret version af programmet . Et komplet eksempel på klientsiden kan findes .
Bestil generator
Generatoren sender simpelthen monotont voksende ordre-ID'er til "ordre"-adressen hvert 5. sekund.
@ApplicationScoped
public class OrderGenerator {
private int orderId = 1;
@Outgoing("orders")
public Flowable<Integer> generate() {
return Flowable.interval(5, TimeUnit.SECONDS)
.map(tick -> orderId++);
}
}
Ordrebehandler
Ordrebehandleren er endnu enklere, den returnerer bare et bekræftelses-id til "bekræftelser"-adressen.
@ApplicationScoped
public class OrderProcessor {
@Incoming("orders")
@Outgoing("confirmations")
public Integer process(Integer order) {
// Идентификатор подтверждения равен удвоенному идентификатору заказа <img draggable="false" class="emoji" alt=":-)" src="https://s.w.org/images/core/emoji/11.2.0/svg/1f642.svg">
return order * 2;
}
}
Bekræftelsesressourcer
Bekræftelsesressourcen er et HTTP-slutpunkt til at angive de bekræftelser, der genereres af vores applikation.
@Path("/confirmations")
public class ConfirmationResource {
@Inject
@Stream("confirmations") Publisher<Integer> orders;
@GET
@Produces(MediaType.TEXT_PLAIN)
public String hello() {
return "hello";
}
@GET
@Path("/stream")
@Produces(MediaType.SERVER_SENT_EVENTS)
public Publisher<Integer> stream() {
return orders;
}
}
justering
For at oprette forbindelse til AMQ Online skal vores applikation have nogle konfigurationsdata, nemlig: Quarkus-forbindelseskonfiguration, AMQP-slutpunktsoplysninger og klientoplysninger. Det er selvfølgelig bedre at opbevare alle konfigurationsdata ét sted, men vi vil bevidst adskille dem for at vise de mulige muligheder for at konfigurere Quarkus-applikationen.
Stik
Konnektorkonfiguration kan leveres på kompileringstidspunktet ved hjælp af en programegenskabsfil:
mp.messaging.outgoing.orders.connector=smallrye-amqp
mp.messaging.incoming.orders.connector=smallrye-amqp
For at gøre tingene enkle, bruger vi kun en beskedkø til "ordrer"-adressen. Og "bekræftelser"-adressen i vores applikation vil bruge en kø i hukommelsen.
AMQP-endepunkt
På kompileringstidspunktet er værtsnavnet og portnummeret for AMQP-slutpunktet ukendt, så de skal injiceres. Slutpunktet kan indstilles i det configmap, der er oprettet af AMQ Online, så vi vil definere dem gennem miljøvariabler i applikationsmanifestet:
spec:
template:
spec:
containers:
- env:
- name: AMQP_HOST
valueFrom:
configMapKeyRef:
name: quarkus-config
key: service.host
- name: AMQP_PORT
valueFrom:
configMapKeyRef:
name: quarkus-config
key: service.port.amqp
Legitimationsoplysninger
Tjenestekontotokenet kan bruges til at autentificere vores applikation til OpenShift. For at gøre dette skal du først oprette en brugerdefineret ConfigSource, der læser godkendelsestokenet fra pod'ens filsystem:
public class MessagingCredentialsConfigSource implements ConfigSource {
private static final Set<String> propertyNames;
static {
propertyNames = new HashSet<>();
propertyNames.add("amqp-username");
propertyNames.add("amqp-password");
}
@Override
public Set<String> getPropertyNames() {
return propertyNames;
}
@Override
public Map<String, String> getProperties() {
try {
Map<String, String> properties = new HashMap<>();
properties.put("amqp-username", "@@serviceaccount@@");
properties.put("amqp-password", readTokenFromFile());
return properties;
} catch (IOException e) {
throw new UncheckedIOException(e);
}
}
@Override
public String getValue(String key) {
if ("amqp-username".equals(key)) {
return "@@serviceaccount@@";
}
if ("amqp-password".equals(key)) {
try {
return readTokenFromFile();
} catch (IOException e) {
throw new UncheckedIOException(e);
}
}
return null;
}
@Override
public String getName() {
return "messaging-credentials-config";
}
private static String readTokenFromFile() throws IOException {
return new String(Files.readAllBytes(Paths.get("/var/run/secrets/kubernetes.io/serviceaccount/token")), StandardCharsets.UTF_8);
}
}
Byg og implementer applikationen
Da applikationen skal kompileres til en eksekverbar fil, kræves en GraalVM virtuel maskine. For detaljer om, hvordan du opsætter et miljø til dette, se de tilsvarende instruktioner i .
Derefter skal du, ved at følge instruktionerne, der er givet der, downloade kilden, bygge og implementere vores applikation:
git clone https://github.com/EnMasseProject/enmasse-example-clients
cd enmasse-example-clients/quarkus-example-client
oc new-project myapp
mvn -Pnative -Dfabric8.mode=openshift -Dfabric8.build.strategy=docker package fabric8:build fabric8:resource fabric8:apply
Efter disse kommandoer vil applikationen blive implementeret, men vil ikke starte, før vi konfigurerer de beskedressourcer, vi har brug for i AMQ Online.
Opsætning af beskedsystemet
Nu er der kun tilbage at indstille de ressourcer, som vores applikation har brug for i beskedsystemet. For at gøre dette skal du oprette: 1) et adresseområde for at initialisere meddelelsessystemets slutpunkt; 2) adresse for at konfigurere de adresser, vi bruger i applikationen; 3) Beskedbruger til at indstille klientoplysninger.
Adresseplads
Et AddressSpace-objekt i AMQ Online er en gruppe adresser, der deler forbindelsesslutpunkter og godkendelses- og autorisationspolitikker. Når du opretter et adresseområde, kan du angive, hvordan meddelelsesendepunkter vil blive eksponeret:
apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
name: quarkus-example
spec:
type: brokered
plan: brokered-single-broker
endpoints:
- name: messaging
service: messaging
exports:
- name: quarkus-config
kind: configmap
Adresse
Adresser bruges til at sende og modtage beskeder. Hver adresse har en type, som bestemmer dens semantik, samt en plan, som specificerer antallet af ressourcer, der skal reserveres. Adressen kan f.eks. bestemmes sådan:
apiVersion: enmasse.io/v1beta1
kind: Address
metadata:
name: quarkus-example.orders
spec:
address: orders
type: queue
plan: brokered-queue
Beskeder bruger
For at sikre, at kun betroede applikationer kan sende og modtage beskeder til dine adresser, skal du oprette en bruger i beskedsystemet. For applikationer, der kører på en klynge, kan klienter godkendes ved hjælp af en OpenShift-tjenestekonto. Brugeren "servicekonto" kan for eksempel defineres sådan:
apiVersion: user.enmasse.io/v1beta1
kind: MessagingUser
metadata:
name: quarkus-example.app
spec:
username: system:serviceaccount:myapp:default
authentication:
type: serviceaccount
authorization:
- operations: ["send", "recv"]
addresses: ["orders"]
Tilladelser til at konfigurere applikationen
For at AMQ Online kan oprette det configmap, som vi brugte til at indlejre AMQP-slutpunktsoplysningerne, skal Rolle og RoleBinding indstilles:
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: quarkus-config
spec:
rules:
- apiGroups: [ "" ]
resources: [ "configmaps" ]
verbs: [ "create" ]
- apiGroups: [ "" ]
resources: [ "configmaps" ]
resourceNames: [ "quarkus-config" ]
verbs: [ "get", "update", "patch" ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: quarkus-config
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: quarkus-config
subjects:
- kind: ServiceAccount
name: address-space-controller
namespace: amq-online-infra
Sådan anvender du konfigurationer
Du kan anvende meddelelsessystemets konfiguration på denne måde:
cd enmasse-example-clients/quarkus-example-client
oc project myapp
oc apply -f src/main/resources/k8s/addressspace
oc apply -f src/main/resources/k8s/address
Applikationsbekræftelse
For at sikre, at applikationen er startet, lad os først og fremmest kontrollere, om de tilsvarende adresser er blevet oprettet og er aktive:
until [[ `oc get address quarkus-example.prices -o jsonpath='{.status.phase}'` == "Active" ]]; do echo "Not yet ready"; sleep 5; done
Lad os derefter tjekke applikationens rute-URL (bare åbn denne adresse i browseren):
echo "http://$(oc get route quarkus-example-client -o jsonpath='{.spec.host}')/prices.html"
Browseren skal vise, at billetter opdateres med jævne mellemrum, efterhånden som beskeder sendes og modtages af AMQ Online.
Opsummering
Så vi skrev en Quarkus-applikation, der bruger AMQP til meddelelser, konfigurerede applikationen til at køre på Red Hat OpenShift-platformen og implementerede dens konfiguration baseret på AMQ Online-konfigurationen. Vi oprettede derefter de nødvendige manifester for at initialisere meddelelsessystemet til vores applikation.
Dette afslutter serien om Quarkus, men der er en masse nye og interessante ting forude, følg med!
Kilde: www.habr.com