Wenn es zu viele Mikroservices gibt
\n\nSie haben Ihren ersten Mikroservice in TypeScript geschrieben. Er funktioniert. Dann den zweiten, dritten, zehnten. Und plötzlich stellen Sie fest, dass Sie mehr Zeit damit verbringen, die Mikroservices überhaupt miteinander kommunizieren zu lassen, als mit dem Schreiben der Geschäftslogik. Timeouts, Retries, Lastverteilung, Traffic-Verschlüsselung, Metriken – all das muss in jedem Service einzeln implementiert werden.
\n\nHier kommt Service Mesh ins Spiel – eine Technologie, die die gesamte Kommunikationsinfrastruktur aus dem Code in eine separate Ebene auslagert. Und ja, sie funktioniert hervorragend mit TypeScript-Mikroservices. In diesem Artikel werden wir anhand realer Codebeispiele praktisch erläutern, wie das funktioniert.
\n\nWas ist Service Mesh in einfachen Worten
\n\nStellen Sie sich vor, jeder Ihrer TypeScript-Mikroservices ist ein Mitarbeiter in einem großen Büro. Ohne Service Mesh muss jeder Mitarbeiter selbst seine Kabel verlegen, sein Telefon einrichten und darauf achten, dass er nicht abgehört wird. Mit Service Mesh kümmert sich eine spezielle IT-Abteilung darum, die jedem Mitarbeiter einen „persönlichen Assistenten“ (Sidecar Proxy) zur Seite stellt.
\n\nIn der Technologiewelt heißt dieser Assistent Envoy Proxy, und die gesamte Infrastruktur wird von einem Orchestrator wie Istio oder Linkerd verwaltet. Das Beste daran: Ihr TypeScript-Code bleibt nahezu unverändert.
\n\nWichtige Funktionen von Service Mesh
\n\n- \n
- Traffic Management – intelligentes Routing, A/B-Tests, Canary-Releases \n
- Security – automatische mTLS-Verschlüsselung zwischen Services \n
- Observability – Metriken, Logs, Tracing „out of the box“ \n
- Resilience – Retries, Circuit Breaker, Timeouts auf Infrastrukturebene \n
Warum TypeScript-Mikroservices besonders von Service Mesh profitieren
\n\nTypeScript ist eine Sprache mit einem starken Typsystem, aber seine primäre Laufzeitumgebung (Node.js) ist nicht gerade für ihre I/O-Leistung bekannt. Wenn Sie einen Mikroservice in TypeScript schreiben, bedeuten jede zusätzliche HTTP-Anfrage, jede manuelle Implementierung von Retries oder jeder TLS-Handshake eine zusätzliche Belastung für die Event Loop.
\n\nService Mesh übernimmt diese Last. Ihr TypeScript-Code bleibt sauber: Er nimmt einfach Anfragen entgegen und beantwortet sie, während Envoy die gesamte „Infrastrukturarbeit“ erledigt. Dies ist besonders wichtig, wenn Sie Dutzende von Mikroservices haben – jeder mit seiner eigenen Logik für Wiederholungsversuche und Timeouts.
\n\nPraktisches Beispiel: TypeScript-Mikroservice unter Service Mesh
\n\nStellen wir uns vor, wir haben zwei Mikroservices in TypeScript: user-service und order-service. Der Order-Service muss Benutzerdaten abrufen. Ohne Service Mesh würden wir etwa Folgendes schreiben:
// Ohne Service Mesh – manuelles HTTP-Management\nimport axios from 'axios';\n\nclass UserClient {\n private baseUrl = 'http://user-service:3000';\n private retries = 3;\n\n async getUser(id: string): Promise<User> {\n for (let i = 0; i < this.retries; i++) {\n try {\n const response = await axios.get(`${this.baseUrl}/users/${id}`, {\n timeout: 5000,\n httpsAgent: new https.Agent({ rejectUnauthorized: true })\n });\n return response.data;\n } catch (error) {\n if (i === this.retries - 1) throw error;\n await delay(1000 * Math.pow(2, i));\n }\n }\n }\n}\n\nUnd mit Service Mesh wird daraus:
\n\n// Mit Service Mesh – einfacher HTTP-Request\nimport axios from 'axios';\n\nclass UserClient {\n async getUser(id: string): Promise<User> {\n const response = await axios.get(`http://user-service/users/${id}`);\n return response.data;\n }\n}\n\nHaben Sie den Unterschied bemerkt? Die gesamte Komplexität – Retries, Timeouts, Verschlüsselung – ist