Azure App Configuration — często zadawane pytania

W tym artykule znajdują się odpowiedzi na często zadawane pytania dotyczące usługi Azure App Configuration.

Czym różni się usługa App Configuration od usługi Azure Key Vault?

Usługa App Configuration ułatwia deweloperom zarządzanie ustawieniami aplikacji i kontrolowanie dostępności funkcji. Ma na celu uproszczenie wielu zadań związanych z pracą ze złożonymi danymi konfiguracji.

Usługa App Configuration obsługuje:

• Hierarchiczne przestrzenie nazw
• Etykieta
• Obszerne zapytania
• Pobieranie wsadowe
• Wyspecjalizowane operacje zarządzania
• Interfejs użytkownika zarządzania funkcjami

Usługa App Configuration uzupełnia usługę Key Vault, a obie powinny być używane obok siebie we większości wdrożeń aplikacji.

Czy należy przechowywać wpisy tajne w usłudze App Configuration?

Chociaż usługa App Configuration zapewnia wysoki poziom zabezpieczeń, usługa Key Vault nadal jest najlepszym miejscem do przechowywania wpisów tajnych aplikacji. Usługa Key Vault zapewnia szyfrowanie na poziomie sprzętu, szczegółowe zasady dostępu i operacje zarządzania, takie jak rotacja certyfikatów.

Możesz utworzyć w usłudze App Configuration pary klucz-wartość, które odwołują się do sekretów przechowywanych w usłudze Key Vault. Aby uzyskać więcej informacji, zobacz Use Key Vault references in an ASP.NET Core app (Używanie odwołań do usługi Key Vault w aplikacji ASP.NET Core).

Czy usługa App Configuration szyfruje moje dane?

Tak. Usługa App Configuration zawsze szyfruje wszystkie dane przesyłane i magazynowane. Cała komunikacja sieciowa odbywa się za pośrednictwem protokołu TLS 1.2 lub TLS 1.3. Usługa App Configuration obsługuje szyfrowanie danych magazynowanych za pomocą kluczy zarządzanych przez firmę Microsoft lub kluczy zarządzanych przez klienta.

Czym różni się App Configuration od ustawień usługi Azure App Service?

Usługa Azure App Service umożliwia definiowanie ustawień aplikacji dla każdego wystąpienia usługi Azure App Service. Te ustawienia są przekazywane jako zmienne środowiskowe do kodu aplikacji. Jeśli chcesz, możesz skojarzyć ustawienie z określonym miejscem wdrożenia. Aby uzyskać więcej informacji, zobacz Konfigurowanie ustawień aplikacji.

Natomiast aplikacja systemu Azure Configuration umożliwia zdefiniowanie ustawień, które mogą być współużytkowane przez wiele aplikacji. Obejmuje to aplikacje uruchomione w usłudze App Service, a także inne platformy. Kod aplikacji uzyskuje dostęp do tych ustawień za pośrednictwem dostawców konfiguracji dla platformy .NET i języka Java, za pośrednictwem zestawu Azure SDK lub bezpośrednio za pośrednictwem interfejsów API REST.

Odwołania do danych usługi App Configuration można dodawać w ustawieniach aplikacji usługi App Service. Możesz również zaimportować i wyeksportować ustawienia między usługą App Service i usługą App Configuration. Ta możliwość umożliwia szybkie utworzenie nowego zasobu App Configuration na podstawie istniejących ustawień usługi App Service. Możesz również udostępnić konfigurację istniejącej aplikacji, która opiera się na ustawieniach usługi App Service.

Czy istnieją ograniczenia rozmiaru dotyczące kluczy i wartości przechowywanych w usłudze App Configuration?

Istnieje limit 10 KB dla pojedynczej wartości klucza, w tym atrybutów, takich jak etykieta, typ zawartości, tagi i inne metadane. Nie ma limitu liczby kluczy i etykiet, o ile ich całkowity rozmiar jest niższy niż limit magazynu.

Ten limit klucz-wartość powinien być wystarczający dla pojedynczego ustawienia w większości aplikacji. Jeśli okaże się, że ustawienie jest większe niż ten limit, możesz rozważyć przechowywanie danych w innym miejscu i dodać odwołanie do tych danych w usłudze App Configuration.

Aby uzyskać pełną listę limitów, zobacz ograniczenia nazewnictwa i limity subskrypcji i usługi.

Jak przechowywać konfiguracje dla wielu środowisk (test, przemieszczanie, produkcja itd.)?

Możesz kontrolować, kto może uzyskiwać dostęp do usługi App Configuration na poziomie poszczególnych sklepów. Użyj oddzielnego magazynu dla każdego środowiska, które wymaga różnych uprawnień. Takie podejście zapewnia najlepszą izolację zabezpieczeń.

Jeśli nie potrzebujesz izolacji zabezpieczeń między środowiskami, możesz użyć etykiet, aby odróżnić wartości konfiguracji. Użyj etykiet, aby włączyć różne konfiguracje dla różnych środowisk , zawiera kompletny przykład.

Jakie są zalecane sposoby korzystania z usługi App Configuration?

Zobacz najlepsze rozwiązania.

Ile kosztuje usługa App Configuration?

Istnieją cztery warstwy cenowe: Bezpłatna, Deweloper, Standardowa i Premium. Aby uzyskać szczegółowe informacje o cenach, zapoznaj się ze stroną cennika usługi App Configuration.

Której warstwy usługi App Configuration należy używać?

Wszystkie warstwy konfiguracji aplikacji oferują podstawowe funkcje, w tym ustawienia konfiguracji, flagi funkcji, odwołania do usługi Key Vault, migawki konfiguracji, podstawowe operacje zarządzania, metryki i dzienniki.

Poniżej przedstawiono kwestie, które należy wziąć pod uwagę przy wyborze warstwy.

• Cel: Warstwa Bezpłatna jest idealna do oceny usługi w środowiskach nieprodukcyjnych, umożliwiając eksplorowanie jej funkcji bez żadnych kosztów.

  Warstwa Deweloper jest ekonomiczna dla małych, nieprodukcyjnych przypadków użycia i jest wyposażona w funkcje i możliwości dostosowane specjalnie do potrzeb programistycznych i testowych.

  Warstwa Standard jest przeznaczona do średnioskalowych wdrożeń produkcyjnych i zastosowań nieprodukcyjnych, zapewniając równowagę między wydajnością a efektywnością kosztową.

  W przypadku wysokiej ilości lub potrzeb produkcyjnych na poziomie przedsiębiorstwa warstwa Premium oferuje najwyższy poziom wydajności i skalowalności, dzięki czemu aplikacje działają bezproblemowo nawet pod dużym obciążeniem.

• Zasoby w ramach subskrypcji: Zasób składa się z jednego magazynu konfiguracji. Każda subskrypcja w warstwie Bezpłatna jest ograniczona do jednego magazynu konfiguracji w każdym regionie. Subskrypcje w warstwach Developer, Standard i Premium mogą mieć nieograniczoną liczbę magazynów konfiguracji.

