Харамсалтай нь энэ нэр томьёо нь орос хэлтэй дүйцэхүйц сайн үг байдаггүй. Википедиа өгдөг "Олон түрээслэх, олон түрээслэх." Үүнийг заримдаа "олон өмч" гэж нэрлэдэг. Сэдэв нь түрээслэх эсвэл өмчлөхтэй үндсэндээ хамааралгүй тул эдгээр нэр томъёо нь зарим талаараа ойлгомжгүй байж болно. Энэ бол програм хангамжийн архитектур, түүний үйл ажиллагааны зохион байгуулалтын асуудал юм. Сүүлийнх нь чухал биш юм.
Бид 1С: Enterprise-д зориулсан үүлэн (үйлчилгээ) үйлдлийн загварт хандах хандлагыг боловсруулж эхлэхийн зэрэгцээ олон түрээсийн талаарх ойлголтоо хөгжүүлж эхэлсэн. Энэ нь хэдэн жилийн өмнө байсан. Түүнээс хойш бидний ойлголт байнга өргөжиж байна. Бид энэ сэдвийн шинэ талуудыг (давуу, сул тал, нарийн төвөгтэй байдал, онцлог гэх мэт) байнга олж илрүүлдэг.
Заримдаа хөгжүүлэгчид олон түрээслэлтийг маш энгийн ойлголт гэж тайлбарладаг: "Олон байгууллагын өгөгдлийг нэг мэдээллийн санд хадгалахын тулд та байгууллагын ID бүхий баганыг бүх хүснэгтэд нэмж, шүүлтүүр тавих хэрэгтэй." Бид мэдээж тэр үеэс л энэ асуудлаар ажлаа эхэлсэн. Гэхдээ энэ бол зүгээр л нэг талбар (мөн нарийн төвөгтэй талбар) гэдгийг бид хурдан ойлгосон. Үнэн хэрэгтээ энэ нь "бүхэл бүтэн улс" юм.
Олон наст байдлын үндсэн санааг ойролцоогоор дараах байдлаар тодорхойлж болно. Ердийн програм бол дэд бүтцийг (хана, дээвэр, усан хангамж, халаалт гэх мэт) хуваалцдаг ганц гэр бүлд зориулагдсан зуслангийн байшин юм. Гэсэн хэдий ч олон түрээсийн програм нь орон сууцны барилга юм. Айл бүр ижил дэд бүтцийг ашигладаг боловч дэд бүтэц нь өөрөө бүхэл бүтэн барилгад хэрэгждэг.
Олон түрээслэх нь сайн эсвэл муу арга уу? Энэ асуудлын талаархи санал бодол маш олон янз байдаг. "Сайн, муу" гэж байдаггүй юм шиг санагддаг. Шийдвэрлэж буй тодорхой сорилтуудтай давуу болон сул талуудыг жинлэх хэрэгтэй. Гэхдээ энэ бол тусдаа сэдэв ...
Энгийн утгаараа олон түрээсийн зорилго нь дэд бүтцийн зардлыг "нийгэмжүүлэх" замаар хэрэглээний засвар үйлчилгээний зардлыг бууруулах явдал юм. Энэ нь захиалгат шийдлийг боловсруулахын оронд стандарт шийдлийг (өөрчлөх, боловсронгуй болгох боломжтой) ашиглан хэрэглээний зардлыг бууруулахтай ижил арга юм. Ялгаа нь нэг тохиолдолд хөгжил нь нийгэмшсэн, нөгөө тохиолдолд үйл ажиллагаа.
Үүнээс гадна, энэ нь борлуулалтын аргатай шууд холбоогүй гэдгийг дахин хэлье. Олон түрээсийн архитектурыг олон тооны ижил төстэй салбарууд эсвэл холдингуудыг автоматжуулахын тулд корпораци эсвэл хэлтсийн мэдээллийн технологийн дэд бүтцэд хялбархан ашиглаж болно.
Олон түрээслэх нь зөвхөн өгөгдөл хадгалах ажлыг зохион байгуулахаас илүү зүйл гэж хэлж болно. Энэ нь програмын бүхэл бүтэн үйл ажиллагааны загвар юм (түүний архитектурын чухал талууд, түүний байршуулалтын загвар, засвар үйлчилгээний зохион байгуулалт).
Олон түрээсийн загварын хамгийн төвөгтэй бөгөөд сонирхолтой тал нь бидний бодлоор програмын үндсэн функц нь хоёр хуваагдсан байдаг. Зарим функц нь тодорхой өгөгдлийн бүс (орон сууц) -тай ажилладаг бөгөөд бусад орон сууцанд оршин суугчид байгаа эсэхийг мэддэггүй. Бусад функцууд нь барилгыг бүхэлд нь ойлгож, бүх оршин суугчдад нэгэн зэрэг ажилладаг. Гэсэн хэдий ч сүүлийнх нь эдгээр нь эцсийн эцэст бие даасан орон сууц бөгөөд шаардлагатай түвшний нарийн нягтрал, аюулгүй байдлыг хангах ёстой гэдгийг үл тоомсорлож болохгүй.
1С: Enterprise-д олон түрээсийн загварыг хэд хэдэн технологийн түвшинд хэрэгжүүлдэг. Эдгээр нь 1C: Enterprise платформын механизмууд, механизмууд юм"Мөн"», механизмууд (стандарт дэд системийн номын сангууд).
Эдгээр элемент бүр нь олон түрээслэгчтэй байшингийн ерөнхий дэд бүтцэд хувь нэмэр оруулдаг. Үүнийг яагаад платформ гэх мэт ганц биш олон технологид хэрэгжүүлдэг вэ? Юуны өмнө бид зарим механизмыг байршуулах хувилбарт тохируулан өөрчилж болно гэдэгт итгэдэг. Гэхдээ ерөнхийдөө энэ бол нарийн төвөгтэй асуудал бөгөөд бид олон түрээсийн тал бүрийг хэрэгжүүлэхэд аль давхарга нь хамгийн тохиромжтой вэ гэсэн сонголттой байнга тулгардаг.
Үндсэн механизмуудыг мөрийн хөтөлбөрт хэрэгжүүлэх шаардлагатай байсан нь ойлгомжтой. Жишээлбэл, өгөгдлийн тусгаарлалт нь өөрөө олон түрээсийн талаарх хэлэлцүүлгийг эхлүүлдэг төрөл юм. Гэвч эцэст нь олон түрээсийн загвар нь платформын механизмын нэлээд хэсгийг эвдэж, тэдгээрийг боловсронгуй болгох, зарим тохиолдолд дахин бодох шаардлагатай болсон.
Платформын түвшинд бид үндсэн механизмуудыг хэрэгжүүлсэн. Эдгээр нь олон түрээсийн загварт ажиллаж байгаа програмуудыг үүсгэх боломжийг олгодог. Гэсэн хэдий ч энэ загварт програмууд зөв ажиллахын тулд тэдгээрийн амьдралын мөчлөгийг удирдах систем шаардлагатай. Үүнд 1cFresh технологи, бизнесийг дэмжих систем (BSS) түвшинд бизнесийн нэгдсэн логик давхаргаар дамжуулан хүрдэг. Орон сууцны дэд бүтэц нь оршин суугчдыг хэрэгцээтэй бүх зүйлээр хангадагтай адил 1cFresh технологи нь олон түрээсийн загварт ажилладаг програмуудад шаардлагатай бүх зүйлийг хангадаг. Аппликейшнүүдийг энэ дэд бүтэцтэй харьцах боломжийг олгохын тулд (маш их өөрчлөлт хийлгүйгээр) зохих "холбогч"-уудыг BSS дэд систем хэлбэрээр суулгасан болно.
Платформын механизмын хувьд бид туршлага хуримтлуулж, үүлэнд суурилсан 1С: Аж ахуйн нэгжийн шийдлийг хөгжүүлснээр энэ архитектурт хамаарах механизмуудыг өргөжүүлж байгааг харахад хялбар юм. Нэг жишээ хэлье. Олон түрээсийн загварт хэрэглээний засвар үйлчилгээнд оролцогчдын дунд үүргийн хуваарилалт ихээхэн өөрчлөгддөг. Хэрэглээний үйл ажиллагааг хариуцах хүмүүсийн үүрэг (хариуцлагын түвшин) ихээхэн нэмэгдсэн. Тэд одоо илүү хүчирхэг програмын хяналтын хэрэгсэл шаарддаг. Учир нь програмын хэрэглэгчид (түрээслэгчид) хамгийн түрүүнд хамтран ажилладаг үйлчилгээ үзүүлэгчдээ итгэдэг. Үүнийг шийдвэрлэхийн тулд бид 8.3 хувилбарт шинэ функцийг хэрэгжүүлсэн. Энэ механизм нь үйлчилгээ үзүүлэгчийн администраторуудад програм хөгжүүлэгчдийн эрх чөлөөг аюулгүй байдлын шаардлагатай түвшинд хязгаарлах боломжийг олгодог бөгөөд энэ нь үндсэндээ тодорхой хамгаалагдсан хязгаарлагдмал орчинд түрээслэгч бүрийн програмын ажиллагааг тусгаарлах боломжийг олгодог.
Үүнтэй адил сонирхолтой нь олон түрээсийн горимд ажилладаг програмуудыг удирдах архитектур юм (1cFresh болон BSP технологид хэрэгжүүлсэн). Энд стандарт байршуулалтын загвартай харьцуулахад удирдлагын процессыг автоматжуулах шаардлага нэлээд өндөр байна. Ийм олон арван үйл явц байдаг: шинэ өгөгдлийн газар ("орон сууц") бий болгох, програмуудыг шинэчлэх, зохицуулалтын мэдээллийг шинэчлэх, нөөцлөлт гэх мэт. Мэдээжийн хэрэг найдвартай байдал, хүртээмжтэй байх шаардлага нэмэгддэг. Жишээлбэл, програмууд болон удирдлагын системийн бүрэлдэхүүн хэсгүүдийн найдвартай харилцан үйлчлэлийг хангахын тулд бид баталгаатай хүргэлт бүхий асинхрон дуудлагын системийг хэрэгжүүлсэн.
Маш нарийн зүйл бол өгөгдөл, процессыг хуваалцах арга зам юм. Энэ нь зөвхөн анх харахад энгийн мэт санагддаг (хэрэв хэн нэгэнд тийм юм шиг санагдаж байвал). Хамгийн том сорилт бол өгөгдөл, үйл явцын төвлөрлийг төвлөрлийг сааруулахтай тэнцвэржүүлэх явдал юм. Нэг талаас, төвлөрөл нь зардлыг бууруулдаг (дискний зай, CPU-ийн нөөц, администраторын хүчин чармайлт гэх мэт). Нөгөөтэйгүүр, энэ нь "түрээслэгчдийн" эрх чөлөөг хязгаарладаг. Энэ нь программыг хөгжүүлэгч нарийн утгаар (нэг "орон сууц" -д үйлчлэх) болон өргөн утгаараа (бүх "түрээслэгч" -д нэгэн зэрэг үйлчлэх) нэгэн зэрэг авч үзэх ёстой "хоёр хуваагдал" програмын нэг тал юм.
Ийм "дилемма"-ны жишээ бол зохицуулалтын болон лавлагааны мэдээлэл юм. Мэдээжийн хэрэг, энэ нь барилгын бүх "оршин суугчид"-д нийтлэг болгох нь сонирхол татдаг. Энэ нь үүнийг нэг хуулбараар хадгалах, хүн бүрт нэгэн зэрэг шинэчлэх боломжийг олгоно. Гэхдээ заримдаа тодорхой оршин суугч тодорхой өөрчлөлтийг шаарддаг. Хачирхалтай нь энэ нь зохицуулагчид (засгийн газрын агентлагууд) заасан мэдээллийн хувьд ч практикт тохиолддог. Эндээс ерөнхийд нь дүгнэх үү, үгүй юу гэсэн хэцүү асуулт гарч ирнэ. Мэдээллийг хүн бүрт ерөнхийд нь, хүссэн хүмүүст нь нууцлах нь мэдээжийн хэрэг. Гэхдээ энэ нь нэлээд төвөгтэй хэрэгжилтэд хүргэдэг. Гэхдээ бид үүн дээр ажиллаж байна ...
Өөр нэг жишээ бол ердийн процессуудын дизайн (хуваарьтай, хяналтын системээр эхлүүлсэн гэх мэт) юм. Нэг талаас, тэдгээрийг мэдээллийн талбар бүрт тусад нь хэрэгжүүлэх боломжтой. Энэ нь илүү хялбар бөгөөд илүү тохиромжтой. Гэсэн хэдий ч, нөгөө талаас, ийм нарийн ширхэгтэй хэрэгжилт нь системд ихээхэн ачааллыг бий болгодог. Энэ ачааллыг багасгахын тулд хуваалцсан процессуудыг хэрэгжүүлэх шаардлагатай. Гэсэн хэдий ч эдгээр нь илүү болгоомжтой дизайн шаарддаг.
Мэдээжийн хэрэг, энэ нь маш чухал асуултыг бий болгодог. Аппликейшн хөгжүүлэгчид олон түрээслэлтийг хэрхэн хангах вэ? Тэд юу хийх хэрэгтэй вэ? Мэдээжийн хэрэг, бид технологийн болон дэд бүтцийн асуудлуудыг нийлүүлсэн технологийн мөрөн дээр аль болох их ачааллыг хангахыг хичээж, програм хөгжүүлэгчийг зөвхөн бизнесийн логикоор бодох боломжийг олгодог. Архитектурын бусад чухал асуудлуудын нэгэн адил програм хөгжүүлэгчид олон түрээсийн үйлчилгээ хэрхэн ажилладаг талаар тодорхой ойлголттой байх шаардлагатай бөгөөд програмыг боловсруулах явцад тодорхой хүчин чармайлт шаардагдана. Яагаад? Учир нь өгөгдлийн семантикийг авч үзэхгүйгээр технологи автоматаар шийдвэрлэх боломжгүй талууд байдаг. Жишээлбэл, хуваалцсан мэдээллийн хил хязгаарыг тодорхойлох. Гэхдээ бид эдгээр бэрхшээлийг аль болох бага байлгахыг хичээдэг. Ийм хэрэглээний хэрэгжилтийн жишээнүүд аль хэдийн бий.
1C: Enterprise-д олон түрээслэлтийг хэрэгжүүлэх чухал тал бол бид нэг программ олон түрээсийн болон стандарт горимд ажиллах боломжтой эрлийз загварыг бий болгож байгаа явдал юм. Энэ бол маш нарийн төвөгтэй ажил бөгөөд тусдаа хэлэлцүүлгийн сэдэв юм.
Эх сурвалж: www.habr.com
