Kafka kupitia proksi: bootstrap inafanya kazi, lakini miunganisho ya broker inashindikana

Muunganisho wa bootstrap unaweza kufanikiwa huku mteja wa Kafka bado hawezi kuzalisha au kutumia. Seva za bootstrap husaidia mteja kugundua kundi; si lazima ziwe endpoints pekee ambazo mteja ataunganisha nazo.

Metadata ya broker ina anwani zinazotumika kwa miunganisho ya baadaye. Ikiwa majina au bandari hizo hazifikiki kupitia njia ya proksi iliyokusudiwa, muunganisho wa kwanza uliofanikiwa hautatui kazi iliyobaki.

Soma endpoints zilizotangazwa

Linganisha anwani ya bootstrap na anwani za broker ambazo mteja hupokea kwa kweli. Jina la bootstrap la umma linaweza kupeleka kwa majina ya kibinafsi yaliyotangazwa, na kusambaza bandari moja ya ndani hakuandiki upya kila anwani kwenye metadata kiotomatiki.

Tambua pia njia ya proksi inayoungwa mkono na utekelezaji wa mteja. Sifa ya SOCKS ya mfumo wa Java si uhakikisho kwamba usafirishaji wa maktaba unaotegemea NIO hutumia utaratibu wa proksi wa JDK Socket. Kagua mteja halisi wa Kafka na ujumuishaji wa mtandao badala ya kudhani kila soketi ya Java inaheshimu mpangilio sawa.

Mteja anayefahamu proksi anahitaji njia iliyoruhusiwa kuelekea endpoints husika za broker. Mpangilio wa ngazi ya mtandao unahitaji ufikivu na utatuzi wa majina unaolingana. Hivi ni miundo tofauti, na hakuna hata moja inayotolewa kwa kuorodhesha proksi kama seva ya bootstrap pekee.

Tenganisha mipangilio ya itifaki ya usalama na uthibitishaji. Proksi inaweza kuweka njia ya TCP wakati utambulisho wa TLS, uthibitishaji wa SASL au idhini ya broker bado inashindikana.

Kwa uchunguzi, kumbuka endpoint ipi ilishindikana na kama ilitoka kwenye usanidi tuli au metadata iliyorudishwa. Tofauti hiyo hupunguza tatizo zaidi kuliko kubadilisha endpoint iliyokuwa tayari kufikiwa mara kwa mara.