Freigeben über

  • Artikel

Februar 2017

Band 32, Nummer 2

Dieser Artikel wurde maschinell übersetzt.

Azure: Interna der Azure App Service-Architektur

Durch Yochay Kiriaty | Februar 2017

Azure App Service ist eine hervorragende Plattform als Dienst (PaaS), bietet eine Anwendungsplattform für Entwickler zum Erstellen von Web, Mobile und API-Anwendung betrachtet. Seine Angebote zwischen einfachen Marketing und Digital Anwesenheit für skalierbare e-Commerce-Lösungen und hyperskalierbaren, anpassbare Anwendungen.

App Service ist vollständig verwaltet, was bedeutet, dass keine administrativen Aufgaben sind erforderlich, um die Unterstreichung Compute-Infrastrukturen (Server) zu verwalten, auf denen die Anwendung ausgeführt, wird. Sie müssen die Serverwartung Unterstreichung kümmern, wie die Plattform das Betriebssystem und die Frameworks für Sie patches. Ihre Anwendung auf virtualisierten Servern ausgeführt wird, jedoch sollten Sie nur darauf zum Festlegen von der maximalen Anzahl von Serverinstanzen, auf denen die Anwendung ausgeführt werden soll. Die Plattform-Handles, die Skalierung, wenn eine Anwendung zusätzliche muss compute-Ressourcen und zur gleichen Zeit, den Lastenausgleich für Datenverkehr über mehrere Instanzen der Anwendung verarbeitet.

Während die App Service-Team empfiehlt es sich um keine Unterstreichung Implementierungsdetails auszublenden ausführt, ist es gut, achten Sie unterhalb der Abdeckung Funktionsweise. Dieser Artikel behandelt die grundlegende interne Architektur für App-Service (wie der Dienst wird erstellt und ausgeführt wird) und bietet einige bewährte Methoden für bestimmte Szenarios.

Globale und geografisch verteilten Architektur

Cloud-computing schnell skaliert und endlose Kapazität. Cloud-Niveau kann als auf einem Computerbildschirm erläutert werden. Aus der Ferne zu suchen und Sie ein Bild löschen und komfortable finden Sie unter. Wenn Sie genauer hinsehen, beachten Sie, dass das Bild auf dem Bildschirm aus vielen kleinen Pixel besteht. Viele Server besteht aus die Cloud, wie ein Bild. App Service-Clustern bunches von Servern in einer einzigen Einheit "Skalierungseinheit" (oder einem "Stempel") genannt. Es gibt viele dieser Mengen-Einheiten in der ganzen Welt in Azure-Datencentern.

Als Teil von Azure hat die App Service globale. In jeder Region unterstützte Azure finden Sie App Service-Skalierungseinheiten Arbeitslasten (Applications) und Sätze von regionale Kontrolle Einheiten Kunden ausgeführt. Steuerelement Einheiten transparent an den Kunden (bis diese Fehlfunktion), und als Teil der Plattform. Es ist ein spezielles Steuerelement-Einheit, die als Gateway für alle Management-API-Aufrufe verwendet wird. Z. B. wenn ein Kunde eine Anforderung zum Erstellen einer neuen Anwendung, über das Portal, Befehlszeilen-Schnittstelle oder direkt über die Azure-REST-API stellt die Anforderung wird weitergeleitet an einen zentralen Azure-Endpunkt (management.azure.com). Der Azure-Ressourcen-Manager oder ARM (bit.ly/2i6UD07), können Sie mit anderen Azure-Ressourcen in Ihrer Anwendung als eine einzelne Gruppe. Von ARM definierte API können Sie Azure-Ressourcen zu verwalten. ARM verwalten nicht tatsächlich einzelne Ressourcen. Jeder Dienst in Azure hat eine eigene Implementierung der Management-API, die als Proxys von ARM ist. Im Fall von App Service leitet ARM App Service-API-Aufrufe zum App Service Geo-Master.

Die Geo-Master hat Kontext über alle Skalierungseinheiten weltweit. Z. B. Wenn Sie eine neue App Service-Anwendung (oder Website) erstellen, Geo-Master sucht nach den am besten geeigneten Mengen-Einheit für die Anwendung und die Create-Anforderung an der entsprechenden Skalierungseinheit weitergeleitet. Die Skalierungseinheit ist jetzt damit beauftragt, mit eine neue app-Bereitstellung und alle erforderlichen Ressourcen zuweisen. Abbildung 1 zeigt den Fluss der Erstellen einer neuen app.

Globale Verbreitung von App Service-Skalierungseinheiten
Abbildung 1 globale Verbreitung von App Service-Skalierungseinheiten

Dies ist der Prozess zum Erstellen einer neuen app:

  1. Benutzer stellt eine Anforderung zum Erstellen einer neuen Website.
  2. ARM wird sichergestellt, Benutzer hat Zugriff auf die Ressource, die den angegebenen Vorgang zulassen (in diesem Fall erstellen) und leitet die Anforderungen zu App Service Geo-Master.
  3. Geo-Master findet die am beste geeigneten Skalierungseinheit für die Anforderung des Benutzers und leitet die Anforderung.
  4. Die Skalierungseinheit erstellt die neue Anwendung.
  5. Geo-Master meldet Erfolg bei der erstellungsanforderung.

Es ist, zwar wichtig zu verstehen, dass App-Dienst viele Skalierungseinheiten hat wird die Anwendung in der Regel innerhalb einer einzelnen App Service-Skalierungseinheit ausgeführt. Selbst wenn Azure Traffic Manager in mehreren Regionen ausgeführt, wird die Anwendung in zwei oder mehr separate Skalierungseinheiten ausgeführt. Aus den einzelnen Skalierung Einheit Sicht, wird jedoch Ihre app in einer einzelnen Skalierungseinheit eingeschränkt.

Was ist ein Anwendungsdienst Mengen-Einheit?

Eine App Service-Skalierungseinheit ist eine Sammlung von Servern, die hosten und Ausführen der Anwendung. Eine normale Mengen-Einheit kann mehr als 1.000 Server verfügen. Das clustering von Servern ermöglicht, Größenvorteile und Wiederverwendung von gemeinsam genutzten Infrastruktur. Der wesentliche Baustein von App Service-Skalierungseinheit ist ein Azure Cloud Service-Bereitstellung (Beachten Sie, dass App-Dienst erstmalig als Vorschau im Juni 2012). Alle angegebenen Mengen-Einheit unabhängig und kann eigenständig ausgeführt werden.

Skalierung Einheit Main-Bausteine

Die wichtigste Funktionen des Skalierungseinheit ist zum Hosten und Ausführen von kundenanwendungen. Anwendungen auf Windows-Servern ausgeführt und sind als Web-Worker oder Mitarbeiter kurz bezeichnet. Die meisten der Server in einer bestimmten Skalierungseinheit sind Mitarbeiter. Eine Maßeinheit verfügt jedoch über mehrere zusätzliche Unterstützung Server erforderlich, um die Funktionalität von App Service zu erreichen. Unterstützung von Servern über Rollen, und jede Rolle auf mehrere Instanzen für Redundanz und der Dezimalstellenanzahl bereitgestellt wird.

Front-End

Front-End ist eine Layer 7-Lastenausgleich, fungiert als Proxy und Verteilen von eingehenden HTTP-Anfragen zwischen verschiedenen Komponenten und die jeweiligen Mitarbeiter. Derzeit ist der Anwendungsdienst Lastenausgleichsalgorithmus einen einfachen Roundrobin zwischen einer Gruppe von Servern, die für eine bestimmte Anwendung zugeordnet.

Web-Worker

Mitarbeiter sind das Rückgrat von App Service-Mengen-Einheit. Die Ausführung der Anwendung.

Mit App Service können Sie auswählen, wie die Anwendung ausgeführt werden sollen. Sie können die Ausführung Ihrer Anwendung auf gemeinsam genutzte oder dedizierte Server auswählen. Dazu müssen Sie eine App Service-Plan auswählen. Eine App Service-Plan definiert einen Satz von Funktionen, Funktionen und Server-Zuordnungen. Eine freigegebene Worker hostet Applikationen von mehreren unterschiedlichen Kunden dort dedizierte Worker garantiert mindestens eine Anwendung eines einzelnen Kunden ausgeführt. Es gibt mehrere dedizierte Server-Typen und Größen, aus denen Sie auswählen können. Je größer die Servergröße sind CPU- und weitere Ressourcen für zugeordnete Anwendung verfügbar. App Service-Plan definiert die Größe des reservierten Server für Ihre Anwendung.

Eine App Service-Skalierungseinheit hat mehrere Pools mit Arbeitsthreads vorab bereitgestellt und bereit ist, Ihre Anwendung zu hosten, wie in dargestellt Abbildung 2, Abschnitt 1. Wenn Sie dedizierte App Service-Plan auf eine Größe von zwei Servern definieren, App-Dienst ordnet zwei Server, wie in dargestellt Abbildung 2, Abschnitt 2. Weiter, wenn Sie die App Service-Plan skalieren – beispielsweise durch Hinzufügen von zwei weitere Arbeitskräfte – verfügbare Mitarbeiter werden aus einem Pool von Arbeitsthreads bereit für unterwegs-zugeordnet, wie in dargestellt Abbildung 2, Abschnitt 3. Da Workern bereits vorab bereitgestellt und warme, muss ausgeführt werden, lediglich für die Anwendung auf die Worker bereitgestellt werden. Sobald die Anwendung bereitgestellt wird, der Arbeitsthread die Drehung eingefügt wird, und Front-End kann Datenverkehr zu reservieren. Dieser gesamte Prozess dauert in der Regel wenige Sekunden.