• Pamięć masowa na zasób: W warstwie Bezpłatna każdy magazyn konfiguracji jest ograniczony do 10 MB zwykłej pamięci masowej i 10 MB pamięci masowej migawek. W warstwie Deweloper każdy magazyn konfiguracji może używać do 500 MB zwykłego magazynu i dodatkowego 500 MB magazynu migawek. W warstwie Standard każdy magazyn konfiguracji może używać maksymalnie 1 GB standardowej przestrzeni magazynowej oraz dodatkowego 1 GB przestrzeni magazynowej na migawki. W warstwie Premium każdy magazyn konfiguracji może używać do 4 GB zwykłego magazynu i dodatkowego 4 GB magazynu migawek.

• Historia poprawek: usługa App Configuration przechowuje historię wszystkich zmian wprowadzonych w kluczach. W warstwach Bezpłatna i Deweloper ta historia jest przechowywana przez siedem dni. W warstwach Standardowa i Premium ta historia jest przechowywana przez 30 dni.

• Limit żądań: sklepy w warstwie bezpłatnej są ograniczone do 1 000 żądań dziennie. Gdy sklep osiągnie 1000 żądań, zwraca kod stanu HTTP 429 dla wszystkich żądań do północy CZASU UTC.

  Sklepy w warstwie Deweloper mają limit 6 000 żądań na godzinę. Po wyczerpaniu limitu przydziału godzinowego dodatkowe żądania zwracają kod stanu HTTP 429, wskazując zbyt wiele żądań do końca godziny.

  Magazyny w warstwie Standardowa są ograniczone do 30 000 żądań na godzinę. Po wyczerpaniu limitu godzinowego dodatkowe żądania mogą zwracać kod stanu HTTP 429, oznaczający zbyt dużą liczbę żądań, aż do końca godziny. W miarę wysyłania większej liczby żądań przekraczających przydział większy odsetek z nich może zwracać kod stanu 429.

  Sklepy w warstwie Premium nie mają limitu liczby żądań, co zapewnia, że dostęp do sklepu nigdy nie jest blokowany.

• Przepływność: magazyny usługi App Configuration we wszystkich warstwach mają limit przepływności. Żądania, które przekraczają ten limit, otrzymują odpowiedź z kodem statusu HTTP 429.

  Magazyny danych w warstwach Bezpłatna i Deweloper nie mają gwarantowanej przepustowości.

  Magazyny w warstwie Standard obsługują przepustowość† do 300 żądań na sekundę (RPS) w przypadku żądań odczytu i do 60 RPS w przypadku żądań zapisu.

  Konta magazynu w warstwie Premium obsługują przepustowość† do 450 RPS w przypadku żądań odczytu i do 100 RPS w przypadku żądań zapisu.

  †Wskaźnik przepustowości jest zwykle mierzony jako średnia liczba żądań obsługiwanych przez magazyn App Configuration bez ograniczania w określonym przedziale czasu.

• Umowa dotycząca poziomu usług: plan bezpłatny i plan deweloperski nie mają SLA. Warstwa Standardowa ma umowę SLA gwarantującą dostępność na poziomie 99,9% i dostępność na poziomie 99,95% z włączoną replikacją geograficzną. Warstwa Premium ma umowę SLA gwarantującą dostępność na poziomie 99,9% i dostępność na poziomie 99,99% z włączoną replikacją geograficzną.

• Funkcje: Wszystkie warstwy cenowe obejmują następujące funkcje: szyfrowanie przy użyciu kluczy zarządzanych przez firmę Microsoft, uwierzytelnianie za pomocą klucza dostępu lub Microsoft Entra ID, kontrolę dostępu opartą na rolach platformy Azure (RBAC), tożsamość zarządzaną, tagi usług oraz nadmiarowość między strefami dostępności.

  Warstwa Deweloper obejmuje również obsługę usługi Private Link.

  Warstwy Standard i Premium oferują więcej funkcjonalności, w tym obsługę Private Link, szyfrowanie przy użyciu kluczy zarządzanych przez klienta, ochronę przed przywracalnym usunięciem oraz obsługę georeplikacji.

• Koszt: korzystanie ze sklepu w warstwie Bezpłatnej nie wiąże się z żadnymi kosztami.

  Sklepy w warstwie Deweloper są objęte dzienną opłatą za użytkowanie, która obejmuje pierwsze 3 000 żądań każdego dnia. Żądania wykraczające poza tę dzienną alokację powodują naliczanie opłat za nadwyżkę.

  Magazyny w warstwie Standardowa mają opłatę za dzienne użycie, która obejmuje pierwsze 200 000 żądań każdego dnia. Żądania wykraczające poza tę dzienną alokację powodują naliczanie opłat za nadwyżkę.

  Magazyny w warstwie Premium mają również opłatę za dzienne użycie i obejmują replikę. Pierwsze 800 000 żądań dotyczących źródła i pierwsze 800 000 żądań dotyczących repliki każdego dnia są wliczone w dzienną opłatę. Żądania przekraczające tę dzienną alokację powodują naliczanie opłat za nadwyżkę.

Czy mogę zwiększyć lub obniżyć magazyn App Configuration?

Magazyn App Configuration można uaktualnić w dowolnym momencie, na przykład z warstwy Bezpłatna do warstwy Deweloper, Standardowa lub Premium albo z warstwy Developer, Standard do warstwy Premium.

Magazyn App Configuration można przełączyć z warstwy Premium na warstwę Standard, ponieważ obie warstwy są przeznaczone do zastosowań produkcyjnych. Jednak obniżenie poziomu do warstwy nieprodukcyjnej, takiej jak warstwa Bezpłatna, nie jest obsługiwane. Aby to osiągnąć, możesz utworzyć nowy magazyn w żądanej warstwie, a następnie zaimportować dane konfiguracji do tego magazynu.

Przed obniżeniem poziomu magazynu usługi App Configuration z warstwy Premium do warstwy Standardowa upewnij się, że użycie zwykłego magazynu i magazynu migawek jest poniżej limitów warstwy Standardowa. Bieżące użycie można zweryfikować za pomocą metryk usługi Azure Monitor — Daily Storage Usage i Snapshot Storage Size — dla magazynu usługi App Configuration w portalu Azure.

Gdzie znajdują się dane przechowywane w usłudze App Configuration?

Dane klienta przechowywane w konfiguracji aplikacji znajdują się w regionie, w którym utworzono sklep konfiguracji aplikacji klienta. Dane klienta są replikowane do innego regionu tylko wtedy, gdy klient włączy replikację geograficzną dla tego regionu. Dotyczy to wszystkich dostępnych regionów. Klienci mogą przenosić, kopiować lub uzyskiwać dostęp do danych z dowolnej lokalizacji na całym świecie.

Jak usługa App Configuration zapewnia wysoką dostępność danych?

aplikacja systemu Azure Configuration obsługuje replikację geograficzną w celu zwiększenia odporności na awarie regionalne.

aplikacja systemu Azure Configuration obsługuje strefy dostępności platformy Azure w celu ochrony aplikacji i danych przed pojedynczymi awariami centrum danych. Wszystkie regiony z obsługą strefy dostępności składają się z co najmniej trzech stref dostępności, w których każde z nich jest fizycznie niezależnym centrum danych. Aby zapewnić odporność, ta funkcja w usłudze App Configuration jest włączona dla wszystkich klientów bez dodatkowych opłat. Poniżej przedstawiono regiony, w których usługa App Configuration włączyła obsługę stref dostępności. Aby uzyskać więcej informacji, zobacz Regiony platformy Azure z obsługą stref dostępności.

