Ein einzelnes Backend wurde für ein expandierendes Gesundheits- und Ernährungsunternehmen zu klein. AI Chatbot-Verkehr, die massive Aufnahme von Wearable-Daten und alltägliche API-Anfragen konkurrierten alle um dieselben Ressourcen – was das System schwer skalierbar und riskant in der Bereitstellung machte. Wir haben es in fokussierte, unabhängig bereitstellbare Services re-architekturiert, die hinter einem einzigen API gateway auf AWS orchestriert werden.
Die Herausforderung
- Eine Codebasis für alle Aufgaben. Ein Workflow umfasste Benutzerverwaltung, AI Chatbot-Inferenz, Rezepte und Gesundheitsdatenanalyse. Eine Spitze in einem beliebigen Bereich beeinträchtigte die gesamte Plattform, und jede Änderung bedeutete die Neuimplementierung des Ganzen.
- Extrem unterschiedliche Ressourcenprofile. LLM-gestĂĽtzte Chatbot-Anfragen sind CPU- und speicherintensiv sowie stoĂźweise; die Aufnahme von Wearable-Daten ist schreibintensiv und kontinuierlich; Kern-CRUD APIs sind leichtgewichtig und konstant. Einen Server fĂĽr alle drei zu dimensionieren bedeutete, fĂĽr einige Workloads zu viel zu bezahlen und andere zu unterversorgen.
- Unabhängige Skalierung und Bereitstellung. Das Team musste die AI-Workload skalieren, ohne die Kern-API zu berühren, und Änderungen an einer Domain bereitstellen, ohne die anderen zu gefährden.
Ein einziger, sicherer Eingangspunkt. Trotz mehrerer Backend-Services benötigten Clients (mobil, Web, Admin) eine konsistente, authentifizierte Oberfläche für die Kommunikation – ohne die interne Service-Topologie nach außen preiszugeben.
Unsere Lösung
Wir haben die Plattform in drei fokussierte NestJS-Services hinter einem AWS Application Load Balancer aufgeteilt, wobei der Hauptserver als API gateway und Orchestrator fungiert. Er verwaltet die Authentifizierung und die Kerndomains und delegiert spezialisierte Aufgaben über authentifizierte REST an die Chatbot- und Gesundheits-Microservices. Eine gemeinsame Daten- und Messaging-Schicht hält die Services lose gekoppelt, aber konsistent.
Architektur
- Main Server (NestJS) — API gateway und Orchestrator: Authentifizierung, Benutzer, Ziele, Rezepte, Terminplanung und Benachrichtigungen. Alle Clients haben einen einzigen öffentlichen Zugangspunkt.
- Chatbot Microservice (NestJS) — Konversationsdienst für AI, betrieben von Azure OpenAI (GPT-4o) über LangChain/LangGraph, mit Elasticsearch-gestütztem RAG für Rezept- und Wissensabruf.
- Health Microservice (NestJS) — nimmt Wearable- und manuelle Gesundheitsdaten (Apple Health, Health Connect) auf, aggregiert sie und stellt Analysen bereit.
- AWS ECS Fargate fĂĽhrt die drei containerisierten Services aus, jeder mit eigener CPU-/Speicherdimensionierung und Skalierungsrichtlinie.
- Application Load Balancer beendet HTTPS und leitet den Datenverkehr pfadbasiert an den richtigen Service weiter.
- Gemeinsame Datenschicht — MongoDB Atlas (primärer Speicher), Redis (Cache/Sessions), Elasticsearch (Suche), ActiveMQ (asynchrone Benachrichtigungszustellung).
Hauptmerkmale
1. Orchestrator-Muster. Der Hauptserver ist der einzige Dienst, der Clients zugänglich gemacht wird. Er authentifiziert jede Anfrage und führt dann interne Service-to-Service-Aufrufe aus – so bleibt die Backend-Topologie privat und die Client-Integration einfach.
2. Authentifizierte Service-to-Service-Aufrufe. Die Inter-Service-Kommunikation erfolgt ĂĽber REST ĂĽber einen gemeinsam genutzten HTTP-Client, gesichert mit dienstspezifischen Bearer API-Keys:
// Hauptserver delegiert eine AI-Anfrage an den Chatbot-Microservice const reply = await this.microserviceClient.post( this.chatbotApiKey, // dienstspezifischer Bearer-Key `${this.chatbotUrl}/chat`, { user, question, sessionId, attachment }, ); |
3. Unabhängige Skalierung pro Workload. Jeder Service ist eine separate Fargate-Task-Definition mit eigener Dimensionierung – der speicherintensive Chatbot-Service skaliert unabhängig von der leichtgewichtigen Kern-API, sodass AI-Verkehrsspitzen alltägliche Anfragen nie ausbremsen.
4. Richtig dimensionierter AI-Service mit integrierter Ausfallsicherheit. Der Chatbot-Service rotiert über mehrere Azure OpenAI-Keys und schaltet bei Ratenbegrenzungen oder Fehlern automatisch um – so bleiben AI-Funktionen unter Last reaktionsfähig.
5. Benachrichtigungen über asynchrones Messaging. Da ActiveMQ-Verzögerungswarteschlangen zeitbasierte Hinweise und Erinnerungen vom Anfrage-Stream trennen, beeinträchtigt oder verlangsamt die Benachrichtigungszustellung niemals den Kern-API-Verkehr.
6. Wiederholbare, isolierte Bereitstellungen. Von ECR bis ECS wird jeder Dienst als eigenes Docker-Image ausgeliefert. Eine Änderung am Health-Service führt lediglich zur erneuten Bereitstellung des Health-Services – schnelle, risikoarme Releases mit Rolling Updates, die auf ihre Funktionsfähigkeit überprüft werden.
7. Ein konsistenter Client-Vertrag. Mobile (React Native) und das Admin-Dashboard kommunizieren alle mit einem einzigen, lastverteilten HTTPS-Eingangspunkt – die interne Aufteilung in Microservices ist für sie unsichtbar.
Ergebnisse
- Heutzutage skalieren die Workloads für AI Chatbots, Gesundheitsdaten und Kern-APIs separat; keine Aufgabe kann die anderen beeinträchtigen.
- Jeder Dienst wird eigenständig bereitgestellt, wodurch risikoreiche plattformweite Releases zu schnellen, isolierten Updates werden.
- Die Rechenleistung ist pro Service richtig dimensioniert, wodurch die Überprovisionierung eines Einheits-Servers entfällt.
- Ein einziger sicherer, lastverteilter Eingangspunkt hält die Client-Integration einfach, während das Backend privat und modular bleibt.
Technologie-Stack
NestJS · TypeScript · Node.js 20 · Azure OpenAI (GPT-4o) · LangChain · MongoDB Atlas · Redis · Elasticsearch · ActiveMQ · AWS ECS Fargate · Application Load Balancer · Amazon ECR · Docker
Weitere Blogbeiträge
1. Wie wir Video-Verarbeitungs-Workloads mit AWS ECS skalieren
2. Wie wir Amazon ECR zur Verwaltung und Bereitstellung von Container-Images nutzen
3. Wie wir AWS EC2 für Workloads in hochleistungsfähiger Videoverarbeitung nutzen