Anwendung der Serverprozess in App Service-Skalierungseinheit
Abbildung 2: Server-Anwendungsprozess in App Service-Skalierungseinheit

Abbildung 2, Abschnitt 4 zeigt mehrere App Service-Plänen, als mehrfarbigen Rechtecke, identifiziert jedes darstellt, eine App Service-Plan, die für mehrere Kunden gehören können.

Dateiserver

Jede Anwendung benötigt Speicher für Inhalte wie HTML, JS-Dateien, Bilder oder Codedateien und andere Inhalte für die Anwendung erforderlich sind. Ein Dateiserver lädt Azure Storage-Blobs und macht sie als Netzlaufwerke, die der Arbeitsthread verfügbar. Ein Worker ordnet, solche Netzwerklaufwerke als lokale, sodass jede Anwendung, die auf alle angegebenen Worker ausgeführt, die "local" Laufwerk zu verwenden, wie Sie erwarten würden, wenn die Anwendung auf einem Server mithilfe der lokalen Festplatte ausgeführt wurden. Beliebigen dateibezogene Lese-Schreib-Operation von der Anwendung durchläuft einen Dateiserver aus.

API-Controller

API-Controller können als Erweiterung zu App Service Geo-Master angezeigt werden. Während der Geo-Master alle App Service-Anwendung über alle Skalierungseinheiten kennt, ist es der API-Controller, der tatsächlich die Management-Vorgang ausführt, der Ihre Anwendung auswirkt. Geo-Master Delegaten API Erfüllung einer bestimmten Skalierungseinheit über die API-Controller. Z. B. nach Geo-Master einen API-Aufruf eine neue Anwendung erstellt wird, organisiert die API-Controller die erforderlichen Schritte zum Erstellen der Anwendung an die Skalierungseinheit. Wenn Sie Azure-Portal zum Zurücksetzen Ihrer Anwendung verwenden, ist es der API-Controller, der alle Web-Worker derzeit zugeordneten auf Ihre Anwendung für den Neustart der app benachrichtigt.

Herausgeber

Azure App Service unterstützt FTP-Zugriff auf eine Anwendung. Da app-Inhalt in Azure Storage-Blobs gespeichert und vom Dateiserver zugeordnet, hat die App Service eine Rolle "Herausgeber" FTP-Funktionalität verfügbar zu machen. Die Verleger-Rolle kann Kunden, die Verwendung von FTP Zugriff auf ihre Anwendungsinhalt und Protokolle.

Es ist wichtig zu beachten, dass es viele verschiedene Arten zum Bereitstellen von Anwendungen als FTP. Einer der häufige Bereitstellungsmethoden ist Web Deploy (in Visual Studio) oder eines der unterstützten weiterhin Bereitstellungsoptionen wie Visual Studio-Freigabe-Manager oder GitHub.

SQL Azure

Jede Mengen-Einheit App Service verwendet Azure SQL-Datenbank, um Metadaten für die Anwendung beizubehalten. Jede Anwendung, die eine bestimmte Maßeinheit zugewiesen ist, hat eine Darstellung in einer SQL-Datenbank. Der SQL-Datenbank wird auch verwendet, um Laufzeitinformationen zu speichern.

Daten-Funktion

Alle Rollen sind erforderlich, Daten in der Datenbank ausgeführt werden. Als Beispiele: einen Web-Worker Konfigurationsinformationen benötigt werden, wenn eine app starten Front-Ends müssen wissen, welche Server zum Ausführen einer bestimmten Anwendung um die ordnungsgemäße Weiterleitung des HTTP-Anforderungen an die entsprechenden Server zugewiesen werden. und Domänencontrollern lesen und Aktualisieren von Daten aus der Datenbank basierend auf API-Aufrufe, die von Kunden. Die Rolle der Daten kann als eine Cacheebene zwischen SQL-Datenbank und alle anderen Rollen in einer bestimmten Maßeinheit beschrieben werden. Es abstrahiert die Datenschicht (SQL-Datenbank) vom Rest der Rollen, Skalierung und Leistung verbessert werden, als auch Software-Entwicklung und Wartung vereinfacht.

Weniger als offensichtliche Best Practices

Jetzt wissen Sie, wie Azure App Service erstellt wird sehen wir uns einige Tipps und Tricks aus der App Service-Team. Hierbei handelt es sich um praktische Erfahrungen von App Service-Entwicklungsteams von Numerus Kundenprojekten.

Steuern der Dichte

Die Mehrzahl der Kunden, die eine geringe Anzahl (weniger als 10) von Applikationen pro App Service-Plan ausführen. Es gibt jedoch viele Szenarios, in denen Kunden viele weitere Anwendungen ausgeführt werden. Es ist wichtig, um zu verhindern, dass versehentlich über eine Compute-Kapazität der zugrunde liegenden Server.

Beginnen wir mit der Hierarchie der Anwendung und deren computeressourcen. Es gibt zwei Web-apps und eine mobile Back-End-app, die dieser App Service-Plan zugeordnet. Der Plan wird auf zwei Servern festgelegt.

Führen alle Programme, die in einer bestimmten App-Service-Plan enthaltenen standardmäßig auf alle verfügbaren Compute-Ressourcen (Server), Service-Plan zugeordnet. Alle drei Anwendungen, die auf beiden Servern ausgeführt werden. Im einfachen Fall einer App Service-Plan einen einzelnen Server hat, ist es einfach zu verstehen: Die Komponenten in App Service-Plan ausführen auf einem einzelnen Server.

Es ist weniger intuitiv, was geschieht, wenn es mehrere Compute-Ressourcen, die Ihre App Service-Plan zugeordnet sind. Beispielsweise berechnen hat eine einzelne App-Service-Plan, wenn 10 Ressourcen, und klicken Sie dann jede app in den Anwendungsdienst auf jeder Compute-Ressource ausgeführt wird. Wenn 50 Programme in App Service-Plan sind, alle 50 wird auf dem ersten Server ausgeführt werden und die gleichen 50 wird auf dem zweiten Server ausgeführt werden und usw., mit dem 10. Server, die auch führt alle 50 apps.

Für einige Szenarien, in denen Ihre Anwendung viele Compute-Ressourcen in der Regel an einen Anstieg in der eingehenden HTTP-Anforderungen behandeln erfordert, sollten Sie Ihre Anwendung auf alle verfügbaren Server ausgeführt wird. Dies ist jedoch auch eine unbeabsichtigte Folge, die bei einer App Service-Plan von einem Server zu viele skaliert wird. Wenn eine App Service-Plan CPU bzw. Arbeitsspeicher aufgrund einer großen Anzahl von Clientanwendungen, die ausgeführt wird ist, erhöhen die Anzahl der Server, App Service-Plan wird nicht das Problem behoben.

Stattdessen sollten Sie die Verteilung des Netzwerkdatenverkehrs für jede Anwendung und trennen Sie long Tail von apps mit geringem Volumen in eine separate App-Service-Plan zu. Können Sie apps mit hohem Volumen in separaten App Service-Pläne ausführen. 50 mit app-Beispiel weiter oben, nach dem Muster im Datenverkehr analysieren Sie am Ende der folgenden Zuordnung zu App Service-Pläne und compute-Ressourcen:

  • 40 mit geringem Volumen Applikationen verbleiben in einer einzelnen App Service-Plan auf eine Ressource ausgeführt wird.
  • Fünf Mitte bis geringe Volume-Anwendung verwenden, einen zweiten App Service-Plan auf eine Ressource ausgeführt wird.
  • Die verbleibenden fünf Applikationen gefunden umfangreicher Verwendung aufweisen. Jede Anwendung wird auf eine separate App-Service-Plan bereitgestellt.  Eine Regel für automatische Skalierung wird in jeder App Service-Plan verwenden Sie mindestens eine Ressource, mit Regeln in/Out-Basis der CPU und arbeitsspeicherauslastung skalieren festgelegt.

Das Ergebnis dieses Ansatzes ist, die 50-apps verwenden sieben Serverressourcen mindestens mit den fünf Anwendungen mit hohem Volumen jeweils mit den erforderlichen Spielraum bei Bedarf unabhängig voneinander skalieren anhand der Last.

App-Skalierung

Eine Alternative zur Ausführung einer großen Anzahl von Applikationen auf effizientere Weise ist die app-Skalierung von Azure App Service verwendet. Das Dokument, bit.ly/2iQUm1S app-Skalierung ausführlich behandelt. Pro App-Skalierung können Sie die maximale Anzahl von Servern, die einer bestimmten Anwendung zugeordnet, und Sie können dies tun, pro Anwendung. In diesem Fall wird eine Anwendung auf die definierte maximale Anzahl von Servern und nicht auf alle verfügbaren Server ausgeführt.

Verwenden die früheren 50 app-Beispiel mit app-Skalierung für die App Service-Plan aktiviert alle 50 apps können die gleiche App-Service-Plan zugewiesen werden. Anschließend können die Skalierung Merkmale der einzelnen apps geändert werden:

  • 40 mit geringem Volumen-Clientanwendungen, die auf bis zu einem einzelnen Server wird jede Ausführung festgelegt.
  • Fünf mid - um mit geringem Volumen-Clientanwendungen, die auf beiden Servern ausgeführt.
  • Fünf verbleibenden Anwendungen mit hohem Volumen auf maximal 10 Servern ausgeführt werden.

