Lag-रहित रियल-टाइम डेटा पाइपलाइन के लिए आर्किटेक्चर सुधार की कहानी

<p>यह Kafka consumer group और partition की संख्या के बीच संबंध, और उससे पैदा होने वाली auto scaling की कठिनाइयों को हल करने के लिए एक नए आर्किटेक्चर को अपनाने की कहानी है.<br /> <br /> - Airbridge सेवा और workload का परिचय<br /> - मौजूदा आर्किटेक्चर की समस्याएँ<br /> - नए आर्किटेक्चर का प्रस्ताव<br /> - विकल्प 1: Spark streaming जैसा driver, executor model<br /> - विकल्प 2: Kafka consumer और application server decouple model<br /> - विकल्प 2 को चुनने के कारण<br /> - Kafka consumer और application server decouple model आर्किटेक्चर<br /> - नए आर्किटेक्चर में ध्यान देने योग्य बातें<br /> - सामना की गई कठिनाइयाँ<br /> - नए आर्किटेक्चर लागू करने के बाद के परिणाम<br /> - आगे और क्या आज़माना बाकी है</p>

[lamanus]

<p>वाह... मैं भी ECS इस्तेमाल करता हूँ, लेकिन मैंने इस स्तर तक इस पर कभी नहीं सोचा था। अच्छा लगा.</p>

[lamanus]

<p>लगता है कि envoy का इस्तेमाल करते समय AZ के बीच ट्रैफ़िक कम करने के लिए किया गया अनुरोध होल्डिंग स्थिति में था।<br /> <br /> https://github.com/aws/aws-app-mesh-roadmap/issues/94</p>;