Hogyan kezeljük a szoftverrendszerek tervezésének bonyolultságát?

miről van szó? Mérnöki pályafutásunk során nap mint nap, minden pillanatban sok különböző összetettségű és helyzetű problémával találkozunk, ahol döntést kell hoznunk, vagy adathiány miatt el kell halasztanunk. Amikor új szolgáltatásokat építünk, infrastruktúrát építünk, vagy akár fejlesztési folyamatokat alakítunk ki, különféle kihívások hatalmas világát érintjük. Nehéz, sőt talán lehetetlen felsorolni az összes problémát. E problémák némelyikével csak akkor találkozhat, ha egy adott résben dolgozik. Másrészt sok olyan probléma van, amelyeket mindannyiunknak meg kell értenünk, hogyan kell megoldani, mivel ezek döntő fontosságúak az informatikai rendszerek felépítésében. Nagy valószínűséggel minden projektben találkozni fog velük. Ebben a cikkben megosztom tapasztalataimat néhány olyan problémával kapcsolatban, amelyekkel szoftverprogramok létrehozása során találkoztam. Mi az az átfogó aggodalom? Ha belenézünk a Wikipédiába, a következő definíciót találjuk Az aspektus-orientált szoftverfejlesztésben az átfogó szempontok a program olyan aspektusai, amelyek több modult érintenek anélkül, hogy bármelyik modulba beágyazódnának. Ezeket az aggályokat gyakran nem lehet tisztán lebontani a rendszer többi részéből sem a tervezés, sem a megvalósítás során, és szóródáshoz (kódduplikáció), összegabalyodáshoz (a rendszerek közötti jelentős függőségek), vagy mindkettőhöz vezethetnek. Nagyon jól leírja, hogy mi ez, de szeretném egy kicsit kiterjeszteni és leegyszerűsíteni: A a rendszer/szervezet olyan koncepciója vagy összetevője, amely számos más részt érint (vagy „átvág”). több területet átfogó aggály Az ilyen aggályok legjobb példái a rendszerarchitektúra, naplózás, biztonság, tranzakciókezelés, telemetria, adatbázis-tervezés és még sok más. A cikk későbbi részében ezek közül sokat fogunk részletesebben kifejteni. A kód szintjén az átfogó szempontokat gyakran olyan technikák segítségével valósítják meg, mint például , ahol ezek az aggályok különálló komponensekké modulárisak, amelyek az egész alkalmazásban alkalmazhatók. Ez elszigeteli az üzleti logikát ezektől a problémáktól, így a kód olvashatóbbá és karbantarthatóbbá válik. az aspektus-orientált programozás (AOP) Szempontok besorolása Számos lehetséges módszer létezik a szempontok osztályozására úgy, hogy különböző tulajdonságokkal, például hatókörrel, mérettel, funkcionalitással, fontossággal, céllal és egyebekkel szegmentálja őket, de ebben a cikkben egy egyszerű hatókör-besorolást fogok használni. Ez alatt azt értem, hogy hova irányul ez a konkrét szempont, legyen szó akár az egész szervezetről, egy adott rendszerről, vagy annak egy meghatározott eleméről. Tehát a szempontokat és fogom felosztani. makróra mikrora alatt elsősorban azokat a megfontolásokat értem, amelyeket a rendszer egészére vonatkozóan követünk, mint a választott rendszerarchitektúra és annak kialakítása (monolit, mikroszolgáltatások, szolgáltatás-orientált architektúra), technológiai stack, szervezeti struktúra stb. elsősorban a stratégiai és magas szintű szempontokhoz kapcsolódnak döntéseket. Makrószempont A makroszempontok Mindeközben a aspektus sokkal közelebb áll a kódszinthez és a fejlesztéshez. Például, hogy melyik keretrendszert használjuk az adatbázissal való interakcióhoz, a mappák és osztályok projektstruktúráját, vagy akár konkrét objektumtervezési mintákat. Micro Bár ez a besorolás nem ideális, segít a lehetséges problémák, valamint a rájuk alkalmazott megoldások fontosságának és hatásának megértésében. Ebben a cikkben elsősorban a makroszempontokra összpontosítok. Makró szempontok Szervezeti felépítés Amikor csak elkezdtem tanulni a szoftverarchitektúráról, sok érdekes cikket olvastam a Conway-törvényről és annak a szervezeti struktúrára gyakorolt hatásáról. Főleg . Tehát ez a törvény kimondja ezt Minden szervezet, amely rendszert tervez (tág értelemben), olyan tervet készít, amelynek szerkezete a szervezet kommunikációs struktúrájának másolata. Mindig is azt hittem, hogy ez a fogalom valóban nagyon univerzális, és az aranyszabályt képviseli. Aztán elkezdtem tanulni Eric Evans Domain-Driven Design (DDD) megközelítését modellezési rendszerekre. Eric Evans hangsúlyozza a Bounded Context azonosítás fontosságát. Ez a koncepció magában foglalja egy összetett tartománymodell felosztását kisebb, jobban kezelhető szakaszokra, amelyek mindegyike saját korlátozott tudáskészlettel rendelkezik. Ez a megközelítés segíti a hatékony csapatkommunikációt, mivel csökkenti a teljes tartomány széles körű ismeretének szükségességét, és minimalizálja a kontextusváltást, ezáltal hatékonyabbá teszi a beszélgetéseket. A kontextusváltás a valaha volt legrosszabb és leginkább erőforrásigényes dolog. Még a számítógépek is küzdenek vele. Bár nem valószínű, hogy a kontextusváltás teljes hiányát elérjük, úgy gondolom, hogy erre kell törekednünk. Visszatérve Conway törvényéhez, több problémát is találtam vele kapcsolatban. amellyel a Conway-törvénnyel találkoztam, amely azt sugallja, hogy a rendszertervezés tükrözi a szervezeti struktúrát, az összetett és átfogó, határos kontextusok kialakításának lehetősége. Ez a bonyolultság akkor merül fel, ha a szervezeti struktúra nincs összhangban a tartomány határaival, ami határos kontextusokhoz vezet, amelyek erősen függenek egymástól és tele vannak információval. Ez gyakori kontextusváltáshoz vezet a fejlesztőcsapat számára. Az első probléma, , hogy a szervezeti terminológia a kód szintjére szivárog. Amikor a szervezeti struktúrák megváltoznak, ez kódbázis módosításokat tesz szükségessé, ami értékes erőforrásokat emészt fel. Egy másik probléma Így követése segít felépíteni azt a rendszert és szervezetet, amely elősegíti a kívánt szoftverarchitektúrát. Figyelemre méltó azonban, hogy ez a megközelítés nem működik túl jól a már kialakult architektúrában és struktúrákban, mivel a változások ebben a szakaszban elhúzódnak, de az induló vállalkozásoknál kivételesen teljesít, mivel gyorsan bevezetik a változtatásokat. az Inverse Conway Maneuver Nagy sárlabda Ez a minta vagy „anti-minta” egy rendszer felépítését hajtja végre architektúra nélkül. Nincsenek szabályok, nincsenek határok, és nincs stratégia az elkerülhetetlenül növekvő összetettség ellenőrzésére. A komplexitás a szoftverrendszerek felépítésének legfélelmetesebb ellensége. Ahhoz, hogy elkerüljük az ilyen típusú rendszer felépítését, meghatározott szabályokat és megszorításokat kell követnünk. Rendszer architektúra A szoftverarchitektúrára számtalan definíció létezik. Sokukat szeretem, mivel különböző szempontokat fednek le. Ahhoz azonban, hogy érvelni tudjunk az építészetről, természetesen meg kell alkotnunk néhányat az elménkben. És érdemes megjegyezni, hogy ez a meghatározás változhat. Így legalább egyelőre megvan a következő leírás magamnak. azokról a döntésekről és döntésekről szól, amelyeket minden nap meghoz, és amelyek hatással vannak az épített rendszerre. A szoftverarchitektúra A döntések meghozatalához a felmerülő problémák megoldására vonatkozó elveknek és mintáknak a „táskájában” kell lenniük, és azt is alapvetően fontos kijelenteni, hogy a követelmények megértése kulcsfontosságú annak kialakításához, amire egy vállalkozásnak szüksége van. Néha azonban a követelmények nem átláthatóak, vagy nem is definiáltak, ebben az esetben jobb, ha megvárod a további felvilágosítást, vagy hagyatkozz a tapasztalatodra és bízz az intuíciódban. De különben is, nem tudsz megfelelően dönteni, ha nincsenek elveid és mintáid, amelyekre támaszkodhatsz. Itt jutok el a szoftverarchitektúra stílusának meghatározásához. olyan elvek és minták összessége, amelyek meghatározzák a szoftverek felépítését. A Software Architecture Style A tervezett építészet különböző oldalaira nagyon sok különböző építészeti stílus fókuszál, és ezek egyidejű alkalmazása normális helyzet. Például, mint például: Monolit építészet Domain-vezérelt tervezés Komponens alapú Mikroszolgáltatások Cső és szűrők Eseményvezérelt Mikrokernel Szolgáltatás-orientált és így tovább… Természetesen megvannak a maguk előnyei és hátrányai, de a legfontosabb dolog, amit megtanultam, az az, hogy az építészet fokozatosan, a tényleges problémák függvényében fejlődik. A monolitikus architektúrától kezdve nagyszerű választás a működési bonyolultságok csökkentésére, nagy valószínűséggel ez az architektúra megfelel az Ön igényeinek még a termék felépítésének Product-market Fit (PMI) szakaszának elérése után is. Méretben megfontolhatja az eseményvezérelt megközelítés és a mikroszolgáltatások felé történő elmozdulást a független telepítés, a heterogén technológiai veremkörnyezet és a kevésbé csatolt architektúra elérése érdekében (és időközben kevésbé átlátható az eseményvezérelt és a pub-sub megközelítések természete miatt, ha ezeket elfogadják). Az egyszerűség és a hatékonyság közel áll egymáshoz, és nagy hatással vannak egymásra. Általában a bonyolult architektúrák befolyásolják az új funkciók fejlesztési sebességét, támogatják és fenntartják a meglévőket, és kihívást jelentenek a rendszer természetes fejlődésében. Az összetett rendszerek azonban gyakran összetett és átfogó architektúrát igényelnek, ami elkerülhetetlen. Valójában ez egy nagyon tág téma, és sok nagyszerű ötlet létezik a természetes evolúcióhoz szükséges rendszerek felépítéséről és felépítéséről. Tapasztalataim alapján a következő megközelítést dolgoztam ki: Szinte mindig a monolitikus architektúra stílusával kezdődik, mivel ez kiküszöböli az elosztott rendszerek természetéből adódó problémák nagy részét. Érdemes a moduláris monolitot is követni, hogy a világos határokkal rendelkező építőelemekre összpontosítsunk. A komponens alapú megközelítés alkalmazása segíthet nekik az események segítségével kommunikálni egymással, de a közvetlen hívások (más néven RPC) már az elején leegyszerűsítik a dolgokat. Fontos azonban a komponensek közötti függőségek nyomon követése, mivel ha az A komponens sokat tud a B komponensről, akkor talán érdemes összevonni őket. Ha közelebb kerül ahhoz a helyzethez, amikor méreteznie kell a fejlesztést és a rendszert, érdemes lehet követnie a mintát, hogy fokozatosan kivonja azokat az összetevőket, amelyeket önállóan kell telepíteni, vagy akár speciális követelményeknek megfelelően méretezni kell. Stangler- Most, ha van egy világos jövőképe, ami egy kis hihetetlen szerencse, akkor dönthet a kívánt architektúra mellett. Jelenleg dönthet úgy, hogy a mikroszolgáltatási architektúra felé mozdul el úgy, hogy hangszerelési és koreográfiai megközelítéseket is alkalmaz, CQRS mintát épít be a független léptékű írási és olvasási műveletekhez, vagy akár úgy dönthet, hogy ragaszkodik a monolitikus architektúrához, ha az megfelel az Ön igényeinek. Szintén létfontosságú az olyan számok és mutatók megértése, mint például (napi aktív felhasználók), (havi aktív felhasználók), (másodpercenkénti kérés) és (tranzakció per másodperc), mivel ezek segíthetnek a döntések meghozatalában, mivel az architektúra 100 aktív felhasználó és 100 millió aktív felhasználó különbözik. a DAU a MAU az RPC a TPC Utolsó megjegyzésként azt szeretném mondani, hogy az architektúra jelentős hatással van a termék sikerére. A méretezésnél a termékek rosszul megtervezett architektúrájára van szükség, ami nagy valószínűséggel kudarchoz vezet, mivel az ügyfelek nem várnak, amíg te méretezed a rendszert, hanem versenytársat választanak, így előrébb kell lennünk a potenciális méretezéssel. Másrészt, ha egy nagyon bonyolult és már méretezhető rendszerrel rendelkezik anélkül, hogy ügyfelei vannak, vagy nem tervezi, hogy sokakat szerezzen be, az semmibe fog kerülni a vállalkozásának. Bár elismerem, hogy ez néha nem lehet lean megközelítés, az ötlet az, hogy legyen egy méretezhető, de még nem skálázott rendszer. Technológiai verem kiválasztása A technológiai köteg kiválasztása szintén makroszintű döntés, mivel befolyásolja a felvételt, a rendszer természetes fejlődési perspektíváit, a méretezhetőséget és a rendszer teljesítményét. Íme a technológiai köteg kiválasztásának alapvető szempontjainak listája: Például a Blazor keretrendszerrel egy egyszerű webalkalmazás is készíthető, ha fejlesztőinek van tapasztalatuk vele, de a WebAssembly éretlensége miatt a React és a Typescript választása a hosszú távú siker érdekében jobb döntés lehet. A projekt követelményei és összetettsége. Ha nagy mennyiségű forgalomra számít, az ASP.NET Core választása a Django helyett bölcs választás lehet, mivel kiváló teljesítményt nyújt az egyidejű kérések kezelésében. Ez a döntés azonban a várható forgalom mértékétől függ. Ha potenciálisan több milliárd kérést kell kezelnie alacsony késleltetéssel, a szemétgyűjtés jelenléte kihívást jelenthet. Skálázhatósági és teljesítményigények. A legtöbb esetben ezekkel a tényezőkkel kell törődnünk. A piacra jutás ideje, a karbantartási költségek és a munkaerő-felvételi stabilitás akadálytalanul szolgálja üzleti igényeit. Bérbeadás, fejlesztési idő és költség. A fejlesztőcsapat készségkészlete kritikus tényező. Általában hatékonyabb olyan technológiákat használni, amelyeket csapata már ismer, hacsak nincs komoly ok arra, hogy egy új verem elsajátításába fektessen be. Csapatszakértelem és erőforrások. Egy erős közösség, valamint a könyvtárak és eszközök gazdag ökoszisztémája nagyban megkönnyítheti a fejlesztési folyamatot. A népszerű technológiák gyakran jobb közösségi támogatást nyújtanak, ami felbecsülhetetlen értékű lehet a problémák megoldásában és az erőforrások megtalálásában. Így erőforrásokat takaríthat meg, és elsősorban a termékre összpontosíthat. Érettség. Vegye figyelembe a technológia hosszú távú életképességét. A széles körben elfogadott és támogatott technológiák kevésbé valószínű, hogy elavulnak, és általában rendszeres frissítéseket és fejlesztéseket kapnak. Hosszú távú karbantartás és támogatás. Hogyan befolyásolhatja az üzleti növekedést a több technológiai halom? Egyrészt egy újabb köteg bevezetése növelheti a munkaerő-felvételt, másrészt viszont további karbantartási költségekkel jár, mivel mindkét köteget támogatnia kell. Tehát, ahogy korábban mondtam, véleményem szerint csak a plusz igény lehet érv több technológiai halom beépítése mellett. De mi a helyzet az adott probléma legjobb eszközének kiválasztásával? Néha nincs más választása, mint új eszközöket hozni egy adott probléma megoldására a fent említett szempontok alapján, ilyen esetekben érdemes a legjobb megoldást kiválasztani. Kihívást jelenthet olyan rendszerek létrehozása, amelyek nem kapcsolódnak egy adott technológiához. Mégis érdemes olyan állapotra törekedni, ahol a rendszer nincs szorosan összekapcsolva a technológiával, és nem hal meg, ha holnap egy adott keretrendszer vagy eszköz sebezhetővé vagy akár elavulttá válik. Egy másik fontos szempont a nyílt forráskódú és a védett szoftverek függőségei. A szabadalmaztatott szoftver kevesebb rugalmasságot és testreszabhatóságot biztosít. Mégis, a legveszélyesebb tényező a szállítói bezárkózás, amikor Ön függ a szállító termékeitől, áraitól, feltételeitől és ütemtervétől. Ez kockázatos lehet, ha az eladó irányt változtat, megemeli az árakat vagy leállítja a terméket. Egyetlen hibapont kiküszöbölése minden szinten kulcsfontosságú a növekedést szolgáló megbízható rendszerek felépítéséhez. A nyílt forráskódú szoftver csökkenti ezt a kockázatot, mivel nem egyetlen entitás irányítja azt. Single Point of Failure (SPOF) Egyetlen hibapont (SPOF) a rendszer bármely olyan részére vonatkozik, amely meghibásodása esetén az egész rendszer működése leáll. Az SPOF-ok minden szinten történő kiküszöbölése kulcsfontosságú minden olyan rendszer esetében, amely magas rendelkezésre állást igényel. Minden, beleértve a tudást, a személyzetet, a rendszerelemeket, a felhőszolgáltatókat és az internetkábeleket, meghibásodhat. Számos alapvető technikát alkalmazhatunk az egyes hibák kiküszöbölésére: A kritikus komponensek redundanciájának megvalósítása. Ez azt jelenti, hogy olyan biztonsági mentési összetevők vannak, amelyek átvehetik az irányítást, ha az elsődleges összetevő meghibásodik. A redundancia a rendszer különböző rétegeiben alkalmazható, beleértve a hardvert (szerverek, lemezek), a hálózatot (hivatkozások, kapcsolók) és a szoftvereket (adatbázisok, alkalmazásszerverek). Ha mindent az egyik felhőszolgáltatóban tárol, és ott még biztonsági másolatokat is készít, fontolja meg egy rendszeres további biztonsági mentés létrehozását egy másikban, hogy csökkentse az elveszett költségeket katasztrófa esetén. Redundancia. Ossza meg rendszerét több fizikai helyen, például adatközpontokban vagy felhőrégiókban. Ez a megközelítés megvédi a rendszert a helyspecifikus hibáktól, például áramkimaradásoktól vagy természeti katasztrófáktól. Adatközpontok. Alkalmazzon feladatátvételi megközelítést minden összetevőjére (DNS, CDN, terheléselosztók, Kubernetes, API-átjárók és adatbázisok). Mivel a problémák váratlanul is felmerülhetnek, kulcsfontosságú, hogy rendelkezzen egy biztonsági mentési tervvel, amellyel bármely összetevőt gyorsan lecserélhet a klónjára. Feladatátvétel. A következő elvek betartásával gondoskodjon arról, hogy szolgáltatásai a kezdetektől vízszintesen méretezhetőek és magasan elérhetők legyenek: Magas rendelkezésre állású szolgáltatások. Gyakorolja a szolgáltatás állapottalanságát, és kerülje a felhasználói munkamenetek memóriabeli gyorsítótárban való tárolását. Ehelyett használjon elosztott gyorsítótár-rendszert, például a Redis-t. A logika fejlesztése során kerülje az üzenetfogyasztás időrendi sorrendjét. Minimalizálja a törést okozó változtatásokat, hogy elkerülje az API-fogyasztók megzavarását. Ahol lehetséges, válasszon visszafelé kompatibilis változtatásokat. Vegye figyelembe a költségeket is, mivel néha egy törést jelentő változtatás végrehajtása költséghatékonyabb lehet. Szerelje be az áttelepítés végrehajtását a telepítési folyamatba. Hozzon létre egy stratégiát az egyidejű kérések kezelésére. A megbízhatóság és a megfigyelhetőség fokozása érdekében hajtsa végre a szolgáltatásfelderítést, -figyelést és -naplózást. Az üzleti logika fejlesztése idempotenssé, elismerve, hogy a hálózati hibák elkerülhetetlenek. Rendszeresen ellenőrizze és minimalizálja a külső függőséget. Minden külső függőség potenciális SPOF-okat hozhat létre, ezért elengedhetetlen ezeknek a kockázatoknak a megértése és csökkentése. Függőség felülvizsgálata. Soha ne felejtse el a tudás terjesztésének fontosságát a szervezeten belül. Az emberek kiszámíthatatlanok lehetnek, és egyetlen egyénre támaszkodni kockázatos. Ösztönözze a csapat tagjait, hogy dokumentálással digitalizálják tudásukat. Ügyeljen azonban a túlzott dokumentálásra. Használjon különféle AI-eszközöket a folyamat egyszerűsítésére. Rendszeres tudásmegosztás. Következtetés Ebben a cikkben számos kulcsfontosságú szemponttal foglalkoztunk, és bemutattuk, hogyan kezeljük ezek összetettségét. makró- Köszönöm, hogy elolvastad! Találkozunk legközelebb!