Ameryka	Europa	Bliski Wschód	Afryka	Azja i Pacyfik
Brazylia Południowa	Francja Środkowa	Izrael Środkowy		Australia Wschodnia
Kanada Środkowa	Niemcy Środkowo-Zachodnie	Katar Środkowy		Indie Środkowe
Środkowe stany USA	Włochy Północne	Północne Zjednoczone Emiraty Arabskie		Chiny Północne 3
Wschodnie stany USA	Europa Północna			Azja Wschodnia
Wschodnie stany USA 2	Norwegia Wschodnia			Japonia Wschodnia
Meksyk Środkowy	Polska Środkowa			Korea Środkowa
Południowo-środkowe stany USA	Hiszpania Środkowa			Azja Południowo-Wschodnia
US Gov Wirginia	Szwecja Środkowa
Zachodnie stany USA 2	Szwajcaria Północna
Zachodnie stany USA 3	Południowe Zjednoczone Królestwo
	Europa Zachodnia

Czy istnieją limity liczby żądań wysyłanych do usługi App Configuration?

Magazyny usługi App Configuration mają różne limity żądań w zależności od warstwy. Sklepy w warstwie Free są ograniczone do 1000 żądań dziennie, sklepy w warstwie Developer do 6000 żądań na godzinę, sklepy w warstwie Standard do 30 000 żądań na godzinę, a sklepy w warstwie Premium nie mają limitu żądań, co zapewnia nieprzerwany dostęp.

Magazyny usługi App Configuration mają limity przepustowości zależne od swojej warstwy. Magazyny w warstwach Bezpłatna i Deweloper nie mają gwarantowanej przepustowości. Konta magazynu w warstwie Standard obsługują do 300 żądań na sekundę (RPS) dla operacji odczytu i do 60 żądań na sekundę (RPS) dla operacji zapisu. Magazyny w warstwie Premium obsługują przepustowość do 450 RPS w przypadku operacji odczytu i do 100 RPS w przypadku operacji zapisu.

Jak mogę oszacować liczbę żądań, które moja aplikacja może wysłać do usługi App Configuration?

Załóżmy, że masz aplikację z 1000 ustawieniami konfiguracji. Aplikacja ładuje wszystkie te ustawienia z usługi App Configuration po uruchomieniu. Następnie co 30 sekund sprawdza klucz wartownika, aby wykryć zmiany konfiguracji. Niezależnie od tego, czy korzystasz z platformy Kubernetes, usługi App Service, czy maszyn wirtualnych, załóżmy, że masz 50 wystąpień aplikacji uruchomionych jednocześnie.

Najpierw szacujmy żądania monitorowania konfiguracji. Każda instancja aplikacji wysyła do usługi App Configuration jedno żądanie dotyczące klucza sentinel* co 30 sekund, dlatego w ciągu godziny wysyła 120 żądań (=3600/30). Jeśli masz 50 wystąpień aplikacji, aplikacja wysyła 6000 (=120x50) łącznych żądań co godzinę na potrzeby monitorowania konfiguracji. Należy pamiętać, że ponieważ żądania dotyczące klucza Sentinel są częste i w większości pozostają bez zmian, większość z nich nie wlicza się do limitów godzinowego przydziału dla magazynu† w warstwie Standard.

Po drugie szacujmy żądania ładowania/ponownego ładowania konfiguracji. Aplikacja ładuje wszystkie ustawienia podczas uruchamiania lub za każdym razem, gdy zostanie wykryta zmiana klucza sentinel. Każde żądanie do usługi App Configuration może pobrać do 100 par klucz-wartość, więc załadowanie wszystkich ustawień wymaga 10 (=1000/100) żądań. Jeśli masz 50 wystąpień aplikacji, wysyłasz 500 (=10x50) łącznych żądań po ponownym uruchomieniu aplikacji lub ponownym załadowaniu jej konfiguracji.

Na koniec złóżmy to w całość. Przy założeniu, że klucz sentinel został zaktualizowany dwa razy w ciągu godziny, magazyn usługi App Configuration otrzyma zatem 7000 (=6 000+500x2) łącznych żądań dla tej godziny. Należy pamiętać, że spośród tych żądań tylko około 1000 (=500x2) wlicza się do dostępnego godzinowego limitu dla magazynu w warstwie Standard. Zaktualizuj wartości liczbowe w tym przykładzie tak, aby odpowiadały Twojej konkretnej konfiguracji, i odpowiednio zaprojektuj rozwiązanie, tak aby zapewnić sobie wystarczający bufor względem godzinowego limitu przydziału.

*Flagi funkcjonalności nie używają klucza kontrolnego do monitorowania zmian i są monitorowane niezależnie od konfiguracji. Wymagane jest jedno żądanie do monitorowania każdych 100 flag funkcji w każdym interwale odświeżania.

†Sklepy w warstwie bezpłatnej nie mają wyłączenia z dziennego limitu dla częstych, powtarzających się żądań.

Moja aplikacja otrzymuje odpowiedzi z kodem stanu HTTP 429. Dlaczego?

Aplikacja może otrzymać odpowiedź http o kodzie stanu 429 w następujących okolicznościach:

• Przekroczenie dziennego limitu żądań dla sklepu w warstwie bezpłatnej.
• Przekroczenie godzinowego limitu żądań dla sklepu w poziomie Developer.
• Przekroczenie godzinowego limitu żądań dla sklepu w warstwie Standard.
• Przekroczenie limitu przepustowości sklepu na dowolnym poziomie.
• Przekroczenie limitu przepustowości magazynu w dowolnej warstwie.
• Próba utworzenia lub zmodyfikowania wartości klucza po przekroczeniu limitu przydziału magazynu.

Sprawdź treść odpowiedzi 429, aby poznać konkretny powód, dla którego żądanie zakończyło się niepowodzeniem. Możesz również zbierać dzienniki dla magazynu App Configuration w usłudze Azure Monitor i skonfigurować alerty dla metryki Wykorzystanie limitu żądań.

Odbieranie chwilowego kodu stanu HTTP 429 zwykle nie powoduje żadnych szkód, ponieważ klienci usługi App Configuration obsługują je bezpiecznie. Jeśli jednak aplikacja regularnie korzysta z kodu stanu HTTP 429, rozważ następujące opcje:

• Uaktualnij swój sklep do warstwy Premium: ta warstwa nie ma limitu przydziału żądań oraz oferuje zwiększony limit magazynowania i wyższy limit przepustowości.
• Użyj dostawców konfiguracji aplikacji: Dostawcy usług mają wbudowane mechanizmy ponawiania i buforowania, a także wiele innych funkcji zapewniających odporność. Pamiętaj, aby zaktualizować dostawcę do najnowszej wersji, aby uzyskać wszystkie najnowsze ulepszenia.
• Użyj zestawów SDK usługi App Configuration, jeśli aplikacja musi wysyłać żądania zapisu. Chociaż zestawy SDK mogą nie być tak rozbudowane jak rozwiązania dostawców, automatycznie ponawiają żądania w przypadku odpowiedzi z kodem stanu HTTP 429 oraz innych przejściowych błędów.
• Uwzględnij logikę ponawiania prób w klientach niestandardowych, jeśli nie możesz używać dostawców usługi App Configuration ani pakietów SDK. Nagłówek retry-after-ms w odpowiedzi zawiera sugerowany czas oczekiwania (w milisekundach) przed ponowną próbą żądania.
• Rozłóż żądania między wiele wystąpień klienta: Pomaga to uzyskać maksymalną przepustowość magazynu App Configuration.
• Zmniejsz liczbę żądań wysyłanych do usługi App Configuration: postępuj zgodnie ze wskazówkami, aby zminimalizować liczbę żądań.
• Zmniejsz przechowywanie wersji klucz-wartość, jeśli przeprowadzasz częste aktualizacje klucz-wartość i nie musisz zachowywać wersji przez maksymalny czas dozwolony przez usługę App Configuration. Poprawki są wliczane do całkowitego zużycia pamięci w sklepie. Jeśli limit przydziału magazynu zostanie przekroczony, nie będzie już można tworzyć ani modyfikować flag klucz-wartości lub funkcji.
• Zwiększ odporność aplikacji: rozważ integrację replikacji geograficznej, aby umożliwić przechodzenie w tryb failover i równoważenie obciążenia. Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi tworzenia wysoce odpornych aplikacji.

Jak używać usługi App Configuration w aplikacjach klienckich z konfiguracją hiperskala?

Zobacz najlepsze rozwiązania dotyczące aplikacji klienckich w usłudze App Configuration

Dlaczego nie mogę utworzyć magazynu App Configuration o takiej samej nazwie jak magazyn, który właśnie został usunięty?

Wszystkie magazyny usługi App Configuration w warstwach Standard i Premium mają automatycznie włączoną funkcję soft-delete. Po usunięciu magazynu App Configuration w warstwie Standard lub Premium jego nazwa jest zarezerwowana na okres przechowywania. Aby ponownie utworzyć magazyn o tej samej nazwie przed wygaśnięciem okresu przechowywania, należy najpierw przeczyścić magazyn usunięty nietrwale, pod warunkiem, że magazyn nie ma włączonej ochrony przed przeczyszczeniem. Jeśli ochrona przed przeczyszczeniem jest włączona, musisz poczekać na upłynięcie okresu przechowywania. Użyj funkcji przeczyszczania lub ustaw krótszy okres przechowywania, jeśli często trzeba ponownie utworzyć magazyn o tej samej nazwie. Przepływy pracy, które wymagają ponownego utworzenia magazynu o tej samej nazwie, powinny zezwalać na jedną godzinę między przeczyszczeniem magazynu konfiguracji i wykonaniem kolejnej operacji tworzenia. Zalecenie to jest sformułowane, ponieważ po zażądaniu czyszczenia rzeczywiste usunięcie zasobów magazynu konfiguracji jest wykonywane asynchronicznie, co wymaga pewnego dodatkowego czasu na sfinalizowanie. Aby uniknąć konieczności czekania, zaleca się, aby przepływy pracy tworzące tymczasowe magazyny konfiguracji używały unikatowych nazw.

Jak mogę przywrócić magazyn usługi App Configuration, który został usunięty błędnie?

Wszystkie magazyny konfiguracji aplikacji w warstwach Standard i Premium obsługują funkcję odzyskiwalnego usuwania, której nie można wyłączyć. Usunięty magazyn można odzyskać w okresie jego przechowywania. Postępuj zgodnie z poniższymi instrukcjami, aby odzyskać omyłkowo usunięty magazyn usługi App Configuration.

Jak określić, kto uzyskał dostęp do magazynu App Configuration?

Użyj dzienników aktywności , aby zobaczyć, kto uzyskiwał dostęp do lub modyfikował płaszczyznę sterowania sklepu App Configuration. Użyj dzienników zasobów , aby określić, kto uzyskiwał dostęp do płaszczyzny danych.

Czy można programowo tworzyć i aktualizować flagi funkcji lub odwołania do usługi Key Vault?

Tak. Chociaż można zarządzać flagami funkcji i odwołaniami usługi Key Vault w usłudze App Configuration za pośrednictwem witryny Azure Portal lub interfejsu wiersza polecenia, można również tworzyć i aktualizować je programowo przy użyciu zestawów SDK usługi App Configuration. Dlatego możesz napisać własny portal zarządzania lub zarządzać nimi programowo w swoim procesie CI/CD. Flaga funkcjonalności i interfejsy API odwołań do usługi Key Vault są dostępne w pakietach SDK dla wszystkich obsługiwanych języków. Zapoznaj się z przykładowymi linkami, aby zobaczyć przykłady w każdym obsługiwanym języku.

Ocenianie i używanie flag funkcjonalności w aplikacji wymaga dostawcy usługi App Configuration oraz bibliotek do zarządzania funkcjami, które są dostępne dla platform .NET, Java Spring, Python, JavaScript i Go. Aby uzyskać więcej informacji, zapoznaj się z tematem Zarządzanie funkcjami — omówienie.

Jak używać profilów Java Spring w usłudze App Configuration?

Profile spring umożliwiają oddzielenie części aplikacji, w tym konfiguracji i udostępnienie jej tylko w niektórych środowiskach lub w przypadku użycia określonych bibliotek.

Zaleca się ustawienie etykiety par klucz-wartość tak, aby odpowiadała profilom Spring. Domyślnie biblioteka dostawcy Spring dla App Configuration ładuje pary klucz-wartość oznaczone etykietami odpowiadającymi aktualnie aktywnym profilom Spring (${spring.profiles.active}), jeśli filtr etykiet nie został jawnie ustawiony. Jeśli nie ustawiono aktywnego profilu Spring, zostaną załadowane pary klucz-wartość z etykietą „no label”.

Na przykład dla profili dev i prod należy utworzyć odpowiednie pary klucz–wartość zgodnie z poniższymi etykietami.

Klawisz	Etykieta	Wartość
/application/config.message	dev	Witaj od dewelopera
/application/config.message	Prod	Witaj z prod

Gdy profil Spring jest ustawiony na dev, wartość parametru config.message będzie wynosić Hello from dev. Gdy profil Spring jest ustawiony na prod, wartość config.message wynosi Hello from prod.

To domyślne zachowanie można zastąpić, ustawiając filtr etykiet w pliku właściwości aplikacji. Biblioteka dostawcy spring ładuje wartości kluczy z określonymi etykietami niezależnie od aktywnego profilu Spring.

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

Aby wybrać inne etykiety i profile spring, możesz użyć filtru etykiet, takiego jak ',${spring.profiles.active}', który wybierze wszystkie klucze bez etykiety i tych pasujących do profilów spring. Skrajnie prawe etykiety mają priorytet w przypadku wykrycia zduplikowanych kluczy.

Jak włączyć zarządzanie funkcjami w aplikacjach Blazor lub jako usługi o określonym zakresie w aplikacjach platformy .NET?

Począwszy od wersji 3.1.0 biblioteka Microsoft.FeatureManagement umożliwia uruchamianie usług zarządzania funkcjami, w tym filtrów funkcji, jako usług o określonym zakresie w aplikacjach .NET opartych na iniekcji zależności. Aby skorzystać z tej funkcji, możesz po prostu zastąpić w kodzie wywołanie AddFeatureManagement wywołaniem AddScopedFeatureManagement, jak pokazano w poniższym fragmencie kodu:

services.AddScopedFeatureManagement();

Filtry funkcji mogą oceniać flagę funkcji na podstawie właściwości żądania HTTP. Zwykle wykonuje się to przez sprawdzenie elementu HttpContext za pomocą wzorca IHttpContextAccessorSingleton. Jednak ten wzorzec nie działa w przypadku aplikacji serwera Blazor, w których należy zamiast tego używać usług o określonym zakresie. W takim przypadku należy użyć metody AddScopedFeatureManagement.

Jak otrzymywać ogłoszenia dotyczące nowych wydań i innych informacji związanych z usługą App Configuration?

Subskrybuj nasze repozytorium ogłoszeń GitHub.

Jak zgłosić problem lub przekazać sugestię?

Możesz skontaktować się z nami bezpośrednio w usłudze GitHub.

Następne kroki

• Informacje o usłudze Azure App Configuration

W tym artykule znajdują się odpowiedzi na często zadawane pytania dotyczące usługi Azure App Configuration.

Usługa App Configuration ułatwia deweloperom zarządzanie ustawieniami aplikacji i kontrolowanie dostępności funkcji. Ma na celu uproszczenie wielu zadań związanych z pracą ze złożonymi danymi konfiguracji.

Usługa App Configuration obsługuje:

• Hierarchiczne przestrzenie nazw
• Etykieta
• Obszerne zapytania
• Pobieranie wsadowe
• Wyspecjalizowane operacje zarządzania
• Interfejs użytkownika zarządzania funkcjami

Usługa App Configuration uzupełnia usługę Key Vault, a obie powinny być używane obok siebie we większości wdrożeń aplikacji.

Chociaż usługa App Configuration zapewnia wysoki poziom zabezpieczeń, usługa Key Vault nadal jest najlepszym miejscem do przechowywania wpisów tajnych aplikacji. Usługa Key Vault zapewnia szyfrowanie na poziomie sprzętu, szczegółowe zasady dostępu i operacje zarządzania, takie jak rotacja certyfikatów.

Możesz utworzyć w usłudze App Configuration pary klucz-wartość, które odwołują się do sekretów przechowywanych w usłudze Key Vault. Aby uzyskać więcej informacji, zobacz Use Key Vault references in an ASP.NET Core app (Używanie odwołań do usługi Key Vault w aplikacji ASP.NET Core).

Tak. Usługa App Configuration zawsze szyfruje wszystkie dane przesyłane i magazynowane. Cała komunikacja sieciowa odbywa się za pośrednictwem protokołu TLS 1.2 lub TLS 1.3. Usługa App Configuration obsługuje szyfrowanie danych magazynowanych za pomocą kluczy zarządzanych przez firmę Microsoft lub kluczy zarządzanych przez klienta.

Usługa Azure App Service umożliwia definiowanie ustawień aplikacji dla każdego wystąpienia usługi Azure App Service. Te ustawienia są przekazywane jako zmienne środowiskowe do kodu aplikacji. Jeśli chcesz, możesz skojarzyć ustawienie z określonym miejscem wdrożenia. Aby uzyskać więcej informacji, zobacz Konfigurowanie ustawień aplikacji.

Natomiast aplikacja systemu Azure Configuration umożliwia zdefiniowanie ustawień, które mogą być współużytkowane przez wiele aplikacji. Obejmuje to aplikacje uruchomione w usłudze App Service, a także inne platformy. Kod aplikacji uzyskuje dostęp do tych ustawień za pośrednictwem dostawców konfiguracji dla platformy .NET i języka Java, za pośrednictwem zestawu Azure SDK lub bezpośrednio za pośrednictwem interfejsów API REST.

Odwołania do danych usługi App Configuration można dodawać w ustawieniach aplikacji usługi App Service. Możesz również zaimportować i wyeksportować ustawienia między usługą App Service i usługą App Configuration. Ta możliwość umożliwia szybkie utworzenie nowego zasobu App Configuration na podstawie istniejących ustawień usługi App Service. Możesz również udostępnić konfigurację istniejącej aplikacji, która opiera się na ustawieniach usługi App Service.

Istnieje limit 10 KB dla pojedynczej wartości klucza, w tym atrybutów, takich jak etykieta, typ zawartości, tagi i inne metadane. Nie ma limitu liczby kluczy i etykiet, o ile ich całkowity rozmiar jest niższy niż limit magazynu.

Ten limit klucz-wartość powinien być wystarczający dla pojedynczego ustawienia w większości aplikacji. Jeśli okaże się, że ustawienie jest większe niż ten limit, możesz rozważyć przechowywanie danych w innym miejscu i dodać odwołanie do tych danych w usłudze App Configuration.

Aby uzyskać pełną listę limitów, zobacz ograniczenia nazewnictwa i limity subskrypcji i usługi.

Możesz kontrolować, kto może uzyskiwać dostęp do usługi App Configuration na poziomie poszczególnych sklepów. Użyj oddzielnego magazynu dla każdego środowiska, które wymaga różnych uprawnień. Takie podejście zapewnia najlepszą izolację zabezpieczeń.

Jeśli nie potrzebujesz izolacji zabezpieczeń między środowiskami, możesz użyć etykiet, aby odróżnić wartości konfiguracji. Użyj etykiet, aby włączyć różne konfiguracje dla różnych środowisk , zawiera kompletny przykład.

Zobacz najlepsze rozwiązania.

Istnieją cztery warstwy cenowe: Bezpłatna, Deweloper, Standardowa i Premium. Aby uzyskać szczegółowe informacje o cenach, zapoznaj się ze stroną cennika usługi App Configuration.

Wszystkie warstwy konfiguracji aplikacji oferują podstawowe funkcje, w tym ustawienia konfiguracji, flagi funkcji, odwołania do usługi Key Vault, migawki konfiguracji, podstawowe operacje zarządzania, metryki i dzienniki.

Poniżej przedstawiono kwestie, które należy wziąć pod uwagę przy wyborze warstwy.

• Cel: Warstwa Bezpłatna jest idealna do oceny usługi w środowiskach nieprodukcyjnych, umożliwiając eksplorowanie jej funkcji bez żadnych kosztów.

  Warstwa Deweloper jest ekonomiczna dla małych, nieprodukcyjnych przypadków użycia i jest wyposażona w funkcje i możliwości dostosowane specjalnie do potrzeb programistycznych i testowych.

  Warstwa Standard jest przeznaczona do średnioskalowych wdrożeń produkcyjnych i zastosowań nieprodukcyjnych, zapewniając równowagę między wydajnością a efektywnością kosztową.

  W przypadku wysokiej ilości lub potrzeb produkcyjnych na poziomie przedsiębiorstwa warstwa Premium oferuje najwyższy poziom wydajności i skalowalności, dzięki czemu aplikacje działają bezproblemowo nawet pod dużym obciążeniem.

• Zasoby w ramach subskrypcji: Zasób składa się z jednego magazynu konfiguracji. Każda subskrypcja w warstwie Bezpłatna jest ograniczona do jednego magazynu konfiguracji w każdym regionie. Subskrypcje w warstwach Developer, Standard i Premium mogą mieć nieograniczoną liczbę magazynów konfiguracji.

