Програм хангамжийн архитектур ба системийн дизайн: Том зураг ба нөөцийн гарын авлага

Сайн байна уу хамт олон.

Өнөөдөр бид орчин үеийн програм хангамжийн системийг зохион бүтээх зарчмуудыг харьцангуй бага хэмжээгээр тайлбарлах үүрэг хүлээсэн Тугберк Угурлугийн нийтлэлийн орчуулгыг танд санал болгож байна. Зохиогч өөрийнхөө тухай товчхондоо:

Програм хангамжийн архитектур ба системийн дизайн: Том зураг ба нөөцийн гарын авлага
2019 оны байдлаар архитектурын хэв маяг + дизайны хэв маяг гэх мэт асар том сэдвийг хабро нийтлэлд тусгах нь туйлын боломжгүй тул бид зөвхөн ноён Уруглугийн текстийг төдийгүй түүний эелдэг байдлаар оруулсан олон тооны холбоосыг санал болгож байна. Хэрэв танд таалагдвал бид тараагдсан системийн дизайны талаар илүү нарийн мэргэшсэн текстийг нийтлэх болно.

Програм хангамжийн архитектур ба системийн дизайн: Том зураг ба нөөцийн гарын авлага

Хормын хувилбар Исаак Смит Unsplash-аас

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

Системийг зохион бүтээж эхэлж буй хэн бүхэнд өгөх хамгийн сайн зөвлөгөө бол: ямар ч таамаглал бүү хий! Та анхнаасаа энэ системийн талаар мэдэгдэж байгаа баримтууд болон үүнтэй холбоотой хүлээлтийг тодорхой зааж өгөх хэрэгтэй. Загвар зохион бүтээж эхлэхэд тань туслах хэдэн сайн асуулт байна:

  • Бидний шийдэх гэж байгаа асуудал юу вэ?
  • Манай системтэй харьцах хэрэглэгчдийн хамгийн дээд тоо хэд вэ?
  • Бид өгөгдөл бичих, унших ямар хэв маягийг ашиглах вэ?
  • Хүлээгдэж буй бүтэлгүйтлийн тохиолдол юу вэ, бид тэдгээрийг хэрхэн шийдвэрлэх вэ?
  • Системийн тогтвортой байдал, хүртээмжтэй байдлын талаар ямар хүлээлт байна вэ?
  • Ажиллаж байхдаа хөндлөнгийн шалгалт, зохицуулалттай холбоотой аливаа шаардлагыг заавал харгалзан үзэх шаардлагатай юу?
  • Бид ямар төрлийн эмзэг өгөгдлийг хадгалах вэ?

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

Анхны түвшинг тохируулна уу

Энд би "суурь" гэж юу гэсэн үг вэ? Үнэндээ бидний үед програм хангамжийн салбарын ихэнх асуудлыг одоо байгаа арга, технологийг ашиглан "шийдвэрлэх" боломжтой. Үүний дагуу, энэ ландшафтыг чиглүүлснээр та өөр хэн нэгэн таны өмнө шийдэх ёстой асуудалтай тулгарах үед тодорхой эхлэлийг авах болно. Программууд нь бизнес болон хэрэглэгчийн асуудлыг шийдэхийн тулд бичигдсэн байдаг тул бид асуудлыг хамгийн энгийн бөгөөд энгийн (хэрэглэгчийн үүднээс) шийдвэрлэхийг эрмэлздэг гэдгийг бүү мартаарай. Үүнийг санах нь яагаад чухал вэ? Магадгүй та координатын системдээ бүх асуудлыг шийдэх өвөрмөц шийдлийг хайх дуртай, учир нь та "Би хаа сайгүй хэв маягийг дагаж мөрдвөл би ямар програмист вэ" гэж боддог уу? Үнэндээ, Эндхийн урлаг хаана юу хийхээ шийддэг. Мэдээжийн хэрэг, бидний хүн нэг бүр үе үе давтагдашгүй асуудлуудтай тулгардаг бөгөөд тэдгээр нь тус бүр нь жинхэнэ сорилт юм. Гэсэн хэдий ч, хэрэв бидний анхны түвшинг тодорхой тодорхойлсон бол бид эрч хүчээ юунд зарцуулахаа мэддэг: бидний өмнө тавигдсан асуудлыг шийдвэрлэх бэлэн хувилбаруудыг хайх, эсвэл цаашид судалж, илүү гүнзгий ойлголттой болох.

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

За, хаанаас эхлэх вэ? У Донна Мартина GitHub дээр нэртэй репозитор байдаг системийн дизайн-праймер, үүнээс та том хэмжээний системийг хэрхэн зохион бүтээх талаар суралцахаас гадна энэ сэдвээр ярилцлагад бэлтгэх боломжтой. Хадгалах газар нь жишээнүүдийн хэсэгтэй бодит архитектурууд, ялангуяа системийнхээ дизайнд хэрхэн хандахыг авч үздэг зарим алдартай компаниудЖишээлбэл, Twitter, Uber гэх мэт.

Гэсэн хэдий ч, энэ материал руу шилжихээсээ өмнө практикт тулгарч буй архитектурын хамгийн чухал сорилтуудыг нарийвчлан авч үзье. Зөрүүд, олон талт асуудлыг ОЛОН талаас нь тодорхой зааж өгөөд тухайн тогтолцоонд мөрдөгдөж буй журмын хүрээнд шийдвэрлэх учиртай учраас энэ нь чухал юм. Жексон Габбард, Фэйсбүүкийн хуучин ажилтан бичжээ Системийн дизайны ярилцлагын тухай 50 минутын видео, тэр олон зуун өргөдөл гаргагчийг шалгасан туршлагаасаа хуваалцсан. Энэхүү видео нь том системийн дизайн болон ийм албан тушаалд нэр дэвшигчийг хайж олоход чухал амжилтын шалгуурт ихээхэн анхаарал хандуулдаг ч системийг зохион бүтээхэд юу хамгийн чухал болохыг харуулсан иж бүрэн эх сурвалж болно. Би бас санал болгож байна хураангуй энэ видео.

Өгөгдлийг хадгалах, олж авах талаар мэдлэгийг бий болгох

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

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

Програм хангамжийн архитектур ба системийн дизайн: Том зураг ба нөөцийн гарын авлага

Хормын хувилбар Самуэл Зеллер Unsplash-аас

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

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

Харилцааны загварууд

Системүүд нь янз бүрийн бүрэлдэхүүн хэсгүүдээс бүрддэг; Эдгээр нь нэг физик зангилаа дотор ажилладаг өөр өөр процессууд эсвэл таны сүлжээний өөр өөр хэсгүүдэд ажилладаг өөр өөр машинууд байж болно. Таны сүлжээн дэх эдгээр нөөцийн зарим нь хувийн байж болох ч зарим нь олон нийтэд нээлттэй байх ёстой бөгөөд гаднаас хандах хэрэглэгчдэд нээлттэй байх ёстой.

Эдгээр нөөцийг бие биетэйгээ харилцах, түүнчлэн бүхэл бүтэн систем болон гадаад ертөнцийн хооронд мэдээлэл солилцох шаардлагатай байна. Системийн дизайны хүрээнд бид дахин шинэ бөгөөд өвөрмөц сорилтуудтай тулгарч байна. Тэд хэрхэн ашигтай болохыг харцгаая асинхрон даалгаврын урсгал, мөн юу хХарилцааны янз бүрийн хэлбэрүүд байдаг.

Програм хангамжийн архитектур ба системийн дизайн: Том зураг ба нөөцийн гарын авлага

Хормын хувилбар Тони Стоддард Unsplash-аас

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

Холболтын хуваарилалт

Энэ сэдвийг тусдаа хэсэгт оруулах нь хүн бүрт зөвтгөгдөнө гэдэгт би итгэлгүй байна. Гэсэн хэдий ч би энэ үзэл баримтлалыг энд дэлгэрэнгүй танилцуулах бөгөөд энэ хэсгийн материалыг "холболтын хуваарилалт" гэсэн нэр томъёогоор хамгийн зөв тайлбарласан гэдэгт би итгэж байна.

