Shared Services der Integrationsplattform¶
Die Integrationsplattform bietet neben deinem spoke vier Shared Services: Service Bus, Event Hubs, API Management und eine Container Registry. Ein Shared Service ist teure oder häufig genutzte Integrationsinfrastruktur, die mehrere Workloads bedient, mit eigenem Lebenszyklus, im Besitz des Plattform-Teams. Diese Seite beschreibt, was pro Service für die Integration spezifisch ist. Die generischen Mechanismen stehen in der MCP-Dokumentation: wie sich ein spoke mit einem Shared Service verbindet (Shared Services) und was jede Spoke- Erweiterung erstellt (Spoke-Erweiterungen).
Optional, pro Plattform festgelegt
Welche Shared Services auf deiner Plattform existieren, in welchen Umgebungen und in welcher Konfiguration, unterscheidet sich pro Plattform. Zwei der folgenden Designs (API Management und Event Hubs) sind in den Entscheidungsdokumenten als Proposed markiert: Sie beschreiben das beabsichtigte Angebot, nicht unbedingt das, was läuft. Frag dein Plattform-Team.
Überblick¶
| Service | Wofür er da ist | Verbindung zu deinem spoke | Details |
|---|---|---|---|
| Service Bus | Enterprise Messaging mit Queues und Topics | extensions.servicebus und die JSON-Automatisierung |
Service Bus |
| Event Hubs | Event-Streaming mit hohem Volumen | extensions.eventhub (ein eigener Event Hub im gemeinsamen Namespace) |
Event Hubs |
| API Management | Ein Gateway, um APIs zu veröffentlichen und abzusichern | extensions.apim, dann APIOps |
API Management |
| Container Registry | Private Container-Images, enthält auch veröffentlichte Plattform-Zutaten | extensions.acr |
Container Registry |
Eine Erweiterung zu aktivieren ist eine Standardänderung: Das Plattform-Team setzt enabled dafür in deiner spoke-Datei auf true, und sie wird
beim nächsten spoke-Deployment wirksam (Spoke-JSON).
Aller Verkehr zwischen deinem spoke und einem Shared Service läuft über die hub-Firewall und braucht eine Regel, wo er nicht schon erlaubt ist. Die Shared Services sind nur über Private Endpoint erreichbar (Architektur).
Welcher Messaging-Service?¶
Die Plattform bietet beide Services, weil sie unterschiedliche Probleme lösen.
| Event Hubs | Service Bus | |
|---|---|---|
| Muster | Event-Streaming (eine Reihe von Events) | Enterprise Messaging (einzelne Nachrichten) |
| Typische Nutzung | Telemetrie, Log-Aggregation, Datenpipelines, Kafka-Workloads, Replay | Bestellungen, Befehle, Request-Reply, Sessions, Transaktionen |
| Consumer | Partitionierte Consumer, mehrere Leser | Competing Consumers, ein Leser pro Nachricht |
| Reihenfolge | Pro Partition | Strikte Reihenfolge mit Sessions |
| Aufbewahrung | Events können erneut abgespielt werden | Gespeichert, bis sie verarbeitet sind |
| Protokolle | AMQP, Kafka, HTTPS | AMQP, HTTPS |
| Fehlgeschlagene Nachrichten | Nicht für Dead-Letter-Behandlung ausgelegt | Dead-Letter-Queues, Deferral, geplante Zustellung |
Wähle Service Bus, wenn Zustellgarantien und Fehlerbehandlung wichtig sind. Wähle Event Hubs für Volumen und Replay.
Container Registry¶
Eine gemeinsame Azure Container Registry enthält private Images für eigene Integrationen und die Pakete der von der Plattform veröffentlichten Zutaten. Sie ist der eine Shared Service im Basis-Deployment des Shared-Services-spokes, weil die Plattform selbst sie braucht.
- Zugriff. Deployment-Identities der Workloads pushen und pullen. Die Erweiterung gibt deinem spoke zwei Gruppen und zwei Managed Identities, eine zum Pullen und eine zum Pushen (Shared Services). Der Zugriff läuft nur über Entra ID. Verwende keine Admin-Keys.
- Images löschen ist dem Plattform-Team vorbehalten, damit Teams die Images der anderen nicht löschen können.
- Nutzung durch Module. Ein Container-App-Modul zieht seine Images mit einer Managed Identity, die du benennst (Module).
- Deployment. Das Referenzdesign deployt eine Registry für die gesamte Landschaft, weil eine Registry nicht teuer ist und keine Geschäftsdaten enthält.
- Verfügbarkeit. In der Referenzanalyse ist die Zonenredundanz der Registry ausgeschaltet, und Container Apps hängen von ihr ab, um Images zu ziehen. Die Analyse empfiehlt, sie zu aktivieren (Verfügbarkeit).
Event Hubs¶
Status: proposed
Das Entscheidungsdokument ist im Status Proposed (ADR-016).
Das Design bietet Azure Event Hubs als Shared Service an, statt eines Event-Hubs-Namespace pro Workload, um die Streaming-Infrastruktur zu zentralisieren und Kosten zu begrenzen.
| Thema | Vorgeschlagenes Design |
|---|---|
| Tier | Premium. Er unterstützt Private Endpoints, isoliert Ressourcen zwischen Tenants, unterstützt Customer-managed Keys und Laufzeit-Audit-Logs, enthält Capture, erlaubt es, Partitionen nach der Erstellung zu erhöhen, und behält Events bis zu 90 Tage. Skaliert in Processing Units (1 bis 16). |
| Warum nicht Standard | Keine Ressourcenisolation, kürzere Aufbewahrung, keine Customer-managed Keys, Capture separat abgerechnet, keine dynamischen Partitionen |
| Warum nicht Dedicated | Höhere Mindestkosten und weniger Elastizität. Zu erwägen, wenn der anhaltende Durchsatz übersteigt, was Premium unterstützt. |
| Netzwerk | Private Endpoints, öffentlicher Netzwerkzugriff aus |
| Verfügbarkeit | Availability Zones werden in den unterstützten Tiers automatisch genutzt |
| Dein Zugriff | Über extensions.eventhub: ein eigener Event Hub im gemeinsamen Namespace. Die Erweiterung gibt deinen Gruppen Owners, Contributors und Readers die Rollen, die unter Was jede Erweiterung erstellt aufgelistet sind. |
API Management¶
Status: proposed
Das Entscheidungsdokument ist im Status Proposed (ADR-015). Monitoring und Hostnamen-Konfiguration sind darin noch nicht beschrieben.
Eine gemeinsame API-Management-Instanz zentralisiert die APIs der Organisation: ein Gateway, einheitliche Authentifizierung, Versionierung und Lebenszyklus, ein Developer Portal, Monitoring, Rate Limiting und Transformation. Sie ist günstiger als eine Instanz pro Workload.
Zwei Angebote¶
| Premium (classic) | Standard v2 | |
|---|---|---|
| Netzwerkisolation | Voll: VNet Injection, nichts direkt exponiert | Reduziert: Private Endpoints und VNet-Integration, öffentlicher Zugriff aus. Die Management Plane und das Developer Portal bleiben öffentlich erreichbar (mit Authentifizierung). |
| Internet-Exposition | Über Application Gateway mit WAF | Über Application Gateway mit WAF |
| Verfügbarkeit | Zonen, optional Multi-Region. 99,95 % in einer Region, 99,99 % in Multi-Region | Eine Region, eine Zone. 99,95 % |
| Skalierung | 1 bis 99 Units (laut Entscheidungsdokument) | 1 bis 10 Units |
| Kosten | Höher | Niedriger |
Das Entscheidungsdokument empfiehlt für die meisten Enterprise-Szenarien Standard v2 mit Private Endpoints und Premium, wenn vollständige Netzwerkisolation eine (regulatorische) Anforderung ist oder Zonenredundanz gebraucht wird. Nutze den Developer Tier der klassischen Familie nur für die Nicht-Produktion, wenn du seine Grenzen akzeptierst. Zonenausfälle führen bei einem Single-Zone-Setup zu einem vollständigen Ausfall. Wo die Plattform in einer Region läuft, kann ein erneutes Deployment über APIOps und Infrastructure as Code die Recovery-Ziele erfüllen.
Exponiere API Management nicht direkt im Internet. Veröffentliche es über das Application Gateway mit WAF. Wenn Workspaces aus sind und Defender for Cloud genutzt wird, kann Defender for APIs die APIs schützen.
Isolation zwischen Workloads: zentral oder Workspaces¶
| Modell | Wie die Isolation funktioniert | Wann |
|---|---|---|
| Zentral (Default) | Eine Instanz. APIs werden durch Products und Subscriptions sowie durch Azure RBAC mit benutzerdefinierten Rollen getrennt. Tags und Namensgebung helfen. | Ein Team verwaltet alle APIs (zentrales Betriebsmodell) |
| Workspaces (Opt-in) | Ein Workspace pro Workload, das APIs bereitstellt. Teams verwalten darin ihre eigenen APIs, Products und Subscriptions. | Dezentrales Modell, wenn die Limits der Workspaces akzeptabel sind |
Workspaces auf dem gemeinsamen Gateway haben Einschränkungen: keine Authentication Policy mit Managed Identity, keine Key-Vault-Integration für Workspace-Secrets, keine GraphQL-Resolver oder -Validierung, keine Authorization-Context-Policies, nur aggregierte Metriken (nicht pro Workspace), keine workspace-spezifischen Analytics, kein Defender for APIs und gemeinsame Compute-Ressourcen mit dem Hauptservice. Die Anzahl der Workspaces ist pro Tier begrenzt (bis zu 30 bei Premium, 5 bei Standard, 1 bei Basic und Developer). Dedizierte Workspace- Gateways werden im Angebot nicht unterstützt, ebenso wenig Self-hosted Gateways. Das Managed Gateway ist der Default.
Die Spoke-Erweiterung spiegelt diese Wahl wider: Im zentralen Modell erhalten deine Gruppen Rollen auf der gesamten Instanz, im dezentralen Modell auf einem eigenen Workspace (Was jede Erweiterung erstellt).
APIOps¶
Workload-Teams pflegen ihre APIs in Git: OpenAPI-Spezifikationen, Policies, Products, Named Values und Konfigurations- Templates für mehrere Umgebungen, deployt über die pipeline. Das ist der GitOps-Gedanke, angewendet auf APIs. Committe keine Subscription Keys; verweise auf Key-Vault-Secrets (Shared Services).
Skalierung und Policies¶
- Die Skalierung erfolgt manuell. Die Integrationsplattform-Engineers beobachten die Last und ändern die Anzahl der Scale Units, dann deployen sie den Shared Service erneut. Die Skalierung verursacht keine Downtime für das Gateway oder das Developer Portal.
- Zwei optionale Policies sind vorgesehen: nur zentrales API Management (Workloads dürfen kein eigenes deployen) und kein öffentlich verfügbares API Management (öffentlicher Zugriff kann nicht aktiviert werden).