Są pewne problemy z cross postingiem z powodu dialektu przecen w oryginalnym poście. Szczególnie nie pokazano schematów, które istnieją w oryginalnym poście. Więc proszę sprawdzić oryginał, jeśli jesteś zainteresowany. Myślę, że oryginał jest bardziej zrozumiały

Aktualizacja HBase do architektury Event Sourcing i CQRS w 3 tygodnie

TL;DR

• Zastosowaliśmy niebiesko-zieloną strategię wdrażania aktualizacji wersji HBase jako uzupełnienie systemu architektury Event Sourcing i CQRS.
• Podejście do wdrożenia zadziałało całkiem dobrze i w sumie osiągnięcie celu projektu zajęło tylko 3 tygodnie. To doświadczenie było dla nas nowe i ekscytujące. Więc chcę się tym podzielić :)

Informacje o aktualizacji bazy danych

Aktualizacja bazy danych jest zawsze kłopotliwa i za każdym razem, gdy masz do czynienia z takimi okolicznościami w scenariuszach produkcyjnych, będziesz bardzo zdenerwowany (powiedziałbym, że 100 razy w porównaniu z innymi operacjami produkcyjnymi, z którymi masz do czynienia) .

To uczucie jest trudne do podzielenia się z osobami, które nie mają doświadczenia lub ekspozycji w obsłudze środowisk Bazy Danych. I myślę, że 99,9% ludzi zgodziłoby się, gdybyś miał doświadczenie i przeszedł przez trudne czasy w radzeniu sobie z operacjami związanymi z bazą danych. Jest to ryzykowne i dużo kosztuje, ale samo uaktualnienie nie oznacza, że ​​dodaje produktowi nową wartość i chociaż w wielu przypadkach nie jest traktowane priorytetowo, chyba że jest jakiś pilny powód.

Jednocześnie istnieje ogromne ukryte ryzyko, jeśli baza danych stanie się „nietykalna”, a sposób radzenia sobie z tym problemem jest tematem, wielu programistów i operatorów boryka się z takimi sytuacjami

Podejście do aktualizacji

Ogólnie masz dwie możliwości.

aktualizacja stopniowa

Jednym z nich jest aktualizacja krocząca. Aktualizacja wersji bazy danych jedna po drugiej w sposób sekwencyjny.
Znalazłem tutaj dobre wyjaśnienie. Przeczytaj to, jeśli nie znasz tego słowa.

Co oznacza stopniowe uaktualnianie w tworzeniu oprogramowania?

• Plusy

  • Dane znajdują się w jednym miejscu. Nie musisz więc myśleć o tym, jak zsynchronizować dane między różnymi klastrami i jak zagwarantować, że synchronizacja działa idealnie.

• Wady

  • Po zakończeniu aktualizacji nie ma łatwego sposobu na jej cofnięcie. Więc jeśli aktualizacja spowoduje jakoś problem z wydajnością, będziesz miał duże kłopoty.
  • Długo działająca baza danych ma nieoczekiwany stan, którego nie można odtworzyć w środowisku testowym. Czasami trzeba uporać się z problemem, jeśli chodzi o produkcję. A ta możliwość naprawdę cię denerwuje.

niebiesko-zielone wdrożenie

Drugi to niebiesko-zielone wdrożenie. W takim przypadku należy osobno udostępnić zaktualizowany klaster bazy danych i przełączyć aplikację tak, aby w pewnym momencie korzystała z nowej.
Sprawdź ten wpis na blogu, jeśli nie znasz słowa „niebiesko-zielone wdrożenie”.

Wdrożenie BlueGreen

Myślę, że to podejście jest szeroko rozpowszechnione we wdrażaniu aplikacji internetowych, ale jeśli zastąpisz słowo „router” na „aplikacja” i „serwer sieciowy” na „baza danych”, to samo podejście można zastosować do aktualizacji bazy danych.

