Бағдарламалық жүйелерді жобалау кезінде күрделілікпен қалай күресуге болады

Мұның бәрі не туралы?

Инженерлік мансап барысында біз күн сайын, әр сәт сайын әртүрлі күрделіліктегі және шешім қабылдауға немесе деректердің болмауына байланысты оны кейінге қалдыруға тура келетін жағдайларға тап боламыз. Біз жаңа қызметтерді салғанда, инфрақұрылымды салғанда немесе тіпті даму процестерін қалыптастырған кезде біз әртүрлі қиындықтардың үлкен әлеміне қол жеткіземіз.

Барлық мәселелерді тізіп шығу қиын, мүмкін, мүмкін емес. Сіз белгілі бір тауашада жұмыс істегенде ғана осы мәселелердің кейбіріне тап боласыз. Екінші жағынан, қалай шешуге болатынын бәріміз түсінуіміз керек көп нәрсе бар, өйткені олар АТ жүйелерін құру үшін өте маңызды. Жоғары ықтималдықпен сіз оларды барлық жобаларда кездестіресіз.

Бұл мақалада мен бағдарламалық жасақтамаларды жасау кезінде кездесетін кейбір мәселелер бойынша тәжірибеммен бөлісемін.

Кросс-кесу туралы алаңдаушылық дегеніміз не?

Википедияға қарасақ, келесі анықтаманы табамыз

Аспектілі бағдарланған бағдарламалық жасақтаманы әзірлеуде қиылысатын мәселелер бірнеше модульдерге әсер ететін, олардың ешқайсысында инкапсуляциялану мүмкіндігінсіз бағдарламаның аспектілері болып табылады. Бұл алаңдаушылықтарды жобалау кезінде де, іске асыруда да жүйенің қалған бөлігінен таза түрде ажыратуға болмайды және шашырауға (кодтың қайталануы), шатасуға (жүйелер арасындағы маңызды тәуелділіктер) немесе екеуіне де әкелуі мүмкін.

Бұл оның не екенін жақсы сипаттайды, бірақ мен оны біршама кеңейтіп, жеңілдеткім келеді:

Толық алаңдаушылық - бұл жүйенің/ұйымның көптеген басқа бөліктеріне әсер ететін (немесе «кесіп өтетін») тұжырымдамасы немесе құрамдас бөлігі.

Мұндай алаңдаушылықтардың ең жақсы мысалдары - жүйе архитектурасы, журнал жүргізу, қауіпсіздік, транзакцияларды басқару, телеметрия, дерекқорды жобалау және басқалары. Біз олардың көпшілігіне кейінірек осы мақалада толығырақ тоқталамыз.

Код деңгейінде қиылысатын мәселелер жиі Аспект-бағдарланған бағдарламалау (AOP) сияқты әдістер арқылы жүзеге асырылады, мұнда бұл алаңдаушылықтар барлық қолданбада қолданылуы мүмкін бөлек құрамдастарға модульденеді. Бұл бизнес логикасын осы алаңдаушылықтардан оқшаулап, кодты оқуға және қолдауға мүмкіндік береді.

Аспектінің классификациясы

Аспекттерді әртүрлі сипаттармен сегменттеу арқылы олардың ауқымы, өлшемі, функционалдығы, маңыздылығы, мақсаттылығы және басқалары арқылы жіктеудің көптеген мүмкін жолдары бар, бірақ бұл мақалада мен қарапайым ауқым классификациясын қолданатын боламын. Бұл арқылы мен бұл нақты аспект қайда бағытталғанын айтқым келеді, мейлі ол бүкіл ұйым болсын, белгілі бір жүйе немесе сол жүйенің белгілі бір элементі болсын.

Сонымен, мен аспектілерді Макро және Микро деп бөлемін.

Макро аспектіде мен негізінен таңдалған жүйе архитектурасы және оның дизайны (монолиттік, микросервистер, қызмет көрсетуге бағытталған архитектура), технология стекі, ұйым құрылымы және т.б. сияқты бүкіл жүйеге қатысты ескерілетін ойларды айтамын. Макро аспектілер негізінен стратегиялық және жоғары деңгейге қатысты. шешімдер.

