Сайн уу, Хабр. Өнөөдөр би хичээлийн шинэ урсгалыг эхлүүлэхийн тулд тусгайлан бичсэн цуврал нийтлэлээ үргэлжлүүлж байна. .
Танилцуулга
Архитектурын хэв маягийг сонгох нь мэдээллийн системийг бий болгох техникийн үндсэн шийдвэрүүдийн нэг юм. Энэхүү цуврал нийтлэлд би барилгын хэрэглээний хамгийн алдартай архитектурын хэв маягт дүн шинжилгээ хийж, аль архитектурын хэв маягийг хэзээ илүүд үздэг вэ гэсэн асуултанд хариулахыг санал болгож байна. Танилцуулгын явцад би цул хэлбэрээс микро үйлчилгээ хүртэлх архитектурын хэв маягийн хөгжлийг тайлбарласан логик хэлхээг зурахыг хичээх болно.
В Бид цул чулууг авч үзээд цул нь хэмжээ, холболт, байршуулалт, өргөтгөх чадвар, найдвартай байдал, хатуу байдал зэрэг олон асуудалтай гэсэн дүгнэлтэд хүрсэн.
Энэ удаад би системийг модуль/номын сангийн багц (бүрэлдэхүүнд чиглэсэн архитектур) эсвэл үйлчилгээ (үйлчилгээнд чиглэсэн архитектур) хэлбэрээр зохион байгуулах боломжуудын талаар ярихыг санал болгож байна.
Бүрэлдэхүүн хэсгүүдэд чиглэсэн архитектур
Бүрэлдэхүүн хэсгүүдэд чиглэсэн архитектур нь системийг одоогийн болон ирээдүйн төслүүдэд ашиглах боломжтой бүрэлдэхүүн хэсгүүдийн багц хэлбэрээр гүйцэтгэх явдал юм. Системийг бүрэлдэхүүн хэсгүүдэд хуваахдаа тэдгээрийг дахин ашиглах, солих, контекстийн бие даасан байдал, өргөтгөх чадвар, бүрхүүл, бие даасан байдлыг харгалзан үзнэ.
Бүрэлдэхүүн хэсгүүдийг зөв ашигласнаар "том бөмбөлөг шороо" (том хэмжээтэй + өндөр холболт) -ын асуудал шийдэгдэж, бүрэлдэхүүн хэсгүүд нь өөрөө угсрах хэсэг (модуль, номын сан) болон байршуулах хэсэг (үйлчилгээ) байж болно. Байршуулах нэгжүүд нь үргэлж ажиллаж байгаа процесст дүрслэгддэггүй: жишээлбэл, вэб програм болон мэдээллийн баазыг хамт байрлуулдаг.
Ихэнхдээ цул хавтанг модулиудын багц хэлбэрээр боловсруулдаг. Энэ хандлага нь бие даасан хөгжилд хүргэдэг боловч бие даасан масштаб, байршуулалт, алдааг тэсвэрлэх чадвар, технологийн нийт стекээс хараат бус байх зэрэг асуудлууд байсаар байна. Тийм ч учраас модуль нь хэсэгчлэн бие даасан бүрэлдэхүүн хэсэг юм.
Ийм цултай холбоотой хамгийн том асуудал бол модулиудад хуваагдах нь цэвэр логик бөгөөд хөгжүүлэгчид үүнийг амархан зөрчих явдал юм. Үндсэн модуль гарч ирэх бөгөөд энэ нь аажмаар хогийн цэг болж хувирах, модулиудын хоорондын хамаарлын график өсөх гэх мэт. Иймэрхүү бэрхшээлээс зайлсхийхийн тулд хөгжүүлэлтийг маш боловсронгуй баг, эсвэл бүрэн цагийн кодыг хянаж, логик бүтцийг зөрчсөн хөгжүүлэгчдийн гарыг зодож буй "архитектор" -ын удирдлаган дор хийх ёстой.
"Хамгийн тохиромжтой" цул нь логикоор тусгаарлагдсан модулиудын багц бөгөөд тус бүр нь өөрийн мэдээллийн санд харагдана.
Үйлчилгээнд чиглэсэн архитектур
Хэрэв системийг үйлчилгээний багц хэлбэрээр зохион байгуулах гэж байгаа бол бид үйлчилгээнд чиглэсэн архитектурын тухай ярьж байна. Үүний зарчим нь хэрэглэгч төвтэй хэрэглээний харилцан үйлчлэл, бизнесийн үйлчилгээг дахин ашиглах, технологийн стекийн бие даасан байдал, бие даасан байдал (бие даасан хувьсал, өргөтгөх чадвар, байршуулалт) юм.
Үйлчилгээнд чиглэсэн архитектур (SOA = үйлчилгээнд чиглэсэн архитектур) нь цул байгууламжийн тодорхойлсон бүх асуудлыг шийддэг: өөрчлөлт гарахад зөвхөн нэг үйлчилгээ нөлөөлдөг бөгөөд сайн тодорхойлсон API нь бүрэлдэхүүн хэсгүүдийн сайн бүрхүүлийг дэмждэг.
Гэхдээ бүх зүйл тийм ч жигд биш: SOA нь шинэ асуудлуудыг бий болгодог. Алсын дуудлага нь орон нутгийнхаас илүү үнэтэй бөгөөд бүрэлдэхүүн хэсгүүдийн хооронд үүрэг хариуцлагыг дахин хуваарилах нь илүү үнэтэй болсон.
Дашрамд хэлэхэд, бие даасан байршуулах боломж нь үйлчилгээний маш чухал шинж чанар юм. Хэрэв үйлчилгээг хамтад нь эсвэл тодорхой дарааллаар байрлуулах шаардлагатай бол системийг үйлчилгээнд чиглэсэн гэж үзэх боломжгүй юм. Энэ тохиолдолд тэд тархсан цул (зөвхөн SOA-ийн үүднээс төдийгүй микро үйлчилгээний архитектурын үүднээс эсрэг загвар гэж үздэг) тухай ярьдаг.
Үйлчилгээнд чиглэсэн архитектурыг архитектурын нийгэмлэг болон үйлдвэрлэгчид сайн дэмждэг. Энэ нь олон курс, гэрчилгээ, сайн боловсруулсан хэв маяг байгаа гэсэн үг юм. Сүүлийнх нь жишээлбэл, алдартай байгууллагын үйлчилгээний автобус (ESB = аж ахуйн нэгжийн үйлчилгээний автобус) багтана. Үүний зэрэгцээ, ESB нь борлуулагчдын ачаа тээш бөгөөд үүнийг заавал SOA-д ашиглах шаардлагагүй.
Үйлчилгээнд чиглэсэн архитектурын алдар нэр 2008 онд дээд цэгтээ хүрч, дараа нь буурч эхэлсэн бөгөөд энэ нь бичил үйлчилгээ гарч ирсний дараа (~ 2015) мэдэгдэхүйц болсон.
дүгнэлт
Мэдээллийн системийг үйлчилгээ, модулиудын хэлбэрээр зохион байгуулах боломжуудын талаар ярилцсаны дараа би эцэст нь микро үйлчилгээний архитектурын зарчмууд руу шилжиж, дараагийн хэсэгт микро үйлчилгээний архитектур ба үйлчилгээнд чиглэсэн архитектурын ялгааг онцгойлон анхаарч үзэхийг санал болгож байна.
Эх сурвалж: www.habr.com