Witajcie, koledzy.
Dziś przedkładamy tłumaczenie artykułu Tugberka Ugurlu, który postanowił w stosunkowo niewielkiej objętości przedstawić zasady projektowania nowoczesnych systemów programowych. Oto, co autor mówi o sobie w zwięzłej formie:
Ponieważ stwierdzenie, że nie jest możliwe uchwycenie w pojedynczym artykule tak ogromnego tematu, jak wzorce architektoniczne i projektowe na rok 2019, zdecydowanie prawdziwe, zalecamy nie tylko sam tekst pana Ugurlu, ale również liczne linki, które on w nim uprzejmie zamieścił. Jeśli się spodoba, opublikujemy również bardziej specjalistyczny tekst dotyczący projektowania systemów rozproszonych.
Zdjęcie ze strony Unsplash
Jeśli nigdy nie miałeś do czynienia z takimi wyzwaniami, jak projektowanie systemu oprogramowania od podstaw, to przystępując do takiej pracy, czasami trudno jest nawet określić, od czego zacząć. Uważam, że najpierw należy wyznaczyć granice, aby w miarę pewnie wiedzieć, co dokładnie zamierzasz zaprojektować, a następnie zabrać się do pracy, nie wychodząc poza te granice. Jako punkt wyjścia możesz wziąć jakiś produkt lub usługę (najlepiej taką, którą bardzo lubisz) i przyjrzeć się jej realizacji. Możesz się zdziwić, jak prosty wydaje się dany produkt, a jak ogromna złożoność się za nim kryje. Nie zapominaj: , i to jest w porządku.
Myślę, że najlepsza rada, jaką mogę dać tym, którzy przystępują do projektowania systemu, brzmi: nie rób żadnych założeń! Od samego początku należy konkretyzować znane fakty dotyczące tego systemu oraz związane z nim oczekiwania. Oto kilka dobrych pytań, na które odpowiedzi pomogą Ci rozpocząć projektowanie:
- Jakie jest zagadnienie, które próbujemy rozwiązać?
- Jakie jest szczytowe obciążenie użytkowników, którzy będą korzystać z naszego systemu?
- Jakie wzorce zapisu i odczytu danych będą u nas stosowane?
- Jakie są przewidywane przypadki awarii i jak zamierzamy sobie z nimi radzić?
- Jakie są oczekiwania dotyczące spójności i dostępności systemu?
- Czy musimy w pracy uwzględniać jakieś wymagania związane z zewnętrzną kontrolą i regulacjami?
- Jakie rodzaje poufnych danych zamierzamy przechowywać?
To tylko kilka pytań, które były przydatne zarówno dla mnie, jak i dla zespołów, w których miałem okazję uczestniczyć przez lata mojej kariery zawodowej. Jeśli znasz odpowiedzi na te pytania (i na wszelkie inne, istotne w kontekście, w którym pracujesz), to można stopniowo zagłębiać się w techniczne szczegóły zadania.
Ustalamy poziom bazowy
Co rozumiem tutaj przez „poziom bazowy” (baseline)? W dzisiejszych czasach większość problemów w branży oprogramowania można rozwiązać przy użyciu istniejących metod i technologii. Odpowiednio, orientując się w tym krajobrazie, otrzymujesz pewną przewagę, stając w obliczu zadań, które ktoś już przed tobą musiał rozwiązać. Nie zapominajmy, że programy są pisane w celu rozwiązywania problemów firm i użytkowników, dlatego staramy się rozwiązać problem w jak najprostszy sposób (z perspektywy użytkownika). Dlaczego to ważne? Być może w swoim systemie koordynatów lubisz znajdować unikalne rozwiązania dla wszystkich zadań, ponieważ uważasz, że „jakim jestem programistą, jeśli wszędzie stosuję wzorce”? Tak naprawdę sztuka polega tutaj na podejmowaniu decyzji, gdzie i co robić. Oczywiście każdy z nas czasami musi stawić czoła unikalnym problemom, z których każdy jest prawdziwym wyzwaniem. Jeśli jednak nasz poziom bazowy jest jasno określony, wiemy, na co poświęcać siły: na poszukiwanie gotowych rozwiązań dla zadania, które przed nami stoi, lub na dalsze jego badanie i głębsze zrozumienie.
Myślę, że udało mi się przekonać cię, że jeśli specjalista pewnie rozumie, jaka jest architektoniczna struktura niektórych niezwykłych systemów oprogramowania, to ta wiedza będzie nieoceniona w opanowaniu sztuki architekta oraz wypracowaniu solidnego fundamentu w tej dziedzinie.
Dobrze, od czego więc zacząć? U jest repozytorium na GitHubie o nazwie , z materiałami, dzięki którym możesz nauczyć się projektowania rozbudowanych systemów, a także przygotować się do rozmów rekrutacyjnych na ten temat. Repozytorium zawiera sekcję z przykładami , gdzie dokładnie omówiono, jak podchodzą do projektowania swoich systemów , na przykład Twitter, Uber itd.
Jednak zanim przejdziemy do tego materiału, przyjrzyjmy się dokładniej najważniejszym wyzwaniom architektonicznym, z którymi spotykają się w praktyce. Ma to znaczenie, ponieważ konieczne jest precyzowanie WIELU aspektów trudnego i wieloaspektowego problemu, a następnie jego rozwiązywanie w ramach regulacji obowiązującej w danym systemie. , były pracownik Facebooka, nagrał , gdzie podzielił się własnym doświadczeniem z analizowania setek kandydatów. Mimo że wideo wyraźnie dotyczy projektowania dużych systemów i kryteriów sukcesu, które są ważne przy wyborze kandydata na takie stanowisko, mimo to, będzie to nieocenione źródło informacji na temat tego, co jest najważniejsze przy projektowaniu systemów. Proszę również o tego wideo.
Zdobądź wiedzę na temat przechowywania i wydobywania danych
Zazwyczaj twoje decyzje dotyczące długoterminowego przechowywania i wydawania danych mają kluczowy wpływ na wydajność systemu. Dlatego musisz przede wszystkim rozumieć oczekiwane charakterystyki zapisu i odczytu danych w swoim systemie. Następnie musisz być w stanie ocenić te wskaźniki i podejmować decyzje na ich podstawie. Jednak efektywnie zajmiesz się tym tylko wtedy, gdy rozumiesz istniejące wzorce przechowywania danych. W zasadzie oznacza to pewną wiedzę dotyczącą .
Bazy danych można uznać za struktury danych, które charakteryzują się wyjątkową skalowalnością i trwałością. Dlatego znajomość struktur danych będzie bardzo przydatna również przy wyborze konkretnej bazy danych. Na przykład, – to serwer struktur danych, który obsługuje różne typy wartości. Umożliwia pracę z takimi strukturami danych jak listy i zbiory, odczytywanie danych za pomocą znanych algorytmów, takich jak , organizując tę pracę w stylu trwałym i wysoko dostępnym.
Zdjęcie ze strony Unsplash
Kiedy opanujesz różne wzorce przechowywania danych, przejdź do nauki o spójności i dostępności danych. Najpierw musisz przyswoić przynajmniej w ogólnych zarysach, a następnie doskonalić tę wiedzę, dokładniej badając ustalone wzorce i . Dzięki temu poszerzysz swoje horyzonty w tej dziedzinie i zrozumiesz, że odczyt i zapis danych to w rzeczywistości dwa bardzo różne problemy, z którymi wiążą się własne specyficzne wyzwania. Dysponując kilkoma wzorcami zapewniającymi spójność i dostępność, możesz znacznie zwiększyć wydajność systemu, jednocześnie gwarantując nieprzerwaną dostawę danych do swoich aplikacji.
Na koniec, kończąc rozmowę o kwestiach przechowywania danych, warto wspomnieć również o cachowaniu. Czy powinno być realizowane jednocześnie na kliencie i na serwerze? Jakie dane będą przechowywane w twoim cache? I dlaczego? Jak zorganizujesz invalidację cache? Czy będzie ona realizowana regularnie, co pewien czas? Jeśli tak, to jak często? Tematy te polecam zacząć od wyżej wspomnianego podręcznika projektowania systemów.
Wzorce komunikacyjne
Systemy składają się z różnych komponentów; mogą to być zarówno różne procesy działające w ramach jednego fizycznego węzła, jak i różne maszyny działające w różnych częściach twojej sieci. Niektóre z tych zasobów w twojej sieci mogą być prywatne, ale inne muszą być publiczne i otwarte dla konsumentów, którzy się do nich odwołują z zewnątrz.
Należy zapewnić komunikację tych zasobów między sobą, a także wymianę informacji między całym systemem a światem zewnętrznym. W kontekście projektowania systemów stajemy w obliczu nowego zestawu unikalnych wyzwań. Zastanówmy się, w jaki sposób , oraz jakie są dostępne różnorodne wzorce komunikacji.
Zdjęcie ze strony Unsplash
, do której również należy podchodzić z pełną powagą i aktywnie się nią zajmować. Rozdzielanie połączeń
Rozdzielanie połączeń
Nie jestem pewien, czy wydzielenie tego tematu do osobnej sekcji będzie dla wszystkich uzasadnione. Niemniej jednak, szczegółowo przedstawię tutaj tę koncepcję, uważając, że materiał tej sekcji najlepiej opisuje termin „rozdział połączeń” (connection distribution).
Systemy są budowane poprzez prawidłowe łączenie wielu komponentów, a ich komunikacja ze sobą często jest organizowana na bazie ustalonych protokołów, na przykład TCP i UDP. Jednakże te protokoły często bywają niewystarczające dla zaspokojenia wszystkich potrzeb nowoczesnych systemów, które często działają pod dużym obciążeniem, a także silnie zależą od potrzeb użytkowników. Często konieczne jest poszukiwanie sposobów na rozdzielanie połączeń, aby poradzić sobie z takimi dużymi obciążeniami w systemie.
Na podstawie takiego rozdzielenia leży dobrze znany (DNS). Taki system umożliwia przekształcenie nazwy domeny, na przykład, algorytmu ważącego podejście (weighted round robin) oraz metod opartych na opóźnieniach, które pomagają rozdzielać obciążenie.
jest zasadniczo kluczowy i prawie każdy większy system w Internecie, z którym mamy dzisiaj do czynienia, znajduje się za jednym lub wieloma balansującymi obciążenie. Balansujące obciążenie pomagają rozdzielać żądania klientów między wiele dostępnych instancji. Balansujące obciążenie mogą być zarówno sprzętowe, jak i programowe, jednak w praktyce częściej spotyka się te programowe, na przykład z i . konceptualnie również są bardzo podobne do balansujących obciążenie, chociaż pomiędzy nimi a tymi drugimi istnieje szereg . Różnice te należy koniecznie uwzględnić przy projektowaniu systemu z uwzględnieniem Twoich potrzeb.
Należy też pamiętać o (CDN). CDN to globalna sieć rozproszonych serwerów proxy, dostarczających informacje z węzłów, które są geograficznie bliżej konkretnego użytkownika. Sieci CDN są preferowane, jeśli pracujesz z plikami statycznymi, napisanymi w JavaScript, CSS i HTML. Ponadto obecnie popularne są takie usługi chmurowe, w ramach których udostępniane są menedżery ruchu, na przykład, , zapewniające globalne rozprzestrzenienie i obniżone opóźnienia podczas pracy z dynamiczną treścią. Jednak takie usługi są zazwyczaj przydatne w sytuacjach, gdy trzeba pracować z usługami sieciowymi bez przechowywania stanu.
Porozmawiajmy o logice biznesowej. Strukturyzowanie logiki biznesowej, przepływów zadań i komponentów
Zatem udało nam się omówić różne aspekty infrastrukturalne systemu. Prawdopodobnie użytkownik nawet nie myśli o wszystkich tych elementach twojego systemu i, szczerze mówiąc, zupełnie nie martwi się tym. Użytkownika interesuje, jak wygląda interakcja z twoim systemem, co można osiągnąć, działając w ten sposób, a także jak system wykonuje polecenia użytkownika, co i jak robi z danymi użytkownika.
Jak wynika z tytułu tego artykułu, zamierzałem omówić w nim architekturę oprogramowania i projektowanie systemów. Odpowiednio, nie planowałem poruszać wzorców projektowania oprogramowania, które opisują, jak tworzone są komponenty programowe. Jednak im więcej o tym myślę, tym bardziej wydaje mi się, że granica między wzorcami projektowania oprogramowania a wzorcami architektonicznymi jest bardzo rozmyta, a te dwa pojęcia są ze sobą ściśle powiązane. Weźmy na przykład (event sourcing). Jeśli przyjmiesz ten wzorzec architektoniczny - wpłynie on praktycznie na wszystkie aspekty twojego systemu: długoterminowe przechowywanie danych, poziom spójności przyjęty w twoim systemie, kontury komponentów w nim itp. Dlatego postanowiłem wspomnieć o kilku wzorcach architektonicznych bezpośrednio związanych z logiką biznesową. Nawet jeśli w tym artykule muszę ograniczyć się do prostego wykazu, zachęcam cię do zapoznania się z nim i przemyślenia idei związanych z tymi wzorcami. Oto, proszę:
- Koncepcje , w szczególności, ,
Podejścia kooperacyjne
Wysoce nieprawdopodobne jest, że będziesz na projekcie osobą, która odpowiada za cały proces projektowania systemu. Wręcz przeciwnie, najprawdopodobniej będziesz musiał współpracować z kolegami, którzy pracują zarówno w ramach twojego zadania, jak i poza nim. W takim przypadku może być konieczne wspólne ocenianie wybranych rozwiązań technologicznych, wydobywanie potrzeb biznesowych i zrozumienie, jak najlepiej rozdzielać zadania.
Zdjęcie ze strony Unsplash
W pierwszej kolejności należy wypracować dokładne i powszechnie uznawane zrozumienie celu biznesowego, który próbujesz osiągnąć, oraz z jakimi zmiennymi elementami będziesz musiał się zmierzyć. Techniki modelowania grupowego, szczególnie (event storming) mogą znacznie przyspieszyć ten proces i zwiększyć twoje szanse na sukces. Możesz się tym zająć przed lub po nakreśleniu , a następnie pogłębiać ten temat w miarę dojrzewania produktu. W oparciu o poziom zgody, który zostanie tutaj osiągnięty, możesz także sformułować dla ograniczonego kontekstu, w którym pracujesz. Kiedy będziesz musiał mówić o architekturze swojego systemu, przyda ci się , zaproponowany przez , szczególnie gdy trzeba będzie zrozumieć, jak głęboko trzeba wdrożyć szczegóły problemu, wizualizując rzeczy, które chcesz przekazać.
Prawdopodobnie w tej dziedzinie znajdzie się inna dojrzała technologia, równie użyteczna jak projektowanie oparte na domenie. Niemniej jednak, wracamy do zrozumienia obszaru tematycznego, więc wiedza i doświadczenie w zakresie będą dla ciebie przydatne.
Źródło: habr.com
