Eliminowanie przestojów za pośrednictwem aktualizacji usługi w wersji
W przeszłości administratorzy musieli przejąć serwer w tryb offline w celu zaktualizowania i uaktualnienia oprogramowania lokalnego. Jednak przestój jest kompletnym nonstarterem dla globalnych usług 24×7. Wiele nowoczesnych usług w chmurze jest krytyczną zależnością dla użytkowników, którzy mogą uruchamiać swoje firmy. Nigdy nie ma dobrego czasu na wyłączenie systemu, więc jak zespół może zapewnić ciągłą usługę podczas instalowania ważnych aktualizacji zabezpieczeń i funkcji?
Korzystając z aktualizacji z wersjami, te usługi krytyczne mogą być bezproblemowo przenoszone z jednej wersji do innej , podczas gdy klienci aktywnie z nich korzystają. Nie wszystkie aktualizacje są trudne. Aktualizowanie układów frontonu lub stylów jest łatwe. Zmiany w funkcjach mogą być trudne, ale istnieją dobrze znane rozwiązania w celu ograniczenia ryzyka migracji. Jednak zmiany, które pochodzą z warstwy danych, wprowadzają nową klasę wyzwań, które wymagają szczególnej uwagi.
Aktualizowanie warstw oddzielnie
W przypadku rozproszonej usługi online w wielu centrach danych i oddzielnym magazynie danych nie wszystko może się zmieniać jednocześnie. Jeśli typowa usługa jest podzielona na kod aplikacji i bazy danych, które prawdopodobnie są wersjonowane niezależnie od siebie, jedna z tych stron musi wchłonąć złożoność obsługi wersji.
Często przechowywanie wersji jest łatwiejsze do obsługi w kodzie aplikacji. Większe systemy zwykle mają sporo starszego kodu, takiego jak SQL, który znajduje się w jego bazach danych. Zamiast dodatkowo komplikować ten kod SQL, kod aplikacji powinien obsługiwać złożoność. W szczególności można utworzyć zestaw klas fabrycznych, które rozumieją przechowywanie wersji SQL.
Podczas każdego przebiegu utwórz nowy interfejs z tej wersji, aby zawsze istniał kod zgodny z każdą wersją bazy danych. Podczas wdrażania można łatwo wycofać wszystkie pliki binarne. Jeśli coś pójdzie nie tak po wdrożeniu nowych plików binarnych, wróć do poprzedniego kodu. Jeśli wdrożenie binarne zakończy się pomyślnie, uruchom obsługę bazy danych.
Jak to działa? Załóżmy na przykład, że zespół wdraża obecnie przebieg 123. Pliki binarne rozumieją schemat bazy danych Sprint 123 i rozumieją schemat przebiegu 122. Ogólnym wzorcem jest praca z wersjami/przebiegami N i N-1 schematu SQL. Pliki binarne wysyłają zapytanie do bazy danych, określają, z którą wersją schematu rozmawiają, a następnie ładują odpowiednie powiązanie. Następnie kod aplikacji obsługuje przypadek, gdy nowy schemat danych nie jest jeszcze dostępny. Po udostępnieniu nowej wersji kod aplikacji może rozpocząć korzystanie z nowych funkcji, które są włączone przez najnowszą wersję bazy danych.
Przerzucanie tylko za pomocą warstwy danych
Po uaktualnieniu baz danych usługa jest w sytuacji wycofywania, jeśli wystąpi problem. Migracje baz danych online są złożone i często wieloetapowe, dlatego stopniowe przechodzenie do przodu jest zwykle najlepszym sposobem rozwiązania problemu. Innymi słowy, jeśli uaktualnienie zakończy się niepowodzeniem, wycofanie prawdopodobnie zakończy się niepowodzeniem. Nie ma większej wartości w inwestowaniu w wysiłek, aby skompilować i przetestować kod wycofywania, którego zespół nigdy nie spodziewa się użyć.
Sekwencja wdrażania
Rozważmy scenariusz, w którym należy dodać zestaw kolumn do bazy danych i przekształcić niektóre dane. To przejście musi być niewidoczne dla użytkowników, co oznacza, że unikanie blokad tabeli jest jak najwięcej, a następnie trzymanie blokad przez najkrótszy możliwy czas, aby nie były one zrozumiałe.
Pierwszą rzeczą, jaką robimy, jest manipulowanie danymi, prawdopodobnie w tabelach równoległych przy użyciu wyzwalacza SQL w celu zachowania synchronizacji danych. Duże migracje i przekształcenia danych czasami muszą być wieloetapowe w kilku wdrożeniach w wielu przebiegach.
Po równoległym utworzeniu dodatkowych danych lub nowego schematu zespół przejdzie do trybu wdrażania kodu aplikacji. W trybie wdrażania, gdy kod wykonuje wywołanie bazy danych, najpierw pobiera blokadę schematu, a następnie zwalnia go po uruchomieniu procedury składowanej. Baza danych nie może zmienić się między czasem uruchomienia wywołania bazy danych a uruchomieniem procedury składowanej.
Kod uaktualniania działa jako składnik zapisywania schematu i żąda blokady modułu zapisywania w schemacie. Kod aplikacji ma priorytet podczas blokowania czytnika, a kod uaktualniania znajduje się w tle, próbując uzyskać blokadę modułu zapisywania. W ramach blokady modułu zapisywania dozwolona jest tylko niewielka liczba bardzo szybkich operacji w tabelach. Następnie blokada zostanie zwolniona, a aplikacja rejestruje nową wersję bazy danych i używa interfejsu zgodnego z nową wersją bazy danych.
Wszystkie uaktualnienia bazy danych są wykonywane przy użyciu wzorca migracji. Zestaw kodu i skryptów sprawdza wersję bazy danych, a następnie wprowadza zmiany przyrostowe w celu zmigrowania schematu ze starej do nowej wersji. Wszystkie migracje są zautomatyzowane i wdrażane za pośrednictwem usługi zarządzania wydaniami.
Interfejs użytkownika sieci Web musi być również aktualizowany bez zakłócania działania użytkowników. Podczas uaktualniania plików JavaScript, arkuszy stylów lub obrazów należy unikać mieszania starych i nowych wersji ładowanych przez klienta. Może to prowadzić do błędów, które mogą utracić pracę w toku, takie jak pole edytowane przez użytkownika. W związku z tym należy wersję wszystkich plików JavaScript, CSS i image, umieszczając wszystkie pliki skojarzone z wdrożeniem w oddzielnym folderze z wersją. Gdy internetowy interfejs użytkownika wykonuje wywołania z powrotem do warstwy aplikacji, zasoby z określoną wersją są ładowane. Tylko wtedy, gdy akcja użytkownika powoduje odświeżenie pełnej strony, nowy internetowy interfejs użytkownika zostanie załadowany do przeglądarki. Środowisko użytkownika nie jest zakłócane przez uaktualnienie.
Następne kroki
Firma Microsoft od dziesięcioleci jest jedną z największych firm programistycznych na świecie. Dowiedz się, jak firma Microsoft obsługuje niezawodne systemy za pomocą metodyki DevOps.