Хөөе Хабр!
тухай номыг дагаж мөрдөхийг бид танд сануулж байна Бид номын сангийн тухай нэгэн адил сонирхолтой бүтээл хэвлүүлсэн .
Одоогийн байдлаар олон нийт энэхүү хүчирхэг хэрэгслийн хязгаарыг дөнгөж сурч байна. Тэгвэл саяхан нэгэн нийтлэл хэвлэгдэн гарсан бөгөөд түүний орчуулгыг та бүхэнд толилуулж байна. Зохиогч өөрийн туршлагаасаа Кафка урсгалыг хэрхэн хуваарилагдсан мэдээллийн сан болгох талаар өгүүлдэг. Уншихыг сайхан өнгөрүүлээрэй!
Апачи номын сан Apache Kafka дээр тархсан урсгал боловсруулахад зориулж дэлхий даяар ашигладаг. Энэхүү хүрээний дутуу үнэлэгдсэн талуудын нэг нь утас боловсруулахад үндэслэсэн орон нутгийн төлөв байдлыг хадгалах боломжийг олгодог явдал юм.
Энэ нийтлэлд би манай компани үүлэн хэрэглээний аюулгүй байдлын бүтээгдэхүүн боловсруулахдаа энэ боломжийг хэрхэн ашигтайгаар ашиглаж чадсаныг танд хэлэх болно. Kafka Streams-ийг ашиглан бид хуваалцсан төлөвийн микро үйлчилгээг бий болгосон бөгөөд тэдгээр нь тус бүр нь систем дэх объектуудын төлөв байдлын талаар найдвартай мэдээллийн найдвартай, өндөр хүртээмжтэй эх сурвалж болдог. Бидний хувьд энэ нь найдвартай байдал, дэмжлэг үзүүлэхэд хялбар байдлын хувьд урагшлах алхам юм.
Хэрэв та өөрийн объектын албан ёсны төлөвийг дэмжихийн тулд нэгдсэн мэдээллийн санг ашиглах боломжийг олгодог өөр аргыг сонирхож байгаа бол уншаарай, энэ нь сонирхолтой байх болно ...
Яагаад бид дундын мужтай ажиллах арга барилаа өөрчлөх цаг болсон гэж бодсон
Агентын тайланд үндэслэн янз бүрийн объектын төлөвийг хадгалах шаардлагатай байсан (жишээлбэл: сайт халдлагад өртсөн үү)? Kafka Streams руу шилжихээсээ өмнө бид төрийн удирдлагын нэгдсэн мэдээллийн санд (+ үйлчилгээний API) тулгуурладаг байсан. Энэ арга нь сул талуудтай: тууштай байдал, синхрончлолыг хадгалах нь жинхэнэ сорилт болдог. Мэдээллийн сан нь түгжрэлд орох эсвэл төгсгөл болж магадгүй мөн урьдчилан таамаглах аргагүй байдалд ордог.
Зураг 1: Шилжихээс өмнө ердийн хуваах төлөвийн хувилбар
Кафка ба Кафка урсгалууд: агентууд өөрсдийн үзэл бодлыг API-ээр дамжуулж, шинэчлэгдсэн төлөвийг төв мэдээллийн сангаар тооцдог.
Kafka Streams-тэй танилцаж, хуваалцсан төрийн микро үйлчилгээг бий болгоход хялбар болгоно
Жил орчмын өмнө бид эдгээр асуудлуудыг шийдвэрлэхийн тулд төрийн хамтын хувилбаруудаа сайтар судалж үзэхээр шийдсэн. Бид тэр даруй Кафка урсгалыг туршиж үзэхээр шийдсэн - энэ нь хэр зэрэг өргөжүүлэх боломжтой, өндөр хүртээмжтэй, алдааг тэсвэрлэх чадвартай, ямар баялаг дамжуулалтын функцтэй болохыг бид мэднэ (өөрчлөлтүүд, түүний дотор төлөвтэй). Кафка дахь мессежийн систем хэр боловсронгуй, найдвартай болсныг дурдахгүй өнгөрч болохгүй зүйл бол бидэнд хэрэгтэй зүйл юм.
Бидний үүсгэсэн статустай микро үйлчилгээ бүр нь нэлээд энгийн топологи бүхий Кафка урсгалын жишээн дээр бүтээгдсэн. Энэ нь 1) эх сурвалж 2) байнгын түлхүүр-утга хадгалах процессор 3) угаалтуураас бүрдэнэ.
Зураг 2: Төлөв бичил үйлчилгээнд зориулсан манай урсгалын жишээнүүдийн анхдагч топологи. Энд бас төлөвлөлтийн мета өгөгдлийг агуулсан хадгалах газар байгааг анхаарна уу.
Энэхүү шинэ арга барилд агентууд эх сурвалжийн сэдэвт оруулсан мессежүүдийг зохиож, хэрэглэгчид, тухайлбал, шуудангийн мэдэгдлийн үйлчилгээ нь угаалтуураар дамжуулан тооцоолсон хуваалцсан төлөвийг хүлээн авдаг (гаралтын сэдэв).
Зураг 3: Хуваалцсан бичил үйлчилгээтэй хувилбарын шинэ жишээ даалгавар: 1) агент нь Кафкагийн эх сурвалжийн сэдэвт ирсэн мессежийг үүсгэдэг; 2) хуваалцсан төлөвтэй микро үйлчилгээ (Кафка урсгалыг ашиглан) үүнийг боловсруулж, тооцоолсон төлөвийг Кафкагийн эцсийн сэдэвт бичдэг; үүний дараа 3) хэрэглэгчид шинэ төлөвийг хүлээн зөвшөөрдөг
Хөөе, энэ барьсан түлхүүр үнэ цэнийн дэлгүүр үнэхээр хэрэгтэй!
Дээр дурдсанчлан манай хуваалцсан төлөвийн топологи нь түлхүүр утгын дэлгүүрийг агуулдаг. Бид үүнийг ашиглах хэд хэдэн сонголтыг олсон бөгөөд тэдгээрийн хоёрыг доор тайлбарлав.
Сонголт №1: Тооцоолохдоо түлхүүр утгын нөөцийг ашиглана уу
Манай анхны түлхүүр үнэ цэнийн дэлгүүр нь тооцоолол хийхэд шаардлагатай туслах өгөгдлийг агуулдаг. Тухайлбал, зарим тохиолдолд дундын төрийг "олонхийн санал"-ын зарчмаар тодорхойлсон. Хадгалах газар нь зарим объектын төлөвийн талаархи хамгийн сүүлийн үеийн агентын бүх тайланг агуулж болно. Дараа нь бид нэг эсвэл өөр агентаас шинэ тайлан хүлээн авмагц бид үүнийг хадгалж, хадгалалтаас ижил объектын төлөв байдлын талаарх тайланг бусад бүх агентаас авч, тооцооллыг давтаж болно.
Доорх 4-р зурагт бид түлхүүр/үнэ цэнэгийн хадгалалтыг процессорын боловсруулалтын аргад хэрхэн нэвтрүүлж, шинэ мессежийг боловсруулах боломжтой болсныг харуулав.
Зураг 4: Бид процессорын боловсруулалтын аргын түлхүүр-утга хадгалах хандалтыг нээж өгдөг (үүний дараа хуваалцсан төлөвтэй ажилладаг скрипт бүр уг аргыг хэрэгжүүлэх ёстой. doProcess)
Сонголт №2: Кафка урсгал дээр CRUD API үүсгэх
Даалгаврын үндсэн урсгалыг бий болгосны дараа бид хуваалцсан төрийн микро үйлчилгээнд зориулж RESTful CRUD API бичихийг оролдож эхлэв. Бид зарим эсвэл бүх объектын төлөвийг сэргээх, мөн объектын төлөвийг тохируулах эсвэл устгах боломжтой байхыг хүссэн (арын хэсгийн дэмжлэгт хэрэгтэй).
Бүх Get State API-г дэмжихийн тулд боловсруулалтын явцад төлөвийг дахин тооцоолох шаардлагатай үед бид үүнийг удаан хугацааны турш барьсан түлхүүр-утга хадгалах санд хадгалдаг. Энэ тохиолдолд доорх жагсаалтад үзүүлсэн шиг Kafka Streams-ийн нэг жишээг ашиглан ийм API-г хэрэгжүүлэх нь маш энгийн болно.
Зураг 5: Объектийн урьдчилан тооцоолсон төлөвийг олж авахын тулд суурилуулсан түлхүүр-утга агуулахыг ашиглана
API-ээр дамжуулан объектын төлөвийг шинэчлэх нь хэрэгжүүлэхэд хялбар байдаг. Үндсэндээ та Кафка продюсерийг үүсгэж, түүгээрээ шинэ төлөвийг агуулсан бичлэг хийхэд хангалттай. Энэ нь API-ээр дамжуулан үүсгэсэн бүх мессежийг бусад үйлдвэрлэгчдээс (жишээ нь, агентуудаас) хүлээн авсантай ижил аргаар боловсруулах болно гэдгийг баталгаажуулдаг.
Зураг 6: Та Кафка продюсерийг ашиглан объектын төлөвийг тохируулж болно
Жижиг хүндрэл: Кафка олон хуваалттай
Дараа нь бид нэг хувилбарт хуваалцсан төрийн микро үйлчилгээний кластераар хангах замаар боловсруулалтын ачааллыг хуваарилж, хүртээмжийг сайжруулахыг хүссэн. Суулгах нь маш хялбар байсан: бид бүх тохиолдлуудыг ижил програмын ID (мөн ижил ачаалах серверүүд) дор ажиллуулахаар тохируулсны дараа бараг бүх зүйл автоматаар хийгдсэн. Бид мөн эх сурвалжийн сэдэв бүр хэд хэдэн хуваалтаас бүрдэх бөгөөд ингэснээр жишээ тус бүрт ийм хуваалтуудын дэд багцыг оноож болно гэж заасан.
Жишээлбэл, бүтэлгүйтсэний дараа сэргээх тохиолдолд энэ хуулбарыг өөр инстанц руу шилжүүлэхийн тулд улсын дэлгүүрийн нөөц хуулбарыг хийх нь нийтлэг практик гэдгийг би бас дурдах болно. Kafka Streams дахь улсын дэлгүүр бүрийн хувьд өөрчлөлтийн бүртгэлтэй (орон нутгийн шинэчлэлтүүдийг хянадаг) хуулбарласан сэдвийг үүсгэдэг. Тиймээс Кафка улсын дэлгүүрийг байнга нөөцөлж байдаг. Тиймээс, нэг эсвэл өөр Кафка урсгалын жишээ бүтэлгүйтсэн тохиолдолд улсын дэлгүүрийг харгалзах хуваалтууд хаашаа шилжих өөр инстант дээр хурдан сэргээж болно. Дэлгүүрт хэдэн сая бичлэг байсан ч энэ нь хэдхэн секундын дотор хийгддэг болохыг бидний туршилт харуулсан.
Хуваалцсан төлөвтэй нэг микро үйлчилгээнээс микро үйлчилгээний кластер руу шилжсэнээр Get State API-г хэрэгжүүлэх нь тийм ч хялбар биш болно. Шинэ нөхцөл байдалд бичил үйлчилгээ бүрийн улсын дэлгүүр нь ерөнхий зургийн зөвхөн нэг хэсгийг (түлхүүрүүд нь тодорхой хуваалттай зурагдсан объектууд) агуулдаг. Бидэнд шаардлагатай объектын төлөвийг аль жишээнд агуулж байгааг тодорхойлох шаардлагатай байсан бөгөөд үүнийг доор үзүүлсэн шиг хэлхээний мета өгөгдөл дээр үндэслэн хийсэн.
Зураг 7: Урсгалын мета өгөгдлийг ашиглан бид хүссэн объектын төлөвийг аль жишээнээс асуухыг тодорхойлно; ижил төстэй аргыг GET ALL API-д ашигласан
Гол олдворууд
Кафка урсгал дахь улсын дэлгүүрүүд нь бодит тархсан мэдээллийн сан болж,
- Кафкад байнга хуулбарлагдсан байдаг
- CRUD API-г ийм систем дээр хялбархан барьж болно
- Олон хуваалтыг зохицуулах нь арай илүү төвөгтэй юм
- Мөн туслах өгөгдлийг хадгалахын тулд урсгалын топологид нэг буюу хэд хэдэн муж улсын дэлгүүр нэмэх боломжтой. Энэ сонголтыг дараах зорилгоор ашиглаж болно:
- Урсгал боловсруулах явцад тооцоолол хийхэд шаардлагатай өгөгдлийг урт хугацаанд хадгалах
- Дараагийн удаа дамжуулалтын инстанц хангагдсан үед ашигтай байж болох өгөгдлийг урт хугацаанд хадгалах
- илүү их ...
Эдгээр болон бусад давуу талууд нь Кафка урсгалыг манайх шиг тархсан системд дэлхийн төлөв байдлыг хадгалахад тохиромжтой болгодог. Kafka Streams нь үйлдвэрлэлд маш найдвартай болох нь нотлогдсон (бид үүнийг ашигласнаас хойш бараг ямар ч мессеж алдагдаагүй), түүний чадавхи үүгээр зогсохгүй гэдэгт бид итгэлтэй байна!
Эх сурвалж: www.habr.com