Die zugrunde liegende App-Service-Plan kann mit mindestens fünf Server beginnen. Und Regeln zur automatischen Skalierung können festgelegt werden, um als Grundlage Arbeitsspeicherbedarf Druck im Vergleich zu skalieren. CPU.

Azure App Service wird die Zuweisung von Applikationen auf Serverressourcen automatisch behandelt. Der Dienst wird ebenfalls automatisch behandeln beschränken die maximale Anzahl der ausgeführten Anwendungsinstanzen basierend auf der Anzahl der Worker für jede einzelne Anwendung festlegen. Daher führt erhöht die Anzahl der Worker in App Service-Plan nicht zu 50 app-Instanzen, die auf jeder verfügbaren virtuellen Maschine dreht. 

Zusammenfassend lässt sich sagen, packs"pro app-Skalierung" Applications auf den zugrunde liegenden Servern eine App Service-Plan zugeordnet. App-Skalierung führt nicht in jeder Anwendung, die auf jeder Compute-Ressource, die eine App Service-Plan zugeordnet, wie zuvor beschrieben.

Application-Steckplätze

App Service bietet ein Feature namens "bereitstellungsslots" (bit.ly/2iJzv3f). Kurz gesagt, kann ein bereitstellungsslot Sie eine andere Anwendung (Slot) als Ihre Produktions-app. Es ist eine andere Anwendung, die Sie, zum Testen von neuen Codes verwenden können vor der in die Produktion überführen.

Anwendung Slots gehört zu den am häufigsten verwendeten Funktionen in App Service. Allerdings ist es wichtig zu verstehen, dass jede Anwendung Slot auch eine Anwendung einen eigenen rechts. Dies bedeutet, dass Anwendung Slots benutzerdefinierte Domänen zugeordnet werden, andere SSL-Zertifikate, verschiedene Einstellungen usw. können. Dies bedeutet auch, dass die Zuweisung von einer Anwendung-Steckplatz für eine App Service-Plan aus der App Service-Plan zugeordneten main Produktions-Steckplatz separat verwaltet werden kann.

Standardmäßig wird jede Anwendung Slot in der gleichen App Service-Plan als Produktions-Steckplatz erstellt. Dieser Ansatz ist für Anwendungen mit geringem Volumen und/oder Applikationen mit geringer Auslastung von CPU, Speicher in Ordnung.

Da alle Anwendungen in einer App Service-Plan auf denselben Servern ausgeführt werden, bedeutet jedoch standardmäßig alle von einer Anwendung Steckplätze auf genau dieselbe zugrunde liegende Server wie Produktion ausgeführt werden. Dies kann auf Probleme, z. B. CPU oder Arbeitsspeicher Einschränkungen führen, wenn Belastungstests für nicht-produktionsslots ausgeführt, die auf dem gleichen Server wie Produktions-Anwendung ausgeführt werden soll.

Wenn Ressourcen nur für Szenarien wie z. B. das Ausführen von Auslastungstests festgelegt ist, dann vorübergehend in einer anderen App Service-Plan, mit einem eigenen Satz von Servern, verschieben einen Steckplatz geschieht Folgendes:

  • Erstellen Sie zusätzliche App Service-Plan für die nicht-produktionsslots. Wichtiger Hinweis: Jede App Service-Plan muss in der gleichen Ressourcengruppe und derselben Region wie die Produktions-Steckplatz App Service-Plan.
  • Verschieben Sie einen nicht-Produktions-Steckplatz zu einer anderen App-Service-Plan und somit ein separater Pool von Compute-Ressourcen.
  • Ressourcenintensive (oder riskant) Aufgaben während der Ausführung in separaten App Service-Plan ausführen. Auslastungstests können z. B. für eine nicht-produktionsslot ausgeführt werden, ohne negative Auswirkungen auf die Produktions-Steckplatz, da es keine Ressourcenkonflikte werden.
  • Wenn der nicht-Produktions-Steckplatz in die Produktion ausgetauscht werden bereit ist, verschieben Sie sie zurück auf die gleiche App Service-Plan Produktions-Steckplatz ausführen. Dann kann der Auslagerungsvorgang Slot durchgeführt werden.

Bereitstellung in der Produktion ohne Ausfallzeiten

Sie haben erfolgreiche eine Anwendung auf eine App Service-Plan ausgeführt wird, und Sie haben ein großartiges Team damit Updates für Ihre Anwendung auf täglicher Basis. In diesem Fall möchten Sie die Bits direkt in die Produktion bereitstellen. Sie möchten die Bereitstellung und Minimieren der Ausfallzeit. Dafür können Sie Ihre Anwendung Steckplätze. Legen Sie die Bereitstellung auf den Slot "Pre-Production" der Produktions-Einstellung konfiguriert werden kann, und den neuesten Code bereitstellen. Sie können nun sicher auf Ihre app testen. Sobald Sie zufrieden sind, können Sie die neuen Version in die Produktion überführen. Der Auslagerungsvorgang nicht die Anwendung neu starten, und im Gegenzug die benachrichtigt des Front-End-Lastenausgleichs zum Umleiten von Datenverkehr auf die neueste Slots.

Einige Programme müssen zum Aufwärmen, bevor sie problemlos die Produktionslast verarbeiten können, z. B. wenn die Anwendung muss zum Laden von Daten in den Cache oder eine Anwendung .NET die .NET Runtime JIT Ihre Assemblys kann. In diesem Fall sollten Sie auch mit der Anwendung Slots warme die Anwendung, bevor diese in Produktion geht.

Häufig sehen wir Kunden, bei denen einen Pre-Production-Steckplatz, der zum Testen und Aufwärmen von der Anwendung verwendet wird. Kontinuierliche Bereitstellung Tools wie Visual Studio Release Manager können zum Einrichten einer Pipeline vom Code in der Pre-Production Steckplätze, führen Sie für die Überprüfung testen, und alle erforderlichen Pfade in Ihrer app, bevor diese in Produktion geht warme bereitgestellt werden.

Scale Unit-Netzwerkkonfiguration

Die App Service-Skalierungseinheit ist auf Cloud-Dienst bereitgestellt. Daher bedeutet es einige Netzwerkkonfiguration und die Funktionen, die Sie zum Verständnis der Effekte Netzwerk auf Ihre apps mit vertraut werden können.

Der Mengen-Einheit verfügt über eine einzelne VIP (Virtual IP)-Adresse, die auf der ganzen Welt verfügbar gemacht. Alle Programme, die eine bestimmte Maßeinheit zugeordnet werden durch diese VIP bedient. Die VIP-Adresse ist die Darstellung des Cloud-Diensts auf dem die App Service-Skalierungseinheit bereitgestellt wird.

App Service-Anwendung dienen nur HTTP (Port 80) und HTTPS (Port 443)-Datenverkehr. Jede App Service-Anwendung hat standardmäßig integrierte HTTPS für den Domänennamen *.azurewebsites.NET zu unterstützen. App Service unterstützt Zertifikate für Server Name Angabe (SNI) und IP-basierte Secure Sockets Layer (SSL). Im Fall von IP-basiertes SSL ist eine bestimmte Anwendung eine dedizierte IP-Adresse für eingehenden Datenverkehr zugeordnet, die die Bereitstellung von Cloud-Dienst zugeordnet ist. Hinweis: Front-Ends beendet die SSL-Verbindung für alle HTTPS-Anforderungen für alle ASP.NET-Anwendungen und jede Art von Zertifikat. Das Front-End leitet die Anforderung dann an dem festgelegten Worker für eine bestimmte Anwendung.

Öffentliche VIP-Adresse

Es wird standardmäßig eine einzelne öffentliche VIP für alle eingehenden HTTP-Datenverkehr. Jede Anwendung ist eine einzelne VIP adressiert. Wenn Sie eine Anwendung in App Service haben, führen Sie Nslookup-Befehl (von Windows oder PowerShell-Konsole), und anzuzeigen Sie das Ergebnis. Im Folgenden finden Sie ein Beispiel:

#1 PS C:\> nslookup awesomewebapp.azurewebsites.net
#2 Server:  UnKnown
#3 Address:  10.221.0.3
#4 Non-authoritative answer:
#5 Name:    waws-prod-bay-001.cloudapp.net
#6 Address:  168.62.20.37
#7 Aliases:  awesomewebapp.azurewebsites.net

Es folgt eine Erläuterung der Ausgabe des awesomewebapp.azurewebsites.net:

  • Zeile #1 führt Nslookup Abfragen Auflösung für awseomwebapp.azurewebsites.net.
  • Zeile #5 zeigt den Domänennamen des der Mengen-Einheit Awseomwebapp app ausgeführt wird. Sie werden bemerken, dass eine App Service-Skalierungseinheit in Azure-Cloud-Dienst (durch das Suffix cloudapp.net) bereitgestellt wird. WAWS steht für Windows Azure (wenn Azure weiterhin Windows aufgerufen wurde) Websites (der ursprüngliche Name der App Service).
  • Zeile #6 zeigt die VIP der Mengen-Einheit. Alle Programme, die gehostete und auf Waws-Prod-Bay-001 (Zeile 5) sind für die öffentliche VIP bezeichneten adressierbar.
  • Zeile #7 zeigt alle Domäne Aliase für die gleiche IP-Adresse zugeordnet.

