Ujawniamy bezpaństwowy Owad WebAPI hostowany na wszystkich węzłach w klastrze usług serwisowych (liczba wystąpień -1) na platformie Azure. WebAPI jest przeznaczony do użytku publicznego i powinien być wysoce dostępny nawet w przypadku ulepszeń wewnętrznych usług i samego WebAPI. Mamy moduł ładujący Azure (LB) przed klastrem, który bada klastry na porcie 80 za pomocą sondy TCP co 5 sekund, aby określić, które węzły mogą odbierać ruch http.Wysoce dostępny Service Fabric WebApi hostowany na platformie Azure
Występują problemy podczas aktualizacji interfejsu WebAPI, a mianowicie LB kieruje do węzła, który jest aktualizowany, ale nie jest jeszcze zarejestrowany jako offline przez sondę. Usługa Fabric nie koordynuje procesu aktualizacji z LB, więc nie ma szans (ani żadnego interfejsu API na platformie Azure LB), aby wyeliminować węzeł podczas aktualizacji.
Zastanawiamy się, w jaki sposób ludzie osiągają wysoce dostępne usługi http na Service Fabric na platformie Azure. Mam nadzieję, że ktoś skomentuje ich ogólne podejście.
Myśleliśmy o tym. Musimy opóźnić proces zamykania podczas aktualizacji, który obejmuje przechwytywanie Ctrl-C wysłanego do procesu i czekanie na wystarczającą liczbę sond LB, aby trafić w punkt końcowy zdrowia, aby uznać za bezpieczne całkowite zamknięcie procesu. Musimy również zapewnić wystarczającą ilość czasu na aktualizację, aby uniknąć sytuacji, w której proces zamieni aplikację w Ostrzeżenie/Błąd, ponieważ jest powolny, aby zareagować na zamknięcie. –