Системүүд нь олон бүрэлдэхүүн хэсгүүдийг зөв холбосноор үүсдэг бөгөөд тэдгээрийн хоорондын харилцаа холбоо нь TCP болон UDP гэх мэт тогтоосон протоколуудын үндсэн дээр зохион байгуулагддаг. Гэсэн хэдий ч эдгээр протоколууд нь ихэвчлэн өндөр ачаалалтай ажилладаг орчин үеийн системийн бүх хэрэгцээг хангахад хангалтгүй байдаг бөгөөд хэрэглэгчийн хэрэгцээ шаардлагаас ихээхэн хамаардаг. Систем дээрх ийм өндөр ачааллыг даван туулахын тулд холболтыг хуваарилах арга замыг хайж олох шаардлагатай байдаг.

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

Ачааллыг тэнцвэржүүлэх нь үндсэндээ чухал бөгөөд өнөөдөр бидний ажиллаж буй бараг бүх том интернет систем нь нэг буюу хэд хэдэн ачаалал тэнцвэржүүлэгчийн ард байрладаг. Ачаалал тэнцвэржүүлэгч нь үйлчлүүлэгчийн хүсэлтийг олон боломжит тохиолдлуудад түгээхэд тусалдаг. Ачаалал тэнцвэржүүлэгчид нь техник хангамж, програм хангамжийн аль алинд нь байдаг боловч практик дээр та ихэвчлэн програм хангамжтай ажиллах хэрэгтэй болдог. HAProxy и ELB. Урвуу прокси Эхний болон хоёр дахь хооронд хэлбэлздэг боловч концепцийн хувьд ачаалал тэнцвэржүүлэгчтэй маш төстэй тодорхой ялгаа. Таны хэрэгцээнд тулгуурлан системийг зохион бүтээхдээ эдгээр ялгааг анхаарч үзэх хэрэгтэй.

Та бас мэдэх ёстой контент хүргэх сүлжээ (CDN). CDN нь газарзүйн байршлын хувьд тодорхой хэрэглэгчтэй ойр байрлах цэгүүдээс мэдээлэл хүргэдэг прокси серверүүдийн дэлхий даяар тархсан сүлжээ юм. Хэрэв та JavaScript, CSS болон HTML дээр бичигдсэн статик файлуудтай ажилладаг бол CDN-г ашиглах нь дээр. Үүнээс гадна замын хөдөлгөөний менежерээр хангадаг үүлэн үйлчилгээнүүд өнөөдөр түгээмэл байдаг, жишээлбэл, Azure замын хөдөлгөөний менежер, танд динамик агуулгатай ажиллах үед дэлхий даяар түгээх, хоцролтыг багасгах боломжийг олгоно. Гэсэн хэдий ч ийм үйлчилгээ нь харьяалалгүй вэб үйлчилгээтэй ажиллах шаардлагатай тохиолдолд ихэвчлэн хэрэгтэй байдаг.

Бизнесийн логикийн талаар ярилцъя. Бизнесийн логик, даалгаврын урсгал, бүрэлдэхүүн хэсгүүдийн бүтэц

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

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

Хамтарсан арга барилууд

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

Програм хангамжийн архитектур ба системийн дизайн: Том зураг ба нөөцийн гарын авлага

Хормын хувилбар Калейдико Unsplash-аас

Эхний алхам бол таны хүрэхийг оролдож буй бизнесийн зорилго юу болох, ямар хөдөлгөөнт хэсгүүдтэй ажиллах талаар үнэн зөв, нийтлэг ойлголтыг бий болгох явдал юм. Бүлгийн загварчлалын техник, тухайлбал шуургатай үйл явдлууд (үйл явдлын шуурга) нь энэ үйл явцыг ихээхэн хурдасгаж, амжилтанд хүрэх боломжийг нэмэгдүүлэхэд тусална. Энэ ажлыг тоймлохын өмнө эсвэл дараа нь хийж болно таны үйлчилгээний хил хязгаар, дараа нь бүтээгдэхүүн боловсрох тусам гүнзгийрүүлнэ. Энд хүрэх тууштай байдлын түвшинд үндэслэн та мөн томъёолж болно нийтлэг хэл таны ажиллаж буй хязгаарлагдмал нөхцөл байдлын хувьд. Та өөрийн системийн архитектурын талаар ярих шаардлагатай бол энэ нь танд хэрэгтэй байж магадгүй юм загвар C4, санал болгосон Саймон Браун, ялангуяа харилцахыг хүсч буй зүйлээ төсөөлж, асуудлынхаа нарийн ширийнийг хичнээн их ойлгох хэрэгтэйг ойлгох хэрэгтэй.

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

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх