Hello kollégák.
Ma figyelmükbe ajánljuk Tugberk Ugurlu cikkének fordítását, aki arra vállalkozott, hogy viszonylag kis kötetben felvázolja a modern szoftverrendszerek tervezésének alapelveit. A szerző összefoglalóan elmondja magáról:
Mivel egy habro cikkben végképp lehetetlen olyan kolosszális témát feldolgozni, mint az építészeti minták + tervezési minták 2019-től, ezért nem csak magának Uruglu úrnak a szövegét ajánljuk figyelmébe, hanem azt a számos linket is, amelyeket szívesen belehelyezett. Ha tetszik, az elosztott rendszerek tervezéséről egy speciálisabb szöveget adunk ki.
Pillanatkép az Unsplash-től
Ha még soha nem kellett olyan kihívásokkal szembesülnie, mint egy szoftverrendszer tervezése a semmiből, akkor az ilyen munka megkezdésekor néha még az sem világos, hogy hol is kezdje. Úgy gondolom, hogy először meg kell húzni a határokat, hogy többé-kevésbé magabiztos elképzelésed legyen arról, hogy mit is fogsz pontosan tervezni, majd feltűröd az ingujjat, és a határokon belül kell dolgozni. Kiindulási pontként vehet egy terméket vagy szolgáltatást (ideális esetben olyat, amelyik nagyon tetszik), és kitalálja, hogyan valósítsa meg. Lehet, hogy meg fog lepődni, hogy milyen egyszerűnek tűnik ez a termék, és mennyi összetettséget tartalmaz valójában. Ne felejtsd el: , és ez rendben van.
Azt hiszem, a legjobb tanács, amit mindenkinek adhatok, aki elkezdi a rendszer tervezését, a következő: ne tételezzen! Már a kezdet kezdetén meg kell határoznia a rendszerről ismert tényeket és a vele kapcsolatos elvárásokat. Íme néhány jó kérdés, amelyek segíthetnek a tervezés megkezdésében:
- Mi az a probléma, amit megpróbálunk megoldani?
- Mennyi a rendszerünkkel interakcióba lépő felhasználók csúcsszáma?
- Milyen írási és adatolvasási mintákat fogunk használni?
- Melyek a várható kudarcok, hogyan fogjuk kezelni ezeket?
- Mik az elvárások a rendszer konzisztenciájával és elérhetőségével kapcsolatban?
- A munkavégzés során figyelembe kell vennie a külső ellenőrzéssel, szabályozással kapcsolatos követelményeket?
- Milyen típusú érzékeny adatokat fogunk tárolni?
Ez csak néhány kérdés, amelyek hasznosak voltak számomra és azoknak a csapatoknak is, amelyekben részt vettem a szakmai tevékenységem során. Ha ismeri a választ ezekre a kérdésekre (és minden olyan kérdésre, amely releváns a munkakörnyezet szempontjából), akkor fokozatosan elmélyülhet a probléma technikai részleteiben.
Állítsa be a kezdeti szintet
Mit értek itt „alapállapot” alatt? Valójában napjainkban a szoftveripar legtöbb problémája „megoldható” a meglévő módszerekkel és technológiákkal. Ennek megfelelően ezen a tájon navigálva bizonyos előnyhöz jut, amikor olyan problémákkal szembesül, amelyeket valaki másnak kellett megoldania előtte. Ne felejtsük el, hogy a programok üzleti és felhasználói problémák megoldására készültek, ezért arra törekszünk, hogy a problémát a lehető legegyszerűbb és legegyszerűbb módon (felhasználói szempontból) oldjuk meg. Miért fontos ezt emlékezni? Talán a koordinátarendszerében szeret egyedi megoldásokat keresni minden problémára, mert azt gondolja, „miféle programozó vagyok én, ha mindenhol mintákat követek”? Valójában, a művészet itt dönt arról, hogy hol és mit tegyen. Természetesen mindannyiunknak időről időre meg kell küzdenie egyedi problémákkal, amelyek mindegyike igazi kihívást jelent. Ha azonban a kezdeti szintünk egyértelműen meghatározott, akkor tudjuk, hogy mire fordítjuk az energiánkat: kész lehetőségek felkutatására az előttünk álló probléma megoldására, vagy továbbtanulmányozására és mélyebb megértésére.
Azt hiszem, sikerült meggyőznöm, hogy ha egy szakember magabiztosan érti, mi az építészeti összetevője néhány csodálatos szoftverrendszernek, akkor ez a tudás nélkülözhetetlen lesz az építész művészetének elsajátításához, és szilárd alapok kialakításához ezen a területen.
Oké, akkor hol kezdjem? U Van egy adattár a GitHubon, melynek neve , amelyből elsajátíthatod a nagyméretű rendszerek tervezését, valamint interjúkra készülhetsz ebben a témában. Az adattárnak van egy szakasza példákkal , ahol különösen azt veszik figyelembe, hogy hogyan viszonyulnak rendszereik kialakításához pl Twitter, Uber stb.
Mielőtt azonban rátérnénk erre az anyagra, nézzük meg közelebbről a legfontosabb építészeti kihívásokat, amelyekkel a gyakorlatban szembesülünk. Ez azért fontos, mert egy makacs és sokrétű probléma SOK szempontját kell meghatározni, majd az adott rendszerben hatályos szabályozás keretei között megoldani. , a Facebook egykori alkalmazottja – írta , ahol több száz jelentkező átvilágításáról osztotta meg saját tapasztalatait. Noha a videó nagy hangsúlyt fektet a nagy rendszerek tervezésére és azokra a sikerkritériumokra, amelyek fontosak egy ilyen pozícióra jelölt személy keresésekor, mégis átfogó forrásként szolgál majd arról, hogy melyek a legfontosabbak a rendszerek tervezése során. azt is javaslom ez a videó.
Gyűjtsön ismereteket az adatok tárolásáról és visszakereséséről
Általában az adatok hosszú távú tárolására és lekérésére vonatkozó döntése kritikus hatással van a rendszer teljesítményére. Ezért először meg kell értenie a rendszer elvárt írási és olvasási jellemzőit. Ezután képesnek kell lennie arra, hogy értékelje ezeket a mutatókat, és az elvégzett értékelések alapján döntsön. Ezzel a munkával azonban csak akkor tud hatékonyan megbirkózni, ha ismeri a meglévő adattárolási mintákat. Ez elvileg szilárd tudást jelent a kapcsolódó .
Az adatbázisok rendkívül méretezhető és tartós adatstruktúráknak tekinthetők. Ezért az adatstruktúrák ismerete nagyon hasznos lehet egy adott adatbázis kiválasztásakor. Például, egy adatszerkezet-kiszolgáló, amely különféle típusú értékeket támogat. Lehetővé teszi adatstruktúrákkal, például listákkal és halmazokkal való munkát, és adatok olvasását jól ismert algoritmusok segítségével, például, , az ilyen jellegű munkák megszervezése tartós és könnyen hozzáférhető stílusban.
Pillanatkép az Unsplash-től
Miután kellőképpen megértette a különböző adattárolási mintákat, folytassa az adatok konzisztenciájának és elérhetőségének tanulmányozásával. Először is meg kell értened legalábbis általánosságban, majd ezt a tudást a kialakult minták alaposabb vizsgálatával csiszoljuk и . Így megértheti a területet, és megértheti, hogy az adatok olvasása és írása valójában két nagyon különböző probléma, mindegyiknek megvan a maga egyedi kihívása. Néhány konzisztencia- és rendelkezésre állási mintával felvértezve jelentősen növelheti a rendszer teljesítményét, miközben zökkenőmentes adatáramlást biztosít az alkalmazások felé.
Végezetül, az adattárolási problémákról szóló beszélgetést lezárva, meg kell említenünk a gyorsítótárazást is. Egyszerre kell futnia a kliensen és a szerveren? Milyen adatok lesznek a gyorsítótárban? És miért? Hogyan szervezi meg a gyorsítótár érvénytelenítését? Rendszeresen, bizonyos időközönként meg fog tenni? Ha igen, milyen gyakran? Javaslom, hogy kezdje el ezzel a témakörrel tanulni a fent említett rendszertervező alapozó.
Kommunikációs minták
A rendszerek különböző összetevőkből állnak; ezek lehetnek különböző folyamatok, amelyek ugyanazon a fizikai csomóponton belül futnak, vagy különböző gépek, amelyek a hálózat különböző részein futnak. A hálózaton belül ezeknek az erőforrásoknak egy része privát lehet, de másoknak nyilvánosnak kell lenniük, és nyitottnak kell lenniük a kívülről hozzáférő fogyasztók számára.
Biztosítani kell ezen erőforrások egymás közötti kommunikációját, valamint az egész rendszer és a külvilág közötti információcserét. A rendszertervezés kapcsán itt is egy sor új és egyedi kihívással kell szembenéznünk. Lássuk, hogyan lehetnek hasznosak , és mit p.
Pillanatkép az Unsplash-től
A külvilággal való kommunikáció megszervezésénél mindig nagyon fontos , amelynek biztosítását szintén komolyan kell venni és aktívan kell folytatni.
Csatlakozás elosztása
Nem vagyok benne biztos, hogy ennek a témának egy külön szakaszba helyezése mindenki számára indokoltnak tűnik. Ennek ellenére itt részletesen bemutatom ezt a fogalmat, és úgy gondolom, hogy az ebben a részben található anyagot a „kapcsolatelosztás” kifejezés írja le a legpontosabban.
A rendszereket számos komponens megfelelő összekapcsolásával alakítják ki, és kommunikációjuk egymással gyakran meghatározott protokollok, például TCP és UDP alapján szerveződik. Ezek a protokollok azonban önmagukban gyakran nem elegendőek a modern rendszerek minden igényének kielégítésére, amelyek gyakran nagy terhelés mellett működnek, és nagymértékben függenek a felhasználói igényektől. Gyakran meg kell találni a kapcsolatok elosztásának módját, hogy megbirkózzon a rendszer ilyen nagy terheléseivel.
Ez az elosztás a jól ismert (DNS). Egy ilyen rendszer lehetővé teszi a tartománynév-átalakításokat, például a súlyozott körmérést és a késleltetésen alapuló módszereket a terhelés elosztása érdekében.
alapvetően fontos, és gyakorlatilag minden nagy internetes rendszer, amellyel ma foglalkozunk, egy vagy több terheléselosztó mögött található. A terheléselosztók segítenek elosztani az ügyfélkérelmeket több rendelkezésre álló példány között. A terheléselosztók hardveres és szoftveres változatban is érkeznek, azonban a gyakorlatban gyakrabban kell számolni szoftveresekkel, pl. и . fogalmilag is nagyon hasonlít a terheléselosztókhoz, bár van egy tartomány az első és a második között . Ezeket a különbségeket figyelembe kell venni, amikor egy rendszert az Ön igényei alapján tervezünk.
Tudnia kell arról is (CDN). A CDN a proxykiszolgálók globális elosztott hálózata, amely információkat szolgáltat olyan csomópontokról, amelyek földrajzilag közelebb vannak egy adott felhasználóhoz. A CDN-ek használata előnyösebb, ha JavaScript, CSS és HTML nyelven írt statikus fájlokkal dolgozik. Emellett ma már elterjedtek a forgalomkezelőket biztosító felhőszolgáltatások, pl. , amely globális terjesztést és csökkentett késleltetést biztosít, amikor dinamikus tartalommal dolgozik. Az ilyen szolgáltatások azonban általában olyan esetekben hasznosak, amikor állapot nélküli webszolgáltatásokkal kell dolgozni.
Beszéljünk az üzleti logikáról. Üzleti logika, feladatfolyamatok és összetevők strukturálása
Így sikerült megvitatni a rendszer különféle infrastrukturális vonatkozásait. Valószínűleg a felhasználó nem is gondol a rendszer összes ilyen elemére, és őszintén szólva egyáltalán nem törődik velük. A felhasználót érdekli, hogy milyen interakció a rendszerével, mit lehet ezzel elérni, és az is, hogy a rendszer hogyan hajtja végre a felhasználói parancsokat, mit és hogyan tesz a felhasználói adatokkal.
Ahogy a cikk címe is sugallja, a szoftverarchitektúráról és a rendszertervezésről akartam beszélni. Ennek megfelelően nem terveztem lefedni azokat a szoftvertervezési mintákat, amelyek leírják a szoftverkomponensek létrehozását. Azonban minél többet gondolok rá, annál inkább úgy tűnik számomra, hogy a szoftvertervezési minták és az építészeti minták közötti határ nagyon elmosódott, és a két fogalom szorosan összefügg. Vegyük például (esemény beszerzése). Ha egyszer elfogadja ezt az építészeti mintát, az a rendszer szinte minden aspektusára hatással lesz: az adatok hosszú távú tárolására, a rendszerben alkalmazott konzisztencia szintjére, a benne lévő komponensek alakjára stb. stb. Ezért úgy döntöttem, hogy megemlítek néhány olyan építészeti mintát, amelyek közvetlenül kapcsolódnak az üzleti logikához. Annak ellenére, hogy ennek a cikknek egy egyszerű listára kell korlátozódnia, arra biztatlak, hogy ismerkedjen meg vele, és gondolja át az ezekkel a mintákkal kapcsolatos ötleteket. Tessék:
- Fogalmak , különösen, ,
Együttműködésen alapuló megközelítések
Rendkívül valószínűtlen, hogy olyan résztvevőként találja magát egy projektben, aki kizárólagosan felelős a rendszertervezési folyamatért. Éppen ellenkezőleg, valószínűleg kapcsolatba kell lépnie a feladatán belül és kívül dolgozó kollégákkal. Ebben az esetben előfordulhat, hogy kollégáival együtt értékelnie kell a kiválasztott technológiai megoldásokat, azonosítania kell az üzleti igényeket, és meg kell értenie, hogyan lehet a legjobban párhuzamosítani a feladatokat.
Pillanatkép az Unsplash-től
Az első lépés az, hogy pontosan és közösen megértsük, mi az elérni kívánt üzleti cél, és milyen mozgó alkatrészekkel kell megküzdenie. Csoportmodellezési technikák, különösen (eseményvihar) segít jelentősen felgyorsítani ezt a folyamatot és növelni a siker esélyeit. Ezt a munkát el lehet végezni a vázolás előtt vagy után , majd a termék érésekor mélyítse el. Az itt elért következetesség szintje alapján is fogalmazhat abban a korlátozott környezetben, amelyben dolgozik. Ha rendszere architektúrájáról kell beszélnie, hasznos lehet , javasolta , különösen akkor, ha meg kell értened, mennyit kell belemenned a probléma részleteibe, vizualizálva a közölni kívánt dolgokat.
Valószínűleg van egy másik kiforrott technológia ebben a témában, amely nem kevésbé hasznos, mint a Domain Driven Design. Valahogy azonban visszatérünk a tárgykör megértéséhez, tehát az adott területen szerzett tudáshoz és tapasztalathoz hasznosnak kell lennie az Ön számára.
Forrás: will.com