• Pamięć masowa na zasób: W warstwie Bezpłatna każdy magazyn konfiguracji jest ograniczony do 10 MB zwykłej pamięci masowej i 10 MB pamięci masowej migawek. W warstwie Deweloper każdy magazyn konfiguracji może używać do 500 MB zwykłego magazynu i dodatkowego 500 MB magazynu migawek. W warstwie Standard każdy magazyn konfiguracji może używać maksymalnie 1 GB standardowej przestrzeni magazynowej oraz dodatkowego 1 GB przestrzeni magazynowej na migawki. W warstwie Premium każdy magazyn konfiguracji może używać do 4 GB zwykłego magazynu i dodatkowego 4 GB magazynu migawek.

• Historia poprawek: usługa App Configuration przechowuje historię wszystkich zmian wprowadzonych w kluczach. W warstwach Bezpłatna i Deweloper ta historia jest przechowywana przez siedem dni. W warstwach Standardowa i Premium ta historia jest przechowywana przez 30 dni.

• Limit żądań: sklepy w warstwie bezpłatnej są ograniczone do 1 000 żądań dziennie. Gdy sklep osiągnie 1000 żądań, zwraca kod stanu HTTP 429 dla wszystkich żądań do północy CZASU UTC.

  Sklepy w warstwie Deweloper mają limit 6 000 żądań na godzinę. Po wyczerpaniu limitu przydziału godzinowego dodatkowe żądania zwracają kod stanu HTTP 429, wskazując zbyt wiele żądań do końca godziny.

  Magazyny w warstwie Standardowa są ograniczone do 30 000 żądań na godzinę. Po wyczerpaniu limitu godzinowego dodatkowe żądania mogą zwracać kod stanu HTTP 429, oznaczający zbyt dużą liczbę żądań, aż do końca godziny. W miarę wysyłania większej liczby żądań przekraczających przydział większy odsetek z nich może zwracać kod stanu 429.

  Sklepy w warstwie Premium nie mają limitu liczby żądań, co zapewnia, że dostęp do sklepu nigdy nie jest blokowany.

• Przepływność: magazyny usługi App Configuration we wszystkich warstwach mają limit przepływności. Żądania, które przekraczają ten limit, otrzymują odpowiedź z kodem statusu HTTP 429.

  Magazyny danych w warstwach Bezpłatna i Deweloper nie mają gwarantowanej przepustowości.

  Magazyny w warstwie Standard obsługują przepustowość† do 300 żądań na sekundę (RPS) w przypadku żądań odczytu i do 60 RPS w przypadku żądań zapisu.

  Konta magazynu w warstwie Premium obsługują przepustowość† do 450 RPS w przypadku żądań odczytu i do 100 RPS w przypadku żądań zapisu.

  †Wskaźnik przepustowości jest zwykle mierzony jako średnia liczba żądań obsługiwanych przez magazyn App Configuration bez ograniczania w określonym przedziale czasu.

• Umowa dotycząca poziomu usług: plan bezpłatny i plan deweloperski nie mają SLA. Warstwa Standardowa ma umowę SLA gwarantującą dostępność na poziomie 99,9% i dostępność na poziomie 99,95% z włączoną replikacją geograficzną. Warstwa Premium ma umowę SLA gwarantującą dostępność na poziomie 99,9% i dostępność na poziomie 99,99% z włączoną replikacją geograficzną.

• Funkcje: Wszystkie warstwy cenowe obejmują następujące funkcje: szyfrowanie przy użyciu kluczy zarządzanych przez firmę Microsoft, uwierzytelnianie za pomocą klucza dostępu lub Microsoft Entra ID, kontrolę dostępu opartą na rolach platformy Azure (RBAC), tożsamość zarządzaną, tagi usług oraz nadmiarowość między strefami dostępności.

  Warstwa Deweloper obejmuje również obsługę usługi Private Link.

  Warstwy Standard i Premium oferują więcej funkcjonalności, w tym obsługę Private Link, szyfrowanie przy użyciu kluczy zarządzanych przez klienta, ochronę przed przywracalnym usunięciem oraz obsługę georeplikacji.

• Koszt: korzystanie ze sklepu w warstwie Bezpłatnej nie wiąże się z żadnymi kosztami.

  Sklepy w warstwie Deweloper są objęte dzienną opłatą za użytkowanie, która obejmuje pierwsze 3 000 żądań każdego dnia. Żądania wykraczające poza tę dzienną alokację powodują naliczanie opłat za nadwyżkę.

  Magazyny w warstwie Standardowa mają opłatę za dzienne użycie, która obejmuje pierwsze 200 000 żądań każdego dnia. Żądania wykraczające poza tę dzienną alokację powodują naliczanie opłat za nadwyżkę.

  Magazyny w warstwie Premium mają również opłatę za dzienne użycie i obejmują replikę. Pierwsze 800 000 żądań dotyczących źródła i pierwsze 800 000 żądań dotyczących repliki każdego dnia są wliczone w dzienną opłatę. Żądania przekraczające tę dzienną alokację powodują naliczanie opłat za nadwyżkę.

Magazyn App Configuration można uaktualnić w dowolnym momencie, na przykład z warstwy Bezpłatna do warstwy Deweloper, Standardowa lub Premium albo z warstwy Developer, Standard do warstwy Premium.

Magazyn App Configuration można przełączyć z warstwy Premium na warstwę Standard, ponieważ obie warstwy są przeznaczone do zastosowań produkcyjnych. Jednak obniżenie poziomu do warstwy nieprodukcyjnej, takiej jak warstwa Bezpłatna, nie jest obsługiwane. Aby to osiągnąć, możesz utworzyć nowy magazyn w żądanej warstwie, a następnie zaimportować dane konfiguracji do tego magazynu.

Przed obniżeniem poziomu magazynu usługi App Configuration z warstwy Premium do warstwy Standardowa upewnij się, że użycie zwykłego magazynu i magazynu migawek jest poniżej limitów warstwy Standardowa. Bieżące użycie można zweryfikować za pomocą metryk usługi Azure Monitor — Daily Storage Usage i Snapshot Storage Size — dla magazynu usługi App Configuration w portalu Azure.

Dane klienta przechowywane w konfiguracji aplikacji znajdują się w regionie, w którym utworzono sklep konfiguracji aplikacji klienta. Dane klienta są replikowane do innego regionu tylko wtedy, gdy klient włączy replikację geograficzną dla tego regionu. Dotyczy to wszystkich dostępnych regionów. Klienci mogą przenosić, kopiować lub uzyskiwać dostęp do danych z dowolnej lokalizacji na całym świecie.

aplikacja systemu Azure Configuration obsługuje replikację geograficzną w celu zwiększenia odporności na awarie regionalne.

aplikacja systemu Azure Configuration obsługuje strefy dostępności platformy Azure w celu ochrony aplikacji i danych przed pojedynczymi awariami centrum danych. Wszystkie regiony z obsługą strefy dostępności składają się z co najmniej trzech stref dostępności, w których każde z nich jest fizycznie niezależnym centrum danych. Aby zapewnić odporność, ta funkcja w usłudze App Configuration jest włączona dla wszystkich klientów bez dodatkowych opłat. Poniżej przedstawiono regiony, w których usługa App Configuration włączyła obsługę stref dostępności. Aby uzyskać więcej informacji, zobacz Regiony platformy Azure z obsługą stref dostępności.

