Программалык камсыздоо тутумдарын иштеп чыгууда татаалдыкты кантип чечүү керек

Мунун баары эмне жөнүндө?

Күн сайын, биздин инженердик карьерабыздын ар бир көз ирмеминде биз ар кандай татаалдыктагы ар кандай көйгөйлөргө жана маалыматтардын жетишсиздигинен улам чечим кабыл алышыбыз же аны кийинкиге калтырышыбыз керек болгон кырдаалдарга туш болобуз. Биз жаңы кызматтарды курганда, инфраструктураны курганда, жада калса өнүгүү процесстерин түзгөндө, биз ар кандай чакырыктардын чоң дүйнөсүнө тийебиз.

Бардык көйгөйлөрдү санап чыгуу кыйын, балким, мүмкүн эмес. Белгилүү бир жерде иштесеңиз гана бул көйгөйлөрдүн айрымдарына туш болосуз. Башка жагынан алганда, биз бардыгыбыз кантип чечүү керектигин түшүнүшүбүз керек, анткени алар IT системаларын куруу үчүн абдан маанилүү. Жогорку ыктымалдуулук менен, сиз аларды бардык долбоорлордо кезиктиресиз.

Бул макалада мен программалык камсыздоо программаларын түзүүдө кездешкен кээ бир көйгөйлөр боюнча тажрыйбам менен бөлүшөм.

Cross-Cutting Concern деген эмне?

Википедияны карасак, төмөнкү аныктаманы табабыз

Аспект-багытталган программалык камсыздоону иштеп чыгууда, кайчылаш түйшүктөр программанын бир нече модулдарына таасир этүүчү аспектилери болуп саналат, алардын эч бирине капсулдалуу мүмкүнчүлүгү жок. Бул кооптонууларды көбүнчө системанын калган бөлүгүнөн долбоорлоодо да, ишке ашырууда да ажыратуу мүмкүн эмес жана чачыранды (кодду кайталоо), чаташуу (системалардын ортосундагы олуттуу көз карандылык) же экөөнө тең алып келиши мүмкүн.

Бул анын эмне экенин абдан сүрөттөйт, бирок мен аны бир аз кеңейтип, жөнөкөйлөткүм келет:

Кайчылаш түйшүк – бул системанын/уюмдун концепциясы же компоненти, ал башка көптөгөн бөлүктөргө таасир этет (же "кесип").

Мындай тынчсыздануулардын эң жакшы мисалдары система архитектурасы, журналды каттоо, коопсуздук, транзакцияларды башкаруу, телеметрия, маалымат базасынын дизайны жана башка көптөгөн нерселер. Биз алардын көбүнө кийинчерээк бул макалада кеңири токтолобуз.

Коддун деңгээлинде кайчылаш көйгөйлөр көп учурда Аспектке багытталган программалоо (AOP) сыяктуу ыкмаларды колдонуу менен ишке ашырылат, мында бул тынчсыздануулар бардык колдонмодо колдонула турган өзүнчө компоненттерге модулизацияланган. Бул бизнес логикасын бул кооптонуулардан обочолонтуп, кодду окула турган жана колдоого алгыдай кылат.

Аспекттердин классификациясы

Аспекттерди масштабы, өлчөмү, функционалдуулугу, маанилүүлүгү, максаттуулугу жана башкалар сыяктуу ар кандай касиеттери менен сегментациялоонун көптөгөн жолдору бар, бирок бул макалада мен жөнөкөй масштабдуу классификацияны колдоном. Муну менен мен бул спецификалык аспект кайда багытталганын айтып жатам, ал бүткүл уюмбу, белгилүү бир системабы же ошол системанын белгилүү бир элементиби.

Ошентип, мен аспекттерди Макро жана Микрого бөлөм.

Макро аспект менен мен, негизинен, биз тутумдун тандалган архитектурасы жана анын дизайны (монолиттик, микросервис, тейлөөгө багытталган архитектура), технологиялык стек, уюштуруу түзүмү ж . чечимдер.

Ошол эле учурда, Микро аспект коддун деңгээлине жана өнүгүүсүнө алда канча жакын. Мисалы, маалымат базасы менен өз ара аракеттенүү үчүн кайсы алкак колдонулат, папкалардын жана класстардын долбоордук структурасы, ал тургай, объектинин дизайн үлгүлөрү.

