Push-meddelanden med Azure Notification Hubs: Vanliga frågor och svar

Azure Notification Hubs har två resursnivåer: hubbar och namnrymder. En hubb är en enda push-resurs som kan innehålla plattformsoberoende push-information för en app. Ett namnområde är en samling hubbar i en region. Rekommenderad mappning matchar ett namnområde med en app. Inom ett namnområde kan du ha en produktionshubb som fungerar med din produktionsapp, en testhubb som fungerar med din testapp och så vidare.

Den senaste prisinformationen finns på sidan Notification Hubs Prissättning. Notification Hubs debiteras på namnområdesnivå. (Mer information om definitionen av ett namnområde finns i "Vad är resursstrukturen för Notification Hubs?") Notification Hubs erbjuder tre nivåer:

• Kostnadsfri: Den här nivån är en bra startpunkt för att utforska push-funktioner. Det rekommenderas inte för produktionsappar. Du får 500 enheter och 1 miljon push-meddelanden inkluderade per namnområde per månad, utan någon serviceavtalsgaranti (SLA).
• Basic: Den här nivån (eller standardnivån) rekommenderas för mindre produktionsappar. Du får 200 000 enheter och 10 miljoner push-meddelanden per namnområde per månad som baslinje.
• Standard: Den här nivån rekommenderas för medelstora till stora produktionsappar. Du får 10 miljoner enheter och 10 miljoner push-meddelanden per namnområde per månad som baslinje. Innehåller omfattande telemetri (ytterligare data om push-status tillhandahålls).

Standardnivåfunktioner:

• Omfattande telemetri: Du kan använda Notification Hubs telemetri per meddelande för att spåra push-begäranden och få Plattformsspecifikt meddelandesystem feedback för felsökning.
• Flera innehavare: Du kan arbeta med Plattformsspecifikt meddelandesystem autentiseringsuppgifter på namnområdesnivå. Med det här alternativet kan du enkelt dela upp klienter i hubbar inom samma namnområde.
• Schemalagd push: Du kan schemalägga att meddelanden ska skickas när som helst.
• Massåtgärder: Aktiverar registreringar Export/Import-funktioner enligt beskrivningen i dokumentet Om export/import av registreringar.

För nivåerna Basic Standard Notification Hubs kan korrekt konfigurerade program skicka push-meddelanden eller utföra registreringshanteringsåtgärder minst 99,9 procent av tiden. Mer information om serviceavtalet finns på sidan Notification Hubs serviceavtal.

Gå till Azure Portal > Notification Hubs namnområden eller Notification Hubs. Välj den resurs som du vill uppdatera och gå till Prisnivå. Observera följande krav:

• Den uppdaterade prisnivån gäller för alla hubbar i det namnområde som du arbetar med.
• Om antalet enheter överskrider gränsen för den nivå som du nedgraderar till måste du ta bort enheterna innan du nedgraderar.

Server-SDK:er är tillgängliga för .NET, Java, Node.js, PHP och Python. Notification Hubs API:er baseras på REST-gränssnitt, så du kan arbeta direkt med REST API:er om du använder olika plattformar eller inte vill ha extra beroende. Mer information finns på sidan Notification Hubs REST-API:er.

Push-meddelanden stöds för iOS, Android, Windows Universal, Windows Phone, Android China (via Baidu), Xamarin iOS och Androidoch Safari. Mer information finns på sidan Notification Hubs Komma igång självstudier.

Notification Hubs skickar meddelanden till enheter som kör mobilappar. Den tillhandahåller inte funktioner för e-post eller SMS. Notification Hubs tillhandahåller inte heller någon leveranstjänst för push-meddelanden i webbläsaren. Kunder kan implementera den här funktionen med SignalR ovanpå de plattformar på serversidan som stöds.

Se sidan Notification Hubs för information om antalet enheter som stöds.

Om du behöver stöd för mer än 10 miljoner registrerade enheter måste du partitionera dina enheter över flera namnområden.

Beroende på den valda nivån skalas Azure Notification Hubs automatiskt upp baserat på antalet meddelanden som flödar genom systemet.

Våra kunder använder Notification Hubs att skicka miljontals push-meddelanden varje dag. Du behöver inte göra något särskilt för att skala räckvidden för dina push-meddelanden så länge du använder Azure Notification Hubs.

I ett scenario med normal användning, där den inkommande belastningen är konsekvent och jämn, kan Azure Notification Hubs bearbeta minst 1 miljon push-meddelanden som skickas per minut. Den här frekvensen kan variera beroende på antalet taggar, typen av inkommande meddelanden och andra externa faktorer.

Under den uppskattade leveranstiden beräknar tjänsten målen per plattform och dirigerar meddelanden till Push Notification Service (PNS) baserat på de registrerade taggarna eller tagguttrycken. Det är PNS:s ansvar att skicka meddelanden till enheten.

PNS garanterar inte något serviceavtal för att leverera meddelanden. De flesta push-meddelanden levereras dock till målenheterna inom några minuter (vanligtvis inom 10 minuter) från det att de skickas till Notification Hubs. Några meddelanden kan ta längre tid.

På grund av typen av push-meddelanden (de levereras av ett externt, plattformsspecifikt PNS) finns det ingen fördröjningsgaranti. Vanligtvis levereras de flesta push-meddelanden inom några minuter.

Azure Notification Hubs lagrar kundregistreringsdata i den region som valts av kunden. Notification Hubs tillhandahåller haveriberedskapstäckning för metadata (Notification Hubs namn, anslutningssträng och annan viktig information). För alla regioner utom Brasilien, södra och Sydostasien finns metadatasäkerhetskopiering i en annan region (vanligtvis i den parkopplade Azure-regionen). För regionerna Brasilien, södra och Sydostasien lagras säkerhetskopior i samma region för att tillgodose kraven på datahemhemlighet för dessa regioner.

Mobilapp/miljö

• Använd en meddelandehubb per mobilapp och miljö.
• I ett scenario med flera innehavare ska varje klient ha en separat hubb.
• Dela aldrig samma meddelandehubb för produktions- och testmiljöer. Den här praxis kan orsaka problem när du skickar meddelanden. (Apple erbjuder slutpunkter för sandbox-miljö och push för produktion, var och en med separata autentiseringsuppgifter.)
• Som standard kan du skicka testmeddelanden till dina registrerade enheter via Azure Portal eller den integrerade Azure-komponenten i Visual Studio. Tröskelvärdet är inställt på 10 enheter som väljs slumpmässigt från registreringspoolen.

PNS-autentiseringsuppgifter

När en mobilapp registreras med en plattforms utvecklarportal (till exempel Apple eller Google) skickas en appidentifierare och säkerhetstoken. Appens backend tillhandahåller dessa token till plattformens PNS så att push-meddelanden kan skickas till enheter. Säkerhetstoken kan vara i form av certifikat (till exempel Apple iOS eller Windows Phone) eller säkerhetsnycklar (till exempel Google Android eller Windows). De måste konfigureras i meddelandehubbbar. Konfigurationen görs vanligtvis på meddelandehubbnivå, men det kan också göras på namnområdesnivå i ett scenario med flera innehavare.

Namnrymder

Namnområden kan användas för distributionsgrupp. De kan också användas för att representera alla meddelandehubbbar för alla klienter i samma app i ett scenario med flera innehavare.

Geo-distribution

Geo-distribution är inte alltid viktigt i scenarier med push-meddelanden. Olika PNS:er (till exempel APNs eller FCM) som levererar push-meddelanden till enheter distribueras inte jämnt.

Om du har ett program som används globalt kan du skapa hubbar i olika namnområden med hjälp av Notification Hubs-tjänsten i olika Azure-regioner runtom i världen.

Registreringar från app-backend är användbara när du behöver autentisera klienter innan du skapar registreringen. De är också användbara när du har taggar som måste skapas eller ändras av appens backend baserat på applogik. Mer information finns på sidorna Backend Registration (Registreringsvägledning för backend- och backend-registrering) 2.

Azure Notification Hubs använder en säkerhetsmodell baserad på signaturför delad åtkomst. Du kan använda signaturtoken för delad åtkomst på rotnamnområdesnivå eller på detaljerad meddelandehubbnivå. Token för signaturer för delad åtkomst kan ställas in så att de följer olika auktoriseringsregler, till exempel för att skicka meddelandebehörigheter eller för att lyssna efter meddelandebehörigheter. Mer information finns i dokumentet Notification Hubs säkerhetsmodell.

