Cześć koledzy.
Dziś oddajemy do Państwa rozważenia tłumaczenie artykułu Tugberka Ugurlu, który podjął się przedstawienia w stosunkowo niewielkim tomie zasad projektowania nowoczesnych systemów oprogramowania. Oto, co autor w skrócie mówi o sobie:
Ponieważ absolutnie nie da się omówić w habro tak kolosalnego tematu jak wzorce architektoniczne + wzorce projektowe od 2019 roku, polecamy nie tylko sam tekst pana Uruglu, ale także liczne linki, które życzliwie w nim umieścił. Jeśli Ci się spodoba, opublikujemy bardziej specjalistyczny tekst na temat projektowania systemów rozproszonych.
Zdjęcie z Unsplasha
Jeśli nigdy nie musiałeś mierzyć się z takimi wyzwaniami, jak projektowanie systemu oprogramowania od podstaw, to rozpoczynając taką pracę, czasami nie jest nawet jasne, od czego zacząć. Wierzę, że najpierw trzeba wyznaczyć granice, żeby mieć mniej więcej pewność, co dokładnie będziesz projektować, a potem zakasać rękawy i pracować w ramach tych granic. Na początek możesz wybrać produkt lub usługę (najlepiej taki, który naprawdę Ci się podoba) i dowiedzieć się, jak go wdrożyć. Możesz być zaskoczony, jak prosto wygląda ten produkt i ile w rzeczywistości zawiera złożoności. Nie zapomnij: i to jest w porządku.
Myślę, że najlepszą radą, jaką mogę dać każdemu, kto zaczyna projektować system, jest następująca: nie rób żadnych założeń! Już na samym początku należy określić znane fakty na temat tego systemu i oczekiwania z nim związane. Oto kilka dobrych pytań, które warto zadać, aby pomóc Ci rozpocząć pracę nad projektem:
- Jaki jest problem, który próbujemy rozwiązać?
- Jaka jest maksymalna liczba użytkowników, którzy będą wchodzić w interakcję z naszym systemem?
- Jakie wzorce zapisywania i odczytywania danych będziemy stosować?
- Jakie są oczekiwane przypadki awarii i jak sobie z nimi poradzimy?
- Jakie są oczekiwania dotyczące spójności i dostępności systemu?
- Czy podczas pracy trzeba uwzględnić jakieś wymagania związane z zewnętrzną weryfikacją i regulacją?
- Jakie rodzaje wrażliwych danych będziemy przechowywać?
To tylko kilka pytań, które przez lata działalności zawodowej przydały się zarówno mnie, jak i zespołom, w których uczestniczyłem. Jeśli znasz odpowiedzi na te pytania (i wszelkie inne, które są istotne w kontekście, w którym musisz pracować), możesz stopniowo zagłębiać się w techniczne szczegóły problemu.
Ustaw poziom początkowy
Co mam tutaj na myśli mówiąc „punkt bazowy”? Właściwie w naszych czasach większość problemów w branży oprogramowania „można” rozwiązać przy użyciu istniejących metod i technologii. W związku z tym poruszając się po tym krajobrazie, zyskujesz przewagę w obliczu problemów, które ktoś inny musiał rozwiązać przed tobą. Nie zapominaj, że programy są pisane po to, aby rozwiązywać problemy biznesowe i użytkowników, dlatego staramy się rozwiązać problem w jak najprostszy (z punktu widzenia użytkownika) sposób. Dlaczego warto o tym pamiętać? Może w swoim układzie współrzędnych lubisz szukać unikalnych rozwiązań wszystkich problemów, bo myślisz: „co ze mnie za programista, skoro wszędzie podążam za schematami”? W rzeczywistości, sztuka polega na podejmowaniu decyzji o tym, gdzie i co robić. Oczywiście każdy z nas od czasu do czasu musi mierzyć się z wyjątkowymi problemami, z których każdy jest prawdziwym wyzwaniem. Jeśli jednak nasz poziom początkowy jest jasno określony, to wiemy, na co przeznaczyć naszą energię: na poszukiwanie gotowych opcji rozwiązania postawionego przed nami problemu, czy też dalsze jego studiowanie i głębsze zrozumienie.
Myślę, że udało mi się Cię przekonać, że jeśli specjalista z pewnością zrozumie, na czym polega element architektoniczny jakichś wspaniałych systemów oprogramowania, to wiedza ta będzie niezbędna do opanowania sztuki architekta i zbudowania solidnych podstaw w tej dziedzinie.
OK, więc od czego zacząć? U Na GitHubie istnieje repozytorium o nazwie , z którego można dowiedzieć się, jak projektować systemy wielkoskalowe, a także przygotować się do rozmów kwalifikacyjnych na ten temat. W repozytorium znajduje się sekcja z przykładami , gdzie w szczególności rozważa się, w jaki sposób podchodzą do projektowania swoich systemów np. Twitter, Uber itp.
Zanim jednak przejdziemy do tego materiału, przyjrzyjmy się bliżej najważniejszym wyzwaniom architektonicznym, przed którymi stoimy w praktyce. To o tyle ważne, że trzeba określić WIELE aspektów upartego i wieloaspektowego problemu, a następnie rozwiązać go w ramach obowiązujących w danym systemie przepisów. – napisał były pracownik Facebooka , gdzie podzielił się własnymi doświadczeniami z selekcji setek kandydatów. Chociaż film koncentruje się głównie na projektowaniu dużych systemów i kryteriach sukcesu, które są ważne przy poszukiwaniu kandydata na takie stanowisko, nadal będzie służyć jako kompleksowe źródło informacji na temat najważniejszych rzeczy przy projektowaniu systemów. Sugeruję również ten film.
Zbuduj wiedzę na temat przechowywania i odzyskiwania danych
Zazwyczaj decyzja dotycząca sposobu przechowywania i odzyskiwania danych w dłuższej perspektywie ma krytyczny wpływ na wydajność systemu. Dlatego należy najpierw poznać oczekiwaną charakterystykę zapisu i odczytu systemu. Następnie trzeba umieć ocenić te wskaźniki i dokonać wyborów w oparciu o dokonane oceny. Jednak skutecznie poradzisz sobie z tą pracą tylko wtedy, gdy zrozumiesz istniejące wzorce przechowywania danych. W zasadzie oznacza to solidną wiedzę związaną z .
Bazy danych można traktować jako struktury danych, które są niezwykle skalowalne i trwałe. Dlatego znajomość struktur danych powinna być dla Ciebie bardzo przydatna przy wyborze konkretnej bazy danych. Na przykład, to serwer struktury danych obsługujący różne typy wartości. Umożliwia pracę ze strukturami danych takimi jak listy i zbiory oraz odczytywanie danych przy użyciu dobrze znanych algorytmów, np. , organizując taką pracę w trwałym i łatwo dostępnym stylu.
Zdjęcie z Unsplasha
Po wystarczającym zrozumieniu różnych wzorców przechowywania danych przejdź do badania spójności i dostępności danych. Przede wszystkim musisz zrozumieć przynajmniej ogólnie, a następnie szlifować tę wiedzę, przyglądając się bliżej ustalonym wzorcom и . W ten sposób rozwiniesz wiedzę na ten temat i zrozumiesz, że odczytywanie i zapisywanie danych to w rzeczywistości dwa bardzo różne problemy, z których każdy ma swoje własne, unikalne wyzwania. Dysponując kilkoma wzorcami spójności i dostępności, możesz znacznie zwiększyć wydajność systemu, zapewniając jednocześnie płynny przepływ danych do aplikacji.
Na koniec, kończąc rozmowę o kwestiach przechowywania danych, warto wspomnieć także o buforowaniu. Czy powinien działać jednocześnie na kliencie i serwerze? Jakie dane będą znajdować się w Twojej pamięci podręcznej? I dlaczego? Jak zorganizować unieważnienie pamięci podręcznej? Czy będzie to wykonywane regularnie, w określonych odstępach czasu? Jeśli tak, jak często? Polecam zacząć studiować te tematy od wspomniany wcześniej elementarz projektowania systemu.
Wzorce komunikacji
Systemy składają się z różnych komponentów; mogą to być różne procesy działające w tym samym węźle fizycznym lub różne maszyny działające w różnych częściach sieci. Niektóre z tych zasobów w Twojej sieci mogą być prywatne, ale inne powinny być publiczne i otwarte dla konsumentów uzyskujących do nich dostęp z zewnątrz.
Konieczne jest zapewnienie komunikacji tych zasobów ze sobą, a także wymiany informacji pomiędzy całym systemem a światem zewnętrznym. W kontekście projektowania systemów i tutaj ponownie stajemy przed szeregiem nowych i unikalnych wyzwań. Zobaczmy, jak mogą się przydać , a co str.
Zdjęcie z Unsplasha
Organizowanie komunikacji ze światem zewnętrznym jest zawsze bardzo ważne , których zapewnienie również należy traktować poważnie i aktywnie realizować.
Dystrybucja połączeń
Nie jestem pewien, czy umieszczenie tego tematu w osobnym dziale będzie wydawało się każdemu uzasadnione. Niemniej jednak przedstawię tę koncepcję tutaj szczegółowo i uważam, że materiał w tej sekcji najtrafniej opisuje termin „dystrybucja połączeń”.
Systemy powstają poprzez odpowiednie połączenie wielu komponentów, a ich komunikacja między sobą często zorganizowana jest w oparciu o ustalone protokoły, np. TCP i UDP. Jednak te protokoły jako takie są często niewystarczające, aby zaspokoić wszystkie potrzeby nowoczesnych systemów, które często pracują pod dużym obciążeniem, a także są w dużym stopniu zależne od potrzeb użytkownika. Często konieczne jest znalezienie sposobów dystrybucji połączeń, aby sprostać tak dużym obciążeniom systemu.
Ta dystrybucja opiera się na dobrze znanych (DNS-y). Taki system umożliwia transformacje nazw domen, takie jak metody ważone okrężne i metody oparte na opóźnieniach, aby pomóc w rozłożeniu obciążenia.
ma fundamentalne znaczenie i praktycznie każdy duży system internetowy, z którym mamy obecnie do czynienia, znajduje się za jednym lub kilkoma modułami równoważenia obciążenia. Moduły równoważenia obciążenia pomagają dystrybuować żądania klientów pomiędzy wiele dostępnych instancji. Load Balancery występują zarówno w wersji sprzętowej, jak i programowej, jednak w praktyce częściej mamy do czynienia np. z programowymi и . koncepcyjnie również bardzo podobny do modułów równoważenia obciążenia, chociaż istnieje zakres między pierwszym a drugim . Różnice te należy wziąć pod uwagę przy projektowaniu systemu w oparciu o swoje potrzeby.
Powinieneś także wiedzieć o (CDN). CDN to globalna rozproszona sieć serwerów proxy, która dostarcza informacje z węzłów znajdujących się geograficznie bliżej określonego użytkownika. CDN są preferowane, jeśli pracujesz z plikami statycznymi zapisanymi w JavaScript, CSS i HTML. Ponadto usługi w chmurze zapewniające menedżerów ruchu są dziś powszechne, na przykład , zapewniając globalną dystrybucję i zmniejszone opóźnienia podczas pracy z zawartością dynamiczną. Jednak takie usługi są zwykle przydatne w przypadkach, gdy musisz pracować z bezstanowymi usługami internetowymi.
Porozmawiajmy o logice biznesowej. Strukturyzacja logiki biznesowej, przepływów zadań i komponentów
Udało nam się zatem omówić różne aspekty infrastrukturalne systemu. Najprawdopodobniej użytkownik nawet nie myśli o tych wszystkich elementach Twojego systemu i, szczerze mówiąc, w ogóle się nimi nie przejmuje. Użytkownik jest zainteresowany tym, jak wygląda interakcja z Twoim systemem, co można dzięki temu osiągnąć, a także w jaki sposób system wykonuje polecenia użytkownika, co i jak robi z danymi użytkownika.
Jak sugeruje tytuł tego artykułu, miałem zamiar mówić o architekturze oprogramowania i projektowaniu systemów. W związku z tym nie planowałem omawiać wzorców projektowania oprogramowania opisujących sposób tworzenia komponentów oprogramowania. Jednak im więcej o tym myślę, tym bardziej wydaje mi się, że granica pomiędzy wzorcami projektowania oprogramowania a wzorcami architektonicznymi jest bardzo niewyraźna, a oba pojęcia są ze sobą ściśle powiązane. Weźmy na przykład (źródło wydarzenia). Gdy przyjmiesz ten wzorzec architektoniczny, będzie on miał wpływ na prawie każdy aspekt twojego systemu: długoterminowe przechowywanie danych, poziom spójności przyjęty w twoim systemie, kształt jego komponentów itp., itp. Dlatego zdecydowałem się wspomnieć o kilku wzorcach architektonicznych, które bezpośrednio odnoszą się do logiki biznesowej. Choć ten artykuł będzie musiał ograniczyć się do prostej listy, zachęcam do zapoznania się z nim i przemyślenia idei związanych z tymi wzorcami. Tutaj jesteś:
- Koncepcji , w szczególności, ,
Podejścia oparte na współpracy
Jest bardzo mało prawdopodobne, że znajdziesz się w projekcie jako uczestnik, który ponosi wyłączną odpowiedzialność za proces projektowania systemu. Wręcz przeciwnie, najprawdopodobniej będziesz musiał kontaktować się z kolegami pracującymi zarówno w ramach Twojego zadania, jak i poza nim. W takim przypadku może zaistnieć potrzeba oceny wybranych rozwiązań technologicznych ze współpracownikami, zidentyfikowania potrzeb biznesowych i zrozumienia, w jaki sposób najlepiej zrównoleglić zadania.
Zdjęcie z Unsplasha
Pierwszym krokiem jest dokładne i wspólne zrozumienie celu biznesowego, który chcesz osiągnąć, oraz z jakimi ruchomymi częściami będziesz musiał się uporać. W szczególności techniki modelowania grupowego (eventstorming) pomogą znacznie przyspieszyć ten proces i zwiększyć Twoje szanse na sukces. Tę pracę można wykonać przed lub po zarysie , a następnie pogłębiać w miarę dojrzewania produktu. W zależności od poziomu spójności, który zostanie tutaj osiągnięty, możesz również formułować dla ograniczonego kontekstu, w którym pracujesz. Kiedy chcesz porozmawiać o architekturze swojego systemu, może się to okazać przydatne , zaproponował zwłaszcza gdy musisz zrozumieć, jak bardzo będziesz musiał zagłębić się w szczegóły problemu, wizualizując rzeczy, które chcesz przekazać.
Prawdopodobnie istnieje inna dojrzała technologia na ten temat, która jest nie mniej użyteczna niż Domain Driven Design. Jednak jakimś sposobem wracamy do zrozumienia tematyki, a więc wiedzy i doświadczenia w danej dziedzinie powinno Ci się przydać.
Źródło: www.habr.com