Üdvözlök mindenkit.
Ma bemutatjuk Tugberk Ugurlu írásának fordítását, amelyben viszonylag rövid terjedelemben foglalja össze a modern szoftverrendszerek tervezésének alapelveit. Íme, amit az író magáról elmond:
Mivel lehetetlen átfogni olyan hatalmas témát, mint az architekturális minták + tervezési minták 2019-es állapota, javasoljuk, hogy ne csak Ugurlu szövegét, hanem a számos linket is, amelyet kedvesen elhelyezett benne, nézze meg. Ha tetszik, közzétehetjük a terjeszkedett rendszerek tervezéséről szóló, szűkebb szakmai szöveget is.
Kép az Unsplash-ről
Ha még soha nem találkozott olyan kihívásokkal, mint egy szoftverrendszer nulláról való tervezése, akkor ilyen munka megkezdésekor gyakran nem is világos, hol kezdje. Úgy gondolom, hogy először meg kell határozni a határokat, hogy nagyjából biztosan tudja, mit kíván tervezni, majd fel kell gyűrni az ingujját, és dolgozni anélkül, hogy túllépne ezeken a határokon. Kiindulási pontként választhat egy terméket vagy szolgáltatást (ideálisan olyat, amit nagyon kedvel), és nézze meg a megvalósítását. Lehet, hogy meglepődik, mennyire egyszerűen néz ki az adott termék, és mennyi bonyodalom rejlik benne valójában. Ne feledje: , és ez rendben van.
A legjobb tanács, amit adhatok azoknak, akik a rendszer tervezésébe kezdenek, a következő: ne tegyenek semmiféle feltevést! Már az elején konkretizálni kell a rendszerről ismert tényeket és a kapcsolódó elvárásokat. Íme néhány jó kérdés, amelyek válaszai segítenek a tervezés elkezdésében:
- Milyen probléma megoldására törekszünk?
- Mennyi a csúcsfelhasználók száma, akik a rendszerünkkel interakcióba lépnek?
- Milyen minták szerint fogjuk az adatokat rögzíteni és lekérdezni?
- Mik az elvárt meghibásodási esetek, és hogyan fogunk megküzdeni velük?
- Milyen elvárások vannak a rendszer konzisztenciájával és rendelkezésre állásával kapcsolatban?
- Figyelembe kell venni a külső ellenőrzéssel és szabályozással kapcsolatos követelményeket a munka során?
- Milyen típusú bizalmas adatokat tervezünk tárolni?
Ezek csupán néhány kérdés, amelyek hasznosak voltak mind számomra, mind azoknak a csapatoknak, amelyekben az évek során részt vettem a szakmai tevékenységem során. Ha ismeri a válaszokat ezekre a kérdésekre (és bármely egyéb, az Ön által érintett kontextusban releváns kérdésekre), akkor fokozatosan elmélyedhet a feladat technikai részleteiben.
A kiindulási szint meghatározása
Mit értek itt kiindulási szinten? A mi időnkben a legtöbb probléma a szoftveriparban 'megoldható' a már létező módszerekkel és technológiákkal. Ennek megfelelően, ha megértjük ezt a tájat, akkor kétségkívül előnyre teszünk szert, amikor olyan feladatokkal találkozunk, amelyeket mások nekünk előtt már megoldottak. Ne felejtsük el, hogy a programok a vállalatok és felhasználók problémáinak megoldására készülnek, ezért arra törekszünk, hogy a feladatot a lehető legegyszerűbben (felhasználói szempontból) oldjuk meg. Miért fontos erről emlékezni? Lehet, hogy az Ön koordinátarendszerében szeret egyedi megoldásokat keresni minden feladatra, mert úgy érzi, hogy 'milyen programozó vagyok én, ha mindenhol követem a mintákat'? Valójában, a művészet abban rejlik, hogy eldöntsük, hol és mit tegyünk.. Nyilvánvaló, hogy mindannyiunknak időről időre szembe kell néznie egyedi problémákkal, amelyek mind igazi kihívások. Azonban, ha a kiindulási szintünk világosan meg van határozva, akkor tudjuk, mire kellene fókuszálni: a felmerülő feladat gyors megoldására, vagy annak további tanulmányozására és mélyebb megértésére.
Úgy gondolom, sikerült meggyőznöm, hogy ha a szakember magabiztosan érti a remek szoftverrendszerek architektúrájának elemeit, akkor ezek az ismeretek nélkülözhetetlenek az építész művészetének elsajátításához és egy szilárd alap létrehozásához ezen a területen.
Jól van, de honnan kezdjük? a GitHubon rendelkezik egy tárolóval, amelynek neve , amely alapján megtanulhatja a nagyméretű rendszerek tervezését, valamint felkészülhet a kapcsolódó interjúkra. A tárolóban található egy szekció példákkal , ahol többek között azt vizsgáljuk, hogyan közelítenek a rendszereik tervezéséhez , például a Twitter, Uber stb.
Azonban mielőtt áttérnénk erre a tartalomra, nézzük meg részletesebben a legfontosabb architekturális kihívásokat, amelyekkel a gyakorlatban szembesülni kell. Ez fontos, mivel sok aspektust kell konkretizálni egy nem egyszerű és sokszínű problémán belül, majd ezt a rendszeren belüli szabályozások keretein belül kell megoldani. , a korábbi Facebook munkatárs, készített , ahol megosztotta saját tapasztalatait több száz pályázó áttekintésében. Bár a videó kifejezetten a nagyméretű rendszerek tervezésével és a pozícióhoz keresett jelöltek kiválasztásához szükséges sikerkritériumokkal foglalkozik, mégis átfogó forrássá válik arról, hogy mi a legfontosabb a rendszerek tervezése során. Azt is javaslom, .
Fejlessze az adatok tárolásáról és előhívásáról szerzett ismereteit
Általában a döntés, hogy miként fogja hosszú távon tárolni és kiadni az adatait, kritikus hatással van a rendszer teljesítményére. Ezért először is tisztában kell lennie a feltételezett írási és olvasási teljesítménnyel a rendszerében. Ezt követően értékelnie kell ezeket a mutatókat, és a felmérések alapján kell választania. Azonban hatékonyan végezheti ezt a munkát, ha tisztában van a létező adatok tárolási mintákkal. Ez alapvetően magában foglalja a .
Az adatbázisok tekinthetők olyan adatszerkezeteknek, amelyek élen járnak a skálázhatóságban és tartósságban. Ezért az adatszerkezetek ismerete nagyon hasznos lehet az adatbázisok kiválasztásakor. Például, – ez egy adatstruktúra-szerver, amely különböző típusú értékeket támogat. Lehetővé teszi olyan adatstruktúrákkal való munkát, mint a listák és halmazok, valamint a közismert algoritmusok segítségével adatokat olvasni, például, , megszervezve ezt a munkát tartós és nagy rendelkezésre állású módon.
Kép az Unsplash-ről
Amikor már kellőképpen megismerkedtél a különféle adatmegőrzési mintákkal, lépj tovább az adatok konzisztenciájának és elérhetőségének tanulmányozására. Először is meg kell tanulnod legalábbis általános értelemben, majd ezt a tudást csiszold, részletesebben megvizsgálva a megalapozott és . Így szélesebb látókört nyersz ezen a területen, és megérted, hogy az adatok olvasása és írása valójában két nagyon különböző probléma, mindkettő sajátos kihívásokkal jár. Néhány konzisztencia- és elérhetőségbiztosító mintával felvértezve jelentős mértékben növelheted a rendszer teljesítményét, miközben garantálod az adatfolyam zavartalan ellátását az alkalmazásaid számára.
Végül, befejezve a tárolási kérdésekről folytatott beszélgetést, meg kell említeni a gyorsítótárazást is. Az gyorsítótárazást végezze egyszerre az ügyfél és a szerver? Milyen adatok lesznek a gyorsítódáljban? És miért? Hogyan szervezed meg a gyorsítótár érvénytelenítését? Rendszeresen történik, meghatározott időközönként? Ha igen, milyen gyakran? Javaslom, hogy ezekkel a témákkal a megjelenített rendszervizsgáló könyvecskéjével kezdd el foglalkozni.
Kommunikációs minták
A rendszerek különböző komponensekből állnak; ezek lehetnek olyan folyamatok, amelyek egyazon fizikai csomóponton belül működnek, vagy különböző gépek, amelyek a hálózat különböző részein találhatók. Ezen erőforrások egy része a hálózaton belül lehet privát, míg másoknak nyilvánosnak és a külső felhasználók számára elérhetőnek kell lenniük.
Biztosítani kell ezen erőforrások közötti kommunikációt, valamint az információk cseréjét az egész rendszer és a külső világ között. A rendszerek tervezésének összefüggésében itt ismét új, egyedi kihívásokkal találkozunk. Megtudjuk, hogy milyen előnyöket nyújthatnak , és milyen kihívásokkal járnak..
Kép az Unsplash-ről
A külső világgal való kommunikáció megszervezésénél mindig nagyon fontos , amelyhez szintén komolyan kell hozzáállni és aktívan foglalkozni vele.
Kapcsolatok elosztása
Nem vagyok biztos benne, hogy ennek a témának önálló részbe helyezése mindenki számára indokolt lenne. Mindazonáltal itt részletesen kifejtem ezt a koncepciót, és úgy vélem, hogy ennek a résznek az anyaga legjobban a "kapcsolatok elosztása" (connection distribution) kifejezéssel írható le.
A rendszerek több komponens helyes összekapcsolásával alakulnak ki, és a köztük lévő kommunikáció gyakran megszilárdult protokollok, például a TCP és UDP alapján szerveződik. Azonban ezek a protokollok gyakran nem elegendőek a modern rendszerek összes igényének kielégítésére, amelyek gyakran magas terhelés alatt működnek, és jelentősen függenek a felhasználók igényeitől. Gyakran szükség van a kapcsolatok elosztásának módjainak keresésére a rendszeren belüli magas terhelések kezelésére.
Ennek az elosztásnak a hátterében jól ismert (DNS) áll. Ez a rendszer lehetővé teszi a domain név átkonvertálását, például a súlyozott körkörös algoritmus (weighted round robin) és késleltetésalapú módszerek, amelyek segítenek az terhelés elosztásában.
alapvetően fontos, és gyakorlatilag bármelyik nagyobb internetes rendszer, amellyel ma foglalkozunk, egy vagy több terheléselosztó mögött helyezkedik el. A terheléselosztók segítenek a felhasználói kérések elosztásában a rendelkezésre álló példányok között. A terheléselosztók lehetnek hardveresek vagy szoftveresek, de a gyakorlatban gyakrabban foglalkozunk szoftveresekkel, például a és . konceptuálisan szintén nagyon hasonlít a terheléselosztókhoz, de az első és a második között van néhány . Ezeket a különbségeket figyelembe kell venni, amikor a rendszert az Ön igényeinek megfelelően tervezzük.
A tartalomszolgáltató hálózatokkal (CDN). A CDN egy globálisan elosztott proxyk hálózata, amely az információkat a konkrét felhasználóhoz földrajzilag legközelebb elhelyezkedő csomópontokból szállítja. CDN hálózatot érdemes használni, ha statikus fájlokkal dolgozik, mint például JavaScript, CSS és HTML. Ezenkívül napjainkban népszerűek azok a felhőszolgáltatások, amelyek forgalomkezelőket kínálnak, mint például , amelyek globális elosztást és csökkentett késleltetést biztosítanak dinamikus tartalom kezelésekor. Azonban ezek a szolgáltatások általában akkor hasznosak, amikor állapot nélküli webszolgáltatásokkal dolgozunk.
Beszéljünk az üzleti logikáról. Az üzleti logika, a feladatáramok és a komponensek struktúrája.
Nos, már megvitattuk a rendszer különböző infrastruktúra-aspektusait. Valószínű, hogy a felhasználó nem is gondol mindezekre a rendszer elemeire, és őszintén szólva egyáltalán nem is törődik velük. A felhasználót az érdekli, milyen interakciókat kínál a rendszer, mit lehet elérni ezzel vagy azzal a lépéssel, és hogyan hajtja végre a rendszer a felhasználói parancsokat, mit csinál a felhasználói adatokkal.
Ahogy a cikk címe is mutatja, arról akartam beszélni, hogy mi a szoftverarchitektúra és a rendszerek tervezése. Így nem terveztem, hogy a szoftverfejlesztési mintákra összpontosítok, amelyeket a programkomponensek létrehozásának módjába tartoznak. Azonban minél többet gondolkodom erről, annál inkább úgy tűnik, hogy a határ a szoftverfejlesztési minták és az architekturális minták között meglehetősen homályos, és a két koncepció szorosan összefonódik. Például nézzük meg a (event sourcing). Ha ezt az architekturális mintát alkalmazza, akkor az gyakorlatilag minden szempontot befolyásolni fog a rendszerében: adatok hosszú távú tárolása, a rendszerében elfogadott konzisztenciaszint, a rendszerben található komponensek kontúrjai stb. Ezért úgy döntöttem, hogy megemlítek néhány architekturális mintát, amelyek közvetlenül vonatkoznak az üzleti logikára. Még ha ebben a cikkben meg is kell elégednünk egy egyszerű listával, javaslom, hogy ismerkedjen meg vele és gondolja át a mintákhoz kapcsolódó ötleteket. Íme:
- Koncepciók , különösen ,
Együttműködő megközelítések
Nagyon valószínűtlen, hogy Ön lesz az a résztvevő a projektben, aki egyedül felelős a rendszer tervezési folyamatáért. Éppen ellenkezőleg, valószínű, hogy együtt kell működnie kollégáival, akik a feladatán belül és azon kívül dolgoznak. Ebben az esetben szükség lehet arra, hogy közösen értékeljék a kiválasztott technológiai megoldásokat, kiemeljék az üzleti igényeket és megértsék, hogyan lehet a feladatokat a legjobban párhuzamosítani.
Kép az Unsplash-ről
Elsősorban pontos és közösen elfogadott képet kell kialakítani arról, hogy mi az az üzleti cél, amit el szeretne érni, és milyen mozgó elemekkel kell foglalkoznia. A csoportos modellezési technikák, nevezetesen (event storming) jelentősen felgyorsíthatják ezt a folyamatot, és növelik az Ön sikerének esélyeit. Ezt a munkát elvégezheti még azelőtt vagy azután, hogy körvonalazná , majd ennek mélyebb megértésével foglalkozhat, ahogy a termék érik. Az itt elérendő összhang szintje alapján megfogalmazhatja az Ön által használt korlátozott kontextus számára. Amikor arról kell beszélnie, hogy milyen az Ön rendszerének architektúrája, hasznos lehet egy , amelyet javasolt, különösen akkor, amikor meg kell értenie, hogy mennyire kell mélyen belemerülnie a problémába, visualizálva azokat a dolgokat, amelyeket közölni szeretne.
Valószínű, hogy az ezen a területen létezik más érett technológia is, amely nem kevésbé hasznos, mint a tárgyorientált tervezés. Mégis, bármilyen okból visszatérünk a tárgyterület megértéséhez, így a tárgyorientált tervezés terén szerzett tudás és tapasztalat segíthet Önnek. kell, hogy hasznos legyen.
Forrás: habr.com