Alla meddelanden levereras till målenheter via plattformens PNS. När ett meddelande skickas till Azure Notification Hubs bearbetas det och skickas till respektive PNS.

Alla anslutningar, från avsändaren till Azure-Notification Hubs till PNS, använder HTTPS.

Om du vill skicka känsliga nyttolaster rekommenderar vi att du använder ett säkert push-mönster. Avsändaren skickar ett pingmeddelande med en meddelandeidentifierare till enheten utan den känsliga nyttolasten. När appen på enheten tar emot nyttolasten anropar appen ett säkert API direkt för att hämta meddelandeinformationen. Om du vill ha en guide om hur du implementerar det här mönstret går du Notification Hubs självstudiesidan säker push.

Vi tillhandahåller haveriberedskapstäckning för metadata i slutet (Notification Hubs namn, anslutningssträngen och annan viktig information). När ett haveriberedskapsscenario utlöses är registreringsdata det enda segmentet Notification Hubs infrastruktur som förloras. Du måste implementera en lösning för att fylla dessa data i den nya hubben efter återställningen:

1. Skapa en sekundär meddelandehubb i ett annat datacenter. Vi rekommenderar att du skapar en från början för att skydda dig från en katastrofåterställningshändelse som kan påverka dina hanteringsfunktioner. Du kan också skapa en vid tidpunkten för haveriberedskapshändelsen.

2. Synkronisera den sekundära meddelandehubben med den primära meddelandehubben med något av följande alternativ:

   • Använd en app-backend som samtidigt skapar och uppdaterar installationer i båda meddelandehubben. Med installationer kan du ange din egen unika enhetsidentifierare, vilket gör den mer lämplig för replikeringsscenariot. Mer information finns i den här exempelkoden.
   • Använd en app-backend som hämtar en vanlig dump av registreringar från den primära meddelandehubben som en säkerhetskopia. Den kan sedan utföra en massinfogning i den sekundära meddelandehubben.

Den sekundära meddelandehubben kan få installationer/registreringar som har upphört att gälla. När push-installationen görs till en utgången referens Notification Hubs automatiskt den associerade installations-/registreringsposten baserat på svaret som tas emot från PNS-servern. Om du vill rensa utgångna poster från en sekundär meddelandehubb lägger du till anpassad logik som bearbetar feedback från varje meddelande. Sedan upphör installationen/registreringen att gälla i den sekundära meddelandehubben.

Om du inte har någon backend utför appen en ny registrering i den sekundära meddelandehubben när appen startar på målenheterna. Så småningom kommer den sekundära meddelandehubben att ha alla aktiva enheter registrerade.

Det kommer att finnas en tidsperiod när enheter med oöppnade appar inte tar emot meddelanden.

Azure Notification Hubs krypterar alla kunddata i vila med undantag för registreringstaggar. Därför bör du inte lagra personliga eller konfidentiella data med hjälp av taggar.

Ja. Alla Notification Hubs-hanteringsåtgärder uppdaterar Azure-aktivitetsloggen som exponeras i Azure Portal. Azure-aktivitetsloggen ger insikter om de åtgärder som utförs på resurser i dina prenumerationer. Med hjälp av aktivitetsloggen kan du bestämma vad, vem och när för skrivåtgärder (PUT, POST, DELETE) som gjorts för resurserna i din prenumeration. Du kan också förstå statusen för åtgärderna och andra relevanta egenskaper. Emellertid. Aktivitetsloggen innehåller inte läsåtgärd (GET).

Azure Notification Hubs innehåller flera funktioner för felsökning, särskilt för det vanligaste scenariot med bort ignorerade meddelanden. Mer information finns i Notification Hubs felsökningsguide white paper.

Azure Notification Hubs kan visa telemetridata i Azure Portal. Information om måtten finns på sidan Notification Hubs mått.

Du kan också komma åt mått programmatiskt. Mer information finns i följande artiklar:

• Hämta Azure Monitor mått med .NET. I det här exemplet används användarnamnet och lösenordet. Om du vill använda ett certifikat överbelastar du metoden FromServicePrincipal för att tillhandahålla ett certifikat som visas i det här exemplet.
• Hämta mått och aktivitetsloggar för en resurs
• Genomgång av REST-API:et för Azure Monitoring