Доставчици на конфигурация
Зареждайте маршрути и клъстери програмно, вместо от файл, чрез собствена имплементация на IProxyConfigProvider - полезно за база данни, отдалечено API или произволен друг източник.
Интерфейсът на доставчика
Файлове с конфигурация покриват честия случай на зареждане от IConfiguration. За да заредите от произволно друго място, имплементирайте сами IProxyConfigProvider и IProxyConfig.
IProxyConfigProvider има един-единствен метод, GetConfig(), който връща IProxyConfig - моментна снимка с текущите маршрути и клъстери, заедно с IChangeToken, който доставчикът сигнализира винаги, когато тази снимка остарее, което кара проксито да извика GetConfig() отново.
Директно зареждане на маршрути и клъстери
За най-простия случай - маршрути и клъстери, изцяло известни в кода - InMemoryConfigProvider е готова за употреба реализация на IProxyConfigProvider:
C#services.AddReverseProxy().LoadFromMemory(routes, clusters);За да промените тази конфигурация по-късно, извлечете InMemoryConfigProvider от контейнера за услуги и извикайте Update:
C#httpContext.RequestServices.GetRequiredService<InMemoryConfigProvider>()
.Update(routes, clusters);Жизнен цикъл на доставчика
Стартиране
IProxyConfigProvider се регистрира като синглтън. При стартиране проксито го извлича и извиква GetConfig() веднъж; доставчикът може да:
- хвърли изключение, ако не може да произведе валидна конфигурация - това предотвратява стартирането на приложението;
- блокира синхронно, докато конфигурацията се зареди, което забавя стартирането до момента, в който станат налични валидни данни за маршрутите; или
- върне веднага празен
IProxyConfigи да зареди на заден план, сигнализирайки свояIChangeToken, щом реалните данни станат готови.
Каквато и конфигурация да бъде върната, тя се валидира, а невалиден резултат хвърля изключение, което предотвратява стартирането - вместо това доставчикът може предварително да валидира с IConfigValidator и сам да изключи невалидните записи.
Обектите за маршрути и клъстери, предадени на проксито, трябва да се третират като само за четене, след като бъдат върнати от GetConfig().
Презареждане
Ако IChangeToken поддържа активни обратни извиквания при промяна, проксито регистрира такова след първоначалното зареждане; в противен случай HasChanged се проверява на всеки 5 минути. За да публикува нова конфигурация, доставчикът трябва да я зареди на заден план - изграждайки нови инстанции на маршрути/клъстери, тъй като те са неизменяеми, макар непроменените да могат да се преизползват - по избор да я валидира, и едва тогава да сигнализира предишния IChangeToken. В отговор проксито извиква GetConfig() отново и сравнява резултата с текущата конфигурация, обновявайки само промененото; смяната е атомарна и засяга само новите заявки, а не тези, които вече са в процес на обработка.
IChangeToken обектите са за еднократна употреба. Ако GetConfig() хвърли изключение по време на презареждане, проксито губи способността си да следи за по-нататъшни промени от този доставчик. Всички други грешки при презареждане вместо това се логват и потискат, а проксито продължава да използва последната позната валидна конфигурация.
Ако няколко презареждания бъдат сигнализирани в бърза последователност, проксито може да пропусне някои от тях и да зареди каквото е налично, докато се изравни - всеки IProxyConfig е пълна моментна снимка, а не разлика, така че нищо не се губи при пропускането на междинна снимка.
Множество доставчици
Повече от един IProxyConfigProvider може да бъде регистриран като синглтън; всички те се извличат и конфигурациите им се комбинират, по същия начин, по който могат да се комбинират и няколко секции на файл с конфигурация. Маршрут от един доставчик може да препраща към клъстер от друг, но един-единствен маршрут или клъстер не може да бъде сглобен от частични данни, разпръснати между два доставчика.