Бұл арада микро аспект код деңгейіне және әзірлеуге әлдеқайда жақын. Мысалы, дерекқормен, қалталар мен сыныптардың жоба құрылымымен немесе тіпті нақты нысанды жобалау үлгілерімен өзара әрекеттесу үшін қандай құрылым пайдаланылады.

Бұл классификация идеалды болмаса да, мүмкін болатын проблемаларды және біз оларға қолданатын шешімдердің маңыздылығы мен әсерін түсінуді құрылымдауға көмектеседі.

Бұл мақалада менің басты назарым макро аспектілерге арналады.

Макро аспектілер

Ұйымдастыру құрылымы

Мен бағдарламалық жасақтаманың архитектурасы туралы жаңа ғана біле бастағанда мен Конвей заңы және оның ұйымдық құрылымға әсері туралы көптеген қызықты мақалаларды оқыдым. Әсіресе мынау . Демек, бұл заңда солай айтылған

Жүйені жобалайтын кез келген ұйым (кеңінен анықталған) құрылымы ұйымның коммуникациялық құрылымының көшірмесі болып табылатын дизайнды шығарады.

Мен бұл тұжырымдама шынымен де әмбебап және Алтын ережені білдіреді деп әрқашан сендім.

Содан кейін мен Эрик Эванстың жүйелерді модельдеу үшін Доменге негізделген дизайн (DDD) әдісін үйрене бастадым. Эрик Эванс Шектелген контекстті анықтаудың маңыздылығын атап көрсетеді. Бұл тұжырымдама күрделі домендік модельді әрқайсысының өзінің шектеулі білім жиынтығы бар кішірек, басқарылатын бөлімдерге бөлуді қамтиды. Бұл тәсіл тиімді топтық қарым-қатынасқа көмектеседі, өйткені ол бүкіл домен туралы кең білімге деген қажеттілікті азайтады және контекстті ауыстыруды азайтады, осылайша сөйлесуді тиімдірек етеді. Мәтінмәнді ауыстыру - ең нашар және ең көп ресурстарды қажет ететін нәрсе. Тіпті компьютерлер де онымен күресуде. Мәтінмәндік ауысудың толық болмауына қол жеткізу екіталай болса да, мен осыған ұмтылуымыз керек деп ойлаймын.

Конвей заңына оралсақ, мен онымен бірнеше мәселені таптым.

Жүйе дизайны ұйымдық құрылымды көрсететінін көрсететін Конуэй заңымен кездескен бірінші мәселе - күрделі және жан-жақты Шектелген контексттерді қалыптастыру әлеуеті. Бұл күрделілік ұйымдық құрылым домен шекараларымен сәйкес келмегенде туындайды, бұл өзара қатты тәуелді және ақпаратпен жүктелген Шектелген мәтінмәндерге әкеледі. Бұл әзірлеу тобы үшін жиі контекстті ауыстыруға әкеледі.

Тағы бір мәселе - ұйымдық терминология код деңгейіне дейін ағып кетеді. Ұйымдық құрылымдар өзгерген кезде ол құнды ресурстарды тұтына отырып, кодтық базаны өзгертуді қажет етеді.

Осылайша, Inverse Conway Maneuver қолданбасы қалаған бағдарламалық жасақтама архитектурасын ынталандыратын жүйе мен ұйымды құруға көмектеседі. Дегенмен, бұл тәсіл бұрыннан қалыптасқан архитектура мен құрылымдарда жақсы жұмыс істемейтінін айта кету керек, өйткені бұл кезеңдегі өзгерістер ұзаққа созылады, бірақ ол стартаптарда ерекше нәтиже береді, өйткені олар кез келген өзгерістерді тез енгізеді.

Үлкен балшық шары

Бұл үлгі немесе «анти-үлгі» ешқандай архитектурасы жоқ жүйені құруға көмектеседі. Ешқандай ережелер, шекаралар және сөзсіз өсіп келе жатқан күрделілікті қалай басқаруға болатын стратегия жоқ. Күрделілік бағдарламалық қамтамасыз ету жүйесін құру жолындағы ең қорқынышты жау болып табылады.

