Күн сайын, биздин инженердик карьерабыздын ар бир көз ирмеминде биз ар кандай татаалдыктагы ар кандай көйгөйлөргө жана маалыматтардын жетишсиздигинен улам чечим кабыл алышыбыз же аны кийинкиге калтырышыбыз керек болгон кырдаалдарга туш болобуз. Биз жаңы кызматтарды курганда, инфраструктураны курганда, жада калса өнүгүү процесстерин түзгөндө, биз ар кандай чакырыктардын чоң дүйнөсүнө тийебиз.
Бардык көйгөйлөрдү санап чыгуу кыйын, балким, мүмкүн эмес. Белгилүү бир жерде иштесеңиз гана бул көйгөйлөрдүн айрымдарына туш болосуз. Башка жагынан алганда, биз бардыгыбыз кантип чечүү керектигин түшүнүшүбүз керек, анткени алар IT системаларын куруу үчүн абдан маанилүү. Жогорку ыктымалдуулук менен, сиз аларды бардык долбоорлордо кезиктиресиз.
Бул макалада мен программалык камсыздоо программаларын түзүүдө кездешкен кээ бир көйгөйлөр боюнча тажрыйбам менен бөлүшөм.
Википедияны карасак, төмөнкү аныктаманы табабыз
Аспект-багытталган программалык камсыздоону иштеп чыгууда, кайчылаш түйшүктөр программанын бир нече модулдарына таасир этүүчү аспектилери болуп саналат, алардын эч бирине капсулдалуу мүмкүнчүлүгү жок. Бул кооптонууларды көбүнчө системанын калган бөлүгүнөн долбоорлоодо да, ишке ашырууда да ажыратуу мүмкүн эмес жана чачыранды (кодду кайталоо), чаташуу (системалардын ортосундагы олуттуу көз карандылык) же экөөнө тең алып келиши мүмкүн.
Бул анын эмне экенин абдан сүрөттөйт, бирок мен аны бир аз кеңейтип, жөнөкөйлөткүм келет:
Кайчылаш түйшүк – бул системанын/уюмдун концепциясы же компоненти, ал башка көптөгөн бөлүктөргө таасир этет (же "кесип").
Мындай тынчсыздануулардын эң жакшы мисалдары система архитектурасы, журналды каттоо, коопсуздук, транзакцияларды башкаруу, телеметрия, маалымат базасынын дизайны жана башка көптөгөн нерселер. Биз алардын көбүнө кийинчерээк бул макалада кеңири токтолобуз.
Коддун деңгээлинде кайчылаш көйгөйлөр көп учурда Аспектке багытталган программалоо (AOP) сыяктуу ыкмаларды колдонуу менен ишке ашырылат, мында бул тынчсыздануулар бардык колдонмодо колдонула турган өзүнчө компоненттерге модулизацияланган. Бул бизнес логикасын бул кооптонуулардан обочолонтуп, кодду окула турган жана колдоого алгыдай кылат.
Аспекттерди масштабы, өлчөмү, функционалдуулугу, маанилүүлүгү, максаттуулугу жана башкалар сыяктуу ар кандай касиеттери менен сегментациялоонун көптөгөн жолдору бар, бирок бул макалада мен жөнөкөй масштабдуу классификацияны колдоном. Муну менен мен бул спецификалык аспект кайда багытталганын айтып жатам, ал бүткүл уюмбу, белгилүү бир системабы же ошол системанын белгилүү бир элементиби.
Ошентип, мен аспекттерди Макро жана Микрого бөлөм.
Макро аспект менен мен, негизинен, биз тутумдун тандалган архитектурасы жана анын дизайны (монолиттик, микросервис, тейлөөгө багытталган архитектура), технологиялык стек, уюштуруу түзүмү ж . чечимдер.
Ошол эле учурда, Микро аспект коддун деңгээлине жана өнүгүүсүнө алда канча жакын. Мисалы, маалымат базасы менен өз ара аракеттенүү үчүн кайсы алкак колдонулат, папкалардын жана класстардын долбоордук структурасы, ал тургай, объектинин дизайн үлгүлөрү.
Бул классификация идеалдуу болбосо да, мүмкүн болгон көйгөйлөрдү жана биз аларга колдонгон чечимдердин маанисин жана таасирин түшүнүүнү түзүүгө жардам берет.
Бул макалада менин негизги басым макро аспектилерге бурулат.
Мен программалык камсыздоонун архитектурасын жаңыдан үйрөнө баштаганда Конуэй мыйзамы жана анын уюштуруу структурасына тийгизген таасири тууралуу көптөгөн кызыктуу макалаларды окудум. Айрыкча бул . Демек, бул мыйзам ушундай деп айтылат
Системаны долбоорлогон ар кандай уюм (кеңири түрдө аныкталган) структурасы уюмдун коммуникация түзүмүнүн көчүрмөсү болгон долбоорду чыгарат.
Мен ар дайым бул концепция чындап эле универсалдуу жана Алтын эрежени билдирет деп ишенип келем.
Андан кийин мен Эрик Эванстын системаларды моделдөө үчүн Домендик Дизайн (DDD) ыкмасын үйрөнө баштадым. Эрик Эванс Чектелген Контекстти идентификациялоонун маанилүүлүгүн баса белгилейт. Бул концепция татаал домен моделин ар биринин өзүнүн чектелген билимдер топтому менен кичирээк, башкарылуучу бөлүктөргө бөлүүнү камтыйт. Бул ыкма команданын эффективдүү баарлашуусуна жардам берет, анткени ал бүткүл домен боюнча кеңири билимге болгон муктаждыкты азайтат жана контекстти алмаштырууну азайтат, ошентип сүйлөшүүлөрдү натыйжалуураак кылат. Контекстти алмаштыруу - бул эң начар жана эң көп ресурсту талап кылган нерсе. Ал тургай, компьютерлер аны менен күрөшүп жатышат. Контекстти алмаштыруунун толук жоктугуна жетишүү күмөн болсо да, мен ошого умтулушубуз керек деп ойлойм.
Конвей мыйзамына кайрылып, мен аны менен бир нече маселелерди таптым.
Конвей мыйзамы менен мен туш болгон биринчи маселе , системанын дизайны уюштуруу түзүмүн чагылдырат деп сунуштайт, бул татаал жана ар тараптуу Чектелген Контексттерди түзүү потенциалы. Бул татаалдык уюштуруу структурасы домендин чектерине туура келбеген учурда пайда болуп, бири-бирине катуу көз каранды болгон жана маалымат менен жүктөлгөн Чектелген Контексттерге алып келет. Бул иштеп чыгуу тобу үчүн тез-тез контекстти алмаштырууга алып келет.
Дагы бир маселе , уюштуруу терминологиясы код деңгээлине чейин агып кетет. Уюмдук структуралар өзгөргөндө, ал баалуу ресурстарды жалмап, код базасын өзгөртүүнү талап кылат.
Ошентип, Inverse Conway Maneuver төмөнкү программалык камсыздоонун архитектурасын кубаттаган системаны жана уюмду түзүүгө жардам берет. Бирок, белгилей кетчү нерсе, бул ыкма мурунтан эле калыптанган архитектурада жана структураларда анча жакшы иштебейт, анткени бул этаптагы өзгөрүүлөр узакка созулат, бирок ал стартаптарда өзгөчө жакшы натыйжа берет, анткени алар кандайдыр бир өзгөртүүлөрдү тез киргизет.
Бул үлгү же "анти-үлгү" эч кандай архитектурасы жок системаны курууга түрткү берет. Эч кандай эрежелер, чектер жана сөзсүз өсүп жаткан татаалдыкты кантип көзөмөлдөө боюнча стратегия жок. Татаалдуулук программалык камсыздоо тутумдарын куруу сапарындагы эң коркунучтуу душман.
Мындай типтеги системаны түзбөө үчүн биз белгилүү бир эрежелерди жана чектөөлөрдү сакташыбыз керек.
Программалык камсыздоонун архитектурасы үчүн сансыз аныктамалар бар. Мага алардын көбү жагат, анткени алар анын ар кандай аспектилерин камтыйт. Бирок, архитектура жөнүндө ой жүгүртүү үчүн, табигый түрдө алардын айрымдарын мээбизде калыптандыруу керек. Бул аныктама өнүгүп кетиши мүмкүн экенин белгилей кетүү маанилүү. Ошентип, жок эле дегенде, азыр мен үчүн төмөнкү сүрөттөмө бар.
Программалык камсыздоонун архитектурасы – бул курулган системага таасир эткен күн сайын кабыл алган чечимдериңиз жана тандоолоруңуз.
Чечимдерди кабыл алуу үчүн сизде “баштыкта” пайда болгон көйгөйлөрдү чечүүнүн принциптери жана үлгүлөрү болушу керек, ошондой эле талаптарды түшүнүү бизнеске керектүү нерсени куруунун ачкычы экенин айтуу керек. Бирок, кээде талаптар ачык-айкын эмес, ал тургай, аныкталган эмес, бул учурда, ал көбүрөөк тактоо алуу үчүн күтүп же тажрыйбага таянып, ички туюму ишенген жакшы. Бирок баары бир, таяна турган принциптериңиз жана үлгүлөрүңүз болбосо, туура чечим кабыл ала албайсыз. Мына ушул жерден мен программалык камсыздоонун архитектура стилинин аныктамасына келе жатам.
Программалык камсыздоонун архитектура стили программалык камсыздоону кантип курууну белгилеген принциптердин жана үлгүлөрдүн жыйындысы.
Пландаштырылган архитектуранын ар кайсы тарабына багытталган көптөгөн ар кандай архитектуралык стилдер бар жана алардын бир нечесин бир эле учурда колдонуу кадимки көрүнүш.
Мисалы, мисалы:
Монолиттик архитектура
Доменге негизделген дизайн
Компонентке негизделген
Микросервис
Түтүк жана чыпкалар
Окуяга негизделген
Микро ядро
Кызматка багытталган
жана башка…
Албетте, алардын артыкчылыктары да, кемчиликтери да бар, бирок мен эң негизгиси архитектура актуалдуу көйгөйлөргө жараша акырындык менен өнүгүп жатканын түшүндүм. Монолиттик архитектурадан баштоо операциялык татаалдыктарды азайтуу үчүн эң сонун тандоо, балким, бул архитектура продуктуну куруунун Product-market Fit (PMI) баскычына жеткенден кийин да сиздин муктаждыктарыңызга туура келет. Масштаб боюнча, көз карандысыз жайылтууга, гетерогендүү технологиялык стек чөйрөсүнө жана азыраак бириктирилген архитектурага жетишүү үчүн окуяларга негизделген мамилеге жана микросервистерге өтүүнү ойлонушуңуз мүмкүн (жана ошол эле учурда окуяга негизделген жана паб-суб мамилесинин табиятынан улам ачык-айкын эмес, эгерде булар кабыл алынган). Жөнөкөйлүк жана натыйжалуулук жакын жана бири-бирине чоң таасирин тийгизет. Адатта, татаал архитектуралар жаңы функциялардын өнүгүү ылдамдыгына таасир этет, учурдагыларды колдоп, сактап, системанын табигый эволюциясына шек келтирет.
Бирок, татаал системалар көбүнчө татаал жана комплекстүү архитектураны талап кылат, бул сөзсүз болот.
Чындыгында, бул абдан кенен тема жана табигый эволюция үчүн системаларды кантип түзүү жана куруу жөнүндө көптөгөн сонун идеялар бар. Өзүмдүн тажрыйбамдын негизинде мен төмөнкү ыкманы иштеп чыктым:
DAU (күнүмдүк активдүү колдонуучулар), MAU (айлык активдүү колдонуучулар), RPC (секунддагы суроо) жана TPC (секундадагы транзакция) сыяктуу сандарды жана көрсөткүчтөрдү түшүнүү абдан маанилүү, анткени ал сизге тандоо жасоого жардам берет, анткени архитектура үчүн 100 активдүү колдонуучу жана 100 миллион активдүү колдонуучулар айырмаланат.
Акыркы эскертүү катары, архитектура буюмдун ийгилигине олуттуу таасир этет деп айтаар элем. Масштабда өнүмдөр үчүн начар иштелип чыккан архитектура талап кылынат, бул ийгиликсиздикке алып келиши мүмкүн, анткени кардарлар сиз системаны масштабдап жатканда күтүшпөйт, алар атаандашты тандашат, андыктан биз потенциалдуу масштабдан алдыда болушубуз керек. Кээде бул арык мамиле болушу мүмкүн эмес экенин моюнга алсам да, идея масштабдуу, бирок масштабдуу эмес системага ээ болуу. Башка жагынан алганда, кардарлары жок өтө татаал жана масштабдуу системага ээ болуу же алардын көбүн алууну пландоо сиздин бизнесиңизге бекер эле акчаны талап кылат.
Технологиялык стек тандоо да макродеңгээлдеги чечим, анткени ал жалдоо, системанын табигый эволюциясынын перспективалары, масштабдуулугу жана системанын иштешине таасир этет.
Бул технология стек тандоо үчүн негизги ойлордун тизмеси:
Бир нече технологиялык стектерге ээ болуу бизнестин өсүшүнө кандай таасир этиши мүмкүн?
Бир көз караштан алганда, дагы бир стек киргизүү сиздин жалдооңузду кеңейтиши мүмкүн, бирок экинчи жагынан, бул кошумча тейлөө чыгымдарын алып келет, анткени эки стекти тең колдоо керек. Ошентип, мен жогоруда айткандай, менин көз карашым боюнча, көбүрөөк технология стектерин киргизүү үчүн кошумча муктаждык гана аргумент болушу керек.
Бирок конкреттүү маселе үчүн эң жакшы куралды тандоо принциби жөнүндө эмне айтууга болот?
Кээде сизде жогоруда айтылган ойлордун негизинде конкреттүү маселени чечүү үчүн жаңы инструменттерди алып келүүдөн башка тандооңуз жок, мындай учурларда эң жакшы чечимди тандоо акылга сыярлык.
Белгилүү бир технологияга жогорку байланышы жок системаларды түзүү кыйынга турушу мүмкүн. Ошентсе да, система технология менен тыгыз байланышта болбогон шартка умтулуу пайдалуу жана эгер эртең белгилүү бир алкак же курал алсыз болуп калса же ал тургай эскирип калса, ал өлбөйт.
Дагы бир маанилүү жагдай ачык булак жана менчик программалык көз карандылыкка байланыштуу. Проприетардык программа сизге азыраак ийкемдүүлүктү жана ыңгайлаштыруу мүмкүнчүлүгүн берет. Ошентсе да, эң кооптуу фактор - бул сатуучунун өнүмдөрүнө, баасына, шарттарына жана жол картасына көз каранды болуп калуу. Эгерде сатуучу багытын өзгөртсө, бааны жогорулатып же товарды токтотсо, бул кооптуу болушу мүмкүн. Ачык программалык камсыздоо бул тобокелдикти азайтат, анткени бир уюм аны көзөмөлдөбөйт. Бардык деңгээлдердеги бир катачылыкты жоюу - өсүү үчүн ишенимдүү системаларды куруунун ачкычы.
Бир үзгүлтүккө учураган чекит (SPOF) системанын кандайдыр бир бөлүгүн билдирет, ал иштебей калса, бүт системанын иштешин токтотот. Бардык деңгээлдердеги SPOFтерди жок кылуу жогорку жеткиликтүүлүктү талап кылган ар кандай система үчүн өтө маанилүү. Баары, анын ичинде билим, персонал, системанын компоненттери, булут провайдерлери жана интернет кабелдери иштебей калышы мүмкүн.
Бир эле кемчиликтерди жоюу үчүн биз колдоно турган бир нече негизги ыкмалар бар:
Бул макалада биз бир нече негизги макро аспектилерди жана алардын татаалдыгы менен кантип күрөшө аларыбызды карап чыктык.
окуганыңыз үчүн рахмат! Кийинки жолу көрүшкөнчө!