Saluton ĉiuj!
Mi komencis traduki malgrandan libron:
«",
aŭtoro: Jakub Korab, eldonejo: O'Reilly Media, Inc., eldondato: junio 2017, ISBN: 9781492049296.
De la enkonduko al la libro:
"... Ĉi tiu libro instruos vin kiel pensi pri makleristaj mesaĝsistemoj, komparante kaj kontrastante du popularajn makleristteknologiojn: Apache ActiveMQ kaj Apache Kafka. Ĝi skizos la uzkazojn kaj evoluinstigojn, kiuj igis iliajn programistojn preni tre malsamajn alirojn al la sama areo - mesaĝado inter sistemoj kun meza makleristo. Ni rigardos ĉi tiujn teknologiojn de la fundo kaj reliefigos la efikon de diversaj dezajnaj elektoj survoje. Vi akiros profundan komprenon pri ambaŭ produktoj, komprenon pri kiel ili devas kaj ne estu uzataj, kaj komprenon pri tio, kion serĉi kiam vi konsideras aliajn mesaĝajn teknologiojn en la estonteco. ... ”
Partoj tradukitaj ĝis nun:
Mi afiŝos finitajn ĉapitrojn dum ili estas tradukitaj.
ĈAPITRO 1
Enkonduko
Sistem-al-sistema mesaĝado estas unu el la malplej komprenitaj areoj de IT. Kiel programisto aŭ arkitekto, vi eble tre konas diversajn kadrojn kaj datumbazojn. Tamen, verŝajne vi nur konas kiel funkcias mesaĝaj teknologioj bazitaj en makleristo. Se vi sentas tiel, ne maltrankviliĝu, vi estas en bona kompanio.
Homoj kutime havas tre limigitan kontakton kun la mesaĝa infrastrukturo. Ili ofte konektas al sistemo kreita antaŭ longe, aŭ elŝutas distribuon de la Interreto, instalas ĝin en PROM kaj komencas skribi kodon por ĝi. Post funkciado de la infrastrukturo en PROM, la rezultoj povas esti miksitaj: mesaĝoj perdiĝas pro misfunkciadoj, sendo ne funkcias kiel vi atendis, aŭ makleristoj "pendigas" viajn produktantojn aŭ ne sendas mesaĝojn al viaj konsumantoj.
Sonas konata?
Ofta scenaro estas kie via mesaĝa kodo funkcias bonege, por la momento. Ĝis ĝi ĉesos funkcii. Ĉi tiu periodo trankviligas onies gardiston en falsan senton de sekureco, kondukante al pli da kodo bazita sur malveraj kredoj pri la fundamenta konduto de la teknologio. Kiam aferoj misfunkcias, vi alfrontas maloportunan veron: ke vi ne vere komprenis la suban konduton de la produkto aŭ la kompromisojn elektitajn de la aŭtoroj, kiel rendimento kontraŭ fidindeco aŭ transakcebleco kontraŭ horizontala skaleblo. .
Sen profunda kompreno pri kiel funkcias makleristoj, homoj faras ŝajne akcepteblajn deklarojn pri siaj mesaĝaj sistemoj, kiel ekzemple:
- La sistemo neniam perdos mesaĝojn
- Mesaĝoj estos prilaboritaj sinsekve
- Aldonante konsumantojn rapidigos la sistemon
- Mesaĝoj estos liveritaj nur unufoje
Bedaŭrinde, iuj el ĉi tiuj deklaroj baziĝas sur supozoj, kiuj validas nur sub certaj cirkonstancoj, dum aliaj estas simple malĝustaj.
Ĉi tiu libro instruos vin kiel pensi pri broker-bazitaj mesaĝsistemoj, komparante kaj kontrastante du popularajn makleristteknologiojn: Apache ActiveMQ kaj Apache Kafka. Ĝi skizos la uzkazojn kaj evoluinstigojn, kiuj igis iliajn programistojn preni tre malsamajn alirojn al la sama areo - mesaĝado inter sistemoj kun meza makleristo. Ni rigardos ĉi tiujn teknologiojn de la fundo kaj reliefigos la efikon de diversaj dezajnaj elektoj survoje. Vi akiros profundan komprenon pri ambaŭ produktoj, komprenon pri kiel ili devas kaj ne devas esti uzataj, kaj komprenon pri tio, kion serĉi kiam vi konsideras aliajn mesaĝajn teknologiojn en la estonteco.
Antaŭ ol komenci, ni transiru la bazojn.
Kio estas Mesaĝa Sistemo kaj kial ĝi bezonas?
Por ke du aplikaĵoj komunikiĝu inter si, ili unue devas difini interfacon. Difini ĉi tiun interfacon implikas elekti transporton aŭ protokolon, kiel HTTP, MQTT aŭ SMTP, kaj negoci la mesaĝformatojn kiuj estos interŝanĝitaj inter la sistemoj. Tio povas esti strikta procezo, kiel ekzemple difinado de XML-skemo kun mesaĝkostopostuloj, aŭ ĝi povas esti multe malpli formala, kiel ekzemple interkonsento inter du programistoj ke iu parto de la HTTP-peto enhavos la klientidentigilon.
Tiel longe kiel la formato de mesaĝoj kaj la ordo en kiu ili estas senditaj estas konsekvencaj inter sistemoj, ili povas komuniki unu kun la alia sen zorgi pri la efektivigo de la alia sistemo. La internoj de ĉi tiuj sistemoj, kiel la programlingvo aŭ kadro uzata, povas ŝanĝiĝi kun la tempo. Tiel longe kiel la kontrakto mem estas konservita, la interagado povas daŭri sen ŝanĝoj de la alia flanko. La du sistemoj estas efike malkunligitaj (apartitaj) per ĉi tiu interfaco.
Mesaĝsistemoj tipe implikas peranton inter du sistemoj kiuj interagas por plue malkunligi (apartigi) la sendinton de la ricevanto aŭ ricevantoj. En ĉi tiu kazo, la mesaĝa sistemo permesas al la sendinto sendi mesaĝon sen scii kie estas la ricevanto, ĉu li estas aktiva aŭ kiom da okazoj estas.
Ni rigardu kelkajn analogiojn por la specoj de problemoj kiujn mesaĝa sistemo solvas kaj enkonduku kelkajn bazajn terminojn.
Punkto-al-Punkto
Alexandra iras al la poŝtejo por sendi al Adamo pakaĵon. Ŝi iras al la fenestro kaj donas al la dungito la pakaĵon. La dungito prenas la pakaĵon kaj donas al Alexandra kvitancon. Adamo ne bezonas esti hejme kiam la pakaĵo estas sendita. Alexandra estas memcerta ke la pakaĵo estos liverita al Adamo ĉe iu punkto en la estonteco kaj povas daŭri daŭrigi sian komercon. Poste ĉe iu punkto Adamo ricevas pakaĵon.
Ĉi tio estas ekzemplo de mesaĝa modelo punkto-al-punkto. La poŝtejo ĉi tie funkcias kiel pakaĵa distribua mekanismo, certigante ke ĉiu pakaĵo estas liverita unufoje. Uzado de poŝtejo apartigas la agon sendi pakaĵon de la livero de la pakaĵo.
En klasikaj mesaĝsistemoj, la punkto-al-punkta modelo estas efektivigita tra atendovicoj. La atendovico funkcias kiel FIFO (unua enen, unue eliranta) bufro al kiu povas esti abonita de unu aŭ pluraj konsumantoj. Ĉiu mesaĝo estas transdonita nur al unu el la abonitaj konsumantoj. Vicovicoj tipe provas distribui mesaĝojn juste inter konsumantoj. Nur unu konsumanto ricevos ĉi tiun mesaĝon.
La esprimo "daŭra" estas aplikata al atendovicoj. Fidindeco estas servoposedaĵo kiu certigas ke la mesaĝsistemo persistos mesaĝojn en la foresto de aktivaj abonantoj ĝis konsumanto abonas al la atendovico por mesaĝlivero.
Oni ofte konfuzas kun fidindeco persisto kaj kvankam la du terminoj estas uzataj interŝanĝeble, ili servas malsamajn funkciojn. Persisto determinas ĉu la mesaĝsistemo skribas mesaĝon al iu speco de stokado inter ricevado de ĝi kaj sendado de ĝi al la konsumanto. Mesaĝoj senditaj al la vico povas aŭ ne esti persistaj.
Punkt-al-punkta mesaĝado estas uzata kiam la uzkazo postulas unufojan agon sur la mesaĝo. Ekzemploj inkluzivas deponi financon en konton aŭ plenumi liverordon. Ni diskutos poste kial la mesaĝa sistemo memstare ne kapablas provizi unufojan liveraĵon kaj kial vicoj povas en la plej bona kazo provizi liveran garantion almenaŭ unufoje.
Eldonisto-Abonanto
Gabriella vokas la konferencan numeron. Dum ŝi estas ligita al la konferenco, ŝi aŭdas ĉion, kion la parolanto diras, kune kun la ceteraj alvokaj partoprenantoj. Kiam ŝi agordas, ŝi maltrafas tion, kio estas dirita. Rekonekte, ŝi daŭre aŭdas kio estas dirita.
Ĉi tio estas ekzemplo de mesaĝa modelo eldoni-aboni. Konferencovoko funkcias kiel elsenda mekanismo. Al la parolanto ne gravas kiom da homoj estas nuntempe ĉe la voko - la sistemo certigas, ke iu ajn nuntempe konektita aŭdos tion, kio estas dirita.
En klasikaj mesaĝsistemoj, la publikig-aboni mesaĝmodelo estas efektivigita tra pintoj. Temo disponigas la saman elsendan metodon kiel la konferenca mekanismo. Kiam mesaĝo estas sendita al temo, ĝi estas distribuata por ĉiuj abonitaj uzantoj.
Temoj estas kutime nefidinda (nedaŭra). Same kiel aŭskultanto, kiu ne povas aŭdi tion, kio estas dirita en konferenco, kiam la aŭskultanto malkonektas, la abonantoj de la temo maltrafas iujn ajn mesaĝojn kiuj estas senditaj dum ili estas eksterrete. Tial ni povas diri, ke temoj provizas liveran garantion ne pli ol unufoje por ĉiu konsumanto.
Publik-aboni mesaĝado estas tipe uzita kiam la mesaĝoj estas informaj en naturo kaj la perdo de unu mesaĝo ne estas precipe signifa. Ekzemple, temo povas elsendi temperaturvalorojn de grupo de sensiloj unufoje je sekundo. Sistemo, kiu interesiĝas pri la nuna temperaturo kaj kiu abonas temon, ne maltrankviliĝos, se ĝi maltrafas mesaĝon – alia alvenos baldaŭ.
hibridaj modeloj
La retejo de la vendejo metas mendmesaĝojn en "mesaĝvico." La ĉefa konsumanto de ĉi tiuj mesaĝoj estas la plenuma sistemo. Krome, la revizia sistemo devus havi kopiojn de ĉi tiuj ordonmesaĝoj por posta spurado. Ambaŭ sistemoj ne povas permesi mesaĝojn trapasi, eĉ se la sistemoj mem estas neatingeblaj dum iom da tempo. La retejo ne devus esti konscia pri aliaj sistemoj.
Uzkazoj ofte postulas kombinaĵon de publikigi-aboni kaj punkt-al-punktaj mesaĝmodeloj, kiel ekzemple kiam multoblaj sistemoj postulas kopion de mesaĝo kaj kaj fidindeco kaj persisto estas postulataj por malhelpi mesaĝperdon.
Ĉi tiuj kazoj postulas cellokon (ĝenerala termino por atendovicoj kaj temoj) kiu distribuas mesaĝojn baze kiel temo, tiel ke ĉiu mesaĝo estas sendita al aparta sistemo interesita pri tiuj mesaĝoj, sed ankaŭ en kiu ĉiu sistemo povas difini plurajn konsumantojn kiuj ricevas envenantajn. mesaĝoj, kiu pli similas al vico. La legotipo en ĉi tiu kazo estas unufoje por ĉiu koncernato. Tiuj hibridaj cellokoj ofte postulas fortikecon tiel ke se konsumanto iĝas eksterrete, mesaĝoj kiuj estas senditaj en tiu tempo estas ricevitaj post kiam la konsumanto rekonektas.
Hibridaj modeloj ne estas novaj kaj povas esti uzitaj en la plej multaj mesaĝsistemoj, inkluzive de kaj ActiveMQ (per virtualaj aŭ kunmetitaj cellokoj kiuj kombinas temojn kaj atendovicojn) kaj Kafka (implicite, kiel fundamenta posedaĵo de ĝia celdezajno).
Nun kiam ni havas iom da baza terminologio kaj kompreno pri tio, por kio ni povus uzi mesaĝsistemon, ni iru al la detaloj.
Traduko farita:
La jena tradukita parto:
Daŭrigota…
fonto: www.habr.com