Kafka პროქსის გავლით: bootstrap მუშაობს, broker-თან კავშირები ვერ ხერხდება

Bootstrap კავშირი შეიძლება წარმატებით დამყარდეს, მაშინ როცა Kafka კლიენტს ჯერ კიდევ არ შეუძლია წარმოება ან მოხმარება. Bootstrap სერვერები ეხმარება კლიენტს კლასტერის აღმოჩენაში; ისინი სულაც არ არიან ერთადერთი საბოლოო წერტილები, რომლებთანაც კლიენტი დაუკავშირდება.

Broker-ის მეტამონაცემები შეიცავს მისამართებს, რომლებიც გამოიყენება შემდგომი კავშირებისთვის. თუ ეს სახელები ან პორტები მიუწვდომელია განკუთვნილი პროქსის მარშრუტით, პირველი წარმატებული კავშირი დანარჩენ სამუშაოს არ წყვეტს.

წაიკითხეთ გამოცხადებული საბოლოო წერტილები

შეადარეთ bootstrap მისამართი იმ broker მისამართებს, რომლებსაც კლიენტი რეალურად იღებს. საჯარო bootstrap ფსევდონიმი შეიძლება მიგვიყვანოს კერძო გამოცხადებულ სახელებამდე, და ერთი ლოკალური პორტის გადამისამართება ავტომატურად არ გადაწერს მეტამონაცემების ყველა მისამართს.

ასევე განსაზღვრეთ ის პროქსის გზა, რომელსაც კლიენტის იმპლემენტაცია მხარს უჭერს. Java სისტემის SOCKS თვისება არ არის გარანტია, რომ ბიბლიოთეკის NIO-ზე დაფუძნებული ტრანსპორტი იყენებს JDK Socket-ის პროქსის მექანიზმს. შეამოწმეთ რეალური Kafka კლიენტი და ქსელური ინტეგრაცია და ნუ ჩათვლით, რომ ყველა Java socket ერთსა და იმავე პარამეტრს ემორჩილება.

პროქსის გაცნობიერებულ კლიენტს სჭირდება დაშვებული მარშრუტი შესაბამის broker საბოლოო წერტილებამდე. ქსელურ დონეზე მოწყობა საჭიროებს შესაბამის მიწვდომადობას და სახელების გარჩევას. ეს სხვადასხვა დიზაინია და არც ერთი მათგანი არ მიიღწევა მხოლოდ პროქსის bootstrap სერვერად ჩამოთვლით.

უსაფრთხოების პროტოკოლისა და ავთენტიფიკაციის პარამეტრები ცალ-ცალკე შეინახეთ. პროქსმა შეიძლება დაამყაროს TCP გზა, მაშინ როცა TLS იდენტობა, SASL ავთენტიფიკაცია ან broker-ის ავტორიზაცია მაინც ვერ ხერხდება.

დიაგნოსტიკისთვის აღნიშნეთ, რომელი საბოლოო წერტილი ვერ მოხერხდა და ეს სტატიკური კონფიგურაციიდან მოვიდა თუ დაბრუნებული მეტამონაცემებიდან. ეს განსხვავება გაცილებით მეტად ავიწროებს პრობლემას, ვიდრე უკვე მისაწვდომი საბოლოო წერტილის განმეორებითი შეცვლა.