Бул классификация идеалдуу болбосо да, мүмкүн болгон көйгөйлөрдү жана биз аларга колдонгон чечимдердин маанисин жана таасирин түшүнүүнү түзүүгө жардам берет.

Бул макалада менин негизги басым макро аспектилерге бурулат.

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

Уюмдун структурасы

Мен программалык камсыздоонун архитектурасын жаңыдан үйрөнө баштаганда Конуэй мыйзамы жана анын уюштуруу структурасына тийгизген таасири тууралуу көптөгөн кызыктуу макалаларды окудум. Айрыкча бул . Демек, бул мыйзам ушундай деп айтылат

Системаны долбоорлогон ар кандай уюм (кеңири түрдө аныкталган) структурасы уюмдун коммуникация түзүмүнүн көчүрмөсү болгон долбоорду чыгарат.

Мен ар дайым бул концепция чындап эле универсалдуу жана Алтын эрежени билдирет деп ишенип келем.

Андан кийин мен Эрик Эванстын системаларды моделдөө үчүн Домендик Дизайн (DDD) ыкмасын үйрөнө баштадым. Эрик Эванс Чектелген Контекстти идентификациялоонун маанилүүлүгүн баса белгилейт. Бул концепция татаал домен моделин ар биринин өзүнүн чектелген билимдер топтому менен кичирээк, башкарылуучу бөлүктөргө бөлүүнү камтыйт. Бул ыкма команданын эффективдүү баарлашуусуна жардам берет, анткени ал бүткүл домен боюнча кеңири билимге болгон муктаждыкты азайтат жана контекстти алмаштырууну азайтат, ошентип сүйлөшүүлөрдү натыйжалуураак кылат. Контекстти алмаштыруу - бул эң начар жана эң көп ресурсту талап кылган нерсе. Ал тургай, компьютерлер аны менен күрөшүп жатышат. Контекстти алмаштыруунун толук жоктугуна жетишүү күмөн болсо да, мен ошого умтулушубуз керек деп ойлойм.

Конвей мыйзамына кайрылып, мен аны менен бир нече маселелерди таптым.

Конвей мыйзамы менен мен туш болгон биринчи маселе , системанын дизайны уюштуруу түзүмүн чагылдырат деп сунуштайт, бул татаал жана ар тараптуу Чектелген Контексттерди түзүү потенциалы. Бул татаалдык уюштуруу структурасы домендин чектерине туура келбеген учурда пайда болуп, бири-бирине катуу көз каранды болгон жана маалымат менен жүктөлгөн Чектелген Контексттерге алып келет. Бул иштеп чыгуу тобу үчүн тез-тез контекстти алмаштырууга алып келет.

Дагы бир маселе , уюштуруу терминологиясы код деңгээлине чейин агып кетет. Уюмдук структуралар өзгөргөндө, ал баалуу ресурстарды жалмап, код базасын өзгөртүүнү талап кылат.

Ошентип, Inverse Conway Maneuver төмөнкү программалык камсыздоонун архитектурасын кубаттаган системаны жана уюмду түзүүгө жардам берет. Бирок, белгилей кетчү нерсе, бул ыкма мурунтан эле калыптанган архитектурада жана структураларда анча жакшы иштебейт, анткени бул этаптагы өзгөрүүлөр узакка созулат, бирок ал стартаптарда өзгөчө жакшы натыйжа берет, анткени алар кандайдыр бир өзгөртүүлөрдү тез киргизет.

Чоң шар

Бул үлгү же "анти-үлгү" эч кандай архитектурасы жок системаны курууга түрткү берет. Эч кандай эрежелер, чектер жана сөзсүз өсүп жаткан татаалдыкты кантип көзөмөлдөө боюнча стратегия жок. Татаалдуулук программалык камсыздоо тутумдарын куруу сапарындагы эң коркунучтуу душман.

Мындай типтеги системаны түзбөө үчүн биз белгилүү бир эрежелерди жана чектөөлөрдү сакташыбыз керек.

Системалык архитектура

Программалык камсыздоонун архитектурасы үчүн сансыз аныктамалар бар. Мага алардын көбү жагат, анткени алар анын ар кандай аспектилерин камтыйт. Бирок, архитектура жөнүндө ой жүгүртүү үчүн, табигый түрдө алардын айрымдарын мээбизде калыптандыруу керек. Бул аныктама өнүгүп кетиши мүмкүн экенин белгилей кетүү маанилүү. Ошентип, жок эле дегенде, азыр мен үчүн төмөнкү сүрөттөмө бар.

Программалык камсыздоонун архитектурасы – бул курулган системага таасир эткен күн сайын кабыл алган чечимдериңиз жана тандоолоруңуз.

Чечимдерди кабыл алуу үчүн сизде “баштыкта” пайда болгон көйгөйлөрдү чечүүнүн принциптери жана үлгүлөрү болушу керек, ошондой эле талаптарды түшүнүү бизнеске керектүү нерсени куруунун ачкычы экенин айтуу керек. Бирок, кээде талаптар ачык-айкын эмес, ал тургай, аныкталган эмес, бул учурда, ал көбүрөөк тактоо алуу үчүн күтүп же тажрыйбага таянып, ички туюму ишенген жакшы. Бирок баары бир, таяна турган принциптериңиз жана үлгүлөрүңүз болбосо, туура чечим кабыл ала албайсыз. Мына ушул жерден мен программалык камсыздоонун архитектура стилинин аныктамасына келе жатам.

Программалык камсыздоонун архитектура стили программалык камсыздоону кантип курууну белгилеген принциптердин жана үлгүлөрдүн жыйындысы.

Пландаштырылган архитектуранын ар кайсы тарабына багытталган көптөгөн ар кандай архитектуралык стилдер бар жана алардын бир нечесин бир эле учурда колдонуу кадимки көрүнүш.

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

1. Монолиттик архитектура

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

3. Компонентке негизделген

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

5. Түтүк жана чыпкалар

6. Окуяга негизделген

7. Микро ядро

8. Кызматка багытталган

   
   

жана башка…

Албетте, алардын артыкчылыктары да, кемчиликтери да бар, бирок мен эң негизгиси архитектура актуалдуу көйгөйлөргө жараша акырындык менен өнүгүп жатканын түшүндүм. Монолиттик архитектурадан баштоо операциялык татаалдыктарды азайтуу үчүн эң сонун тандоо, балким, бул архитектура продуктуну куруунун Product-market Fit (PMI) баскычына жеткенден кийин да сиздин муктаждыктарыңызга туура келет. Масштаб боюнча, көз карандысыз жайылтууга, гетерогендүү технологиялык стек чөйрөсүнө жана азыраак бириктирилген архитектурага жетишүү үчүн окуяларга негизделген мамилеге жана микросервистерге өтүүнү ойлонушуңуз мүмкүн (жана ошол эле учурда окуяга негизделген жана паб-суб мамилесинин табиятынан улам ачык-айкын эмес, эгерде булар кабыл алынган). Жөнөкөйлүк жана натыйжалуулук жакын жана бири-бирине чоң таасирин тийгизет. Адатта, татаал архитектуралар жаңы функциялардын өнүгүү ылдамдыгына таасир этет, учурдагыларды колдоп, сактап, системанын табигый эволюциясына шек келтирет.

Бирок, татаал системалар көбүнчө татаал жана комплекстүү архитектураны талап кылат, бул сөзсүз болот.

Чындыгында, бул абдан кенен тема жана табигый эволюция үчүн системаларды кантип түзүү жана куруу жөнүндө көптөгөн сонун идеялар бар. Өзүмдүн тажрыйбамдын негизинде мен төмөнкү ыкманы иштеп чыктым:

1. Дээрлик ар дайым монолиттүү архитектура стили менен башталат, анткени ал бөлүштүрүлгөн системалардын табиятынан улам келип чыккан көйгөйлөрдүн көбүн жок кылат. Ошондой эле так чектери бар компоненттерди курууга басым жасоо үчүн модулдук монолитти ээрчүү мааниси бар. Компонентке негизделген ыкманы колдонуу аларга окуяларды колдонуу аркылуу бири-бири менен байланышууга жардам бере алат, бирок түз чалуулар (ака RPC) башында нерселерди жөнөкөйлөтөт. Бирок, компоненттердин ортосундагы көз карандылыкка көз салуу маанилүү, анткени А компоненти В компоненти жөнүндө көп нерсени билсе, балким, аларды бирге бириктирүү мааниси бар.
2. Өнүктүрүүңүздү жана тутумуңузду масштабдашыңыз керек болгон кырдаалга жакындаганыңызда, Stangler үлгүсүнө ылайык өз алдынча жайгаштырылышы керек болгон компоненттерди акырындык менен чыгарууну же атүгүл конкреттүү талаптарды эске алуу менен масштабдуу болушу мүмкүн.
3. Эми, эгер сизде келечекти ачык элестете турган болсоңуз, бул укмуштуудай ийгилик, сиз каалаган архитектураны чечсеңиз болот. Ушул тапта сиз микросервис архитектурасына өтүүнү чечсеңиз болот, ошондой эле Оркестрация жана Хореография ыкмаларын колдонуу, көз карандысыз масштабдагы жазуу жана окуу операциялары үчүн CQRS үлгүсүн киргизүү, же ал тургай, эгерде ал сиздин муктаждыктарыңызга туура келсе, монолиттүү архитектура менен карманууну чечет.

DAU (күнүмдүк активдүү колдонуучулар), MAU (айлык активдүү колдонуучулар), RPC (секунддагы суроо) жана TPC (секундадагы транзакция) сыяктуу сандарды жана көрсөткүчтөрдү түшүнүү абдан маанилүү, анткени ал сизге тандоо жасоого жардам берет, анткени архитектура үчүн 100 активдүү колдонуучу жана 100 миллион активдүү колдонуучулар айырмаланат.

Акыркы эскертүү катары, архитектура буюмдун ийгилигине олуттуу таасир этет деп айтаар элем. Масштабда өнүмдөр үчүн начар иштелип чыккан архитектура талап кылынат, бул ийгиликсиздикке алып келиши мүмкүн, анткени кардарлар сиз системаны масштабдап жатканда күтүшпөйт, алар атаандашты тандашат, андыктан биз потенциалдуу масштабдан алдыда болушубуз керек. Кээде бул арык мамиле болушу мүмкүн эмес экенин моюнга алсам да, идея масштабдуу, бирок масштабдуу эмес системага ээ болуу. Башка жагынан алганда, кардарлары жок өтө татаал жана масштабдуу системага ээ болуу же алардын көбүн алууну пландоо сиздин бизнесиңизге бекер эле акчаны талап кылат.

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

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

Бул технология стек тандоо үчүн негизги ойлордун тизмеси:

• Долбоордун талаптары жана татаалдыгы. Мисалы, жөнөкөй веб-тиркеме Blazor алкактары менен түзүлүшү мүмкүн, эгерде сиздин иштеп чыгуучуларыңыз аны менен тажрыйбага ээ болсо, бирок WebAssembly жетилген эместигинен улам, узак мөөнөттүү ийгилик үчүн React жана Typescriptти тандоо жакшыраак чечим болушу мүмкүн.
• Масштабтоо жана аткаруу муктаждыктары. Эгерде сиз трафиктин чоң көлөмүн алууну болжоп жатсаңыз, Django үстүнөн ASP.NET Core'ду тандоо, анын параллелдүү суроо-талаптарды аткаруудагы жогорку көрсөткүчтөрүнөн улам акылдуу тандоо болушу мүмкүн. Бирок, бул чечим сиз күткөн трафиктин масштабына жараша болот. Эгер сиз потенциалдуу миллиарддаган сурамдарды аз күтүү менен башкаруу керек болсо, таштанды чогултуунун болушу кыйынга турушу мүмкүн.
• Жалдоо, иштеп чыгуу убактысы жана баасы. Көпчүлүк учурларда, бул биз кам көрүшүбүз керек болгон факторлор. Базарга чыгуу убакыты, Техникалык тейлөө наркы жана Жалдоо туруктуулугу бизнесиңиздин муктаждыктарын тоскоолдуксуз ишке ашырат.
• Команданын экспертизасы жана ресурстары. Өнүктүрүү тобуңуздун чеберчилиги маанилүү фактор болуп саналат. Жаңы стекти үйрөнүүгө инвестиция салууга олуттуу себеп болбосо, сиздин командаңыз мурунтан эле тааныш болгон технологияларды колдонуу жалпысынан натыйжалуураак.
• Жетилгендик. Күчтүү коомчулук жана китепканалардын жана куралдардын бай экосистемасы өнүгүү процессин бир топ жеңилдетет. Популярдуу технологиялар көбүнчө коомчулуктун жакшыраак колдоосуна ээ, бул көйгөйлөрдү чечүү жана ресурстарды табуу үчүн баа жеткис жардам берет. Ошентип, сиз ресурстарды үнөмдөп, негизинен продуктуга басым жасай аласыз.
• Узак мөөнөттүү тейлөө жана колдоо. Технологиянын узак мөөнөттүү жашоого жөндөмдүүлүгүн карап көрөлү. Кеңири кабыл алынган жана колдоого алынган технологиялар эскирип калуу ыктымалдыгы азыраак жана жалпысынан үзгүлтүксүз жаңыртууларды жана жакшыртууларды алып турат.

