Сайн уу! Бидэнд сайхан мэдээ байна, OTUS 6-р сард дахин сургалтаа эхлүүлж байна , үүнтэй холбогдуулан бид тантай ашигтай материалыг хуваалцдаг уламжлалтай.
Хэрэв та ямар ч контекстгүйгээр энэ бүх бичил үйлчилгээтэй танилцсан бол энэ нь жаахан хачирхалтай гэж бодсондоо өршөөгдөх болно. Програмыг сүлжээгээр холбосон хэсгүүдэд хуваах нь үүссэн тархсан системд алдааг тэсвэрлэх цогц горимуудыг нэмж оруулах шаардлагатай.
Хэдийгээр энэ арга нь үүнийг бие даасан олон үйлчилгээ болгон хуваахтай холбоотой боловч эцсийн зорилго нь эдгээр үйлчилгээг өөр өөр машин дээр ажиллуулахаас хамаагүй илүү юм. Бид энд мөн чанараараа тархсан гадаад ертөнцтэй харилцах харилцааны тухай ярьж байна. Техникийн утгаараа биш, харин олон хүн, баг, хөтөлбөрөөс бүрдэх экосистем, эдгээр хэсэг бүр ямар нэгэн байдлаар ажлаа хийх шаардлагатай болдог.
Жишээлбэл, компаниуд нь тодорхой зорилгод хүрэхэд хамтдаа хувь нэмэр оруулдаг тархсан системийн цуглуулга юм. Бид энэ баримтыг хэдэн арван жилийн турш үл тоомсорлож, FTP файлуудыг нэгтгэх, эсвэл аж ахуйн нэгжийн интеграцийн хэрэгслийг ашиглан өөрсдийн тусгаарлагдсан зорилгодоо анхаарлаа төвлөрүүлэхийг хичээсээр ирсэн. Гэвч үйлчилгээ гарч ирснээр бүх зүйл өөрчлөгдсөн. Үйлчилгээнүүд нь бидэнд хэтийн төлөвийг харж, хамтдаа ажилладаг харилцан хамааралтай хөтөлбөрүүдийн ертөнцийг харахад тусалсан. Гэсэн хэдий ч амжилттай ажиллахын тулд бид өөр олон үйлчилгээний экосистемд амьдардаг гадаад ертөнц, дангаараа захирдаг хувийн дотоод ертөнц гэсэн хоёр өөр ертөнцийг таньж, төлөвлөх хэрэгтэй.
Энэхүү тархсан ертөнц нь бидний өссөн, дассан ертөнцөөс өөр юм. Уламжлалт цул архитектурыг бий болгох зарчим нь шүүмжлэлийг тэсвэрлэдэггүй. Тиймээс эдгээр системийг зөв болгох нь гайхалтай самбарын диаграмм эсвэл үзэл баримтлалын гайхалтай нотолгоо үүсгэхээс илүү чухал юм. Гол нь ийм систем удаан хугацаанд амжилттай ажиллахад оршино. Аз болоход, үйлчилгээнүүд нь харагдахуйц өөр боловч нэлээд удаж байна. Докер, Кубернетес, бага зэрэг бүдгэрсэн хипстер сахалтай ч гэсэн хамааралтай хэвээр байна.
Тиймээс өнөөдөр бид дүрэм хэрхэн өөрчлөгдсөн, яагаад үйлчилгээнд хандах хандлага, тэдгээрийн бие биедээ дамжуулдаг өгөгдөлд хандах хандлагыг дахин эргэцүүлэн бодох хэрэгтэйг, мөн үүнийг хийхэд яагаад огт өөр хэрэгсэл хэрэгтэйг авч үзэх болно.
Капсул нь үргэлж таны найз байх болно
Бичил үйлчилгээ нь бие биенээсээ хамааралгүй ажиллах боломжтой. Энэ өмч нь тэдэнд хамгийн их үнэ цэнийг өгдөг. Энэ өмч нь үйлчилгээг өргөжүүлэх, өргөжүүлэх боломжийг олгодог. Хэдэн квадриллион хэрэглэгч эсвэл петабайт хүртэлх өгөгдөл (хэдийгээр эдгээр нь бас тусалж чадна) гэсэн утгаараа биш, харин баг, байгууллага тасралтгүй өсөхийн хэрээр хүмүүсийн тоог нэмэгдүүлэх утгаараа юм.
Гэсэн хэдий ч тусгаар тогтнол бол хоёр талдаа иртэй илд юм. Өөрөөр хэлбэл, үйлчилгээ нь өөрөө амархан бөгөөд байгалийн байдлаар ажиллах боломжтой. Гэхдээ өөр үйлчилгээ ашиглахыг шаарддаг үйлчилгээ дотор функц хэрэгжсэн бол бид хоёр үйлчилгээнд бараг зэрэг өөрчлөлт хийх шаардлагатай болдог. Монолит дээр үүнийг хийхэд хялбар байдаг, та зүгээр л өөрчлөлт оруулаад түүнийгээ гаргахаар илгээдэг, гэхдээ бие даасан үйлчилгээг синхрончлох тохиолдолд илүү их асуудал гарах болно. Багуудын хоорондын уялдаа холбоо, суллах мөчлөг нь авхаалж самбаагаа устгадаг.
Стандарт аргын нэг хэсэг болгон, тэд зүгээр л үйлчилгээнүүдийн хооронд функциональ байдлыг тодорхой хувааж, залхмаар төгсгөлийн өөрчлөлтөөс зайлсхийхийг хичээдэг. Ганц нэвтрэх үйлчилгээ нь энд сайн жишээ байж болно. Энэ нь бусад үйлчилгээнүүдээс ялгарах тодорхой үүрэг гүйцэтгэдэг. Энэхүү тодорхой тусгаарлалт нь эргэн тойрон дахь үйлчилгээнүүдийн эрэлт хэрэгцээ хурдацтай өөрчлөгдөж байгаа ертөнцөд нэг удаа нэвтрэх үйлчилгээ өөрчлөгдөх магадлал багатай гэсэн үг юм. Энэ нь хатуу хязгаарлагдмал хүрээнд оршдог.
Асуудал нь бодит ертөнцөд бизнесийн үйлчилгээ нь үүргүүдийн ижил цэвэр тусгаарлалтыг үргэлж хадгалж чаддаггүй явдал юм. Жишээлбэл, ижил бизнесийн үйлчилгээнүүд нь бусад ижил төстэй үйлчилгээнүүдийн өгөгдөлтэй илүү их хэмжээгээр ажилладаг. Хэрэв та онлайн жижиглэнгийн худалдаа эрхэлдэг бол захиалгын урсгал, бүтээгдэхүүний каталог эсвэл хэрэглэгчийн мэдээллийг боловсруулах нь таны олон үйлчилгээнд тавигдах шаардлага болно. Үйлчилгээ бүр ажиллахын тулд энэ өгөгдөлд хандах шаардлагатай болно.
Ихэнх бизнесийн үйлчилгээнүүд ижил өгөгдлийн урсгалыг хуваалцдаг тул тэдний ажил харилцан уялдаатай байдаг.
Ингээд бид ярих ёстой чухал цэг дээр ирлээ. Үйлчилгээнүүд нь ихэвчлэн тусгаарлагдмал байдлаар ажилладаг дэд бүтцийн бүрэлдэхүүн хэсгүүдэд сайн ажилладаг ч ихэнх бизнесийн үйлчилгээнүүд хоорондоо илүү нягт холбоотой байдаг.
Өгөгдлийн дихотоми
Үйлчилгээнд чиглэсэн хандлагууд аль хэдийн байгаа байж болох ч үйлчилгээнүүдийн хооронд их хэмжээний өгөгдлийг хэрхэн хуваалцах талаар ойлголтгүй хэвээр байна.
Хамгийн гол асуудал бол өгөгдөл, үйлчилгээ нь салшгүй холбоотой юм. Нэг талаас, капсулжуулалт нь үйлчилгээг бие биенээсээ салгаж, тэдний өсөлт, цаашдын өөрчлөлтийг хөнгөвчлөхийн тулд өгөгдлийг нуухыг дэмждэг. Нөгөөтэйгүүр, бид бусад өгөгдлийн нэгэн адил хуваалцсан өгөгдлийг чөлөөтэй хувааж, ялах чадвартай байх хэрэгтэй. Гол нь бусад мэдээллийн системтэй адил чөлөөтэй ажиллаж эхлэх боломжтой байх явдал юм.
Гэсэн хэдий ч мэдээллийн систем нь капсулжуулалттай ямар ч холбоогүй юм. Үнэндээ бол эсрэгээрээ. Өгөгдлийн сан нь хадгалсан өгөгдөлдөө хандах боломжийг олгохын тулд чадах бүхнээ хийдэг. Эдгээр нь танд хэрэгтэй өгөгдлийг өөрчлөх боломжийг олгодог хүчирхэг тунхаглалын интерфейстэй ирдэг. Ийм функц нь судалгааны урьдчилсан шатанд чухал ач холбогдолтой боловч байнга хөгжиж буй үйлчилгээний өсөн нэмэгдэж буй нарийн төвөгтэй байдлыг удирдахад чухал биш юм.
Тэгээд энд нэг дилемма үүснэ. Зөрчилдөөн. Дихотоми. Эцсийн эцэст мэдээллийн систем нь өгөгдөл өгөх, үйлчилгээ нь нуугдах явдал юм.
Эдгээр хоёр хүч нь үндсэн юм. Тэд бидний ихэнх ажлын үндэс суурийг тавьж, бидний барьж буй системд илүү сайн байхын төлөө байнга тэмцдэг.
Үйлчилгээний системүүд хөгжиж, хөгжихийн хэрээр бид өгөгдлийн дихотомийн үр дагаврыг олон талаар харж байна. Үйлчилгээний интерфэйс нь улам бүр нэмэгдэж, улам бүр өсөн нэмэгдэж буй функцээр ханган, маш гоёмсог гэрийн өгөгдлийн сан шиг харагдах болно, эсвэл бид бухимдаж, бүхэл бүтэн багц өгөгдлийг үйлчилгээнээс үйлчилгээ рүү шилжүүлэх арга замыг хэрэгжүүлэх болно.
Хариуд нь гэртээ ургуулсан гоёмсог мэдээллийн сан шиг харагдах зүйлийг бий болгох нь бүхэл бүтэн асуудалд хүргэнэ. Энэ нь яагаад аюултай болохыг бид дэлгэрэнгүй ярихгүй хуваалцсан мэдээллийн сан, энэ нь инженерийн болон ашиглалтын ихээхэн зардал шаарддаг гэж хэлье ашиглахыг оролдож буй компанийн хувьд.
Хамгийн муу зүйл бол өгөгдлийн хэмжээ нь үйлчилгээний хил хязгаарыг нэмэгдүүлдэг. Үйлчилгээнд илүү их хуваалцсан өгөгдөл байх тусам интерфэйс нь илүү төвөгтэй болж, өөр өөр үйлчилгээнүүдээс ирж буй өгөгдлийн багцыг нэгтгэхэд хэцүү байх болно.
Өгөгдлийн багцыг бүхэлд нь задлах, зөөх өөр арга нь бас бэрхшээлтэй байдаг. Энэ асуултын нийтлэг хандлага нь өгөгдлийн багцыг бүхэлд нь татаж аваад хадгалах, дараа нь түүнийг хэрэглэгч үйлчилгээ бүрт дотооддоо хадгалах явдал юм.
Асуудал нь өөр өөр үйлчилгээнүүд өөрсдийн хэрэглэж буй мэдээллээ өөр өөрөөр тайлбарладагт оршино. Энэ өгөгдөл үргэлж гарт байдаг. Тэдгээрийг дотооддоо өөрчилж, боловсруулдаг. Тэд эх сурвалж дахь өгөгдөлтэй ямар нэгэн нийтлэг зүйл байхаа больсон.
Хуулбарууд өөрчлөгдөх тусам өгөгдөл нь цаг хугацааны явцад өөрчлөгдөнө.
Муугаар бодоход ийм өгөгдлийг эргээд харахад залруулахад хэцүү байдаг ( Энэ нь үнэхээр аврах ажилд ирэх боломжтой газар юм). Үнэн хэрэгтээ бизнес эрхлэгчдэд тулгардаг технологийн зарим бэрхшээлүүд нь хэрэглээний программ руу үрждэг ялгаатай өгөгдлөөс үүсдэг.
Энэ асуудлын шийдлийг олохын тулд бид хуваалцсан мэдээллийн талаар өөрөөр бодох хэрэгтэй. Тэд бидний барьж буй архитектурын нэгдүгээр зэрэглэлийн объект болох ёстой. ийм өгөгдлийг "гадаад" гэж нэрлэдэг бөгөөд энэ нь маш чухал шинж чанар юм. Үйлчилгээний дотоод үйл ажиллагааг ил гаргахгүйн тулд бид капсулжуулалт хэрэгтэй, гэхдээ үйлчилгээгээ зөв хийж чадахын тулд хуваалцсан өгөгдөлд хандахад хялбар болгох хэрэгтэй.
Асуудал нь үйлчилгээний интерфейс, мессеж, Хуваалцсан мэдээллийн сан нь гадаад өгөгдөлтэй ажиллахад тохиромжтой шийдлийг санал болгодоггүй тул өнөө үед аль ч арга барил нь хамааралтай биш юм. Үйлчилгээний интерфейсүүд нь ямар ч хэмжээгээр өгөгдөл солилцоход тохиромжгүй байдаг. Мессеж нь өгөгдлийг зөөдөг боловч түүхийг нь хадгалдаггүй тул өгөгдөл нь цаг хугацааны явцад гэмтдэг. Хуваалцсан мэдээллийн сан нь нэг цэг дээр хэт их анхаарал хандуулдаг бөгөөд энэ нь ахиц дэвшлийг саатуулдаг. Бид өгөгдлийн бүтэлгүйтлийн мөчлөгт гацах нь гарцаагүй:
Өгөгдлийн алдааны мөчлөг
Streams: өгөгдөл, үйлчилгээнд төвлөрсөн бус хандлага
Бид үйлчилгээний хуваалцсан өгөгдөлтэй ажиллах арга барилыг өөрчлөх хэрэгтэй. Энэ үед аль ч хандлага нь дээр дурдсан хоёрдмол байдалтай тулгардаг, учир нь үүнийг алга болгохын тулд түүн дээр цацаж болох шидэт тоос байхгүй. Гэсэн хэдий ч бид асуудлыг эргэн харж, тохиролцоонд хүрч чадна.
Энэ буулт нь тодорхой хэмжээний төвлөрлийг агуулдаг. Найдвартай, өргөтгөх боломжтой урсгалуудыг хангадаг учраас бид хуваарилагдсан бүртгэлийн механизмыг ашиглаж болно. Бид одоо үйлчилгээнүүдийг эдгээр хуваалцсан хэлхээнд нэгдэж, ажиллуулах боломжтой байхыг хүсч байгаа ч энэ боловсруулалтыг хийдэг төвлөрсөн төвлөрсөн Бурханы үйлчилгээнээс зайлсхийхийг хүсч байна. Тиймээс хамгийн сайн сонголт бол хэрэглээний үйлчилгээ бүрт урсгал боловсруулалтыг бий болгох явдал юм. Ингэснээр үйлчилгээнүүд өөр өөр эх сурвалжаас авсан өгөгдлийн багцыг нэгтгэж, тэдэнтэй шаардлагатай байдлаар ажиллах боломжтой болно.
Энэ хандлагад хүрэх нэг арга бол стриминг платформ ашиглах явдал юм. Олон сонголтууд байдаг, гэхдээ өнөөдөр бид Кафкаг авч үзэх болно, учир нь түүний статустай урсгалын боловсруулалтыг ашиглах нь танилцуулсан асуудлыг үр дүнтэй шийдвэрлэх боломжийг олгодог.
Түгээмэл бүртгэлийн механизмыг ашиглах нь бидэнд сайн гишгэгдсэн замыг дагаж, мессежийг ашиглах боломжийг олгодог. . Энэ арга нь илгээгчээс илүү хүлээн авагч руу урсгалыг хянах боломжийг олгодог тул хүсэлт-хариу механизмаас илүү томруулж, хуваах боломжийг олгодог гэж үздэг. Гэсэн хэдий ч, энэ амьдралын бүх зүйлд та төлөх ёстой бөгөөд энд танд брокер хэрэгтэй. Гэхдээ том системүүдийн хувьд солилцоо нь үнэ цэнэтэй юм (энэ нь таны дундаж вэб програмын хувьд тийм биш байж магадгүй).
Хэрэв брокер нь уламжлалт мессежийн системээс илүү тархсан бүртгэлийг хариуцдаг бол та нэмэлт боломжуудыг ашиглах боломжтой. Тээвэрлэлт нь тархсан файлын системээс гадна шугаман байдлаар масштабтай байж болно. Мэдээллийг бүртгэлд нэлээд удаан хадгалах боломжтой тул бид зөвхөн мессеж солилцохоос гадна мэдээлэл хадгалах боломжтой болно. Хуваалцах төлөвөөс айхгүйгээр өргөтгөх боломжтой хадгалах сан.
Дараа нь та хэрэглээний үйлчилгээнүүдэд тунхаглалын мэдээллийн баазын хэрэгслүүдийг нэмэхийн тулд төлөвийн урсгал боловсруулалтыг ашиглаж болно. Энэ бол маш чухал санаа юм. Өгөгдөл нь бүх үйлчилгээнд хандах боломжтой хуваалцсан дамжуулалтад хадгалагддаг боловч уг үйлчилгээний нэгтгэх, боловсруулах нь хувийн шинж чанартай байдаг. Тэд өөрсдийгөө хатуу хязгаарлагдмал орчинд тусгаарлагдсан байдаг.
Үл хувиршгүй төлөвийн урсгалыг салгах замаар өгөгдлийн дихотомийг арилгана. Дараа нь Stateful Stream Processing ашиглан үйлчилгээ бүрт энэ функцийг нэмнэ үү.
Тиймээс, хэрэв таны үйлчилгээ захиалга, бүтээгдэхүүний каталог, агуулахтай ажиллах шаардлагатай бол энэ нь бүрэн хандалттай байх болно: зөвхөн та ямар өгөгдлийг нэгтгэх, хаана боловсруулах, цаг хугацааны явцад хэрхэн өөрчлөгдөхийг шийдэх болно. Мэдээллийг хуваалцаж байгаа хэдий ч түүнтэй ажиллах нь бүрэн төвлөрсөн бус байдаг. Энэ нь бүх зүйл таны дүрмийн дагуу явагддаг ертөнцөд үйлчилгээ бүрийн хүрээнд үйлдвэрлэгддэг.
Өгөгдлийн бүрэн бүтэн байдлыг алдагдуулахгүйгээр хуваалцах. Хэрэгцээтэй үйлчилгээ болгонд эх сурвалжийг бус функцийг багтаах.
Өгөгдлийг бөөнөөр нь зөөх шаардлагатай болдог. Заримдаа үйлчилгээ нь сонгосон мэдээллийн сангийн системд локал түүхэн өгөгдлийн багцыг шаарддаг. Энэ заль мэх нь хэрэв шаардлагатай бол тархсан бүртгэлийн механизмд хандсанаар хуулбарыг эх сурвалжаас нь сэргээж болно гэдгийг баталж чадна. Кафка дахь холбогч нь үүнийг маш сайн гүйцэтгэдэг.
Тиймээс өнөөдөр хэлэлцэж буй арга нь хэд хэдэн давуу талтай:
- Өгөгдөл нь нийтлэг урсгал хэлбэрээр ашиглагддаг бөгөөд энэ нь логонд удаан хугацаагаар хадгалагдах боломжтой бөгөөд нийтлэг өгөгдөлтэй ажиллах механизм нь тус бүрийн контекст бүрт хатуу холбогдсон байдаг нь үйлчилгээг хялбар, хурдан ажиллуулах боломжийг олгодог. Ийм байдлаар өгөгдлийн хоёр талт байдлыг тэнцвэржүүлж болно.
- Янз бүрийн үйлчилгээнээс ирж буй өгөгдлийг багц болгон хялбархан нэгтгэж болно. Энэ нь хуваалцсан өгөгдөлтэй харилцах харилцааг хялбарчилж, мэдээллийн санд локал өгөгдлийн багц хадгалах шаардлагагүй болно.
- Stateful Stream Processing нь зөвхөн өгөгдлийг кэш болгодог бөгөөд үнэний эх сурвалж нь ерөнхий бүртгэлүүд хэвээр үлддэг тул цаг хугацааны явцад өгөгдөл гэмтэх асуудал тийм ч хурц биш юм.
- Үндсэндээ үйлчилгээ нь өгөгдөлд тулгуурладаг бөгөөд энэ нь өгөгдлийн хэмжээ байнга нэмэгдэж байгаа хэдий ч үйлчилгээ нь бизнесийн үйл явдлуудад хурдан хариу үйлдэл үзүүлэх боломжтой гэсэн үг юм.
- Өргөтгөх чадварын асуудал нь үйлчилгээнд бус брокер дээр гардаг. Энэ нь өргөтгөх чадварын талаар бодох шаардлагагүй тул бичих үйлчилгээний нарийн төвөгтэй байдлыг эрс багасгадаг.
- Шинэ үйлчилгээ нэмэхэд хуучин үйлчилгээгээ өөрчлөх шаардлагагүй тул шинэ үйлчилгээг холбоход хялбар болно.
Таны харж байгаагаар энэ нь зөвхөн REST биш юм. Бид танд хуваалцсан өгөгдөлтэй төвлөрсөн бус байдлаар ажиллах боломжийг олгодог багц хэрэгслийг хүлээн авлаа.
Өнөөдрийн нийтлэлд бүх талыг тусгаагүй. Бид хүсэлт-хариултын парадигм ба үйл явдалд тулгуурласан парадигмыг хэрхэн тэнцвэржүүлэх талаар олж мэдэх шаардлагатай хэвээр байна. Гэхдээ бид дараагийн удаа энэ асуудлыг шийдэх болно. Жишээлбэл, Stateful Stream Processing яагаад ийм сайн байдаг талаар илүү сайн мэдэх шаардлагатай сэдвүүд байдаг. Энэ талаар бид гурав дахь нийтлэлд ярих болно. Хэрэв бид тэдгээрт хандвал давуу талыг ашиглах боломжтой бусад хүчирхэг бүтээн байгуулалтууд байдаг, жишээлбэл, . Энэ нь гүйлгээний баталгааг хангадаг учраас тархсан бизнесийн системүүдийн тоглоомыг өөрчилдөг өргөтгөх боломжтой хэлбэрээр. Үүнийг дөрөв дэх өгүүллээр хэлэлцэх болно. Эцэст нь бид эдгээр зарчмуудын хэрэгжилтийн нарийн ширийнийг авч үзэх шаардлагатай болно.
Гэхдээ одоохондоо үүнийг санаарай: өгөгдлийн дихотоми нь бизнесийн үйлчилгээг бий болгоход бидэнд тулгардаг хүч юм. Мөн бид үүнийг санаж байх ёстой. Энэ заль мэх нь бүх зүйлийг эргүүлж, хуваалцсан өгөгдлийг нэгдүгээр зэрэглэлийн объект гэж үзэж эхлэх явдал юм. Stateful Stream Processing нь үүний өвөрмөц буултыг өгдөг. Энэ нь ахиц дэвшлийг саатуулдаг төвлөрсөн "Бурханы бүрэлдэхүүн хэсгүүдээс" зайлсхийдэг. Нэмж дурдахад, энэ нь өгөгдөл дамжуулах дамжуулах хоолойн уян хатан байдал, өргөтгөх чадвар, уян хатан чанарыг баталгаажуулж, үйлчилгээ бүрт нэмж өгдөг. Тиймээс бид ямар ч үйлчилгээ холбогдож, өгөгдөлтэйгээ ажиллах ухамсрын ерөнхий урсгалд анхаарлаа төвлөрүүлж чадна. Энэ нь үйлчилгээг илүү өргөтгөх, сольж болох, бие даасан болгодог. Тиймээс тэд зөвхөн самбар, таамаглалын тест дээр сайхан харагдахаас гадна хэдэн арван жилийн турш ажиллаж, хөгжих болно.
Эх сурвалж: www.habr.com