Sie haben zwei Microservices in Azure Container Apps: service-a und service-b. Sie möchten, dass service-a service-b aufruft, ohne IPs fest zu codieren, und von Wiederholungsversuchen/Timeouts profitiert. Außerdem müssen Sie den Warenkorbzustand mithilfe eines verwalteten Backends beibehalten, ohne Speicher-SDK-Code schreiben zu müssen. Welche zwei Aktionen sollten Sie durchführen?

Die Aktivierung von Dapr für beide Container Apps und die Zuweisung von App-IDs ermöglicht den Service-Aufruf über Dapr. Durch den Aufruf von http://localhost:3500/v1.0/invoke/service-b/method/{endpoint} kann service-a service-b über den Dapr-Sidecar aufrufen, was automatische Wiederholungsversuche und Timeouts bietet, ohne IPs fest zu codieren. Die Erstellung einer Dapr-Zustandskomponente, die von Azure Cosmos DB unterstützt wird, ermöglicht die Persistenz des Warenkorbzustands. Dapr abstrahiert das zugrunde liegende Speichersystem, sodass service-a die Dapr-Zustands-HTTP-API verwenden kann, um Daten zu speichern und abzurufen, ohne spezifischen SDK-Code für Cosmos DB schreiben zu müssen. Azure Front Door ist ein globaler Lastenausgleich und CDN, der nicht für die interne Service-zu-Service-Kommunikation in Container Apps oder die Zustandspersistenz über Client-Sitzungscookies geeignet ist. Das Einbinden eines Azure Files-Volumes und das Schreiben/Lesen von JSON-Dateien ist eine manuelle und weniger effiziente Methode zur Zustandspersistenz im Vergleich zu Dapr State Management.