• Plusy

  • Podczas aktualizacji nie dotykasz działającej produkcyjnej bazy danych. To sprawia, że ​​Twoje życie jest o wiele łatwiejsze w porównaniu z podejściem do ciągłego ulepszania.
  • Możesz łatwo powrócić do starego klastra, gdy wystąpi nieoczekiwany problem. Możesz także dystrybuować żądania stopniowo, aby zminimalizować zakres w przypadku problemów (Aby to zrobić, jak w „Wady”, musisz jednak zsynchronizować dane z nowego klastra do starego klastra)
  • Ze względu na powyższy czynnik możesz nieco skrócić testowanie obciążenia w środowisku testowym i szybko kontynuować projekt.

• Wady

  • Musisz upewnić się, że dane są synchronizowane między obydwoma klastrami baz danych. Nie tylko ze starego klastra do nowego klastra, ale także z nowego klastra do starego klastra, jeśli chcesz mieć łatwy sposób na przywrócenie po aktualizacji. Jednak w wielu przypadkach wzajemna replikacja danych jest dość trudna. Możliwe jest zapisywanie do dwóch klastrów w każdej operacji, ale należy się przygotować, gdy tylko jeden klaster nie działa, a operacja tylko w tym klastrze nie powiodła się. Taka obsługa byłaby naprawdę skomplikowana.
  • Do uruchomienia obu klastrów potrzebne są serwery o podwójnej wielkości. Będzie to kosztować trochę pieniędzy i może być trudne, jeśli Twój system nie jest w infrastrukturze chmury.

Nasze podejście

Zasadniczo nasze podejście to niebiesko-zielone wdrażanie. A ponieważ mamy Kafkę na czele jako magistralę pozyskiwania zdarzeń, znacznie łatwiej było poradzić sobie z problemem synchronizacji danych w „Wady” wymienionym powyżej.

Obecna architektura

Najpierw przedstawię podstawową architekturę. Btw, cały podsystem wiadomości czatu nazywamy „Falcon”. Dlatego na schemacie znajduje się ikona sokoła.

1. gdy użytkownik końcowy publikuje wiadomość na czacie, write-api umieszcza dane wiadomości w Kafce
2. read-model-updater (w skrócie "rmu") pobiera dane z Kafki, konwertuje je na model do odczytu i umieszcza w HBase
3. Gdy użytkownik końcowy czyta wiadomości na czacie, read-api pobiera dane wiadomości z HBase

W tym poście nie wyjaśniam, dlaczego wybieramy CQRS. Sprawdź więc poniższe slajdy, jeśli chcesz poznać szczegóły lub nie znasz pojęcia CQRS.
Kafka Summit SF 2017 — ogólnoświatowe skalowalne i elastyczne usługi przesyłania wiadomości dzięki strumieniom Kafka i Kafka
Skalowalne i elastyczne usługi przesyłania wiadomości na całym świecie dzięki CQRS i pozyskiwaniu zdarzeń za pomocą Akka, Kafka Streams i HBase

Przebieg aktualizacji bazy danych

Teraz wyjaśnię, w jaki sposób dokonaliśmy aktualizacji bazy danych na tej architekturze

Krok 1: Przygotuj nowe klastry i wykonaj początkowe przywracanie z kopii zapasowej.

Krok 2: Przygotuj innego konsumenta (rmu2 na tym diagramie) do synchronizacji danych z platformy Kafka do nowego klastra bazy danych. Odtworzysz stare wydarzenia Kafki, zaczynając przed początkowym przywracaniem. Upewnij się, że implementujesz idempotentność u swojego konsumenta. Chodzi mi o to, że system musi działać poprawnie, nawet jeśli to samo wydarzenie jest używane więcej niż raz.

Krok 3: Gdy nowy konsument(rmu2) otrzyma najnowsze komunikaty Kafki, przygotuj kolejne read-api, ściągające dane z nowego klastra bazy danych. I stopniowo wysyłaj żądania do nowego read-api.