Ausgehende VIPs

Höchstwahrscheinlich ist die Anwendung mit anderen Azure und nicht-Azure-Diensten verbunden. Daher macht Ihre Anwendung ausgehende Netzwerkaufrufe an Endpunkte nicht auf die Skalierungseinheit Ihrer Anwendung. Dazu gehören Azure-Dienste wie SQL-Datenbank und Azure-Speicher heraus aufrufen. Es gibt bis zu fünf VIPs (die eine öffentliche VIP-Adresse und vier ausgehende dedizierten virtuellen IP-Adressen) für die ausgehende Kommunikation verwendet. Sie können nicht auswählen, welche VIP-Adresse Ihrer app verwendet, und alle ausgehenden Aufrufe über alle apps im Skalierungseinheit der fünf reservierten virtuellen IP-Adressen verwenden. Wenn Ihre Anwendung einen Dienst, der Sie für Positivlisten-IPs, die API-Aufrufe in einen solchen Dienst erfordert verwendet, müssen Sie alle fünf VIPs der Mengen-Einheit zu registrieren. Anzeigen der IP-Adressen werden auf ausgehende VIPs für eine angegebene Maßeinheit (oder für Ihre app aus Ihrer Perspektive) wechseln Sie zu Azure-Portal Siehe Abbildung 3.

App Service-Anwendung ausgehende IP-Adresse anzeigen in Azure-Portal
Abbildung 3 App Service-Anwendung ausgehende IP-Adresse anzeigen in Azure-Portal

Wenn Sie einen speziellen Satz von eingehenden und ausgehenden IP-Adressen benötigen, können Sie dies untersuchen, indem Sie eine vollständig isolierte und dedizierte App-Service-Umgebung auf bit.ly/2hVRSlR.

IP-Adresse und SNI-SSL

App Service unterstützt IP-basierte SSL-Zertifikate. Wenn Sie IP-SSL zu verwenden, weist App Service für Ihre Anwendung eine dedizierte IP-Adresse für nur eingehenden HTTP-Verkehr.

Im Gegensatz zu den Rest von Azure dedizierte IP-Adressen wird die IP-Adresse mit App Service über IP-SSL zugeordnet, solange Sie sich entscheiden, um es zu verwenden. Sie nicht die IP-Adresse besitzen, und wenn Sie Ihre IP-SSL löschen, möglicherweise nicht mehr die IP-Adresse (wie er in eine andere Anwendung zugeordnet werden kann).

App Service unterstützt auch SNI-SSL, die eine dedizierte IP-Adresse nicht erforderlich und wird von modernen Browsern unterstützt. 

Netzwerkanschluss-Kapazität für ausgehende Netzwerkaufrufe

Eine Grundvoraussetzung für Applikationen ist die Möglichkeit, ausgehende Netzwerkaufrufe mit anderen Netzwerkendpunkten auszuführen. Dies schließt aufrufen Azure interne Dienste wie SQL-Datenbank und Azure-Speicher. Es enthält auch Fälle, in denen Clientanwendungen an HTTP/HTTPS-API-Endpunkte Aufrufe – z. B. eine Bing-Search-API aufrufen oder das Aufrufen einer API "Anwendung", die Back-End-Geschäftslogik für eine Webanwendung implementiert.

In fast allen Fällen ist die aufrufenden Anwendung in Azure App Service implizit ein Netzwerksocket öffnen und ausgehende Aufrufe an Endpunkte, die aus Sicht der Azure-Netzwerks "remote" betrachtet werden. Dies ist ein wichtiger Punkt, da Aufrufe, die aus einer app in Azure App Service zu einem Remoteendpunkt darauf beruhen, Azure-Netzwerk einrichten und Verwalten eines Mappings (Network Address Translation, NAT).

Erstellen neuer Einträge in dieser Zuordnung NAT zeitaufwendig, und es ist letztlich eine feste Begrenzung auf die Gesamtanzahl der NAT-Zuordnungen, die für eine Einheit der Skalierung von Azure App Service hergestellt werden kann. Aus diesem Grund erzwingt App Service Beschränkung der Anzahl von ausgehenden Verbindungen, die zu einem bestimmten Zeitpunkt ausstehenden sein können.

Die maximale Verbindungslimits sind folgende:

  • 1.920 Verbindungen pro B1/S1/P1-Instanz
  • 3,968 Verbindungen pro B2/S2/P2-Instanz
  • 8,064 Verbindungen pro B3/S3/P3-Instanz
  • Max. 64K-Obergrenze pro App Service-Umgebung