Ameryka	Europa	Bliski Wschód	Afryka	Azja i Pacyfik
Brazylia Południowa	Francja Środkowa	Izrael Środkowy		Australia Wschodnia
Kanada Środkowa	Niemcy Środkowo-Zachodnie	Katar Środkowy		Indie Środkowe
Środkowe stany USA	Włochy Północne	Północne Zjednoczone Emiraty Arabskie		Chiny Północne 3
Wschodnie stany USA	Europa Północna			Azja Wschodnia
Wschodnie stany USA 2	Norwegia Wschodnia			Japonia Wschodnia
Meksyk Środkowy	Polska Środkowa			Korea Środkowa
Południowo-środkowe stany USA	Hiszpania Środkowa			Azja Południowo-Wschodnia
US Gov Wirginia	Szwecja Środkowa
Zachodnie stany USA 2	Szwajcaria Północna
Zachodnie stany USA 3	Południowe Zjednoczone Królestwo
	Europa Zachodnia

Magazyny usługi App Configuration mają różne limity żądań w zależności od warstwy. Sklepy w warstwie Free są ograniczone do 1000 żądań dziennie, sklepy w warstwie Developer do 6000 żądań na godzinę, sklepy w warstwie Standard do 30 000 żądań na godzinę, a sklepy w warstwie Premium nie mają limitu żądań, co zapewnia nieprzerwany dostęp.

Magazyny usługi App Configuration mają limity przepustowości zależne od swojej warstwy. Magazyny w warstwach Bezpłatna i Deweloper nie mają gwarantowanej przepustowości. Konta magazynu w warstwie Standard obsługują do 300 żądań na sekundę (RPS) dla operacji odczytu i do 60 żądań na sekundę (RPS) dla operacji zapisu. Magazyny w warstwie Premium obsługują przepustowość do 450 RPS w przypadku operacji odczytu i do 100 RPS w przypadku operacji zapisu.

Załóżmy, że masz aplikację z 1000 ustawieniami konfiguracji. Aplikacja ładuje wszystkie te ustawienia z usługi App Configuration po uruchomieniu. Następnie co 30 sekund sprawdza klucz wartownika, aby wykryć zmiany konfiguracji. Niezależnie od tego, czy korzystasz z platformy Kubernetes, usługi App Service, czy maszyn wirtualnych, załóżmy, że masz 50 wystąpień aplikacji uruchomionych jednocześnie.

Najpierw szacujmy żądania monitorowania konfiguracji. Każda instancja aplikacji wysyła do usługi App Configuration jedno żądanie dotyczące klucza sentinel* co 30 sekund, dlatego w ciągu godziny wysyła 120 żądań (=3600/30). Jeśli masz 50 wystąpień aplikacji, aplikacja wysyła 6000 (=120x50) łącznych żądań co godzinę na potrzeby monitorowania konfiguracji. Należy pamiętać, że ponieważ żądania dotyczące klucza Sentinel są częste i w większości pozostają bez zmian, większość z nich nie wlicza się do limitów godzinowego przydziału dla magazynu† w warstwie Standard.

Po drugie szacujmy żądania ładowania/ponownego ładowania konfiguracji. Aplikacja ładuje wszystkie ustawienia podczas uruchamiania lub za każdym razem, gdy zostanie wykryta zmiana klucza sentinel. Każde żądanie do usługi App Configuration może pobrać do 100 par klucz-wartość, więc załadowanie wszystkich ustawień wymaga 10 (=1000/100) żądań. Jeśli masz 50 wystąpień aplikacji, wysyłasz 500 (=10x50) łącznych żądań po ponownym uruchomieniu aplikacji lub ponownym załadowaniu jej konfiguracji.

Na koniec złóżmy to w całość. Przy założeniu, że klucz sentinel został zaktualizowany dwa razy w ciągu godziny, magazyn usługi App Configuration otrzyma zatem 7000 (=6 000+500x2) łącznych żądań dla tej godziny. Należy pamiętać, że spośród tych żądań tylko około 1000 (=500x2) wlicza się do dostępnego godzinowego limitu dla magazynu w warstwie Standard. Zaktualizuj wartości liczbowe w tym przykładzie tak, aby odpowiadały Twojej konkretnej konfiguracji, i odpowiednio zaprojektuj rozwiązanie, tak aby zapewnić sobie wystarczający bufor względem godzinowego limitu przydziału.

*Flagi funkcjonalności nie używają klucza kontrolnego do monitorowania zmian i są monitorowane niezależnie od konfiguracji. Wymagane jest jedno żądanie do monitorowania każdych 100 flag funkcji w każdym interwale odświeżania.

†Sklepy w warstwie bezpłatnej nie mają wyłączenia z dziennego limitu dla częstych, powtarzających się żądań.

Aplikacja może otrzymać odpowiedź http o kodzie stanu 429 w następujących okolicznościach:

• Przekroczenie dziennego limitu żądań dla sklepu w warstwie bezpłatnej.
• Przekroczenie godzinowego limitu żądań dla sklepu w poziomie Developer.
• Przekroczenie godzinowego limitu żądań dla sklepu w warstwie Standard.
• Przekroczenie limitu przepustowości sklepu na dowolnym poziomie.
• Przekroczenie limitu przepustowości magazynu w dowolnej warstwie.
• Próba utworzenia lub zmodyfikowania wartości klucza po przekroczeniu limitu przydziału magazynu.

Sprawdź treść odpowiedzi 429, aby poznać konkretny powód, dla którego żądanie zakończyło się niepowodzeniem. Możesz również zbierać dzienniki dla magazynu App Configuration w usłudze Azure Monitor i skonfigurować alerty dla metryki Wykorzystanie limitu żądań.

Odbieranie chwilowego kodu stanu HTTP 429 zwykle nie powoduje żadnych szkód, ponieważ klienci usługi App Configuration obsługują je bezpiecznie. Jeśli jednak aplikacja regularnie korzysta z kodu stanu HTTP 429, rozważ następujące opcje:

• Uaktualnij swój sklep do warstwy Premium: ta warstwa nie ma limitu przydziału żądań oraz oferuje zwiększony limit magazynowania i wyższy limit przepustowości.
• Użyj dostawców konfiguracji aplikacji: Dostawcy usług mają wbudowane mechanizmy ponawiania i buforowania, a także wiele innych funkcji zapewniających odporność. Pamiętaj, aby zaktualizować dostawcę do najnowszej wersji, aby uzyskać wszystkie najnowsze ulepszenia.
• Użyj zestawów SDK usługi App Configuration, jeśli aplikacja musi wysyłać żądania zapisu. Chociaż zestawy SDK mogą nie być tak rozbudowane jak rozwiązania dostawców, automatycznie ponawiają żądania w przypadku odpowiedzi z kodem stanu HTTP 429 oraz innych przejściowych błędów.
• Uwzględnij logikę ponawiania prób w klientach niestandardowych, jeśli nie możesz używać dostawców usługi App Configuration ani pakietów SDK. Nagłówek retry-after-ms w odpowiedzi zawiera sugerowany czas oczekiwania (w milisekundach) przed ponowną próbą żądania.
• Rozłóż żądania między wiele wystąpień klienta: Pomaga to uzyskać maksymalną przepustowość magazynu App Configuration.
• Zmniejsz liczbę żądań wysyłanych do usługi App Configuration: postępuj zgodnie ze wskazówkami, aby zminimalizować liczbę żądań.
• Zmniejsz przechowywanie wersji klucz-wartość, jeśli przeprowadzasz częste aktualizacje klucz-wartość i nie musisz zachowywać wersji przez maksymalny czas dozwolony przez usługę App Configuration. Poprawki są wliczane do całkowitego zużycia pamięci w sklepie. Jeśli limit przydziału magazynu zostanie przekroczony, nie będzie już można tworzyć ani modyfikować flag klucz-wartości lub funkcji.
• Zwiększ odporność aplikacji: rozważ integrację replikacji geograficznej, aby umożliwić przechodzenie w tryb failover i równoważenie obciążenia. Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi tworzenia wysoce odpornych aplikacji.

Zobacz najlepsze rozwiązania dotyczące aplikacji klienckich w usłudze App Configuration

Wszystkie magazyny usługi App Configuration w warstwach Standard i Premium mają automatycznie włączoną funkcję soft-delete. Po usunięciu magazynu App Configuration w warstwie Standard lub Premium jego nazwa jest zarezerwowana na okres przechowywania. Aby ponownie utworzyć magazyn o tej samej nazwie przed wygaśnięciem okresu przechowywania, należy najpierw przeczyścić magazyn usunięty nietrwale, pod warunkiem, że magazyn nie ma włączonej ochrony przed przeczyszczeniem. Jeśli ochrona przed przeczyszczeniem jest włączona, musisz poczekać na upłynięcie okresu przechowywania. Użyj funkcji przeczyszczania lub ustaw krótszy okres przechowywania, jeśli często trzeba ponownie utworzyć magazyn o tej samej nazwie. Przepływy pracy, które wymagają ponownego utworzenia magazynu o tej samej nazwie, powinny zezwalać na jedną godzinę między przeczyszczeniem magazynu konfiguracji i wykonaniem kolejnej operacji tworzenia. Zalecenie to jest sformułowane, ponieważ po zażądaniu czyszczenia rzeczywiste usunięcie zasobów magazynu konfiguracji jest wykonywane asynchronicznie, co wymaga pewnego dodatkowego czasu na sfinalizowanie. Aby uniknąć konieczności czekania, zaleca się, aby przepływy pracy tworzące tymczasowe magazyny konfiguracji używały unikatowych nazw.

Wszystkie magazyny konfiguracji aplikacji w warstwach Standard i Premium obsługują funkcję odzyskiwalnego usuwania, której nie można wyłączyć. Usunięty magazyn można odzyskać w okresie jego przechowywania. Postępuj zgodnie z poniższymi instrukcjami, aby odzyskać omyłkowo usunięty magazyn usługi App Configuration.

Użyj dzienników aktywności , aby zobaczyć, kto uzyskiwał dostęp do lub modyfikował płaszczyznę sterowania sklepu App Configuration. Użyj dzienników zasobów , aby określić, kto uzyskiwał dostęp do płaszczyzny danych.

Tak. Chociaż można zarządzać flagami funkcji i odwołaniami usługi Key Vault w usłudze App Configuration za pośrednictwem witryny Azure Portal lub interfejsu wiersza polecenia, można również tworzyć i aktualizować je programowo przy użyciu zestawów SDK usługi App Configuration. Dlatego możesz napisać własny portal zarządzania lub zarządzać nimi programowo w swoim procesie CI/CD. Flaga funkcjonalności i interfejsy API odwołań do usługi Key Vault są dostępne w pakietach SDK dla wszystkich obsługiwanych języków. Zapoznaj się z przykładowymi linkami, aby zobaczyć przykłady w każdym obsługiwanym języku.

Ocenianie i używanie flag funkcjonalności w aplikacji wymaga dostawcy usługi App Configuration oraz bibliotek do zarządzania funkcjami, które są dostępne dla platform .NET, Java Spring, Python, JavaScript i Go. Aby uzyskać więcej informacji, zapoznaj się z tematem Zarządzanie funkcjami — omówienie.

Profile spring umożliwiają oddzielenie części aplikacji, w tym konfiguracji i udostępnienie jej tylko w niektórych środowiskach lub w przypadku użycia określonych bibliotek.

Zaleca się ustawienie etykiety par klucz-wartość tak, aby odpowiadała profilom Spring. Domyślnie biblioteka dostawcy Spring dla App Configuration ładuje pary klucz-wartość oznaczone etykietami odpowiadającymi aktualnie aktywnym profilom Spring (${spring.profiles.active}), jeśli filtr etykiet nie został jawnie ustawiony. Jeśli nie ustawiono aktywnego profilu Spring, zostaną załadowane pary klucz-wartość z etykietą „no label”.

Na przykład dla profili dev i prod należy utworzyć odpowiednie pary klucz–wartość zgodnie z poniższymi etykietami.

Klawisz	Etykieta	Wartość
/application/config.message	dev	Witaj od dewelopera
/application/config.message	Prod	Witaj z prod

Gdy profil Spring jest ustawiony na dev, wartość parametru config.message będzie wynosić Hello from dev. Gdy profil Spring jest ustawiony na prod, wartość config.message wynosi Hello from prod.

To domyślne zachowanie można zastąpić, ustawiając filtr etykiet w pliku właściwości aplikacji. Biblioteka dostawcy spring ładuje wartości kluczy z określonymi etykietami niezależnie od aktywnego profilu Spring.

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

Aby wybrać inne etykiety i profile spring, możesz użyć filtru etykiet, takiego jak ',${spring.profiles.active}', który wybierze wszystkie klucze bez etykiety i tych pasujących do profilów spring. Skrajnie prawe etykiety mają priorytet w przypadku wykrycia zduplikowanych kluczy.

Począwszy od wersji 3.1.0 biblioteka Microsoft.FeatureManagement umożliwia uruchamianie usług zarządzania funkcjami, w tym filtrów funkcji, jako usług o określonym zakresie w aplikacjach .NET opartych na iniekcji zależności. Aby skorzystać z tej funkcji, możesz po prostu zastąpić w kodzie wywołanie AddFeatureManagement wywołaniem AddScopedFeatureManagement, jak pokazano w poniższym fragmencie kodu:

services.AddScopedFeatureManagement();

Filtry funkcji mogą oceniać flagę funkcji na podstawie właściwości żądania HTTP. Zwykle wykonuje się to przez sprawdzenie elementu HttpContext za pomocą wzorca IHttpContextAccessorSingleton. Jednak ten wzorzec nie działa w przypadku aplikacji serwera Blazor, w których należy zamiast tego używać usług o określonym zakresie. W takim przypadku należy użyć metody AddScopedFeatureManagement.

Subskrybuj nasze repozytorium ogłoszeń GitHub.

Możesz skontaktować się z nami bezpośrednio w usłudze GitHub.

• Informacje o usłudze Azure App Configuration