Pojawiłaby się pewna różnica stanu między starym klastrem a nowym klastrem, nawet jeśli synchronizacja danych zakończy się w ciągu kilku milisekund. Z powodu tej różnicy wystąpił mały problem, więc musisz wcześniej potwierdzić i przeprowadzić kontrolę oceny, aby zobaczyć, jaki rodzaj problemu może zostać wywołany przez różnicę między klastrami a logiką aplikacji. Lub jeśli masz jakieś dobre warstwy przed read-api, aby rozdzielić żądanie zgodnie z atrybutem użytkownika lub czymś (np. Routing przez Nginx lub Envoy jak proxy), możesz po prostu ustawić tam odpowiednią regułę, a różnica może być skutecznie obsługiwana i nie będzie problemu.

W retrospekcji tego projektu zauważyliśmy, że jeśli możesz odzwierciedlić żądania z istniejącego interfejsu API do nowego, możesz przeprowadzić testowanie obciążenia przy użyciu ruchu produkcyjnego bez wpływu na użytkowników końcowych.

Krok 4: Przełącz się na nowe read-api w 100% i zamknij stare klastry i aplikacje, gdy masz pewność, że wszystko działa idealnie.

Dlaczego uważam, że to podejście jest lepsze

Pozwólcie, że wyjaśnię różnicę w normalnym niebiesko-zielonym podejściu. Jednym z problemów w normalnych niebiesko-zielonych jest to, że musisz upewnić się, że dane są synchronizowane w obu klastrach, najlepiej nie tylko przed aktualizacją, ale także po aktualizacji. W tym podejściu, zamiast korzystać z funkcji replikacji, którą zapewnia baza danych, aktualizacje bazy danych są wprowadzane osobno za pośrednictwem napisanej i przygotowanej przez nas aplikacji. Takie podejście ma wiele zalet.

Po pierwsze, ponieważ działają osobno, nie musisz się martwić, jak dane są synchronizowane w każdej fazie. W szczególności będziesz potrzebować dodatkowego (i dość trudnego w większości przypadków) wysiłku w synchronizowaniu danych z nowego klastra do starego klastra, jeśli chcesz mieć łatwy sposób na przywrócenie po aktualizacji. Ale w tym podejściu po prostu pracują niezależnie. Możesz więc po prostu wrócić do używania starych na wypadek, gdyby po aktualizacji pojawił się nieoczekiwany problem.

Po drugie, nie musisz przejmować się kompatybilnością wersji pomiędzy starymi i nowymi klastrami. Jeśli korzystasz z funkcji synchronizacji danych klastra, którą zapewnia baza danych, mogą wystąpić pewne ograniczenia wersji i problemy ze zgodnością, które mogą wystąpić w niektórych skrajnych przypadkach. Ale w tym podejściu wystarczy przygotować niezależną aplikację, która wstawi dane do każdej bazy danych. Myślę, że w większości przypadków jest to problem, który można rozwiązać znacznie łatwiej. I teoretycznie nie tylko aktualizując wersję bazy danych, ale także możesz przełączyć nowy klaster na zupełnie inny (np. DynamoDB) przy użyciu tego samego podejścia. W takim przypadku nie można użyć danych z kopii zapasowej do wstępnej konfiguracji i trzeba przygotować program do wstępnej migracji danych. Zajmie to trochę czasu, ale myślę, że to rozsądna rzecz do załatwienia.

Wniosek

Tematy CQRS i Event sourcing są często omawiane w architekturze oprogramowania. Z operacyjnego punktu widzenia posiadanie jeszcze jednej warstwy jako magistrali zdarzeń zwiększa złożoność infrastruktury i koszty operacyjne. Szczerze mówiąc, wcześniej nie podobało mi się to podejście z tego punktu widzenia. Zauważyliśmy jednak, że zmienia to również sposób obsługi infrastruktury i zapewnia spokój w działaniu bazy danych. I tak, teraz uwielbiam CQRS i event sourcing :)

Następne wyzwanie

Możesz się zastanawiać, co byśmy ulepszyli Kafkę (autobus zaopatrujący wydarzenia)? Tak, to będzie nasze kolejne wyzwanie. Mam nadzieję, że istnieje lepsze podejście niż normalna aktualizacja krocząca i wdrożenie niebiesko-zielone. Życie inżyniera trwa!