Hej Habr!
Ni memorigas al vi, ke sekvante la libron pri ni publikigis same interesan verkon pri la biblioteko .
Nuntempe, la komunumo nur lernas la limojn de ĉi tiu potenca ilo. Do, ĵus aperis artikolo, kies tradukon ni ŝatus konigi al vi. Laŭ sia propra sperto, la aŭtoro rakontas kiel igi Kafka Streams en distribuitan datumstokadon. Ĝuu legadon!
Apache biblioteko uzata tutmonde en entreprenoj por distribuita flua prilaborado aldone al Apache Kafka. Unu el la subtaksitaj aspektoj de ĉi tiu kadro estas, ke ĝi permesas vin stoki lokan ŝtaton produktitan surbaze de fadena prilaborado.
En ĉi tiu artikolo, mi rakontos al vi, kiel nia kompanio sukcesis profite uzi ĉi tiun ŝancon dum disvolvado de produkto por sekureco de nuba aplikaĵo. Uzante Kafka Streams, ni kreis komunajn ŝtatajn mikroservojn, ĉiu el kiuj funkcias kiel mistolerema kaj tre havebla fonto de fidindaj informoj pri la stato de objektoj en la sistemo. Por ni, ĉi tio estas paŝo antaŭen kaj laŭ fidindeco kaj facileco de subteno.
Se vi interesiĝas pri alternativa aliro, kiu ebligas al vi uzi ununuran centran datumbazon por subteni la formalan staton de viaj objektoj, legu ĝin, ĝi estos interese...
Kial ni pensis, ke estas tempo ŝanĝi la manieron kiel ni laboras kun komuna ŝtato
Ni bezonis konservi la staton de diversaj objektoj surbaze de agentaj raportoj (ekzemple: ĉu la retejo estis atakita)? Antaŭ ol migri al Kafka Streams, ni ofte dependis de ununura centra datumbazo (+ servo API) por ŝtata administrado. Ĉi tiu aliro havas siajn malavantaĝojn: konservi konsistencon kaj sinkronigon fariĝas vera defio. La datumbazo povas fariĝi proplemkolo aŭ finiĝi en kaj suferas de neantaŭvidebleco.
Figuro 1: Tipa split-ŝtata scenaro vidita antaŭ la transiro al
Kafka kaj Kafka Streams: agentoj komunikas siajn opiniojn per API, ĝisdatigita stato estas kalkulita per centra datumbazo
Renkontu Kafka Streams, faciligante krei komunajn ŝtatajn mikroservojn
Antaŭ proksimume jaro, ni decidis rigardi niajn komunajn ŝtatscenarojn por trakti ĉi tiujn problemojn. Ni tuj decidis provi Kafka Streams - ni scias kiom skalebla, tre havebla kaj mistolerema ĝi estas, kian riĉan fluan funkcion ĝi havas (transformoj, inkluzive de ŝtataj). Ĝuste kion ni bezonis, sen mencii kiom matura kaj fidinda fariĝis la mesaĝsistemo en Kafka.
Ĉiu el la ŝtataj mikroservoj, kiujn ni kreis, estis konstruita supre de Kafka Streams-instanco kun sufiĉe simpla topologio. Ĝi konsistis el 1) fonto 2) procesoro kun konstanta ŝlosilvalora vendejo 3) lavujo:
Figuro 2: La defaŭlta topologio de niaj streaming-instancoj por ŝtataj mikroservoj. Notu, ke ekzistas ankaŭ deponejo ĉi tie, kiu enhavas planajn metadatumojn.
En ĉi tiu nova aliro, agentoj komponas mesaĝojn kiuj estas provizitaj en la fontan temon, kaj konsumantoj - ekzemple, poŝta sciiga servo - ricevas la komputitan komunan staton tra la lavujo (eliga temo).
Figuro 3: Nova ekzempla taskofluo por scenaro kun komunaj mikroservoj: 1) la agento generas mesaĝon kiu alvenas al la Kafka fontotemo; 2) mikroservo kun komuna stato (uzante Kafka Streams) prilaboras ĝin kaj skribas la kalkulitan staton al la fina Kafka temo; post kio 3) konsumantoj akceptas la novan ŝtaton
He, ĉi tiu enkonstruita ŝlosilvalora vendejo estas efektive tre utila!
Kiel menciite supre, nia komuna ŝtata topologio enhavas ŝlosilvaloran vendejon. Ni trovis plurajn eblojn por uzi ĝin, kaj du el ili estas priskribitaj sube.
Opcio numero 1: Uzu ŝlosilvaloran vendejon por kalkuloj
Nia unua ŝlosilvalora vendejo enhavis la helpajn datumojn, kiujn ni bezonis por kalkuloj. Ekzemple, en kelkaj kazoj la komuna ŝtato estis determinita per la principo de "plimultaj voĉoj". La deponejo povus teni ĉiujn plej novajn agentajn raportojn pri la stato de iu objekto. Tiam, kiam ni ricevis novan raporton de unu agento aŭ alia, ni povus konservi ĝin, retrovi raportojn de ĉiuj aliaj agentoj pri la stato de la sama objekto el stokado, kaj ripeti la kalkulon.
Figuro 4 malsupre montras kiel ni elmontris la ŝlosilon/valoran vendejon al la pretigmetodo de la procesoro por ke la nova mesaĝo povus esti procesita.
Ilustraĵo 4: Ni malfermas aliron al la ŝlosilvalora vendejo por la pretigmetodo de la procesoro (post tio, ĉiu skripto, kiu funkcias kun komuna stato, devas efektivigi la metodon doProcess)
Opcio #2: Krei CRUD API supre de Kafka Streams
Establinte nian bazan taskofluon, ni komencis provi skribi RESTful CRUD API por niaj komunaj ŝtataj mikroservoj. Ni volis povi retrovi la staton de iuj aŭ ĉiuj objektoj, same kiel agordi aŭ forigi la staton de objekto (utila por subteno de la backend).
Por subteni ĉiujn Get State API-ojn, kiam ajn ni bezonis rekalkuli la staton dum prilaborado, ni konservis ĝin en enkonstruita ŝlosilvalora vendejo dum longa tempo. En ĉi tiu kazo, fariĝas sufiĉe simple efektivigi tian API uzante ununuran ekzemplon de Kafka Streams, kiel montrite en la suba listo:
Figuro 5: Uzante la enkonstruitan ŝlosilvaloran vendejon por akiri la antaŭkomputitan staton de objekto
Ĝisdatigi la staton de objekto per la API ankaŭ estas facile efektivigi. Esence, ĉio, kion vi devas fari, estas krei Kafka-produktanton kaj uzi ĝin por fari rekordon, kiu enhavas la novan ŝtaton. Ĉi tio certigas, ke ĉiuj mesaĝoj generitaj per la API estos prilaboritaj same kiel tiuj ricevitaj de aliaj produktantoj (ekz. agentoj).
Figuro 6: Vi povas agordi la staton de objekto uzante la Kafka-produktanton
Malgranda komplikaĵo: Kafka havas multajn sekciojn
Poste, ni volis distribui la pretigan ŝarĝon kaj plibonigi haveblecon provizante aron de kunŝtataj mikroservoj per scenaro. Agordo estis facila: post kiam ni agordis ĉiujn okazojn por funkcii sub la sama aplika ID (kaj la samaj bootstrap-serviloj), preskaŭ ĉio alia estis farita aŭtomate. Ni ankaŭ precizigis, ke ĉiu fonttemo konsistus el pluraj sekcioj, tiel ke al ĉiu kazo povus esti asignita subaro de tiaj sekcioj.
Mi ankaŭ mencios, ke estas ofta praktiko fari rezervan kopion de la ŝtata vendejo por ke, ekzemple, en kazo de reakiro post malsukceso, translokigu ĉi tiun kopion al alia kazo. Por ĉiu ŝtata butiko en Kafka Streams, reproduktita temo estas kreita kun ŝanĝprotokolo (kiu spuras lokajn ĝisdatigojn). Tiel, Kafka senĉese subtenas la ŝtatan vendejon. Sekve, en kazo de malsukceso de unu aŭ alia Kafka Streams-instanco, la ŝtata vendejo povas esti rapide restarigita sur alia kazo, kie la respondaj sekcioj iros. Niaj provoj montris, ke tio estas farita en demando de sekundoj, eĉ se estas milionoj da diskoj en la vendejo.
Moviĝante de ununura mikroservo kun komuna stato al areto de mikroservoj, fariĝas malpli bagatela efektivigi la Get State API. En la nova situacio, la ŝtata vendejo de ĉiu mikroservo enhavas nur parton de la ĝenerala bildo (tiuj objektoj, kies ŝlosiloj estis mapitaj al specifa sekcio). Ni devis determini, kiu okazo enhavis la staton de la objekto, kiun ni bezonis, kaj ni faris tion surbaze de la fadenaj metadatenoj, kiel montrite sube:
Figuro 7: Uzante fluajn metadatenojn, ni determinas de kiu okazo pridemandi la staton de la dezirata objekto; simila aliro estis uzata kun la GET ALL API
Ŝlosilaj Trovoj
Ŝtataj butikoj en Kafka Streams povas funkcii kiel fakta distribuita datumbazo,
- konstante reproduktita en Kafka
- CRUD API povas facile esti konstruita aldone al tia sistemo
- Pritrakti plurajn sekciojn estas iom pli komplika
- Eblas ankaŭ aldoni unu aŭ plurajn ŝtatajn butikojn al la fluanta topologio por stoki helpajn datumojn. Ĉi tiu opcio povas esti uzata por:
- Longperspektiva stokado de datumoj necesaj por kalkuloj dum flutraktado
- Longdaŭra konservado de datumoj, kiuj povas esti utilaj la venontan fojon, kiam la streaming-instanco estas provizita
- multe pli...
Ĉi tiuj kaj aliaj avantaĝoj igas Kafka Streams bone taŭga por konservi tutmondan staton en distribuita sistemo kiel la nia. Kafka Streams pruvis esti tre fidinda en produktado (ni preskaŭ ne havis mesaĝon perdon de kiam ĝi estis deplojita), kaj ni certas, ke ĝiaj kapabloj ne ĉesos tie!
fonto: www.habr.com