Hej alla! Här är det - vårt sista inlägg i Quarkus-serien! (Se förresten vårt webinar . Vi visar dig hur du börjar om från början eller överför färdiga lösningar)
В I det här inlägget tittade vi på de relevanta verktygen som kan användas för att kvantifiera de förbättringar som erhållits som ett resultat av modernisering av Java-applikationer.
Sedan version 0.17.0, stöder användningen av Advanced Message Queuing Protocol (), som är en öppen standard för att överföra affärsmeddelanden mellan applikationer eller organisationer.
är en tjänst byggd på basis av ett projekt med öppen källkod och implementera en plattformsbaserad meddelandemekanism . För mer information om hur det fungerar, se . Idag visar vi dig hur du kombinerar AMQ Online och Quarkus för att bygga ett modernt OpenShift-baserat meddelandesystem med två nya meddelandetekniker.
Det antas att du redan har distribuerat AMQ Online på OpenShift-plattformen (om inte, se ).
Till att börja med skapar vi en Quarkus-applikation som kommer att vara ett enkelt orderhanteringssystem som använder reaktiva meddelanden. Denna applikation kommer att innehålla en ordergenerator som skickar order till en meddelandekö med ett fast intervall, samt en orderprocessor som kommer att behandla meddelanden från kön och generera bekräftelser som kan visas i webbläsaren.
När vi har skapat applikationen visar vi dig hur du bäddar in meddelandesystemets konfiguration i applikationen och använder AMQ Online för att tillhandahålla de resurser vi behöver i systemet.
Quarkus app
Vår Quarkus-applikation körs på OpenShift och är en modifierad version av programmet . Ett komplett exempel på klientsidan kan hittas .
Beställ generator
Generatorn skickar helt enkelt monotont växande order-ID till "order"-adressen var 5:e sekund.
@ApplicationScoped
public class OrderGenerator {
private int orderId = 1;
@Outgoing("orders")
public Flowable<Integer> generate() {
return Flowable.interval(5, TimeUnit.SECONDS)
.map(tick -> orderId++);
}
}
Beställningsprocessor
Orderhanteraren är ännu enklare, den returnerar bara ett bekräftelse-ID till "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äftelseresurser
Bekräftelseresursen är en HTTP-slutpunkt för att lista de bekräftelser som genereras av vår 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
För att ansluta till AMQ Online kommer vår applikation att behöva vissa konfigurationsdata, nämligen: Quarkus-anslutningskonfiguration, AMQP-slutpunktsinformation och klientuppgifter. Det är naturligtvis bättre att hålla alla konfigurationsdata på ett ställe, men vi kommer medvetet att separera dem för att visa de möjliga alternativen för att konfigurera Quarkus-applikationen.
Kontakter
Anslutningskonfiguration kan tillhandahållas vid kompilering med hjälp av en programegenskapersfil:
mp.messaging.outgoing.orders.connector=smallrye-amqp
mp.messaging.incoming.orders.connector=smallrye-amqp
För att göra det enkelt kommer vi bara att använda en meddelandekö för "beställningsadressen". Och "bekräftelser"-adressen i vår applikation kommer att använda en kö i minnet.
AMQP-slutpunkt
Vid kompilering är värdnamnet och portnumret för AMQP-slutpunkten okända, så de måste injiceras. Slutpunkten kan ställas in i configmap som skapas av AMQ Online, så vi kommer att definiera dem genom 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
Referenser
Servicekontotoken kan användas för att autentisera vår applikation till OpenShift. För att göra detta måste du först skapa en anpassad ConfigSource som läser autentiseringstoken från poddens 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);
}
}
Bygg och distribuera applikationen
Eftersom applikationen måste kompileras till en körbar fil krävs en virtuell GraalVM-maskin. För detaljer om hur du ställer in en miljö för detta, se motsvarande instruktioner i .
Sedan, genom att följa instruktionerna som ges där, måste du ladda ner källan, bygga och distribuera vår 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 dessa kommandon kommer applikationen att distribueras, men kommer inte att starta förrän vi har konfigurerat de meddelanderesurser vi behöver i AMQ Online.
Konfigurera meddelandesystemet
Nu återstår bara att ställa in de resurser som vår applikation behöver i meddelandesystemet. För att göra detta måste du skapa: 1) ett adressutrymme för att initiera meddelandesystemets slutpunkt; 2) adress för att konfigurera adresserna vi använder i applikationen; 3) Meddelandeanvändare för att ställa in klientuppgifter.
Adressutrymme
Ett AddressSpace-objekt i AMQ Online är en grupp adresser som delar anslutningsändpunkter och autentiserings- och auktoriseringspolicyer. När du skapar ett adressutrymme kan du ange hur meddelandeslutpunkter ska exponeras:
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
Adress
Adresser används för att skicka och ta emot meddelanden. Varje adress har en typ som bestämmer dess semantik, samt en plan som anger antalet resurser som ska reserveras. Adressen kan till exempel bestämmas så här:
apiVersion: enmasse.io/v1beta1
kind: Address
metadata:
name: quarkus-example.orders
spec:
address: orders
type: queue
plan: brokered-queue
Meddelandeanvändare
För att säkerställa att endast betrodda applikationer kan skicka och ta emot meddelanden till dina adresser måste du skapa en användare i meddelandesystemet. För applikationer som körs på ett kluster kan klienter autentiseras med ett OpenShift-tjänstkonto. Användaren "serviceaccount" kan till exempel definieras så här:
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"]
Behörigheter att konfigurera programmet
För att AMQ Online ska kunna skapa konfigurationskartan som vi använde för att bädda in AMQP-slutpunktsinformationen, måste Roll och RoleBinding ställas in:
---
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
Hur man tillämpar konfigurationer
Du kan tillämpa meddelandesystemets konfiguration så här:
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
Applikationsverifiering
För att se till att applikationen har startat, låt oss först och främst kontrollera om motsvarande adresser har skapats och är aktiva:
until [[ `oc get address quarkus-example.prices -o jsonpath='{.status.phase}'` == "Active" ]]; do echo "Not yet ready"; sleep 5; done
Låt oss sedan kontrollera applikationens rutt-URL (öppna bara den här adressen i webbläsaren):
echo "http://$(oc get route quarkus-example-client -o jsonpath='{.spec.host}')/prices.html"
Webbläsaren ska visa att biljetter uppdateras med jämna mellanrum när meddelanden skickas och tas emot av AMQ Online.
Sammanfattningsvis
Så vi skrev en Quarkus-applikation som använder AMQP för meddelanden, konfigurerade applikationen att köras på Red Hat OpenShift-plattformen och implementerade dess konfiguration baserat på AMQ Online-konfigurationen. Vi skapade sedan de manifest som behövs för att initiera meddelandesystemet för vår applikation.
Detta avslutar serien om Quarkus, men det är mycket nytt och intressant framför oss, håll utkik!
Källa: will.com