Програм хангамжийн системийг зохион бүтээхдээ нарийн төвөгтэй байдлыг хэрхэн шийдвэрлэх вэ

Энэ бүхэн юуны тухай вэ?

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

Бүх асуудлыг жагсаах нь хэцүү, магадгүй бүр боломжгүй юм. Та зөвхөн тодорхой салбарт ажиллаж байгаа тохиолдолд эдгээр асуудлуудын заримтай тулгарах болно. Нөгөөтэйгүүр, мэдээллийн технологийн системийг бий болгоход чухал үүрэг гүйцэтгэдэг тул хэрхэн шийдвэрлэх талаар бид бүгд ойлгох ёстой олон зүйл бий. Өндөр магадлалтайгаар та бүх төслүүдэд тэдэнтэй тулгарах болно.

Энэ нийтлэлд би программ хангамж бүтээх явцад тохиолдсон зарим асуудлуудын талаар өөрийн туршлагаа хуваалцах болно.

Cross-Cutting Concern гэж юу вэ?

Хэрэв бид Википедиа руу харвал дараах тодорхойлолтыг олох болно

Аспектад чиглэсэн програм хангамж боловсруулахад хөндлөн огтлолын асуудал нь хэд хэдэн модулиудад нөлөөлдөг бөгөөд тэдгээрийн аль нэгэнд нь багтаах боломжгүй байдаг. Эдгээр санаа зовоосон асуудлуудыг дизайн болон хэрэгжилтийн аль алинд нь системийн бусад хэсгээс тодорхой салгах боломжгүй бөгөөд тараагдах (кодын давхардал), орооцолдох (систем хоорондын ихээхэн хамаарал) эсвэл хоёуланг нь үүсгэж болно.

Энэ нь юу болохыг маш их тайлбарласан боловч би үүнийг бага зэрэг өргөжүүлж, хялбаршуулахыг хүсч байна:

Салбарын асуудал нь бусад олон хэсгүүдэд нөлөөлдөг (эсвэл 'хаягдан') систем/байгууллагын үзэл баримтлал эсвэл бүрэлдэхүүн хэсэг юм.

Ийм санаа зовоосон асуудлын хамгийн сайн жишээ бол системийн архитектур, бүртгэл, аюулгүй байдал, гүйлгээний удирдлага, телеметр, мэдээллийн сангийн дизайн болон бусад олон зүйл юм. Энэ нийтлэлд бид тэдгээрийн олонхыг нарийвчлан авч үзэх болно.

Кодын түвшинд хөндлөн огтлолцсон асуудлуудыг ихэвчлэн Aspect-Oriented Programming (AOP) гэх мэт аргуудыг ашиглан хэрэгжүүлдэг бөгөөд эдгээр асуудлуудыг програмын туршид хэрэглэж болох тусдаа бүрэлдэхүүн хэсгүүд болгон модульчлагдсан байдаг. Энэ нь бизнесийн логикийг эдгээр асуудлаас тусгаарлаж, кодыг илүү уншигдах, хадгалах боломжтой болгодог.

Асуудлын ангилал

Хамрах хүрээ, хэмжээ, функциональ байдал, ач холбогдол, зорилтот болон бусад шинж чанаруудаар сегментчилэх замаар талуудыг ангилах олон арга зам байдаг боловч энэ нийтлэлд би энгийн хамрах хүрээний ангиллыг ашиглах болно. Энэ нь бүхэл бүтэн байгууллага, тодорхой систем эсвэл тухайн системийн тодорхой элемент эсэхээс үл хамааран энэ тодорхой тал нь хаашаа чиглэж байгааг би хэлж байна.

Тиймээс би талуудыг Макро болон Микро гэж хуваах гэж байна.

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

Энэ хооронд бичил тал нь кодын түвшин, хөгжилд илүү ойр байдаг. Жишээлбэл, өгөгдлийн сан, хавтас, ангиудын төслийн бүтэц, эсвэл бүр тодорхой объектын дизайны загвартай харьцахад ямар хүрээ ашигладаг вэ.

Хэдийгээр энэ ангилал нь тийм ч тохиромжтой биш боловч боломжит асуудлууд болон тэдгээрт хэрэглэх шийдлүүдийн ач холбогдол, үр нөлөөний талаарх ойлголтыг бүрдүүлэхэд тусалдаг.

Энэ нийтлэлд миний гол анхаарал макро тал дээр байх болно.

Макро талууд

Байгууллагын бүтэц

Програм хангамжийн архитектурын талаар дөнгөж сурч эхлэхдээ Конвейн хууль, түүний байгууллагын бүтцэд үзүүлэх нөлөөллийн талаар олон сонирхолтой нийтлэлүүдийг уншсан. Ялангуяа энэ нь . Тэгэхээр энэ хуульд ингэж заасан байгаа

Системийн загвар зохион бүтээж буй аливаа байгууллага (өргөн утгаар нь тодорхойлсон) бүтэц нь тухайн байгууллагын харилцааны бүтцийн хуулбар болох загварыг гаргах болно.

Энэ үзэл баримтлал нь үнэхээр түгээмэл бөгөөд Алтан дүрмийг илэрхийлдэг гэдэгт би үргэлж итгэдэг.

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

Конвейн хууль руу буцахдаа би түүнтэй холбоотой хэд хэдэн асуудлыг олж мэдсэн.

Системийн дизайн нь байгууллагын бүтцийг тусгадаг гэсэн Конвейн хуулийн талаар миний тулгарсан хамгийн эхний асуудал бол нарийн төвөгтэй, иж бүрэн Хязгаарлагдмал контекстүүдийг бий болгох боломж юм. Байгууллагын бүтэц нь домэйны хил хязгаартай нийцэхгүй байх үед энэ нарийн төвөгтэй байдал үүсдэг бөгөөд энэ нь хоорондоо ихээхэн хамааралтай, мэдээллээр дүүрэн байдаг Хязгаарлагдмал Контекстэд хүргэдэг. Энэ нь хөгжүүлэлтийн багт байнга контекст солигдоход хүргэдэг.

Өөр нэг асуудал бол байгууллагын нэр томьёо нь кодын түвшинд алдагдаж байгаа явдал юм. Байгууллагын бүтэц өөрчлөгдөхөд үнэ цэнэтэй нөөцийг зарцуулж кодын санг өөрчлөх шаардлагатай болдог.

Тиймээс Conway Inverse 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 framework ашиглан энгийн вэб программыг бүтээж болно, гэхдээ WebAssembly-ийн төлөвшил дутмаг учраас React болон Typescript-ийг сонгох нь урт хугацааны амжилтанд хүрэхэд илүү дээр байх болно.
• Өргөтгөх чадвар ба гүйцэтгэлийн хэрэгцээ. Хэрэв та их хэмжээний траффик хүлээн авна гэж бодож байгаа бол Django-гоос ASP.NET Core-г сонгох нь зэрэгцээ хүсэлтийг шийдвэрлэх өндөр гүйцэтгэлтэй тул ухаалаг сонголт байж болох юм. Гэсэн хэдий ч, энэ шийдвэр нь таны хүлээж буй замын хөдөлгөөний цар хүрээнээс хамаарна. Хэрэв та хоцролт багатай олон тэрбум хүсэлтийг удирдах шаардлагатай бол Хог цуглуулах нь бэрхшээлтэй байж магадгүй юм.
• Ажилд авах, хөгжүүлэх хугацаа, зардал. Ихэнх тохиолдолд эдгээр нь бидний анхаарах ёстой хүчин зүйлүүд юм. Зах зээлд гарах хугацаа, Засвар үйлчилгээний зардал, Ажилд авах тогтвортой байдал зэрэг нь таны бизнесийн хэрэгцээг ямар ч саад бэрхшээлгүйгээр хангадаг.
• Багийн туршлага ба нөөц. Танай хөгжлийн багийн ур чадвар чухал хүчин зүйл юм. Шинэ стек сурахад хөрөнгө оруулах хүчтэй шалтгаан байхгүй бол танай багийн аль хэдийн мэддэг технологийг ашиглах нь ерөнхийдөө илүү үр дүнтэй байдаг.
• Төлөвшсөн байдал. Хүчирхэг нийгэмлэг, номын сан, хэрэгслүүдийн баялаг экосистем нь хөгжлийн үйл явцыг ихээхэн хөнгөвчлөх боломжтой. Түгээмэл технологиуд нь ихэвчлэн олон нийтийн дэмжлэгийг илүү сайн дэмждэг бөгөөд энэ нь асуудлыг шийдвэрлэх, нөөцийг олоход үнэлж баршгүй ач холбогдолтой юм. Тиймээс та нөөцөө хэмнэж, голчлон бүтээгдэхүүнд анхаарлаа төвлөрүүлж чадна.
• Урт хугацааны засвар үйлчилгээ, дэмжлэг. Технологийн урт хугацааны амьдрах чадварыг анхаарч үзээрэй. Өргөн нэвтрүүлж, дэмжигдсэн технологиуд хуучирч хоцрох магадлал багатай бөгөөд ерөнхийдөө тогтмол шинэчлэлт, сайжруулалтыг хүлээн авдаг.

Олон тооны технологийн стектэй байх нь бизнесийн өсөлтөд хэрхэн нөлөөлөх вэ?

Нэг өнцгөөс харахад өөр нэг стек оруулах нь таны ажилд авах хэмжээг нэмэгдүүлэх боломжтой боловч нөгөө талаас та хоёр стекийг дэмжих шаардлагатай тул нэмэлт засвар үйлчилгээний зардлыг авчирдаг. Тиймээс, өмнө нь хэлсэнчлэн, миний бодлоор зөвхөн нэмэлт хэрэгцээ нь илүү олон технологийн стек оруулах аргумент байх ёстой.

Гэхдээ тодорхой асуудалд хамгийн сайн хэрэгслийг сонгох зарчим юу вэ?

Заримдаа дээр дурьдсан зүйл дээр үндэслэн тодорхой асуудлыг шийдвэрлэх шинэ хэрэгслийг авчрахаас өөр сонголт байдаггүй тул ийм тохиолдолд хамгийн сайн шийдлийг сонгох нь зүйтэй юм.

Тодорхой технологитой өндөр холболтгүй системийг бий болгох нь бэрхшээлтэй байж болно. Гэсэн хэдий ч, систем нь технологитой нягт уялдаагүй, маргааш тодорхой хүрээ эсвэл хэрэгсэл эмзэг болох эсвэл бүр хуучирсан тохиолдолд үхэхгүй байх нөхцөлийг бүрдүүлэхэд тустай.

Өөр нэг чухал зүйл бол нээлттэй эхийн болон өмчийн програм хангамжийн хамааралтай холбоотой юм. Өмчлөлийн программ хангамж нь танд бага уян хатан байдал, өөрчлөх боломжийг олгодог. Гэсэн хэдий ч хамгийн аюултай хүчин зүйл бол худалдагчийн бүтээгдэхүүн, үнэ, нөхцөл, замын зураглалаас хамааралтай болох худалдагчийг түгжих явдал юм. Хэрэв худалдагч чиглэлээ өөрчилсөн, үнээ нэмсэн эсвэл бараагаа зогсоох юм бол энэ нь эрсдэлтэй байж болно. Нээлттэй эхийн программ хангамж нь энэ эрсдлийг бууруулдаг, учир нь нэг байгууллага үүнийг хянадаггүй. Бүх түвшний бүтэлгүйтлийн нэг цэгийг арилгах нь өсөлтийн найдвартай системийг бий болгох түлхүүр юм.

Нэг бүтэлгүйтлийн цэг (SPOF)

Нэг цэгийн бүтэлгүйтэл (SPOF) нь бүтэлгүйтвэл бүхэл бүтэн системийн ажиллагааг зогсооход хүргэдэг системийн аль нэг хэсгийг хэлнэ. Бүх түвшинд SPOF-ийг устгах нь өндөр хүртээмжтэй байх шаардлагатай аливаа системийн хувьд маш чухал юм. Мэдлэг, боловсон хүчин, системийн бүрэлдэхүүн хэсэг, үүлэн үйлчилгээ үзүүлэгч, интернет кабель зэрэг бүх зүйл бүтэлгүйтэж болзошгүй.

Алдаа дутагдлыг арилгахын тулд хэд хэдэн үндсэн аргуудыг хэрэглэж болно:

1. Илүүдэл. Чухал бүрэлдэхүүн хэсгүүдийн нөөцийг хэрэгжүүлэх. Энэ нь үндсэн бүрэлдэхүүн бүтэлгүйтсэн тохиолдолд нөөцлөх бүрэлдэхүүн хэсгүүдтэй байна гэсэн үг. Тоног төхөөрөмж (сервер, диск), сүлжээ (холбоос, свич), программ хангамж (мэдээллийн сан, програмын сервер) зэрэг системийн өөр өөр давхаргад дахин нөөцлөх боломжтой. Хэрэв та бүх зүйлээ нэг Cloud Provider-д байршуулж, тэр ч байтугай нөөцлөлттэй байгаа бол гамшгийн үед алдагдсан зардлаа бууруулахын тулд өөр төхөөрөмжид байнгын нэмэлт нөөцлөлт хийх талаар бодож үзээрэй.
2. Дата төвүүд. Дата төв эсвэл үүлэн бүс гэх мэт олон физик байршилд системээ түгээ. Энэ арга нь таны системийг цахилгааны тасалдал, байгалийн гамшиг гэх мэт байршлын онцлогтой холбоотой доголдлоос хамгаална.
3. Ажилгүйдэл. Өөрийн бүх бүрэлдэхүүн хэсгүүдэд (DNS, CDN, Ачаалал тэнцвэржүүлэгчид, Kubernetes, API Gateways болон Өгөгдлийн сан) бүрэн гүйцэд солих аргыг хэрэглээрэй. Гэнэтийн асуудал гарч болзошгүй тул шаардлагатай бол аливаа бүрэлдэхүүн хэсгийг клоноор нь солих нөөц төлөвлөгөөтэй байх нь маш чухал юм.
4. Өндөр хүртээмжтэй үйлчилгээ. Дараах зарчмуудыг баримталж, үйлчилгээгээ анхнаасаа хэвтээ байдлаар өргөжүүлэх боломжтой, өндөр хүртээмжтэй байхаар бүтээгээрэй.
   • Үйлчилгээний харьяалалгүй байдлыг дадлагажуулж, хэрэглэгчийн сешнүүдийг санах ойн кэшэд хадгалахаас зайлсхий. Үүний оронд Redis гэх мэт тархсан кэш системийг ашигла.
   • Логик боловсруулахдаа мессежийн хэрэглээний он цагийн дарааллаар найдахаас зайлсхий.
   • API хэрэглэгчдэд саад учруулахаас сэргийлэхийн тулд өөрчлөлтүүдийг багасгах. Боломжтой бол буцаад нийцтэй өөрчлөлтүүдийг сонгоорой. Мөн зардлаа тооцож үз, учир нь заримдаа тасалдсан өөрчлөлтийг хэрэгжүүлэх нь илүү хэмнэлттэй байдаг.
   • Шилжилтийн гүйцэтгэлийг байршуулах хоолойд оруулах.
   • Зэрэгцсэн хүсэлтийг шийдвэрлэх стратегийг бий болгох.
   • Найдвартай байдал, ажиглалтыг сайжруулахын тулд үйлчилгээний нээлт, хяналт, бүртгэлийг хэрэгжүүл.
   • Сүлжээний доголдол зайлшгүй гэдгийг хүлээн зөвшөөрч, чадваргүй байхын тулд бизнесийн логикийг хөгжүүл.
5. Хамааралтай байдлын үнэлгээ. Гадны хамаарлыг тогтмол хянаж, багасгах. Гадны хамаарал бүр нь боломжит SPOF-ийг нэвтрүүлж болох тул эдгээр эрсдлийг ойлгож, бууруулах нь чухал юм.
6. Тогтмол мэдлэг хуваалцах. Байгууллагадаа мэдлэг түгээх ач холбогдлыг хэзээ ч бүү март. Хүмүүс урьдчилан таамаглах аргагүй байж болох ба ганц хүнд найдах нь эрсдэлтэй. Багийн гишүүдийг баримтжуулалтаар дамжуулан мэдлэгээ дижитал хэлбэрт оруулахыг урамшуул. Гэсэн хэдий ч хэт их баримтжуулахаас болгоомжил. Энэ үйл явцыг хялбаршуулахын тулд төрөл бүрийн AI хэрэгслийг ашигла.

Дүгнэлт

Энэ нийтлэлд бид хэд хэдэн гол макро талыг авч үзсэн бөгөөд тэдгээрийн нарийн төвөгтэй байдлыг хэрхэн шийдвэрлэх талаар авч үзсэн.

Уншиж байгаад баярлалаа! Дараагийн удаа уулзацгаая!