Бир нече технологиялык стектерге ээ болуу бизнестин өсүшүнө кандай таасир этиши мүмкүн?

Бир көз караштан алганда, дагы бир стек киргизүү сиздин жалдооңузду кеңейтиши мүмкүн, бирок экинчи жагынан, бул кошумча тейлөө чыгымдарын алып келет, анткени эки стекти тең колдоо керек. Ошентип, мен жогоруда айткандай, менин көз карашым боюнча, көбүрөөк технология стектерин киргизүү үчүн кошумча муктаждык гана аргумент болушу керек.

Бирок конкреттүү маселе үчүн эң жакшы куралды тандоо принциби жөнүндө эмне айтууга болот?

Кээде сизде жогоруда айтылган ойлордун негизинде конкреттүү маселени чечүү үчүн жаңы инструменттерди алып келүүдөн башка тандооңуз жок, мындай учурларда эң жакшы чечимди тандоо акылга сыярлык.

Белгилүү бир технологияга жогорку байланышы жок системаларды түзүү кыйынга турушу мүмкүн. Ошентсе да, система технология менен тыгыз байланышта болбогон шартка умтулуу пайдалуу жана эгер эртең белгилүү бир алкак же курал алсыз болуп калса же ал тургай эскирип калса, ал өлбөйт.

Дагы бир маанилүү жагдай ачык булак жана менчик программалык көз карандылыкка байланыштуу. Проприетардык программа сизге азыраак ийкемдүүлүктү жана ыңгайлаштыруу мүмкүнчүлүгүн берет. Ошентсе да, эң кооптуу фактор - бул сатуучунун өнүмдөрүнө, баасына, шарттарына жана жол картасына көз каранды болуп калуу. Эгерде сатуучу багытын өзгөртсө, бааны жогорулатып же товарды токтотсо, бул кооптуу болушу мүмкүн. Ачык программалык камсыздоо бул тобокелдикти азайтат, анткени бир уюм аны көзөмөлдөбөйт. Бардык деңгээлдердеги бир катачылыкты жоюу - өсүү үчүн ишенимдүү системаларды куруунун ачкычы.

Бир катачылык чекити (SPOF)

Бир үзгүлтүккө учураган чекит (SPOF) системанын кандайдыр бир бөлүгүн билдирет, ал иштебей калса, бүт системанын иштешин токтотот. Бардык деңгээлдердеги SPOFтерди жок кылуу жогорку жеткиликтүүлүктү талап кылган ар кандай система үчүн өтө маанилүү. Баары, анын ичинде билим, персонал, системанын компоненттери, булут провайдерлери жана интернет кабелдери иштебей калышы мүмкүн.

Бир эле кемчиликтерди жоюу үчүн биз колдоно турган бир нече негизги ыкмалар бар:

1. Артыкчылык. маанилүү компоненттери үчүн ашыкча ишке ашыруу. Бул негизги компонент ишке ашпай калса, өзүнө ала турган резервдик компоненттерге ээ дегенди билдирет. Артыкчылык системанын ар кандай катмарларында, анын ичинде аппараттык камсыздоо (серверлер, дисктер), тармактык (шилтемелер, өчүргүчтөр) жана программалык камсыздоодо (маалымат базалары, колдонмо серверлери) колдонулушу мүмкүн. Эгерде сиз бардыгын бир Cloud Провайдеринде жайгаштырып жатсаңыз жана ал тургай, ал жерде камдык көчүрмөлөрүңүз болсо, кырсык болгон учурда жоголгон чыгымыңызды азайтуу үчүн башкасында үзгүлтүксүз кошумча резервдик көчүрмөнү курууну ойлонуп көрүңүз.
2. Маалымат борборлору. Системаңызды маалымат борборлору же булут аймактары сыяктуу бир нече физикалык жерлерге таратыңыз. Бул ыкма тутумуңузду электр энергиясы үзгүлтүккө учурашы же табигый кырсыктар сыяктуу жайгашкан жерге байланыштуу бузулуулардан коргойт.
3. Иштебей калуу. Бардык компоненттериңиз үчүн (DNS, CDN, Жүктөлгөн баланстар, Kubernetes, API шлюздери жана маалымат базалары) иштебей калуу ыкмасын колдонуңуз. Көйгөйлөр күтүлбөгөн жерден келип чыгышы мүмкүн болгондуктан, зарыл болгон учурда кандайдыр бир компонентти анын клону менен алмаштыруу үчүн камдык планга ээ болуу абдан маанилүү.
4. Жогорку жеткиликтүүлүк кызматтары. Кызматтарыңыздын горизонталдык масштабда түзүлүшү жана башынан эле жеткиликтүү болушу үчүн төмөнкү принциптерди карманыңыз:
   • Кызматтын жарандыгы жок болуп, колдонуучу сеанстарын эстутумдагы кэштерде сактоодон алыс болуңуз. Анын ордуна, Redis сыяктуу бөлүштүрүлгөн кэш тутумун колдонуңуз.
   • Логиканы иштеп чыгууда кабарды колдонуунун хронологиялык тартибине таянуудан качыңыз.
   • API керектөөчүлөрүнүн үзгүлтүккө учурашына жол бербөө үчүн өзгөрүүлөрдү азайтыңыз. Мүмкүнчүлүккө жараша, артка туура келген өзгөртүүлөрдү тандаңыз. Ошондой эле, чыгымдарды эске алыңыз, анткени кээде өзгөрүүнү ишке ашыруу үнөмдүү болушу мүмкүн.
   • Миграцияны ишке ашырууну жайылтуу түтүкчөсүнө кошуу.
   • Кошумча суроо-талаптарды чечүү стратегиясын түзүү.
   • Ишенимдүүлүктү жана байкоого жөндөмдүүлүгүн жогорулатуу үчүн кызматтын ачылышын, мониторингин жана журналдарды каттоону ишке ашырыңыз.
   • Тармактын бузулушу сөзсүз болоорун моюнга алып, идемпотенттүү болуу үчүн бизнес логикасын өнүктүрүңүз.
5. Көз карандылыкты карап чыгуу. Тышкы көз карандылыкты үзгүлтүксүз карап чыгып, азайтыңыз. Ар бир тышкы көз карандылык потенциалдуу SPOFs киргизиши мүмкүн, ошондуктан бул тобокелдиктерди түшүнүү жана азайтуу керек.
6. Үзгүлтүксүз билим бөлүшүү. Уюмуңузда билимди жайылтуунун маанилүүлүгүн эч качан унутпаңыз. Адамдар күтүүсүз болушу мүмкүн жана бир адамга таянуу опурталдуу. Команда мүчөлөрүн документация аркылуу өз билимдерин санариптештирүүгө үндөңүз. Бирок, ашыкча документтештирүүнү унутпаңыз. Бул процессти жөнөкөйлөтүү үчүн ар кандай AI куралдарын колдонуңуз.

Корутунду

Бул макалада биз бир нече негизги макро аспектилерди жана алардын татаалдыгы менен кантип күрөшө аларыбызды карап чыктык.

окуганыңыз үчүн рахмат! Кийинки жолу көрүшкөнчө!