Jakie wzorce projektowe są najbardziej wykorzystywane w tworzeniu aplikacji o wysokiej dostępności? [zamknięte]

Jednym z podejść do tworzenia niezawodnego oprogramowania jest crash-only software :

Crash-only software to oprogramowanie, które zawiesza się bezpiecznie i szybko odzyskuje. Jedynym sposobem, aby go zatrzymać, jest rozbicie go, a jedynym sposobem, aby go uruchomić, jest odzyskanie. System tylko w przypadku awarii składa się z komponentów tylko w przypadku awarii, które komunikują się z powtarzalnymi żądaniami; usterki są obsługiwane przez awarię i ponowne uruchomienie wadliwego komponentu oraz ponowną próbę wszelkich żądań, które przekroczyły czas. Powstały system jest często bardziej niezawodny i niezawodny, ponieważ odzyskiwanie po awarii jest pierwszorzędnym obywatelem w procesie rozwoju, a nie po myśli i nie potrzebujesz już dodatkowego kodu (i powiązanych interfejsów i błędów) do jawnego zamykania. Całe oprogramowanie powinno być w stanie bezpiecznie się zawiesić i szybko odzyskać, ale oprogramowanie tylko w przypadku awarii musi mieć te cechy, lub ich brak staje się szybko widoczny.

Polecam przeczytać wypuścić go!Michael Nygard. Przedstawia on szereg anty-wzorców, które wpływają na systemy produkcyjne, oraz wzorców, które pomagają zapobiec jednemu błędnemu komponentowi z usunięciem całego systemu. Książka obejmuje trzy główne obszary: stabilność, pojemność i ogólny projekt (obejmujący sieci, bezpieczeństwo, dostępność i administrację).

Moje poprzednie miejsce pracy zostało ugryzione (w takim czy innym czasie) przez prawie każdy scenariusz awarii Nygard kontury (z utratą przychodów za każdą powstałą awarię). Implementacja niektórych technik i wzorców, które sugeruje, zaowocowała znacznie bardziej stabilnymi i przewidywalnymi systemami (i tak, książka jest trochę Java centric, ale zasady mają zastosowanie w wielu kontekstach).

Źle:

...i będzie serwer pamięci

Dobre:

...i będzie gospodarstwo (wielokrotnego) przechowywania serwery z (wieloma) równoważnikami obciążenia z przodu of them

• Umieść balansery obciążenia przed wszystkim. Na razie możesz mieć 4 backendy, ale w przyszłości możesz mieć ich 400, więc mądrze jest zarządzać nim tylko na LB, a nie wszystkie aplikacje, które używają backendu.

• Użyj wielu poziomów cache.

• Poszukaj popularnych rozwiązań na temat przyspieszania thigów (na przykład memcached).

• Jeśli zamierzasz odnowić system, zrób to część po części, w wielu małych krokach. Jeśli zrobisz to jednym dużym krokiem (wyłącz Stary, włącz nowy i módl się, że zadziała) najprawdopodobniej się nie powiedzie.

• Użyj nazw DNS dla rzeczy, np. storage-lb.servicename rozwiązuje adresy wszystkich nośników pamięci. Jeśli chcesz go dodać, po prostu zmodyfikuj dns, wszystkie usługi zaczną z niego korzystać automatycznie.

• To Proste. Im więcej systemów zależy od Ciebie, tym bardziej ucierpi na tym Twoja usługa.

Projektowanie systemów wysokiej dostępności (HA) jest aktywnym obszarem badań i rozwoju. Jeśli spojrzeć na ACM lub IEEE, istnieje mnóstwo prac badawczych na temat jakości usług (dostępność, niezawodność, skalowalność itp.) i jak je osiągnąć (luźne sprzężenie, adaptacja itp.). Jeśli szukasz bardziej praktycznych zastosowań, spójrz na systemy odporne na błędy i oprogramowanie pośrednie, które jest zbudowane tak, aby umożliwić tworzenie klastrów, siatkę lub działanie w chmurze.

Replikacja i obciążenie równoważenie (inaczej reverse proxy) są jednymi z najczęstszych wzorców osiągania systemów HA i często można to zrobić bez wprowadzania zmian w kodzie bazowego oprogramowania, zakładając, że nie jest zbyt ściśle powiązane. Nawet wiele z najnowszych rozwiązań chmurowych uzyskuje się głównie dzięki replikacji i równoważeniu obciążenia, chociaż mają one tendencję do elastyczności, aby sprostać szerokim zakresom zapotrzebowania na system.

Uczynienie komponentów oprogramowania bezpaństwowym zmniejsza ciężar replikacji, ponieważ stan sam nie musi być replikowany wraz z komponentami oprogramowania. Bezpaństwowość jest jednym z głównych powodów, dla których http skaluje się tak dobrze, ale często wymaga od aplikacji dodawania własnego stanu (np. sesji), który następnie musi być replikowany.

Dlatego łatwiej jest uczynić luźno sprzężone systemy wysoce dostępnymi niż systemy ściśle sprzężone. Ponieważ niezawodność komponentów systemu determinuje ogólną niezawodność systemu, elementy, które są niewiarygodne, mogą wymagać być zastąpione (awarie sprzętu, błędy oprogramowania, itp). Umożliwienie dynamicznej adaptacji w czasie wykonywania pozwala na wymianę tych uszkodzonych komponentów bez wpływu na dostępność całego systemu. Luźne sprzężenie jest kolejnym powodem stosowania niezawodnych systemów przesyłania wiadomości, w których nadawca i odbiorca nie muszą być dostępne w tym samym czasie, ale sam system jest nadal dostępny.

Z tego co rozumiem, szukasz konkretnych wzorców do wykorzystania w aplikacjach java będących częścią architektury HA. Oczywiście istnieje wiele wzorców i najlepszych praktyk, które można wykorzystać, ale nie są to tak naprawdę wzorce HA. Są to raczej dobre pomysły, które można wykorzystać w wielu kontekstach.

Myślę, że próbuję powiedzieć, że architektura wysokiej dostępności składa się z wielu małych części. Jeśli wybierzemy jedną z tych małych części i zbadamy je, prawdopodobnie okazało się, że nie ma magicznych atrybutów HA dla tego małego komponentu. Jeśli zbadamy wszystkie pozostałe komponenty, znajdziemy to samo. To kiedy są one połączone w inteligentny sposób thay stają się HA aplikacji.

Aplikacja HA to aplikacja, w której od początku planujesz najgorsze. Jeśli kiedykolwiek myślisz w kategoriach "ten komponent jest tak stabilny, że nie potrzebujemy do niego dodatkowej redundancji", prawdopodobnie nie jest to architektura HA. W końcu łatwo jest poradź sobie ze scenariuszami problemów, które przewidujesz. To ten, który cię zaskakuje, obniża system.

Mimo wszystko istnieją wzorce, które są szczególnie przydatne w kontekstach HA. Wiele z nich zostało udokumentowanych w klasycznej książce "Patterns of Enterprise Application Architecture" autorstwa Martina Fowlera.

Tłumaczę "Wysoka dostępność" jako "Zero przestojów"`, które można zaimplementować zgodnie z innym pytaniem SE:

Zero przestojów dla aplikacji Java

1. przełącznik A/B: (Rolling upgrade + Fallback mechanism)
2. równoległe wdrażanie - Apache Tomcat: (tylko dla aplikacji internetowych)
3. opóźnione Wiązanie portów
4. zaawansowane Wiązanie portów

Użyję niektórych z tych pojęć, aby przyjść up z wzorców projektowych dla systemu wysokiej dostępności z punktu widzenia oprogramowania, który uzupełnia powyższe podejścia.

wzory do użycia:

Proxy/Fabryka :

Mieć obiekt proxy, a proxy zdecyduje, gdzie przekierować żądania. Załóżmy, że masz wersję 1 i wersję 2 oprogramowania. Jeśli klienci łączą się ze starym protokołem, przekieruj ich do wersji 1 oprogramowania. Nowi klienci mogą łączyć się bezpośrednio z wersją 2. Proxy może mieć metodę fabryczną lub AbstractFactory do renderowania nowej wersji oprogramowania.

Strategia

Możesz zmienić algorytm w czasie wykonywania, wybierając jeden algorytm z rodziny algorytmów. Jeśli weźmiesz przykład z linii lotniczych, możesz przełączać się między algorytmami DiscountFare i NormalFare w miesiącach innych niż szczytowe i szczytowe natężenie ruchu.

Dekorator :

Można zmienić zachowanie obiektu w czasie wykonywania. Dodaj nową klasę i udekoruj dodatkowe odpowiedzialność.

Adapter :

Przydatne przy zmianie interfejsu lub umowy pomiędzy wersją 1 A wersją 2. Adapter odpowiednio zareaguje na Stare i nowe żądania klientów.

Ogólne wytyczne:

1. luźne sprzężenie między obiektami
2. przestrzegaj zasad S. O. L. I. D w aplikacji

Zobacz sourcemaking artykuły na stronie dla powyższych szablonów dla lepszego zrozumienie.

czego nie używać:

Oprócz wzorców projektowych, trzeba podjąć pewne środki ostrożności, aby osiągnąć zero przestojów dla aplikacji.

1. nie wprowadzaj pojedynczego punktu awarii w swoim systemie.
2. używaj rozproszonych pamięci podręcznych(np. Terakota) /zamków oszczędnie.
3. Usuń twarde sprzężenie między usługami. Usuń ciasne sprzężenie między usługami za pomocą magistrali komunikacyjnej/ frameworków (JMS, ActiveMQ itp.)

Wysoka dostępność to bardziej dostępność sprzętu i nadmiarowość niż konwencje kodowania. Jest kilka wzorców, których użyłbym w prawie każdym przypadku HA: wybrałbym singleton patterndla mojego obiektu bazy danych i użył factory pattern do utworzenia Singletona. Fabryka może wtedy mieć logikę obsługi problemów z dostępnością w bazie danych (gdzie występuje większość problemów z dostępnością). Na przykład, jeśli Master jest wyłączony, to podłącz do drugi Mistrz zarówno czyta, jak i pisze, dopóki mistrz nie wróci. Nie wiem, czy są to najbardziej lewarowane wzorce, ale są najbardziej lewarowane w moim kodzie.

Oczywiście ta logika może być obsługiwana w metodzie _ _ construct, ale wzorzec fabryczny pozwoli Ci lepiej kontrolować kod i logikę decyzyjną, jak radzić sobie z problemami z łącznością bazy danych. Fabryka pozwoli również lepiej obsługiwać wzór Singletona.

Absolutnie uniknąłbym wzór dekoratora, oraz wzór obserwatora. Oba tworzą złożoność kodu, która utrudnia jego utrzymanie. Są to przypadki, w których są to najlepszy wybór dla Twoich potrzeb, ale w większości przypadków nie są.