Сәлем әріптестер.
Бүгін біз сіздердің назарларыңызға қазіргі заманғы бағдарламалық жүйелерді жобалау принциптерін салыстырмалы түрде шағын көлемде сипаттауға міндеттенген Тугберк Угурлу мақаласының аудармасын ұсынамыз. Автордың өзі туралы қысқаша айтқанда:
2019 жылдан бастап хабро мақаласында архитектуралық үлгілер + дизайн үлгілері сияқты орасан зор тақырыпты қамту мүмкін емес болғандықтан, біз Уруглу мырзаның мәтінін ғана емес, сонымен бірге ол оған мейірімділікпен қосқан көптеген сілтемелерді де ұсынамыз. Егер сізге ұнаса, біз бөлінген жүйелердің дизайны туралы жоғарырақ мамандандырылған мәтінді жариялаймыз.
Сурет Unsplash сайтынан
Егер сіз бағдарламалық жасақтаманы нөлден бастап жобалау сияқты қиындықтарға кезікпесеңіз, онда мұндай жұмысты бастаған кезде кейде неден бастау керектігі белгісіз. Менің ойымша, сіз дәл нені жобалағыңыз келетіні туралы азды-көпті сенімді түсінікке ие болу үшін алдымен шекараларды сызып алуыңыз керек, содан кейін жеңдеріңізді жинап, сол шекараларда жұмыс жасаңыз. Бастапқы нүкте ретінде сіз өнімді немесе қызметті (ең дұрысы сізге ұнайтын) алып, оны қалай жүзеге асыру керектігін анықтай аласыз. Сіз бұл өнімнің қаншалықты қарапайым көрінетініне және оның қаншалықты күрделі екеніне таң қалуыңыз мүмкін. Ұмытпаңыз: , және бұл жақсы.
Менің ойымша, жүйені жобалауды бастаған кез келген адамға бере алатын ең жақсы кеңес мынау: ешқандай болжам жасамаңыз! Ең басынан бастап сіз осы жүйе туралы белгілі фактілерді және онымен байланысты күтулерді көрсетуіңіз керек. Дизайныңызды бастауға көмектесетін бірнеше жақсы сұрақтар:
- Біз шешуге тырысып жатқан мәселе қандай?
- Біздің жүйемен өзара әрекеттесетін пайдаланушылардың ең жоғары саны қандай?
- Деректерді жазудың және оқудың қандай үлгілерін қолданамыз?
- Күтілетін сәтсіздік жағдайлары қандай, біз оларды қалай шешеміз?
- Жүйенің тұрақтылығы мен қолжетімділігіне қандай үміттер бар?
- Жұмыс кезінде сыртқы тексеру мен реттеуге қатысты қандай да бір талаптарды ескеру керек пе?
- Біз құпия деректердің қандай түрлерін сақтаймыз?
Бұл маған да, мен қатысқан командалар үшін де пайдалы болған бірнеше сұрақтар ғана. Егер сіз осы сұрақтарға жауаптарды білсеңіз (және сіз жұмыс істеу керек контекстке қатысты кез келген басқа), онда сіз біртіндеп мәселенің техникалық мәліметтерін зерттей аласыз.
Бастапқы деңгейді орнатыңыз
Бұл жерде «базалық» дегенді қалай түсінемін? Шын мәнінде, біздің заманымызда бағдарламалық қамтамасыз ету индустриясындағы көптеген мәселелер қолданыстағы әдістер мен технологияларды қолдана отырып «шешу мүмкін». Тиісінше, осы ландшафтты шарлау арқылы сіз басқа біреу сізден бұрын шешуі керек мәселелерге тап болған кезде белгілі бір бастама аласыз. Бағдарламалар бизнес пен пайдаланушының мәселелерін шешу үшін жазылғанын ұмытпаңыз, сондықтан біз мәселені ең қарапайым және қарапайым (пайдаланушы көзқарасы бойынша) шешуге тырысамыз. Неліктен мұны есте сақтау маңызды? Мүмкін сіз өзіңіздің координаттар жүйеңізде барлық мәселелердің бірегей шешімдерін іздегенді ұнататын шығарсыз, өйткені сіз «барлық жерде үлгілерді ұстанатын болсам, мен қандай бағдарламашы боламын» деп ойлайсыз? Ақиқатында, Мұндағы өнер қайда және не істеу керектігі туралы шешім қабылдайды. Әрине, әрқайсымыз мезгіл-мезгіл қайталанбас проблемалармен айналысамыз, олардың әрқайсысы нағыз сынақ. Дегенмен, егер біздің бастапқы деңгейіміз нақты анықталған болса, онда біз өз күшімізді не үшін жұмсау керектігін білеміз: алдымызға қойылған мәселені шешудің дайын нұсқаларын іздеу немесе оны одан әрі зерттеп, тереңірек түсіну.
Менің ойымша, егер маман кейбір тамаша бағдарламалық жүйелердің архитектуралық құрамдас бөлігінің не екенін сенімді түрде түсінетін болса, онда бұл білім сәулетші өнерін меңгеру және осы салада берік негізді дамыту үшін қажет болатынына сендіре алдым деп ойлаймын.
Жарайды, неден бастау керек? У GitHub-да репозиторий деп аталатын репозиторий бар , одан сіз ауқымды жүйелерді жобалауды үйренуге, сондай-ақ осы тақырып бойынша сұхбатқа дайындалуға болады. Репозиторийде мысалдар бар бөлім бар , мұнда, атап айтқанда, олардың жүйелерін жобалауға қалай қарайтыны қарастырылады мысалы, Twitter, Uber және т.б.
Дегенмен, осы материалға көшпес бұрын, тәжірибеде кездесетін ең маңызды архитектуралық қиындықтарды егжей-тегжейлі қарастырайық. Бұл өте маңызды, өйткені сіз қыңыр және көп қырлы мәселенің КӨПТЕГІ аспектілерін көрсетуіңіз керек, содан кейін оны белгілі бір жүйеде әрекет ететін ережелер аясында шешуіңіз керек. , деп жазды Facebook-тің бұрынғы қызметкері , онда ол жүздеген үміткерлерді скринингтен өткізу тәжірибесімен бөлісті. Бейне үлкен жүйе дизайнына және осындай лауазымға үміткерді іздеуде маңызды болатын сәттілік критерийлеріне көп көңіл бөлгенімен, ол әлі де жүйелерді жобалау кезінде ең маңызды нәрселер туралы жан-жақты ресурс ретінде қызмет етеді. Мен де ұсынамын бұл бейне.
Деректерді сақтау және алу туралы білімдерін қалыптастыру
Әдетте, ұзақ мерзімді перспективада деректеріңізді қалай сақтау және алу туралы шешіміңіз жүйе өнімділігіне маңызды әсер етеді. Сондықтан алдымен жүйеңіздің күтілетін жазу және оқу сипаттамаларын түсінуіңіз керек. Содан кейін осы көрсеткіштерді бағалай білу және жасалған бағалаулар негізінде таңдау жасау керек. Дегенмен, бар деректерді сақтау үлгілерін түсінсеңіз ғана бұл жұмысты тиімді жеңе аласыз. Негізінде, бұл байланысты берік білімді білдіреді .
Дерекқорларды өте масштабталатын және ұзақ мерзімді деректер құрылымдары ретінде қарастыруға болады. Сондықтан белгілі бір дерекқорды таңдаған кезде деректер құрылымдарын білу сізге өте пайдалы болуы керек. Мысалы, мәндердің әртүрлі түрлерін қолдайтын деректер құрылымы сервері болып табылады. Ол тізімдер мен жиындар сияқты деректер құрылымдарымен жұмыс істеуге және белгілі алгоритмдерді пайдаланып деректерді оқуға мүмкіндік береді, мысалы, , мұндай жұмысты берік және жоғары қолжетімді стильде ұйымдастыру.
Сурет Unsplash сайтынан
Әртүрлі деректерді сақтау үлгілері туралы жеткілікті түсінігіңіз болған соң, деректердің сәйкестігі мен қолжетімділігін зерттеуге көшіңіз. Ең алдымен, сіз түсінуіңіз керек кем дегенде жалпы мағынада, содан кейін қалыптасқан үлгілерге мұқият қарау арқылы бұл білімді жылтыратыңыз и . Осылайша, сіз осы сала туралы түсінікті дамытасыз және деректерді оқу мен жазу шын мәнінде әрқайсысының өзіндік ерекше қиындықтары бар екі түрлі мәселе екенін түсінесіз. Бірнеше реттілік пен қол жетімділік үлгілерімен қаруланған сіз қолданбаларға біркелкі деректер ағынын қамтамасыз ете отырып, жүйе өнімділігін айтарлықтай арттыра аласыз.
Ақырында, деректерді сақтау мәселелері туралы әңгімені аяқтай отырып, кэштеуді де атап өткен жөн. Ол клиент пен серверде бір уақытта жұмыс істеуі керек пе? Сіздің кэшіңізде қандай деректер болады? Неліктен? Кэшті жарамсыздандыруды қалай ұйымдастырасыз? Ол жүйелі түрде, белгілі бір аралықтармен орындала ма? Егер иә болса, қаншалықты жиі? Мен осы тақырыптарды зерттеуді бастауды ұсынамын жоғарыда аталған жүйені жобалау праймері.
Коммуникация үлгілері
Жүйелер әртүрлі құрамдас бөліктерден тұрады; бұл бір физикалық түйінде жұмыс істейтін әртүрлі процестер немесе желіңіздің әртүрлі бөліктерінде жұмыс істейтін әртүрлі машиналар болуы мүмкін. Желідегі осы ресурстардың кейбірі жеке болуы мүмкін, бірақ басқалары жалпыға қолжетімді және оларға сырттан қол жеткізетін тұтынушылар үшін ашық болуы керек.
Бұл ресурстардың бір-бірімен байланысын, сондай-ақ бүкіл жүйе мен сыртқы әлем арасында ақпарат алмасуды қамтамасыз ету қажет. Жүйелерді жобалау контекстінде біз тағы да жаңа және бірегей қиындықтарға тап болдық. Олардың қалай пайдалы болуы мүмкін екенін көрейік , және не б.
Сурет Unsplash сайтынан
Сыртқы әлеммен қарым-қатынасты ұйымдастыру кезінде ол әрқашан өте маңызды , оны қамтамасыз ету де байыпты және белсенді түрде жүргізілуі керек.
Қосылымды тарату
Бұл тақырыпты бөлек бөлімге қою бәріне орынды болып көрінетініне сенімді емеспін. Дегенмен, мен бұл тұжырымдаманы осы жерде егжей-тегжейлі ұсынамын және бұл бөлімдегі материал «байланысты тарату» терминімен ең дәл сипатталған деп ойлаймын.
Жүйелер көптеген компоненттерді дұрыс қосу арқылы қалыптасады және олардың бір-бірімен байланысы көбінесе белгіленген хаттамалар негізінде ұйымдастырылады, мысалы, TCP және UDP. Дегенмен, бұл хаттамалар көбінесе жоғары жүктемеде жұмыс істейтін және пайдаланушы қажеттіліктеріне өте тәуелді болатын заманауи жүйелердің барлық қажеттіліктерін қанағаттандыру үшін жиі жеткіліксіз. Жүйедегі осындай жоғары жүктемелерге төтеп беру үшін қосылымдарды тарату жолдарын жиі табу қажет.
Бұл үлестірім жалпыға мәлім (DNS). Мұндай жүйе жүктемені бөлуге көмектесу үшін салмақты айналым және кешігуге негізделген әдістер сияқты домен атауын түрлендіруге мүмкіндік береді.
түбегейлі маңызды болып табылады және біз бүгін айналысатын әрбір үлкен Интернет жүйесі бір немесе бірнеше жүктеме балансының артында орналасқан. Жүктемені теңестірушілер клиент сұрауларын бірнеше қолжетімді даналар бойынша таратуға көмектеседі. Жүктеме теңестіргіштері аппараттық құралда да, бағдарламалық жасақтамада да келеді, бірақ іс жүзінде сіз көбінесе бағдарламалық жасақтамамен айналысуға тура келеді, мысалы и . концептуалды түрде жүк теңестіргіштерге өте ұқсас, дегенмен бірінші және екінші арасында диапазон бар . Бұл айырмашылықтар сіздің қажеттіліктеріңізге негізделген жүйені жобалау кезінде ескерілуі керек.
туралы да білу керек (CDN). CDN - белгілі бір пайдаланушыға географиялық жақын орналасқан түйіндерден ақпаратты жеткізетін прокси серверлердің ғаламдық бөлінген желісі. JavaScript, CSS және HTML тілдерінде жазылған статикалық файлдармен жұмыс істесеңіз, CDNs пайдаланған жөн. Сонымен қатар, бүгінде трафик менеджерлерін қамтамасыз ететін бұлттық қызметтер кең таралған, мысалы, , сізге жаһандық таратуды және динамикалық мазмұнмен жұмыс істегенде кідіртуді азайтады. Дегенмен, мұндай қызметтер әдетте азаматтығы жоқ веб-қызметтермен жұмыс істеуге тура келетін жағдайларда пайдалы.
Іскерлік логика туралы сөйлесейік. Бизнес логикасын, тапсырмалар ағындарын және құрамдастарын құрылымдау
Осылайша, біз жүйенің әртүрлі инфрақұрылымдық аспектілерін талқылай алдық. Сірә, пайдаланушы сіздің жүйеңіздің барлық осы элементтері туралы ойламайды және, шынын айтқанда, олар туралы мүлдем ойламайды. Пайдаланушы сіздің жүйеңізбен өзара әрекеттесу дегенді, мұны істеу арқылы не алуға болатынын, сондай-ақ жүйенің пайдаланушы командаларын қалай орындайтынын, пайдаланушы деректерімен не және қалай істейтінін қызықтырады.
Осы мақаланың тақырыбы айтып тұрғандай, мен бағдарламалық жасақтаманың архитектурасы мен жүйе дизайны туралы айтқым келді. Тиісінше, мен бағдарламалық құрал құрамдастарының жасалу жолын сипаттайтын бағдарламалық жасақтаманы жобалау үлгілерін қамтуды жоспарлаған жоқпын. Дегенмен, мен бұл туралы көбірек ойлаған сайын, маған бағдарламалық жасақтаманың дизайн үлгілері мен архитектуралық үлгілердің арасындағы сызық өте бұлыңғыр және екі ұғым бір-бірімен тығыз байланысты болып көрінеді. Мысалға алайық (оқиға көзі). Осы архитектуралық үлгіні қабылдағаннан кейін ол сіздің жүйеңіздің барлық дерлік аспектілеріне әсер етеді: деректерді ұзақ мерзімді сақтау, жүйеңізде қабылданған консистенциясы деңгейі, ондағы құрамдастардың пішіні және т.б.. Сондықтан мен бизнес логикасына тікелей қатысты кейбір архитектуралық үлгілерді атап өтуді жөн көрдім. Бұл мақала қарапайым тізіммен шектелуі керек болса да, мен сізді онымен танысуға және осы үлгілерге байланысты идеялар туралы ойлануға шақырамын. Міне, ұстаңыз:
- Тұжырымдамалар , сондай-ақ, ,
Ынтымақтастық тәсілдер
Жүйені жобалау процесіне жалғыз жауапты қатысушы ретінде жобада өзіңізді табуыңыз екіталай. Керісінше, сіздің тапсырмаңыздың ішінде де, сыртында да жұмыс істейтін әріптестеріңізбен араласуға тура келеді. Бұл жағдайда таңдалған технологиялық шешімдерді әріптестермен бірге бағалау, бизнес қажеттіліктерін анықтау және тапсырмаларды қалай параллельдеуге болатынын түсіну қажет болуы мүмкін.
Сурет Unsplash сайтынан
Бірінші қадам - сіз қол жеткізгіңіз келетін іскерлік мақсаттың не екенін және қандай қозғалмалы бөліктермен күресуге тура келетінін нақты және ортақ түсінуді дамыту. Топтық модельдеу әдістері, атап айтқанда (оқиға штурмингі) бұл процесті айтарлықтай жылдамдатуға және табысқа жету мүмкіндігін арттыруға көмектеседі. Бұл жұмысты сызбаға дейін немесе кейін орындауға болады , содан кейін өнім пісіп жатқанда оны тереңдетіңіз. Мұнда қол жеткізілетін жүйелілік деңгейіне сүйене отырып, сіз де тұжырымдай аласыз сіз жұмыс істейтін шектеулі контекст үшін. Жүйенің архитектурасы туралы айту қажет болғанда, оны пайдалы деп таба аласыз , ұсынылды , әсіресе сіз сөйлескіңіз келетін нәрселерді визуализациялау арқылы мәселенің егжей-тегжейіне қаншалықты кірісу керектігін түсінуіңіз керек болғанда.
Бұл тақырыпта доменге негізделген дизайннан кем емес пайдалы тағы бір жетілген технология болуы мүмкін. Дегенмен, біз қандай да бір жолмен пәндік аймақты түсінуге ораламыз, сондықтан осы саладағы білім мен тәжірибе сізге пайдалы болуы керек.
Ақпарат көзі: www.habr.com