O co w tym wszystkim chodzi?  Każdego dnia, w każdej chwili naszej kariery inżynierskiej napotykamy wiele różnych problemów o różnym stopniu złożoności i sytuacji, w których musimy podjąć decyzję lub odłożyć ją z powodu braku danych. Za każdym razem, gdy budujemy nowe usługi, konstruujemy infrastrukturę, a nawet tworzymy procesy rozwojowe, dotykamy ogromnego świata różnych wyzwań.  Trudno, a może nawet niemożliwe jest wymienienie wszystkich problemów. Na niektóre z nich natkniesz się tylko wtedy, gdy pracujesz w określonej niszy. Z drugiej strony jest wiele, które wszyscy musimy zrozumieć, jak rozwiązać, ponieważ są kluczowe dla budowania systemów informatycznych. Z dużym prawdopodobieństwem natkniesz się na nie we wszystkich projektach.  W tym artykule podzielę się swoimi doświadczeniami dotyczącymi niektórych problemów, na jakie natknąłem się podczas tworzenia programów komputerowych.  Czym jest problem przekrojowy?  Jeśli zajrzymy do Wikipedii, znajdziemy następującą definicję  W zorientowanym aspektowo rozwoju oprogramowania, kwestie przekrojowe to aspekty programu, które wpływają na kilka modułów, bez możliwości ich uwzględnienia w żadnym z nich. Kwestie te często nie mogą być czysto rozłożone od reszty systemu zarówno w projekcie, jak i implementacji, i mogą skutkować rozproszeniem (duplikacją kodu), splątaniem (znacznymi zależnościami między systemami) lub jednym i drugim.  Opis ten doskonale opisuje istotę sprawy, ale chciałbym go nieco rozszerzyć i uprościć:    to koncepcja lub komponent systemu/organizacji, który wpływa na wiele innych części (lub „przecina się”). Zagadnienie przekrojowe  Najlepszymi przykładami takich obaw są architektura systemu, rejestrowanie, bezpieczeństwo, zarządzanie transakcjami, telemetria, projektowanie baz danych i wiele innych. Wiele z nich omówimy szczegółowo w dalszej części artykułu.  Na poziomie kodu, kwestie przekrojowe są często implementowane przy użyciu technik takich jak   , gdzie kwestie te są modularne do oddzielnych komponentów, które można stosować w całej aplikacji. Dzięki temu logika biznesowa pozostaje odizolowana od tych kwestii, co sprawia, że kod jest bardziej czytelny i łatwiejszy w utrzymaniu. Aspect-Oriented Programming (AOP)  Klasyfikacja aspektów  Istnieje wiele możliwych sposobów klasyfikowania aspektów poprzez segmentowanie ich według różnych właściwości, takich jak zakres, rozmiar, funkcjonalność, ważność, cel i inne, ale w tym artykule zamierzam użyć prostej klasyfikacji zakresu. Mam na myśli, gdzie skierowany jest ten konkretny aspekt, czy jest to cała organizacja, konkretny system, czy konkretny element tego systemu.  Zatem podzielę aspekty na   i   . makro mikro  Przez aspekt   rozumiem głównie względy, które bierzemy pod uwagę w odniesieniu do całego systemu, takie jak wybrana architektura systemu i jej projekt (monolityczna, mikrousługi, architektura zorientowana na usługi), stos technologiczny, struktura organizacyjna itd. Aspekty   odnoszą się głównie do decyzji strategicznych i decyzji podejmowanych na wysokim szczeblu. makro makro  Tymczasem aspekt   jest znacznie bliższy poziomowi kodu i rozwojowi. Na przykład, który framework jest używany do interakcji z bazą danych, struktura folderów i klas projektu, a nawet konkretne wzorce projektowania obiektów. Micro  Mimo że klasyfikacja ta nie jest idealna, pomaga ona zrozumieć potencjalne problemy oraz znaczenie i wpływ rozwiązań, które stosujemy w ich rozwiązywaniu.  W tym artykule skupię się przede wszystkim na aspektach makro.  Aspekty makro  Struktura organizacyjna  Kiedy dopiero zaczynałem uczyć się o architekturze oprogramowania, przeczytałem wiele interesujących artykułów o prawie Conwaya i jego wpływie na strukturę organizacyjną. Zwłaszcza   . Tak więc to prawo stwierdza, że ten  Każda organizacja projektująca system (rozumiany szeroko) stworzy projekt, którego struktura będzie kopią struktury komunikacyjnej danej organizacji.  Zawsze wierzyłem, że ta koncepcja jest rzeczywiście bardzo uniwersalna i odzwierciedla Złotą Zasadę.  Następnie zacząłem uczyć się podejścia Erica Evansa do projektowania zorientowanego na domenę (DDD) w zakresie modelowania systemów. Eric Evans podkreśla znaczenie identyfikacji ograniczonego kontekstu. Koncepcja ta polega na podzieleniu złożonego modelu domeny na mniejsze, bardziej zarządzalne sekcje, z których każda ma swój własny, ograniczony zestaw wiedzy. Podejście to wspomaga skuteczną komunikację w zespole, ponieważ zmniejsza potrzebę rozległej wiedzy na temat całej domeny i minimalizuje przełączanie kontekstu, dzięki czemu rozmowy stają się bardziej wydajne. Przełączanie kontekstu jest najgorszą i najbardziej zasobożerną rzeczą na świecie. Nawet komputery mają z tym problem. Chociaż mało prawdopodobne jest osiągnięcie całkowitego braku przełączania kontekstu, uważam, że właśnie do tego powinniśmy dążyć.   Wracając do prawa Conwaya, znalazłem w nim kilka problemów.    na jaki natrafiłem w przypadku prawa Conwaya, które sugeruje, że projekt systemu odzwierciedla strukturę organizacyjną, to potencjał tworzenia złożonych i kompleksowych kontekstów ograniczonych. Ta złożoność pojawia się, gdy struktura organizacyjna nie jest zgodna z granicami domeny, co prowadzi do kontekstów ograniczonych, które są silnie współzależne i obciążone informacjami. Prowadzi to do częstego przełączania kontekstów przez zespół programistów. Pierwszy problem,    jest to, że terminologia organizacyjna przecieka na poziom kodu. Gdy struktury organizacyjne ulegają zmianie, konieczne są modyfikacje bazy kodu, co pochłania cenne zasoby. Innym problemem  Tak więc, podążanie za   pomaga budować system i organizację, które zachęcają do pożądanej architektury oprogramowania. Warto jednak zauważyć, że to podejście nie sprawdzi się zbyt dobrze w już uformowanej architekturze i strukturach, ponieważ zmiany na tym etapie są przedłużane, ale jest wyjątkowo skuteczne w startupach, ponieważ szybko wprowadzają wszelkie zmiany. Inverse Conway Maneuver  Duża Kula Błota  Ten wzorzec lub „antywzorzec” napędza budowanie systemu bez żadnej architektury. Nie ma żadnych reguł, żadnych granic ani żadnej strategii, jak kontrolować nieuchronnie rosnącą złożoność. Złożoność jest najgroźniejszym wrogiem w podróży budowania systemów oprogramowania.   Aby uniknąć stworzenia takiego systemu, musimy przestrzegać określonych zasad i ograniczeń.  Architektura systemu  Istnieje niezliczona ilość definicji architektury oprogramowania. Wiele z nich mi się podoba, ponieważ obejmują różne jej aspekty. Jednak, aby móc rozumować o architekturze, musimy naturalnie uformować niektóre z nich w naszych umysłach. I warto zauważyć, że ta definicja może ewoluować. Więc przynajmniej na razie mam następujący opis dla siebie.    dotyczy decyzji i wyborów, które podejmujesz każdego dnia i które mają wpływ na tworzony system. Architektura oprogramowania  Aby podejmować decyzje, musisz mieć w „torbie” zasady i wzorce rozwiązywania pojawiających się problemów, ważne jest również stwierdzenie, że zrozumienie wymagań jest kluczem do zbudowania tego, czego potrzebuje firma. Jednak czasami wymagania nie są przejrzyste lub nawet nie są zdefiniowane, w takim przypadku lepiej poczekać, aby uzyskać więcej wyjaśnień lub polegać na swoim doświadczeniu i zaufać swojej intuicji. Tak czy inaczej, nie możesz podejmować właściwych decyzji, jeśli nie masz zasad i wzorców, na których możesz polegać. Właśnie tutaj przechodzę do definicji  stylu architektury oprogramowania.    to zbiór zasad i wzorców, które określają sposób tworzenia oprogramowania. Styl architektury oprogramowania  Istnieje wiele różnych stylów architektonicznych, skupionych na różnych aspektach planowanej architektury, a stosowanie wielu z nich na raz jest sytuacją normalną.  Na przykład takie jak:  Architektura monolityczna  Projektowanie zorientowane na domenę  Oparty na komponentach  Mikrousługi  Rury i filtry  Zdarzeniowe  Mikrojądro  Zorientowany na usługi  i tak dalej…  Oczywiście, mają swoje zalety i wady, ale najważniejszą rzeczą, której się nauczyłem, jest to, że architektura ewoluuje stopniowo, w zależności od rzeczywistych problemów. Rozpoczęcie od architektury monolitycznej to świetny wybór, aby zmniejszyć złożoność operacyjną, bardzo prawdopodobne, że ta architektura będzie odpowiadać Twoim potrzebom nawet po osiągnięciu etapu dopasowania produktu do rynku (PMI) podczas tworzenia produktu. W skali możesz rozważyć przejście na podejście oparte na zdarzeniach i mikrousługi w celu osiągnięcia niezależnego wdrożenia, heterogenicznego środowiska stosu technologicznego i mniej sprzężonej architektury (i mniej przejrzystej w międzyczasie ze względu na naturę podejść opartych na zdarzeniach i pub-sub, jeśli zostaną przyjęte). Prostota i wydajność są blisko siebie i mają na siebie duży wpływ. Zazwyczaj skomplikowane architektury wpływają na szybkość rozwoju nowych funkcji, wspierają i utrzymują istniejące oraz stanowią wyzwanie dla naturalnej ewolucji systemu.  Jednakże złożone systemy często wymagają złożonej i kompleksowej architektury, co jest nieuniknione.  Słusznie, to bardzo, bardzo szeroki temat i jest wiele świetnych pomysłów na to, jak ustrukturyzować i zbudować systemy dla naturalnej ewolucji.  Na podstawie mojego doświadczenia opracowałem następujące podejście:  Prawie zawsze zaczyna się od monolitycznego stylu architektury, ponieważ eliminuje on większość problemów wynikających z natury rozproszonych systemów. Ma również sens podążanie za modularnym monolitem, aby skupić się na budowaniu komponentów z wyraźnymi granicami. Zastosowanie podejścia opartego na komponentach mogłoby pomóc im komunikować się ze sobą za pomocą zdarzeń, ale posiadanie bezpośrednich wywołań (zwanych również RPC) upraszcza sprawy na początku. Ważne jest jednak śledzenie zależności między komponentami, ponieważ jeśli komponent A wie dużo o komponencie B, być może ma sens połączenie ich w jeden.  Gdy zbliżysz się do sytuacji, w której konieczne będzie skalowanie rozwoju i systemu, możesz rozważyć zastosowanie wzorca   , który polega na stopniowym wyodrębnianiu komponentów, które należy wdrożyć niezależnie, a nawet skalować zgodnie ze szczególnymi wymaganiami. Stanglera  Teraz, jeśli masz jasną wizję przyszłości, co jest niewiarygodnym szczęściem, możesz zdecydować się na pożądaną architekturę. W tej chwili możesz zdecydować się na przejście na architekturę mikrousług, stosując również podejścia Orchestration i Choreography, włączając wzorzec CQRS dla niezależnych skalowanych operacji zapisu i odczytu, a nawet decydując się na architekturę monolityczną, jeśli spełnia ona Twoje potrzeby.  Ważne jest również zrozumienie liczb i wskaźników, takich jak   (liczba aktywnych użytkowników dziennie),   (liczba aktywnych użytkowników miesięcznie),   (liczba żądań na sekundę) i   (liczba transakcji na sekundę), ponieważ może to pomóc w podejmowaniu decyzji, gdyż architektura dla 100 aktywnych użytkowników i 100 milionów aktywnych użytkowników jest inna. DAU MAU RPC TPC  Na koniec chciałbym powiedzieć, że architektura ma znaczący wpływ na sukces produktu. Źle zaprojektowana architektura produktów jest wymagana w skalowaniu, co bardzo prawdopodobnie prowadzi do porażki, ponieważ klienci nie będą czekać, aż skalujesz system, wybiorą konkurenta, więc musimy wyprzedzać potencjalne skalowanie.   Z drugiej strony, posiadanie bardzo skomplikowanego i już skalowanego systemu bez klientów lub planów zdobycia wielu z nich będzie Cię kosztować pieniądze w Twojej firmie za nic. Chociaż przyznaję, że czasami nie może to być podejście szczupłe, chodzi o to, aby mieć skalowalny, ale nie już skalowany system.  Wybór stosu technologicznego  Wybór zestawu technologii jest również decyzją na poziomie makro, ponieważ wpływa na zatrudnianie, perspektywy naturalnej ewolucji systemu, skalowalność i wydajność systemu.  Poniżej znajduje się lista podstawowych kwestii, które należy wziąć pod uwagę przy wyborze zestawu technologii:    Na przykład, prosta aplikacja internetowa może zostać zbudowana przy użyciu frameworka Blazor, jeśli Twoi programiści mają z nim doświadczenie, ale ze względu na brak dojrzałości WebAssembly, wybór React i Typescript dla długoterminowego sukcesu może być lepszą decyzją Wymagania i złożoność projektu.    Jeśli przewidujesz otrzymywanie dużej ilości ruchu, wybór ASP.NET Core zamiast Django może być mądrym wyborem ze względu na jego lepszą wydajność w obsłudze równoczesnych żądań. Jednak ta decyzja zależy od skali ruchu, której się spodziewasz. Jeśli musisz zarządzać potencjalnie miliardami żądań z niskim opóźnieniem, obecność Garbage Collection może być wyzwaniem. Potrzeby skalowalności i wydajności.    W większości przypadków są to czynniki, o które musimy dbać. Czas wprowadzenia na rynek, koszty utrzymania i stabilność zatrudnienia napędzają potrzeby Twojej firmy bez przeszkód. Zatrudnianie, czas rozwoju i koszt.    Zestaw umiejętności Twojego zespołu programistów jest czynnikiem krytycznym. Zazwyczaj bardziej efektywne jest korzystanie z technologii, z którymi Twój zespół jest już zaznajomiony, chyba że istnieje silny powód, aby zainwestować w naukę nowego stosu. Wiedza i zasoby zespołu.    Silna społeczność i bogaty ekosystem bibliotek i narzędzi mogą znacznie ułatwić proces rozwoju. Popularne technologie często mają lepsze wsparcie społeczności, co może być nieocenione w rozwiązywaniu problemów i znajdowaniu zasobów. Dzięki temu możesz zaoszczędzić zasoby i skupić się głównie na produkcie. Dojrzałość.    Weź pod uwagę długoterminową żywotność technologii. Technologie, które są szeroko przyjęte i obsługiwane, rzadziej stają się przestarzałe i zazwyczaj otrzymują regularne aktualizacje i ulepszenia. Długoterminowa konserwacja i wsparcie.   Jak korzystanie z wielu zestawów technologii może wpłynąć na rozwój firmy?  Z jednej strony wprowadzenie jednego stosu więcej może zwiększyć skalę zatrudnienia, ale z drugiej strony wiąże się z dodatkowymi kosztami utrzymania, ponieważ musisz obsługiwać oba stosy. Tak więc, jak powiedziałem wcześniej, moim zdaniem, tylko dodatkowa potrzeba powinna być argumentem za włączeniem większej liczby stosów technologicznych.   Na czym jednak polega zasada wyboru najlepszego narzędzia do rozwiązania konkretnego problemu?  Czasami nie ma innego wyjścia, jak tylko sięgnąć po nowe narzędzia w celu rozwiązania konkretnego problemu, opierając się na powyższych założeniach. W takich przypadkach warto wybrać najlepsze rozwiązanie.  Tworzenie systemów bez wysokiego sprzężenia z konkretną technologią może być wyzwaniem. Mimo to pomocne jest dążenie do stanu, w którym system nie jest ściśle sprzężony z technologią i nie umrze, jeśli jutro konkretny framework lub narzędzie stanie się podatne na ataki lub nawet przestarzałe.  Innym ważnym czynnikiem jest zależność od oprogramowania open source i własnościowego. Oprogramowanie własnościowe daje mniejszą elastyczność i możliwość dostosowania. Nadal najbardziej niebezpiecznym czynnikiem jest uzależnienie od dostawcy, w którym stajesz się zależny od produktów, cen, warunków i planu działania dostawcy. Może to być ryzykowne, jeśli dostawca zmieni kierunek, podniesie ceny lub zaprzestanie produkcji produktu.   Wyeliminowanie pojedynczego punktu awarii na wszystkich poziomach jest kluczem do budowania niezawodnych systemów wzrostu. Oprogramowanie open source zmniejsza to ryzyko, ponieważ nie kontroluje go pojedyncza jednostka.  Pojedynczy punkt awarii (SPOF)  Pojedynczy punkt awarii (SPOF) odnosi się do dowolnej części systemu, która w przypadku awarii spowoduje, że cały system przestanie działać. Eliminacja SPOF-ów na wszystkich poziomach jest kluczowa dla każdego systemu wymagającego wysokiej dostępności. Wszystko, w tym wiedza, personel, komponenty systemu, dostawcy chmury i kable internetowe, może zawieść.  Istnieje kilka podstawowych technik, które możemy zastosować w celu wyeliminowania pojedynczych punktów awarii:    Wdrażaj nadmiarowość dla krytycznych komponentów. Oznacza to posiadanie komponentów zapasowych, które mogą przejąć zadania, jeśli główny komponent ulegnie awarii. Nadmiarowość można stosować w różnych warstwach systemu, w tym w sprzęcie (serwery, dyski), sieci (łącza, przełączniki) i oprogramowaniu (bazy danych, serwery aplikacji). Jeśli hostujesz wszystko u jednego dostawcy chmury i nawet masz tam kopie zapasowe, rozważ utworzenie regularnej dodatkowej kopii zapasowej u innego, aby zmniejszyć utracone koszty w przypadku katastrofy. Nadmiarowość.    Rozłóż swój system w wielu lokalizacjach fizycznych, takich jak centra danych lub regiony chmurowe. Takie podejście chroni system przed awariami specyficznymi dla danej lokalizacji, takimi jak przerwy w dostawie prądu lub klęski żywiołowe. Centra danych.    Zastosuj podejście failover dla wszystkich komponentów (DNS, CDN, Load balancers, Kubernetes, API Gateways i Databases). Ponieważ problemy mogą pojawić się nieoczekiwanie, kluczowe jest posiadanie planu zapasowego, aby w razie potrzeby szybko zastąpić dowolny komponent jego klonem. Failover.    Upewnij się, że Twoje usługi są zbudowane tak, aby były skalowalne poziomo i wysoce dostępne od samego początku, przestrzegając następujących zasad: Usługi o wysokiej dostępności.  Praktykuj bezstanowość usług i unikaj przechowywania sesji użytkowników w pamięci podręcznej. Zamiast tego używaj rozproszonego systemu pamięci podręcznej, takiego jak Redis.  Przy opracowywaniu logiki unikaj polegania na chronologicznej kolejności odbioru wiadomości.  Minimalizuj zmiany powodujące przerwy, aby zapobiec zakłóceniom dla konsumentów API. Jeśli to możliwe, wybieraj zmiany zgodne z poprzednimi wersjami. Weź również pod uwagę koszty, ponieważ czasami wdrożenie zmiany powodującej przerwy może być bardziej opłacalne.  Włącz wykonywanie migracji do procesu wdrażania.  Opracuj strategię obsługi równoczesnych żądań.  Wdrożenie wykrywania, monitorowania i rejestrowania usług w celu zwiększenia niezawodności i możliwości obserwacji.  Opracuj idempotentną logikę biznesową, pamiętając, że awarie sieci są nieuniknione.    Regularnie przeglądaj i minimalizuj zewnętrzne zależności. Każda zewnętrzna zależność może wprowadzać potencjalne SPOF-y, dlatego ważne jest zrozumienie i ograniczenie tych ryzyk. Przegląd zależności.    Nigdy nie zapominaj o znaczeniu szerzenia wiedzy w swojej organizacji. Ludzie mogą być nieprzewidywalni, a poleganie na jednej osobie jest ryzykowne. Zachęcaj członków zespołu do digitalizacji swojej wiedzy poprzez dokumentację. Uważaj jednak na nadmierną dokumentację. Wykorzystaj różne narzędzia AI, aby uprościć ten proces. Regularne dzielenie się wiedzą.  Wniosek  W tym artykule omówiliśmy kilka kluczowych aspektów   i sposoby radzenia sobie z ich złożonością. makroekonomicznych  Dziękuję za przeczytanie! Do zobaczenia następnym razem!

Read My Stories

Ten dźwięk jest produkowany w oryginalnym języku historii!

Jak radzić sobie ze złożonością podczas projektowania systemów oprogramowania

About Author

UWAGI

ZAWIEŚĆ TAGI

ARTYKUŁ TEN ZOSTAŁ PREZENTOWANY W

Related Stories

Meet the Writer: Hacker Noon's Contributor Elay Romanov of Daiger

Meet the Writer: HackerNoon's Contributor Emmanuel Nwaka, Content Marketing Professional

Listen to Tech Brief Podcasts on Your Headphones: Stay Connected to HackerNoon Anywhere, Anytime

Google's Gemini AI: A Thought Experiment in Deception

Meet the Writer: Hacker Noon's Contributor Elay Romanov of Daiger

Meet the Writer: HackerNoon's Contributor Emmanuel Nwaka, Content Marketing Professional

Listen to Tech Brief Podcasts on Your Headphones: Stay Connected to HackerNoon Anywhere, Anytime

Google's Gemini AI: A Thought Experiment in Deception

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps