Powyższe zdjęcie przedstawia wersję w odcieniach szarości Tencenta, zwykli użytkownicy mają do niej dostęp, serwer Alibaba Cloud jest niedostępny, ping jest normalny, a adres IP rozdzielczości również normalny
Jest po prostu niedostępny, widać, że Tencent lubi też bawić się wypuszczaniem w odcieniach szarości...
1. Dlaczego Grayscale Release
- Usługi internetowe często się zmieniają, a cykle wydawań są krótkie. Szybkość i jakość zawsze trudno połączyć.
- Publikacje w odcieniach szarości mogą zmniejszyć ryzyko publikacji i ograniczyć zakres ich wpływu.
- Ogranicz zależność od testowania i obniż koszty budowy danych do samodzielnego testowania offline.
- Wygodne jest centralne monitorowanie logów i publikowanie ich w całości. Ze względu na rolę równoważenia obciążenia na każdej warstwie trudno jest śledzić pełne połączenie połączenia.
- Możesz używać testowych kont w skali szarości, a potem prawdziwych kont użytkowników w skali szarości po przejściu konta testowego, aby jeszcze bardziej zmniejszyć ryzyko i wpływ publikacji.
- Łatwy cofnięcie się.
Problemy, których nie da się rozwiązać za pomocą wydań w odcieniach szarości
Należy podkreślić, że wspomniany powyżej "tolerowalny wpływ" musi być możliwy do odzyskania, na przykład API nie może być wywoływane przez określony czas, ale po naprawie można je pomyślnie wywołać. Trwała utrata lub zniszczenie danych użytkowników (takich jak informacje o produkcie, zamówienia itp.) jest nie do przyjęcia. Dlatego to architekci przedsiębiorstw internetowych są odpowiedzialnością za naprawę utraconych danych użytkowników do stanu niedawnego (np. godzinę temu lub tydzień temu) poprzez ręczną interwencję w przypadku utraty danych użytkowników spowodowanych zaburzeniami systemu produkcyjnego (np. regularne tworzenie kopii zapasowych danych użytkowników, zapisywanie logów operacyjnych itp.).
WSKAZÓWKI Najpierw przetestuj politykę szarości swojego konta, aby zmniejszyć ryzyko uszkodzenia lub utraty danych prawdziwych użytkowników.
2. Jaki efekt jest oczekiwany?
Niezależnie od zmiany, chcemy, aby konkretne żądania były kierowane do naszej wersji zmiany (wersji w skali szarości) w celu obserwacji i weryfikacji.
3. Strategia szarości
W rzeczywistości to właśnie żądania powinny być kierowane do naszej wersji w skali szarości (maszyna w skali szarości). Często jest to mocno związane z biznesem. Na przykład dla API zazwyczaj obowiązują następujące wymagania:
Konkretni użytkownicy (np. konta testowe)
Konkretne aplikacje (np. testowe lub partnerskie)
Specyficzne moduły i interfejsy (tylko niektóre interfejsy wymagają szarości, która zazwyczaj jest modyfikacją kontenerów API, a niektóre API mniej istotne są używane do testów w skalach szarości). ）
Konkretna maszyna (niektóre adresy IP żądań są przekazywane do maszyny w skali szarości)
4. Dyskusja na temat schematów w odcieniach szarości
Rozwiązanie 1: Poziom kodu jest oceniany przez uzgodnioną flagę, a stary i nowy są dynamicznie zamieniane – podejście Amazona
Realizacja:
Zakop przełącznik w kodzie, wymyśl if-else i ustaw przełącznik na włączony dla maszyn wymagających skali szarości, w przeciwnym razie jest wyłączony. Każda wersja ma dwie wersje.
zasługa
Szybkie cofanie, nie trzeba ponownie publikować i restartować systemu.
niedociągnięcie
Bądź skłonny do kodeksu.
Logika rozgałęziająca niesie ze sobą złożoność.
Tę metodę stosował autor, gdy byłem w Alibaba, przenosząc bazę danych dóbr z Oracle na MySQL i używając zmiennej stanu do kontroli. W ten sposób osiąga się efekt płynnej migracji.
Opcja 2: Maszyna przedpremierowa – praktyka Alibaby
W rzeczywistości to nie jest prawdziwa skala szarości. Ponieważ ta maszyna pre-release jest wewnętrznym adresem IP i nie posiada zewnętrznej usługi. Do weryfikacji wymagane jest powiązanie domeny. Ale dane są całkowicie online. To zasadniczo proste podejście dla niektórych konkretnych użytkowników Grayscale (użytkowników mających dostęp do maszyny Grayscale, wewnętrznych testów). W rzeczywistości podobne podejście istnieje po stronie API, czyli środowiska Gamma, a także udostępniamy domenę maszyny Gamma, aby ułatwić współpracę zewnętrznym użytkownikom współpracującym z testami.
zasługa
Proste
niedociągnięcie
Marnowanie maszyny (można ją wprowadzić do środowiska produkcyjnego po zakończeniu przedpremiery i usunąć z nginx podczas przedpremiery, ale wymagane jest wsparcie dla O&M). ）
Nie jest wystarczająco elastyczny
Usługi IDL mogą być używane tylko dla maszyn warstwy dostępu, a usługi IDL należy rozważać osobno.
Opcja 3: Wdrożenie SET
1. Wdrożenie w izolacji zgodnie z usługami
Na przykład w obecnej praktyce z kontenerami API szczegółowość wdrożenia może być osiągnięta do poziomu API, a front-end przekierowuje zgodnie z nginx. Na przykład co:
Kontener API Micro Shopping: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API Container: api.yixun.com
API zakupów online Container:api.buy.qq.com
Powyższe to odizolowane wdrożenie na poziomie dużych firm. Można je również dodatkowo udoskonalić na poziomie modułu, na przykład API wirtualnego e-commerce, które jest podmodułem biznesowym pod Paipai, ale ponieważ są połączone z WeChat, liczba wizyt znacznie wzrosła, aby uniknąć wpływu na inne biznesy Paipai oraz uniknąć wpływu ze strony innych firm, API polega na osobnym wdrażaniu dwóch maszyn dla nich, nginx może być skonfigurowany do odprowadzania dostępu do wirtualnego API:
Wirtualny kontener API: http://api.paipai.com/v2/virbiz
W ten sposób, gdy wydajemy wersję, możemy najpierw wybrać Yixun z najmniejszym wolumenem biznesowym do publikacji, a następnie zauważyć, że nie ma problemu, zanim zaczniemy korzystać ze wszystkich innych platform.
2. Wdrożenie przez izolację użytkownika
To nie jest zbyt odpowiednie dla otwartych platform, ale jest bardzo odpowiednie dla scenariuszy aplikacji, takich jak SNS. Na przykład system QQ jest podzielony na kilka zestawów według segmentów liczb użytkowników, a każdy zestaw zawiera 100 milionów kolejnych liczb. Zakładając, że najnowsza wartość QQ to blisko 1 miliarda, jest łącznie 10 zestawów (Zestaw 1 do Zestawu 10). Dzięki temu możesz za każdym razem wybrać jeden z SET-ów do publikacji, a wysoki poziom QQ często nie jest zbyt ważnym użytkownikiem, więc SET10 zostanie wydany jako pierwszy.
zasługa
Izolowane wdrożenie z minimalnym wpływem na wszystkie linie biznesowe. Automatycznie wspieraj publikacje w odcieniach szarości.
niedociągnięcie
Ziarnistość skali szarości zależy od ziarnistości izolowanego rozmieszczenia, która jest zazwyczaj duża.
Marnotrawstwo maszyn w porównaniu do scentralizowanego wdrożenia.
Wersje każdej linii biznesowej mogą być niespójne, co nie sprzyja jednolitemu zarządzaniu.
Istnieją pewne koszty wdrożenia i wdrożenia
Schemat 4: Dynamiczne trasowanie
Metoda: Użyj polityki w skali szarości, którą można elastycznie skonfigurować tak, aby wpływała na zachowanie load balance i pozwalała na zwracanie adresu IP oraz portu usługi w skali szarości zgodnie z polityką w skali szarości.
Odpowiedni do obsługi w skali szarości z IDL w back-office.
zasługa
Elastyczny, możliwy do kontrolowania.
niedociągnięcie
Obecne centrum konfiguracyjne oraz samo L5 nie uwzględniają określonych polityk routingu i nie są skalowalne, więc muszą być rozwijane poza nimi.
Źródła metadanych API są stosunkowo rozproszone, a obecnie metadane API i IDL, poziomy API oraz limity częstotliwości są rozproszone między różnymi źródłami danych, dlatego konieczne jest dodanie szarego źródła routingu.
Zazwyczaj istnieją trzy sposoby publikowania odcieni szarości nginx+lua: nginx jest dystrybuowany według ciasteczek, a nginx przypisywany według wagi:
nginx+lua rozróżnia się według adresu IP odwiedzającego, ponieważ firma eksportuje adres IP, a strona internetowa będzie dostępna w wersji starej lub nowej, co nie jest odpowiednie dla tej metody
nginx przypisuje wagi na podstawie wag, co jest proste do zaimplementowania i można to przetestować
NGINX dzieli się na podstawie plików cookie, a Grayscale publikuje na podstawie użytkowników
|
Opublikowano 09.03.2017 15:48:27
|
|
|
|