Programme, die "Verbindungen ausnahmslos Speicherverluste" führen Sie diese Verbindungslimits. Anwendung startet gelegentlich fehlschlagenden da aufrufen, die Korrelation von manchmal eng mit Zeiträumen der höheren Auslastung der Anwendung Fehler bei der. Häufig werden Fehler wie folgt angezeigt: "Es wurde versucht, Zugriff auf einen Socket in einer Weise den Zugriff Berechtigungen aaa.bbb.ccc.ddd."

Die Wahrscheinlichkeit der Ausführung dieses Problem kann erheblich verringert werden, einige bewährte Methoden:

  • Verwenden Sie bei .NET-Anwendungen ADO.NET/EF mit Datenbank-Verbindungspooling.
  • Verwenden Sie für die Php-MySql dauerhaften Datenbankverbindungen.
  • Konfigurieren Sie für Node.js-Anwendungen, die ausgehende Aufrufe zu HTTP/HTTPS-Keep-Alives so, dass ausgehende Verbindungen wiederverwendet werden. Diese Konfiguration wird unter beschrieben bit.ly/2iGrcoo.
  • Für .NET-Anwendungen ausgehende HTTP/HTTPS-Aufrufe vornimmt pool und Wiederverwenden von Instanzen von System.Net.Http.HttpClient oder Keep-alive-Verbindungen mit System.Net.HttpWebRequest verwenden. Hinweis: Denken Sie daran, die System.Net.ServicePointManager.DefaultConnectionLimit zu erhöhen, da Sie andernfalls auf zwei gleichzeitige ausgehende Verbindungen mit den gleichen Endpunkt beschränkt werden.

Es gibt zusätzliche Einschränkungen, die von der App Service-Sandbox auferlegt. Dies sind auf niedrigerer Ebene Limits und Einschränkungen für Azure App Service und informieren Sie sich über diese näher ansehen bit.ly/2hXJ6lL.

Zusammenfassung

Azure App Service bietet eine umfangreiche PaaS-Angebot für das Web, Mobile und API-Anwendung. Während der Dienst einen Großteil der internen Teile verschoben hat, werden diese sofort abstrahiert, damit Entwickler auf hervorragende apps zu schreiben, während der Dienst die Komplexität der Ausführung diese apps auf globaler Ebene behandelt konzentrieren können. 

Viele der bewährten Methoden für App Service Anwendungsskalierung ausgetauschten. Ein gutes Verständnis der Zuordnung der Anwendung zu Web-Worker in einer App Service-Plan ist wichtig, da die Anzahl der apps auf den Dienst ausgeführt wird, gleichzeitig eine optimale Skalierung Konfiguration zu erhöhen.

Angesichts die Cloud-First-Welt, der wir in Betrieb, Azure und Azure App Service immer kontinuierlich weiterentwickelt immer. Viele Innovationen werden in 2017 erwartet.

Skalierung Einheit Komponenten

Es mag so scheinen, als ob Skalierung Einheit Komponenten stark voneinander abhängig sind. Allerdings sind beabsichtigt, diese lose gekoppelt. Eine Anwendung, die derzeit (aktiv Serving HTTP-Datenverkehr) auf einem bestimmten Web-Worker kann weiterhin HTTP-Datenverkehr verwenden, auch wenn andere Rollen in der Mengen-Einheit defekt sind.

Z. B. ein Verleger nicht ordnungsgemäß möglicherweise behindern FTP-Zugriff, jedoch nicht beeinträchtigt HTTP-Datenverkehr von einer Anwendung oder andere Bereitstellungsoptionen. Wenn der Controller einen Fehler, die verhindern der Erstellung einer neuen Anwendung enthält, zwangsläufig nicht, dass apps, die bereits zugewiesenen Mengen-Einheit nicht mehr.

Yochay Kiriatyist ein leitender Programmmanager im Microsoft Azure-Team, insbesondere driving Web, mobil, API und Funktionen als Teil der Azure App Service-Plattform.  Kiriaty arbeitet mit Web-Technologien seit den späten 90s und leidenschaftlich für Skalierung und Leistung. Sie erreichen ihn unter yochay@microsoft.com und können ihm auf Twitter folgen: @yochayk.

Stefan Schackowist Programmmanager im Azure App Services-Team, in der Web-app-Cloud bietet seit den Anfangszeiten gearbeitet hat.  In Azure führt er ein Team von Programm-Managern, die an der Entwicklung und Bereitstellung von Azure App Service sowie die Entwicklung der Produkte von Microsoft auf-hybride (Azure-Paket und Azure Stack) arbeiten. Er kontaktiert werden kann, auf stefsch@microsoft.com.

Unser Dank gilt den folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Eduardo Laureano und Nir Mashkowski