Жүйенің мұндай түрін құруды болдырмау үшін біз нақты ережелер мен шектеулерді сақтауымыз керек.

Жүйе архитектурасы

Бағдарламалық жасақтама архитектурасына сансыз анықтамалар бар. Маған олардың көпшілігі ұнайды, өйткені олар әртүрлі аспектілерді қамтиды. Дегенмен, сәулет туралы пайымдай алу үшін, әрине, олардың кейбірін санамызда қалыптастыруымыз керек. Бұл анықтаманың дамуы мүмкін екенін айта кеткен жөн. Сондықтан, кем дегенде, қазір менде өзім үшін келесі сипаттама бар.

Бағдарламалық жасақтаманың архитектурасы - бұл сіз күн сайын жасайтын жүйеге әсер ететін шешімдер мен таңдаулар туралы.

Шешім қабылдау үшін «сөмкеде» туындайтын мәселелерді шешудің принциптері мен үлгілері болуы керек, сонымен қатар талаптарды түсіну бизнеске қажет нәрсені құрудың кілті екенін айту керек. Дегенмен, кейде талаптар ашық емес немесе тіпті анықталмаған, бұл жағдайда көбірек түсініктеме алуды күткен дұрыс немесе тәжірибеңізге сүйеніп, түйсігіңізге сенген жөн. Дегенмен, сенетін принциптеріңіз бен үлгілеріңіз болмаса, дұрыс шешім қабылдай алмайсыз. Міне, мен бағдарламалық жасақтаманың архитектуралық стилінің анықтамасына келемін.

Бағдарламалық жасақтаманың архитектуралық стилі - бағдарламалық құралды құру жолын белгілейтін принциптер мен үлгілер жиынтығы.

Жоспарланған архитектураның әртүрлі жақтарына бағытталған көптеген әртүрлі архитектуралық стильдер бар және олардың бірнешеуін бірден қолдану қалыпты жағдай болып табылады.

Мысалы, мысалы:

1. Монолитті сәулет

2. Доменге негізделген дизайн

3. Құрамдасқа негізделген

4. Микросервис

5. Құбырлар мен сүзгілер

6. Оқиғаға негізделген

7. Микроядро

8. Қызмет көрсетуге бағытталған

   
   

және т.б.…

Әрине, олардың артықшылықтары мен кемшіліктері бар, бірақ мен түсінген ең маңызды нәрсе - сәулет өзекті мәселелерге байланысты біртіндеп дамиды. Монолитті архитектурадан бастау операциялық қиындықтарды азайту үшін тамаша таңдау болып табылады, бұл архитектура өнімді құрудың Product-market Fit (PMI) кезеңіне жеткеннен кейін де сіздің қажеттіліктеріңізге сәйкес келуі мүмкін. Масштабта оқиғаға негізделген тәсілге және тәуелсіз орналастыруға, біркелкі емес технологиялық стек ортасына және аз біріктірілген архитектураға (және әзірше оқиғаға негізделген және паб-қосалқы тәсілдердің сипатына байланысты азырақ мөлдір) қол жеткізу үшін микросервистерге көшуді қарастыруыңызға болады. бұл қабылданған). Қарапайымдылық пен тиімділік жақын және бір-біріне үлкен әсер етеді. Әдетте, күрделі архитектуралар жаңа мүмкіндіктердің даму жылдамдығына әсер етеді, барларын қолдайды және сақтайды және жүйенің табиғи эволюциясын қиындатады.

Дегенмен, күрделі жүйелер жиі күрделі және жан-жақты архитектураны қажет етеді, бұл сөзсіз.

Шындығында, бұл өте кең тақырып және табиғи эволюция үшін жүйелерді қалай құрылымдау және құру туралы көптеген тамаша идеялар бар. Өз тәжірибеме сүйене отырып, мен келесі әдісті әзірледім:

1. Әрқашан дерлік монолитті сәулет стилінен басталады, өйткені ол бөлінген жүйелердің табиғатына байланысты туындайтын мәселелердің көпшілігін жояды. Сондай-ақ, нақты шекаралары бар құрамдас бөліктерге назар аудару үшін модульдік монолитті ұстанған жөн. Құрамдасқа негізделген тәсілді қолдану оқиғаларды пайдалану арқылы бір-бірімен байланысуға көмектесуі мүмкін, бірақ тікелей қоңыраулар (aka RPC) бастапқыда нәрселерді жеңілдетеді. Дегенмен, құрамдас бөліктер арасындағы тәуелділікті қадағалау маңызды, өйткені А құрамдас бөлігі В құрамдас бөлігі туралы көп білетін болса, мүмкін оларды біреуіне біріктіру мағынасы бар.
2. Әзірлеуді және жүйені масштабтау қажет болған жағдайға жақындаған кезде, тәуелсіз орналастыруды немесе тіпті арнайы талаптармен масштабтауды қажет ететін құрамдастарды біртіндеп шығару үшін Stangler үлгісін орындауды қарастыруға болады.
3. Енді, егер сізде болашақ туралы нақты көзқарас болса, бұл керемет сәттілік, сіз қалаған архитектураны таңдай аласыз. Осы сәтте сіз Оркестрация және Хореография тәсілдерін қолдану, тәуелсіз масштабта жазу және оқу операциялары үшін CQRS үлгісін қосу немесе тіпті қажеттіліктеріңізге сәйкес келетін болса, монолитті архитектураны ұстануға шешім қабылдау арқылы микросервис архитектурасына көшуді шеше аласыз.

Сондай-ақ DAU (күнделікті белсенді пайдаланушылар), MAU (ай сайынғы белсенді пайдаланушылар), RPC (секундына сұрау) және TPC (секундына транзакция) сияқты сандар мен көрсеткіштерді түсіну өте маңызды, өйткені бұл сізге таңдау жасауға көмектесуі мүмкін, себебі архитектура үшін 100 белсенді қолданушы мен 100 миллион белсенді қолданушы әртүрлі.

Соңғы ескерту ретінде мен сәулет өнері өнімнің сәтті болуына айтарлықтай әсер етеді деп айтар едім. Масштабтау кезінде өнімдер үшін нашар жобаланған архитектура қажет, бұл сәтсіздікке әкелуі мүмкін, өйткені тұтынушылар жүйені масштабтау кезінде күтпейді, олар бәсекелесті таңдайды, сондықтан біз ықтимал масштабтаудан алда болуымыз керек. Мен кейде бұл қарапайым тәсіл бола алмайтынын мойындасам да, идея масштабталатын, бірақ қазірдің өзінде масштабталмаған жүйеге ие болу. Екінші жағынан, тұтынушылары жоқ өте күрделі және қазірдің өзінде ауқымды жүйеге ие болу немесе олардың көпшілігін алуды жоспарламау сіздің бизнесіңіз үшін ақшаны босқа жұмсайды.

Технологиялық стек таңдау

Технологиялар стегін таңдау да макродеңгейдегі шешім болып табылады, өйткені ол жалдауға, жүйенің табиғи эволюциясының перспективаларына, масштабтауға және жүйе өнімділігіне әсер етеді.

Технологиялар стегін таңдауға қатысты негізгі ойлардың тізімі мынада:

• Жоба талаптары мен күрделілігі. Мысалы, егер сіздің әзірлеушілеріңізде тәжірибе болса, қарапайым веб-қосымшаны Blazor жүйесімен жасауға болады, бірақ WebAssembly жетілмегендіктен, ұзақ мерзімді табысқа жету үшін React және Typescript таңдау жақсы шешім болуы мүмкін.
• Масштабтау және өнімділік қажеттіліктері. Трафиктің үлкен көлемін алуды болжасаңыз, Django орнына ASP.NET Core нұсқасын таңдау оның қатарлас сұрауларды өңдеудегі жоғары өнімділігіне байланысты дұрыс таңдау болуы мүмкін. Дегенмен, бұл шешім сіз күткен трафик ауқымына байланысты. Төмен кідіріспен ықтимал миллиардтаған сұрауларды басқару қажет болса, Қоқыс жинау мүмкіндігінің болуы қиындық тудыруы мүмкін.
• Жалдау, әзірлеу уақыты және құны. Көп жағдайда бұл бізге қамқорлық қажет факторлар. Нарыққа шығу уақыты, техникалық қызмет көрсету құны және жалдау тұрақтылығы сіздің бизнес қажеттіліктеріңізді кедергісіз қамтамасыз етеді.
• Топтық сараптама және ресурстар. Сіздің дамыту тобыңыздың дағдылар жиынтығы маңызды фактор болып табылады. Жаңа стек үйренуге инвестиция салуға күшті себеп болмаса, сіздің командаңыз бұрыннан таныс технологияларды пайдалану әдетте тиімдірек.
• Жетілу. Күшті қауымдастық және кітапханалар мен құралдардың бай экожүйесі даму процесін айтарлықтай жеңілдетеді. Танымал технологиялар жиі қауымдастықтың жақсырақ қолдауына ие, бұл мәселелерді шешу және ресурстарды табу үшін баға жетпес болуы мүмкін. Осылайша сіз ресурстарды үнемдей аласыз және негізінен өнімге назар аудара аласыз.
• Ұзақ мерзімді техникалық қызмет көрсету және қолдау. Технологияның ұзақ мерзімді өміршеңдігін қарастырыңыз. Кеңінен қабылданған және қолдау көрсетілетін технологиялардың ескіру ықтималдығы аз және әдетте тұрақты жаңартулар мен жақсартуларды алады.

Бірнеше технология стектерінің болуы бизнестің өсуіне қалай әсер етуі мүмкін?

Бір жағынан, тағы бір стек енгізу жалдауыңызды кеңейтуі мүмкін, бірақ екінші жағынан, бұл қосымша техникалық қызмет көрсету шығындарын әкеледі, өйткені екі стекке де қолдау көрсету қажет. Сонымен, жоғарыда айтқанымдай, менің көзқарасым бойынша, қосымша технология стектерін қосудың дәлелі тек қосымша қажеттілік болуы керек.

Бірақ белгілі бір мәселе үшін ең жақсы құралды таңдау принципі туралы не айтуға болады?

Кейде сізде жоғарыда айтылған ойларға негізделген нақты мәселені шешу үшін жаңа құралдарды әкелуден басқа таңдауыңыз болмайды, мұндай жағдайларда ең жақсы шешімді таңдау мағынасы бар.

Белгілі бір технологиямен жоғары байланыссыз жүйелерді құру қиын болуы мүмкін. Дегенмен, жүйенің технологиямен тығыз байланысы жоқ жағдайға ұмтылу пайдалы және егер ертең белгілі бір құрылым немесе құрал осал болып қалса немесе тіпті ескірсе, ол өлмейді.

Тағы бір маңызды мәселе ашық бастапқы және меншікті бағдарламалық жасақтамаға тәуелділіктермен байланысты. Меншікті бағдарламалық құрал сізге аз икемділік пен теңшеу мүмкіндігін береді. Дегенмен, ең қауіпті фактор - жеткізушінің өнімдеріне, бағасына, шарттарына және жол картасына тәуелді болып қалатын жеткізушінің құлыпталуы. Сатушы бағытын өзгертсе, бағаны көтерсе немесе өнімді тоқтатса, бұл қауіпті болуы мүмкін. Ашық бастапқы бағдарламалық жасақтама бұл тәуекелді азайтады, өйткені бір ұйым оны бақылай алмайды. Барлық деңгейлердегі бір сәтсіздік нүктесін жою - өсу үшін сенімді жүйелер құрудың кілті.

Бір сәтсіздік нүктесі (SPOF)

Жалғыз сәтсіздік нүктесі (SPOF) жүйенің кез келген бөлігін білдіреді, егер ол сәтсіздікке ұшыраса, бүкіл жүйе жұмысын тоқтатады. Барлық деңгейлерде SPOF жою жоғары қолжетімділікті қажет ететін кез келген жүйе үшін өте маңызды. Барлығы, соның ішінде білім, қызметкерлер, жүйе құрамдастары, бұлттық провайдерлер және интернет кабельдері сәтсіздікке ұшырауы мүмкін.

Жалғыз сәтсіздік нүктелерін жою үшін қолдануға болатын бірнеше негізгі әдістер бар:

1. Артықшылық. Маңызды құрамдас бөліктер үшін резервті енгізу. Бұл бастапқы құрамдас сәтсіздікке ұшыраған жағдайда қабылдауға болатын сақтық көшірме құрамдастарының болуын білдіреді. Артықшылықты жүйенің әртүрлі деңгейлерінде, соның ішінде аппараттық құралдар (серверлер, дискілер), желі (сілтемелер, қосқыштар) және бағдарламалық қамтамасыз ету (деректер базалары, қолданбалы серверлер) арқылы қолдануға болады. Егер сіз барлығын бір бұлттық провайдерде орналастырсаңыз және тіпті сақтық көшірмелеріңіз болса, апат жағдайында жоғалған шығынды азайту үшін басқасында тұрақты қосымша сақтық көшірме жасауды қарастырыңыз.
2. Деректер орталықтары. Жүйені деректер орталықтары немесе бұлттық аймақтар сияқты бірнеше физикалық орындарға таратыңыз. Бұл тәсіл жүйеңізді электр қуатының үзілуі немесе табиғи апаттар сияқты орынға қатысты ақаулардан қорғайды.
3. Тоқтату. Барлық құрамдас бөліктерге (DNS, CDN, Load balancers, Kubernetes, API Gateways және Databases) ауыстыру тәсілін қолданыңыз. Мәселелер күтпеген жерден туындауы мүмкін болғандықтан, қажет болған жағдайда кез келген құрамдас бөлікті оның клонымен ауыстыру үшін сақтық көшірме жоспарының болуы өте маңызды.
4. Жоғары қолжетімді қызметтер. Төмендегі принциптерді сақтай отырып, қызметтеріңіз басынан бастап көлденең масштабталатын және жоғары қолжетімді болатындай етіп жасалғанына көз жеткізіңіз:
   • Қызметтің азаматтығы жоқтығын үйреніңіз және пайдаланушы сеанстарын жадтағы кэштерде сақтаудан аулақ болыңыз. Оның орнына Redis сияқты бөлінген кэш жүйесін пайдаланыңыз.
   • Логиканы дамытқанда хабарды тұтынудың хронологиялық тәртібіне сенуден аулақ болыңыз.
   • API тұтынушыларын бұзбау үшін өзгерістерді бұзуды азайтыңыз. Мүмкін болса, кері үйлесімді өзгертулерді таңдаңыз. Сондай-ақ, шығындарды ескеріңіз, өйткені кейде үзіліссіз өзгертуді енгізу үнемді болуы мүмкін.
   • Орналастыру құбырына тасымалдауды орындауды қосыңыз.
   • Бір уақыттағы сұрауларды өңдеу стратегиясын құрыңыз.
   • Сенімділік пен бақылау мүмкіндігін арттыру үшін қызметті табу, бақылау және тіркеуді жүзеге асырыңыз.
   • Желінің ақаулары сөзсіз екенін мойындай отырып, идемпотентті болу үшін бизнес логикасын дамытыңыз.
5. Тәуелділікке шолу. Сыртқы тәуелділіктерді жүйелі түрде қарап шығыңыз және азайтыңыз. Әрбір сыртқы тәуелділік әлеуетті SPOF енгізе алады, сондықтан бұл тәуекелдерді түсіну және азайту өте маңызды.
6. Тұрақты білім алмасу. Ұйымыңызда білім таратудың маңыздылығын ешқашан ұмытпаңыз. Адамдарды болжау мүмкін емес және бір адамға сенім арту қауіпті. Топ мүшелерін құжаттама арқылы білімдерін цифрландыруға шақырыңыз. Дегенмен, шамадан тыс құжаттаманы есте сақтаңыз. Бұл процесті жеңілдету үшін әртүрлі AI құралдарын пайдаланыңыз.

Қорытынды

Бұл мақалада біз бірнеше негізгі макро аспектілерді және олардың күрделілігімен қалай күресуге болатынын қарастырдық.

Оқығаныңызға рахмет! Келесі кездескенше!