Сайн уу, Хабр. Яг одоо OTUS дээр шинэ сургалтын элсэлт явагдаж байна . Хичээл эхлэхийн өмнөхөн би та бүхэнтэй анхны нийтлэлээ хуваалцахыг хүсч байна.
Танилцуулга
Архитектурын хэв маягийг сонгох нь мэдээллийн системийг бий болгох техникийн үндсэн шийдвэрүүдийн нэг юм. Энэхүү цуврал нийтлэлд би барилгын хэрэглээний хамгийн алдартай архитектурын хэв маягт дүн шинжилгээ хийж, аль архитектурын хэв маягийг хэзээ илүүд үздэг вэ гэсэн асуултанд хариулахыг санал болгож байна. Танилцуулгын явцад би цул хэлбэрээс микро үйлчилгээ хүртэлх архитектурын хэв маягийн хөгжлийг тайлбарласан логик хэлхээг зурахыг хичээх болно.
Түүх бага
Хэрэв та хөгжүүлэгчдээс "Яагаад бидэнд микро үйлчилгээ хэрэгтэй байна вэ?" гэж асуухыг оролдвол та янз бүрийн хариулт авах болно. Та микро үйлчилгээ нь өргөтгөх чадварыг сайжруулж, кодыг ойлгоход хялбар болгож, алдааг тэсвэрлэх чадварыг сайжруулж, заримдаа "кодоо цэвэрлэх" боломжийг олгодог гэдгийг сонсох болно. Микросервисүүд үүссэний цаад зорилгыг ойлгохын тулд түүхийг харцгаая.
Товчхондоо, бидний одоогийн ойлголт дахь микро үйлчилгээнүүд дараах байдлаар үүссэн: 2011 онд Жеймс Льюис янз бүрийн компаниудын ажилд дүн шинжилгээ хийж, SOA-г байршуулалтыг хурдасгах үүднээс оновчтой болгосон шинэ "бичил програм" бий болсонд анхаарлаа хандуулав. үйлчилгээ. Хэсэг хугацааны дараа 2012 онд архитектурын дээд хэмжээний уулзалтын үеэр уг загварыг микросервис гэж өөрчилсөн. Тиймээс микро үйлчилгээг нэвтрүүлэх анхны зорилго нь алдартай үйлчилгээг сайжруулах явдал байв зах зээлд гарах цаг.
Бичил үйлчилгээ 2015 онд шуугиан тарьж байсан. Зарим судалгаанаас үзэхэд микро үйлчилгээний сэдвээр илтгэл тавиагүй ганц ч хурал дууссангүй. Түүгээр ч барахгүй зарим хурлыг зөвхөн микро үйлчилгээнд зориулжээ. Өнөө үед олон төслүүд энэ архитектурын хэв маягийг ашиглаж эхэлж байгаа бөгөөд хэрэв төсөл нь олон тонн хуучирсан код агуулсан бол микро үйлчилгээ рүү шилжих ажил идэвхтэй явагдаж байгаа байх.
Дээр дурдсан бүх зүйлийг үл харгалзан нэлээд цөөн тооны хөгжүүлэгчид "микросервис" гэсэн ойлголтыг тодорхойлж чаддаг. Гэхдээ бид энэ талаар хэсэг хугацааны дараа ярих болно ...
Монолит
Микро үйлчилгээгээр ялгаатай архитектурын хэв маяг нь цул (эсвэл бүгдийг нэг дор) юм. Монолит гэж юу болохыг хэлэх нь утгагүй байх тул архитектурын хэв маягийн цаашдын хөгжлийг эхлүүлсэн энэхүү архитектурын хэв маягийн сул талуудыг нэн даруй жагсаах болно: хэмжээ, холболт, байршуулалт, өргөтгөх чадвар, найдвартай байдал, хатуу байдал. Доор би дутагдал тус бүрийг тусад нь авч үзэхийг санал болгож байна.
хэмжээ
Монолит нь маш том юм. Мөн энэ нь ихэвчлэн маш том мэдээллийн сантай харилцдаг. Програм нь нэг хөгжүүлэгч ойлгоход хэтэрхий том болсон. Зөвхөн энэ код дээр маш их цаг зарцуулсан хүмүүс цултай сайн ажиллаж чаддаг бол анхлан суралцагчид цул чулууг олох гэж маш их цаг зарцуулдаг бөгөөд тэд үүнийг олох баталгаа байхгүй. Ихэвчлэн цултай ажиллахдаа цул чулууг сайн мэддэг, нэг жил хагасын дотор бусад шинэ хөгжүүлэгчдийн гарыг цохих "нөхцөлтэй" ахмадууд үргэлж байдаг. Мэдээжийн хэрэг, ийм нөхцөлт ахмад настан нь нэг л бүтэлгүйтлийн цэг бөгөөд түүний явах нь цул үхэлд хүргэж болзошгүй юм.
Холболт
Цул бол "том шаврын бөмбөг" бөгөөд өөрчлөлт нь урьдчилан таамаглах аргагүй үр дагаварт хүргэж болзошгүй юм. Нэг газарт өөрчлөлт хийснээр та нөгөө хэсэгт цул гэмтээж болно (ижил "чихээ маажин, *@ унасан"). Энэ нь цул дахь бүрэлдэхүүн хэсгүүд нь маш нарийн төвөгтэй, хамгийн чухал нь тодорхой бус харилцаатай байдагтай холбоотой юм.
Байршуулалт
Бүрэлдэхүүн хэсгүүдийн хоорондын нарийн төвөгтэй харилцааны улмаас цул байрлуулах нь өөрийн гэсэн зан үйлтэй урт үйл явц юм. Ийм зан үйл нь ихэвчлэн бүрэн стандартчлагдаагүй бөгөөд "амаар" дамждаг.
Өргөтгөх чадвар
Монолит модулиуд нь нөөцийн хэрэгцээтэй зөрчилдөж болзошгүй тул техник хангамжийн хувьд буулт хийхийг шаарддаг. Танд А ба В үйлчилгээнүүдээс бүрдсэн цул үйлчилгээ байгаа гэж төсөөлөөд үз дээ. А үйлчилгээ нь хатуу дискний хэмжээг шаарддаг бол В үйлчилгээ нь RAM-ыг шаарддаг. Энэ тохиолдолд цул суурилуулсан машин нь хоёр үйлчилгээний шаардлагыг хангах ёстой, эсвэл та аль нэг үйлчилгээг гараар, зохиомлоор идэвхгүй болгох шаардлагатай болно.
Өөр нэг жишээ (илүү сонгодог): А үйлчилгээ нь В үйлчилгээнээс хамаагүй илүү түгээмэл тул та 100 үйлчилгээ А, 10 үйлчилгээ B байхыг хүсч байна. Дахин хэлэхэд хоёр сонголт: бид 100 бүрэн хэмжээний цул байрлуулна, эсвэл дараа нь B үйлчилгээг гараар идэвхгүй болгох шаардлагатай болно.
Найдвартай байдал
Бүх үйлчилгээнүүд хамт байрладаг тул цул унавал бүх үйлчилгээ нэг дор унадаг. Үнэн хэрэгтээ энэ нь тийм ч муу биш байж магадгүй, ядаж тархсан системд хэсэгчилсэн алдаа гарахгүй, гэхдээ нөгөө талаас хэрэглэгчдийн 0.001% нь ашигладаг функциональ алдааны улмаас та бүх хэрэглэгчдийг алдаж болно. таны системийн.
Инерци
Цулын хэмжээнээс шалтгаалан шинэ технологид шилжихэд хүндрэлтэй байдаг. Үүний үр дүнд тэр ахлагчийг авч үлдэх нь тусдаа ажил юм. Төслийн эхэнд сонгосон технологийн стек нь бүтээгдэхүүний хөгжилд саад учруулж буй блок болж хувирдаг.
дүгнэлт
Дараагийн удаа бид бүрэлдэхүүн хэсгүүд болон SOA руу шилжих замаар хүмүүс эдгээр асуудлыг хэрхэн шийдвэрлэхийг оролдсон талаар ярих болно.
Цааш унших:
Эх сурвалж: www.habr.com