хүн бүрт Сайн байна уу!
Жижигхэн ном орчуулж эхлэв:
«"
зохиогч: Якуб Кораб, нийтлэгч: O'Reilly Media, Inc., хэвлэгдсэн огноо: 2017 оны 9781492049296-р сар, ISBN: XNUMX.
Номын танилцуулгаас:
"... Энэхүү ном нь Apache ActiveMQ болон Apache Kafka гэсэн хоёр алдартай брокерын технологийг харьцуулж, харьцуулах замаар брокерийн мессежийн системийн талаар хэрхэн бодохыг танд заах болно. Энэ нь тэдний хөгжүүлэгчид систем хоорондын зуучлалын мессежийн нэг талбарт тэс өөр хандлагыг авахад хүргэсэн хэрэглээний тохиолдол болон хөгжүүлэлтийн урамшууллыг тоймлон харуулах болно. Бид эдгээр технологиудыг эхнээс нь авч үзэж, янз бүрийн дизайны сонголтуудын нөлөөллийг онцлон харуулах болно. Та хоёр бүтээгдэхүүний талаар гүн гүнзгий ойлголттой болж, тэдгээрийг хэрхэн ашиглах ёстой, ашиглах ёсгүй, ирээдүйд мессежийн бусад технологийг авч үзэхдээ юуг анхаарах талаар ойлголттой болно. ... "
Одоогоор орчуулагдсан хэсгүүд:
Дууссан бүлгүүдийг орчуулах үед нь нийтлэх болно.
БҮЛЭГ 1
Танилцуулга
Систем хоорондын мессеж бол мэдээллийн технологийн хамгийн бага ойлгогддог салбаруудын нэг юм. Хөгжүүлэгч эсвэл архитекторын хувьд та янз бүрийн хүрээ, мэдээллийн санг сайн мэддэг байж магадгүй. Гэсэн хэдий ч, та брокерт суурилсан мессежийн технологи хэрхэн ажилладаг талаар зөвхөн зэрвэсхэн л мэдэх байх. Хэрэв танд ийм мэдрэмж төрж байгаа бол санаа зовох хэрэггүй, чи сайн нөхөрлөдөг.
Хүмүүс ихэвчлэн мессежийн дэд бүтэцтэй маш хязгаарлагдмал харилцаатай байдаг. Ихэнхдээ тэд аль эрт бий болсон системд холбогдож, эсвэл интернетээс түгээлтийн иж бүрдэл татаж аваад, PROM дээр суулгаж, код бичиж эхэлдэг. PROM-д дэд бүтцийг ажиллуулсны дараа үр дүн нь холилдож болно: гацах үед мессеж алдагдах, илгээлт нь таны бодож байсан шиг ажиллахгүй байх, эсвэл брокерууд таны үйлдвэрлэгчдийг өлгөх эсвэл хэрэглэгчдэд мессеж илгээдэггүй.
Танил сонсогдож байна уу?
Таны мессежийн код одоохондоо хэвийн ажилладаг нийтлэг хувилбар. Энэ нь ажиллахаа болих хүртэл. Энэ үе нь сонор сэрэмжийг сулруулж, аюулгүй байдлын хуурамч мэдрэмжийг төрүүлдэг бөгөөд энэ нь технологийн үндсэн зан үйлийн талаархи хуурамч санаан дээр үндэслэсэн кодыг бүр ч илүү болгодог. Бүх зүйл буруугаар эргэж эхлэхэд та эвгүй үнэнтэй тулгарах болно: та бүтээгдэхүүний үндсэн зан төлөвийг, эсвэл гүйцэтгэл ба бат бөх байдал, гүйлгээний эсрэг гэх мэт зохиогчдын сонгосон нөхцлүүдийг үнэхээр ойлгоогүй гэсэн үг. хэвтээ өргөтгөх чадвар.
Брокерууд хэрхэн ажилладаг талаар гүнзгий ойлголтгүй бол хүмүүс мессежийн системийнхээ талаар үндэслэлтэй мэт санагдах нэхэмжлэл гаргадаг, тухайлбал:
- Систем хэзээ ч мессежээ алдахгүй
- Мессежийг дараалан боловсруулах болно
- Хэрэглэгч нэмэх нь системийг илүү хурдан болгоно
- Мессежийг зөвхөн нэг удаа хүргэх болно
Харамсалтай нь эдгээр мэдэгдлийн зарим нь зөвхөн тодорхой нөхцөл байдалд хамаарах таамаглал дээр үндэслэсэн байдаг бол зарим нь үнэн биш юм.
Энэхүү ном нь Apache ActiveMQ болон Apache Kafka гэсэн хоёр алдартай брокерын технологийг харьцуулж, харьцуулан брокерийн мессежийн системийг хэрхэн ойлгохыг танд заах болно. Энэ нь тэдний хөгжүүлэгчид систем хоорондын зуучлалын мессежийн нэг талбарт тэс өөр хандлагыг авахад хүргэсэн хэрэглээний тохиолдол болон хөгжүүлэлтийн урамшууллыг тоймлон харуулах болно. Бид эдгээр технологиудыг эхнээс нь авч үзэж, янз бүрийн дизайны сонголтуудын нөлөөллийг онцлон харуулах болно. Та хоёр бүтээгдэхүүний талаар гүн гүнзгий ойлголттой болж, тэдгээрийг хэрхэн ашиглах ёстой, ашиглах ёсгүй, ирээдүйд мессежийн бусад технологийг авч үзэхдээ юуг анхаарах талаар ойлголттой болно.
Эхлэхээсээ өмнө үндсэн ойлголтуудыг авч үзье.
Мессежийн систем гэж юу вэ, яагаад хэрэгтэй вэ
Хоёр програм хоорондоо харилцахын тулд эхлээд интерфейсийг тодорхойлох ёстой. Энэхүү интерфэйсийг тодорхойлоход HTTP, MQTT эсвэл SMTP гэх мэт тээвэрлэлт эсвэл протоколыг сонгох, систем солилцох мессежийн форматыг тохиролцох зэрэг орно. Энэ нь мессежийн ачааллын зардлын шаардлага бүхий XML схемийг тодорхойлох гэх мэт хатуу процесс байж болно, эсвэл HTTP хүсэлтийн зарим хэсэг нь үйлчлүүлэгчийн танигчийг агуулна гэсэн хоёр хөгжүүлэгчийн хооронд байгуулсан гэрээ гэх мэт албан ёсны бус байж болно. .
Мессежийн формат, илгээх дараалал нь системүүдийн хооронд нийцэж байвал бусад системийн хэрэгжилтэд санаа зовохгүйгээр хоорондоо харилцах боломжтой болно. Ашигласан програмчлалын хэл эсвэл хүрээ гэх мэт эдгээр системийн дотоод байдал нь цаг хугацааны явцад өөрчлөгдөж болно. Гэрээ өөрөө хадгалагдсаар л байвал нөгөө талдаа харилцан үйлчлэл өөрчлөгдөхгүй байж болно. Энэхүү интерфэйсээр хоёр системийг үр дүнтэйгээр салгаж (салгадаг).
Мессежийн систем нь ихэвчлэн илгээгчийг хүлээн авагч эсвэл хүлээн авагчаас салгах (тусгаарлах) зорилгоор харилцан үйлчилдэг хоёр системийн хооронд зуучлагчийг оролцуулдаг. Энэ тохиолдолд мессежийн систем нь илгээгч нь хүлээн авагч хаана байрлаж байгаа, идэвхтэй байгаа эсэх, тэдгээрийн хэд нь байгааг мэдэхгүйгээр мессеж илгээх боломжийг олгодог.
Мессежийн систем шийддэг асуудлуудын хэд хэдэн зүйрлэлийг авч үзээд зарим үндсэн нэр томъёог танилцуулъя.
Цэгээс цэг рүү
Александра Адам руу илгээмж явуулахаар шуудан руу явав. Тэр цонхны дэргэд очоод илгээмжийг ажилтанд өгнө. Ажилтан илгээмжийг аваад Александрад төлбөрийн баримт өгнө. Илгээмжийг илгээх үед Адам гэртээ байх шаардлагагүй. Александра илгээмжийг ирээдүйд хэзээ нэгэн цагт Адамд хүргэж өгөх бөгөөд бизнесээ үргэлжлүүлж чадна гэдэгт итгэлтэй байна. Хожим нь, хэзээ нэгэн цагт Адам илгээмж хүлээн авав.
Энэ бол мессежийн загварын жишээ юм цэгээс цэг рүү. Энд байгаа шуудангийн газар нь багцын хуваарилалтын механизмын үүрэг гүйцэтгэдэг бөгөөд багц бүрийг нэг удаа хүргэхийг баталгаажуулдаг. Шуудангийн салбарыг ашиглах нь илгээмжийг илгээх үйлдлийг илгээмжийг хүргэхээс тусгаарладаг.
Сонгодог мессежийн системд цэгээс цэг хүртэлх загварыг дамжуулан хэрэгжүүлдэг дараалал. Дараалал нь нэг буюу хэд хэдэн хэрэглэгч бүртгүүлэх боломжтой FIFO (эхний орсон, хамгийн түрүүнд гарах) буферын үүрэг гүйцэтгэдэг. Мессеж бүрийг зөвхөн хүргэнэ захиалсан хэрэглэгчдийн нэг. Дараалал нь ихэвчлэн хэрэглэгчдийн дунд мессежийг шударгаар түгээхийг хичээдэг. Зөвхөн нэг хэрэглэгч энэ мессежийг хүлээн авах болно.
"Удаан эдэлгээтэй" гэсэн нэр томъёог дараалалд хэрэглэдэг. Найдвартай байдал Энэ нь хэрэглэгч мессеж хүргэх дараалалд бүртгүүлэх хүртэл идэвхтэй захиалагч байхгүй үед мессежийн систем нь мессежийг хадгалахыг баталгаажуулдаг үйлчилгээний өмч юм.
Найдвартай байдлыг ихэвчлэн андуурдаг тууштай байдал мөн хэдийгээр хоёр нэр томьёо солигдох боловч өөр өөр үүргийг гүйцэтгэдэг. Тогтвортой байдал нь мессежийг хүлээн авах болон хэрэглэгч рүү илгээх хооронд мессежийн систем ямар нэгэн төрлийн санах ойд бичигдсэн эсэхийг тодорхойлдог. Дараалалд илгээсэн мессежүүд тогтвортой байж болно, үгүй ч байж болно.
Ашиглалтын тохиолдол нь мессеж дээр нэг үйлдэл хийх шаардлагатай үед цэгээс цэг рүү мессежийг ашигладаг. Жишээлбэл, дансанд мөнгө байршуулах эсвэл хүргэлтийн захиалгыг биелүүлэх. Мессежийн систем яагаад дангаараа нэг удаагийн хүргэлт хийх чадваргүй, яагаад дараалал нь хамгийн сайндаа хүргэлтийн баталгаа өгч чадах талаар бид дараа хэлэлцэх болно. ядаж нэг удаа.
Нийтлэгч-Захиалагч
Габриелла хурлын дугаар руу залгав. Тэрээр чуулганд холбогдож байхдаа бусад оролцогчдын хамт илтгэгчийн хэлсэн бүх зүйлийг сонсдог. Харанхуй болоход тэр хэлсэн зүйлээ алддаг. Дахин холбогдох үед тэр юу ярьж байгааг үргэлжлүүлэн сонсдог.
Энэ бол мессежийн загварын жишээ юм нийтлэх-захиалах. Хурлын дуудлага нь өргөн нэвтрүүлгийн механизмын үүрэг гүйцэтгэдэг. Ярьж буй хүнд яг хэдэн хүн дуудлага хийж байгаа нь хамаагүй - систем нь одоо холбогдсон хэн бүхэнд юу ярьж байгааг сонсох боломжийг олгодог.
Сонгодог мессежийн системд нийтлэх-захиалах мессежийн загварыг дамжуулан хэрэгжүүлдэг орой. Сэдэв нь хурлын механизмтай адил өргөн нэвтрүүлгийн аргыг өгдөг. Сэдэв рүү мессеж илгээх үед түүнийг тараадаг бүх захиалсан хэрэглэгчдэд зориулсан.
Сэдвүүд ихэвчлэн найдваргүй (тэсвэргүй). Чуулганы дуудлага дээр юу ярьж байгааг сонсож чаддаггүй сонсогчтой адил сонсогч офлайн үед сэдвийн захиалагчид офлайн байхдаа илгээсэн аливаа мессежийг алддаг. Энэ шалтгааны улмаас оройнууд нь хүргэх баталгааг өгдөг гэж бид хэлж чадна. нэгээс илүүгүй удаа хэрэглэгч бүрт.
Нийтлэх-Захиалах мессежийг ихэвчлэн мессежүүд мэдээллийн шинж чанартай, нэг мессеж алдах нь тийм ч чухал биш үед ашигладаг. Жишээлбэл, сэдэв нь секундэд нэг удаа мэдрэгчийн бүлгээс температурын заалтыг дамжуулж болно. Одоогийн температурыг сонирхож байгаа, сэдэвт бүртгүүлдэг систем нь мессеж алгасаад санаа зовохгүй - өөр нэг нь удахгүй ирнэ.
эрлийз загварууд
Дэлгүүрийн вэбсайт нь захиалгын мессежийг "мессежийн дараалал"-д оруулдаг. Эдгээр мессежийн гол хэрэглэгч нь гүйцэтгэх тогтолцоо юм. Нэмж дурдахад аудитын системд дараа нь хянах зорилгоор эдгээр захиалгын мессежийн хуулбар байх ёстой. Системүүд өөрөө хэсэг хугацаанд ажиллахгүй байсан ч хоёр систем хоёулаа мессежийг алдах боломжгүй. Вэбсайт нь бусад системийг мэддэг байх ёсгүй.
Ашиглалтын тохиолдлууд нь ихэвчлэн олон системд мессежийн хуулбар шаардлагатай байдаг ба мессеж алдагдахаас урьдчилан сэргийлэхийн тулд найдвартай, тууштай байх шаардлагатай үед нийтлэх-захиалах болон цэгээс цэг рүү мессежийн загваруудыг хослуулахыг шаарддаг.
Эдгээр тохиолдолд зурвас бүрийг эдгээр мессежийг сонирхож буй тусдаа систем рүү илгээдэг, гэхдээ систем бүр хэд хэдэн хэрэглэгчийг тодорхойлох боломжтой байхын тулд мессежийг үндсэндээ сэдэв шиг түгээдэг очих газар (дараалал ба сэдвийн ерөнхий нэр томъёо) шаардлагатай. Ирж буй мессежийг хүлээн авдаг бөгөөд энэ нь дараалалтай адил юм. Энэ тохиолдолд унших төрөл нь - оролцогч тал бүрт нэг удаа. Эдгээр эрлийз чиглэлүүд нь ихэвчлэн удаан эдэлгээтэй байхыг шаарддаг тул хэрэглэгч салгавал тухайн үед илгээсэн мессежийг хэрэглэгч дахин холбогдох үед хүлээн авдаг.
Гибрид загварууд нь шинэ зүйл биш бөгөөд ActiveMQ (сэдвүүд болон дарааллыг нэгтгэсэн виртуал эсвэл нийлмэл чиглэлүүдээр дамжуулан) болон Кафка (далд байдлаар, зорьсон газрын дизайны үндсэн өмч) зэрэг ихэнх мессежийн системд хэрэглэгдэх боломжтой.
Одоо бид зарим үндсэн нэр томьёотой бөгөөд мессежийн систем нь юунд ашигтай байж болох талаар ойлголттой болсон тул дэлгэрэнгүй мэдээлэл рүү орцгооё.
Орчуулга хийгдсэн:
Дараагийн орчуулсан хэсэг:
Үргэлжлэл бий…
Эх сурвалж: www.habr.com