काफ्का वर एसिंक्रोनस API सह रिफंड टूल सेवा विकसित करण्याचा अनुभव

सुव्यवस्थित प्रक्रिया आणि डझनभर एकमेकांशी जोडलेल्या सेवांसह लमोडासारख्या मोठ्या कंपनीला आपला दृष्टिकोन लक्षणीय बदलण्यास काय भाग पाडू शकते? प्रेरणा पूर्णपणे भिन्न असू शकते: विधान ते सर्व प्रोग्रामरमध्ये अंतर्निहित प्रयोग करण्याच्या इच्छेपर्यंत.

परंतु याचा अर्थ असा नाही की आपण अतिरिक्त फायद्यांवर विश्वास ठेवू शकत नाही. जर तुम्ही काफ्का (थोडे). मोठ्या शॉट्स आणि मनोरंजक शोधांबद्दल देखील निश्चितपणे चर्चा होईल - प्रयोग त्यांच्याशिवाय करू शकत नाही.

अस्वीकरण: हा लेख हायलोड++ वर नोव्हेंबर 2018 मध्ये सेर्गेने आयोजित केलेल्या भेटीतील सामग्रीवर आधारित आहे. काफ्कासोबत काम करताना लामोडा यांच्या थेट अनुभवाने श्रोत्यांना शेड्यूलवरील इतर अहवालांपेक्षा कमी आकर्षित केले. आम्हाला वाटते की तुम्ही समविचारी लोक शोधू शकता आणि नेहमी शोधू शकता याचे हे एक उत्कृष्ट उदाहरण आहे आणि HighLoad++ चे आयोजक यासाठी अनुकूल वातावरण निर्माण करण्याचा प्रयत्न करत राहतील.

प्रक्रियेबद्दल

Lamoda हे एक मोठे ई-कॉमर्स प्लॅटफॉर्म आहे ज्याचे स्वतःचे संपर्क केंद्र, वितरण सेवा (आणि अनेक संलग्न), एक फोटो स्टुडिओ, एक प्रचंड गोदाम आहे आणि हे सर्व त्याच्या स्वतःच्या सॉफ्टवेअरवर चालते. डझनभर पेमेंट पद्धती आहेत, b2b भागीदार जे यापैकी काही किंवा सर्व सेवा वापरू शकतात आणि त्यांना त्यांच्या उत्पादनांची अद्ययावत माहिती जाणून घ्यायची आहे. याव्यतिरिक्त, लमोडा रशियन फेडरेशन व्यतिरिक्त तीन देशांमध्ये कार्यरत आहे आणि तेथे सर्वकाही थोडे वेगळे आहे. एकूण, नवीन ऑर्डर कॉन्फिगर करण्यासाठी कदाचित शंभरहून अधिक मार्ग आहेत, ज्यावर स्वतःच्या पद्धतीने प्रक्रिया करणे आवश्यक आहे. हे सर्व डझनभर सेवांच्या मदतीने कार्य करते जे कधीकधी गैर-स्पष्ट मार्गांनी संवाद साधतात. एक केंद्रीय प्रणाली देखील आहे ज्याची मुख्य जबाबदारी ऑर्डर स्थिती आहे. आम्ही तिला BOB म्हणतो, मी तिच्यासोबत काम करतो.

इव्हेंट-चालित API सह परतावा साधन

इव्हेंट्स-ड्रिव्हन हा शब्द अगदी चकचकीत आहे; याचा अर्थ काय आहे हे आपण थोडे पुढे अधिक तपशीलवार परिभाषित करू. काफ्का मधील इव्हेंट-चालित API दृष्टीकोन वापरण्याचा आम्ही निर्णय घेतला त्या संदर्भाने मी सुरुवात करेन.

कोणत्याही स्टोअरमध्ये, ग्राहक ज्या ऑर्डरसाठी पैसे देतात त्याव्यतिरिक्त, असे काही वेळा असतात जेव्हा स्टोअरला पैसे परत करावे लागतात कारण उत्पादन ग्राहकाला शोभत नाही. ही तुलनेने लहान प्रक्रिया आहे: आवश्यक असल्यास आम्ही माहिती स्पष्ट करतो आणि पैसे हस्तांतरित करतो.

परंतु कायद्यातील बदलांमुळे परतावा अधिक क्लिष्ट झाला आणि आम्हाला त्यासाठी स्वतंत्र मायक्रोसेवा लागू करावी लागली.

आमची प्रेरणा:

1. कायदा FZ-54 - थोडक्यात, कायद्यानुसार प्रत्येक आर्थिक व्यवहाराबाबत कर कार्यालयाला अहवाल देणे आवश्यक आहे, मग तो परतावा असो किंवा पावती, काही मिनिटांच्या अगदी लहान SLA मध्ये. आम्ही, एक ई-कॉमर्स कंपनी म्हणून, बरेच ऑपरेशन्स करतो. तांत्रिकदृष्ट्या, याचा अर्थ नवीन जबाबदारी (आणि म्हणून एक नवीन सेवा) आणि सर्व समाविष्ट प्रणालींमध्ये सुधारणा.
2. BOB विभाजित BOB ला मोठ्या प्रमाणात नॉन-कोर जबाबदाऱ्यांपासून मुक्त करण्यासाठी आणि त्याची एकूण गुंतागुंत कमी करण्यासाठी हा कंपनीचा अंतर्गत प्रकल्प आहे.

हे आकृती मुख्य लामोडा प्रणाली दर्शवते. आता त्यापैकी बहुतेक जास्त आहेत लहान होत असलेल्या मोनोलिथभोवती 5-10 मायक्रोसर्व्हिसेसचे नक्षत्र. ते हळूहळू वाढत आहेत, परंतु आम्ही त्यांना लहान करण्याचा प्रयत्न करीत आहोत, कारण मध्यभागी निवडलेला तुकडा तैनात करणे भितीदायक आहे - आम्ही ते पडू देऊ शकत नाही. आम्हाला सर्व एक्सचेंजेस (बाण) आरक्षित करण्यास भाग पाडले जाते आणि त्यापैकी कोणतेही अनुपलब्ध असू शकते हे लक्षात घेतले पाहिजे.

BOB मध्ये बरेच एक्सचेंजेस आहेत: पेमेंट सिस्टम, वितरण प्रणाली, सूचना प्रणाली इ.

तांत्रिकदृष्ट्या BOB आहे:

• ~150k ओळी कोड + ~100k चाचण्या;
• php7.2 + Zend 1 आणि Symfony घटक 3;
• >100 API आणि ~50 आउटबाउंड एकत्रीकरण;
• 4 देश ज्यांचे स्वतःचे व्यवसाय तर्क आहे.

BOB तैनात करणे महाग आणि वेदनादायक आहे, कोड आणि समस्या सोडवण्याचे प्रमाण इतके आहे की हे सर्व कोणीही त्यांच्या डोक्यात ठेवू शकत नाही. सर्वसाधारणपणे, ते सुलभ करण्यासाठी अनेक कारणे आहेत.

परतीची प्रक्रिया

सुरुवातीला, दोन प्रणाली प्रक्रियेत सामील आहेत: BOB आणि पेमेंट. आता आणखी दोन दिसतात:

• फिस्कलायझेशन सर्व्हिस, जी फिस्कलायझेशन आणि बाह्य सेवांसह संप्रेषणातील समस्यांची काळजी घेईल.
• रिफंड टूल, ज्यामध्ये फक्त नवीन एक्सचेंजेस असतात जेणेकरुन BOB वाढू नये.

आता प्रक्रिया असे दिसते:

1. BOB ला परताव्याची विनंती प्राप्त होते.
2. BOB या रिफंड टूलबद्दल बोलतो.
3. रिफंड टूल पेमेंटला सांगते: "पैसे परत करा."
4. पेमेंट पैसे परत करते.
5. रिफंड टूल आणि BOB स्टेटस एकमेकांशी सिंक्रोनाइझ करतात, कारण सध्या दोघांनाही त्याची गरज आहे. आम्ही अद्याप रिफंड टूलवर पूर्णपणे स्विच करण्यास तयार नाही, कारण BOB कडे UI आहे, लेखांकनासाठी अहवाल आहे आणि सर्वसाधारणपणे इतका डेटा हस्तांतरित केला जाऊ शकत नाही. दोन खुर्च्यांवर बसावे लागेल.
6. आथिर्कीकरणाची विनंती निघून जाते.

परिणामी, आम्ही काफ्कावर एक प्रकारची इव्हेंट बस बनवली - इव्हेंट-बस, ज्यावर सर्वकाही सुरू झाले. हुर्रे, आता आमच्याकडे अपयशाचा एकच मुद्दा आहे (कटाक्ष).

साधक आणि बाधक तेही स्पष्ट आहेत. आम्ही बस बनवली, याचा अर्थ आता सर्व सेवा त्यावर अवलंबून आहेत. हे डिझाइन सुलभ करते, परंतु सिस्टममध्ये अपयशाचा एकच बिंदू सादर करते. काफ्का क्रॅश होईल, प्रक्रिया थांबेल.

इव्हेंट-चालित API म्हणजे काय

या प्रश्नाचे चांगले उत्तर मार्टिन फॉलर (GOTO 2017) च्या अहवालात आहे. "इव्हेंट-चालित आर्किटेक्चरचे अनेक अर्थ".

थोडक्यात आम्ही काय केले:

1. द्वारे सर्व असिंक्रोनस एक्सचेंज गुंडाळा इव्हेंट स्टोरेज. प्रत्येक स्वारस्य असलेल्या ग्राहकांना नेटवर्कवरील स्थिती बदलाबद्दल माहिती देण्याऐवजी, आम्ही केंद्रीकृत स्टोरेजमध्ये स्थिती बदलाविषयी एक इव्हेंट लिहितो आणि विषयामध्ये स्वारस्य असलेले ग्राहक तेथून दिसणारे सर्व काही वाचतात.
2. या प्रकरणातील घटना ही एक सूचना आहे (सूचना) की काहीतरी कुठेतरी बदलले आहे. उदाहरणार्थ, ऑर्डरची स्थिती बदलली आहे. अधिसूचनेमध्ये समाविष्ट नसलेल्या स्थिती बदलासह काही डेटामध्ये स्वारस्य असलेला ग्राहक त्याची स्थिती स्वतः शोधू शकतो.
3. कमाल पर्याय पूर्ण वाढ झालेला इव्हेंट सोर्सिंग आहे, राज्य हस्तांतरण, कोणत्या इव्हेंटमध्ये प्रक्रियेसाठी आवश्यक असलेली सर्व माहिती असते: ती कोठून आली आणि ती कोणत्या स्थितीत गेली, डेटा नेमका कसा बदलला, इ. एकमात्र प्रश्न व्यवहार्यता आणि माहितीचे प्रमाण आहे जी आपण संचयित करू शकता.

रिफंड टूल लाँच करण्याचा एक भाग म्हणून, आम्ही तिसरा पर्याय वापरला. तपशीलवार माहिती काढण्याची गरज नसल्यामुळे या सोप्या इव्हेंट प्रक्रियेमुळे, तसेच प्रत्येक नवीन इव्हेंट ग्राहकांकडून विनंत्या मिळवण्यासाठी स्पष्टीकरण देणारी परिस्थिती निर्माण करते.

परतावा साधन सेवा लोड केलेले नाही, म्हणून काफ्काला गरजेपेक्षा पेनची चव जास्त आहे. मला असे वाटत नाही की जर परतावा सेवा उच्च-लोड प्रकल्प बनली तर व्यवसाय आनंदी होईल.

Async एक्सचेंज जसे IS

असिंक्रोनस एक्सचेंजेससाठी, PHP विभाग सहसा RabbitMQ वापरतो. आम्ही विनंतीसाठी डेटा गोळा केला, तो एका रांगेत ठेवला आणि त्याच सेवेच्या ग्राहकाने तो वाचला आणि पाठवला (किंवा पाठवला नाही). स्वतः API साठी, Lamoda सक्रियपणे Swagger वापरते. आम्ही एपीआय डिझाइन करतो, स्वॅगरमध्ये त्याचे वर्णन करतो आणि क्लायंट आणि सर्व्हर कोड व्युत्पन्न करतो. आम्ही थोडा वर्धित JSON RPC 2.0 देखील वापरतो.

काही ठिकाणी ईएसबी बसेस वापरल्या जातात, काही सक्रिय एमक्यूवर राहतात, परंतु सर्वसाधारणपणे, RabbitMQ - मानक.

Async एक्सचेंज TO BE

इव्हेंट-बसद्वारे एक्सचेंजची रचना करताना, एक समानता शोधली जाऊ शकते. आम्ही इव्हेंट संरचना वर्णनाद्वारे भविष्यातील डेटा एक्सचेंजचे त्याचप्रमाणे वर्णन करतो. yaml फॉरमॅट, आम्हाला कोड जनरेशन स्वतः करावे लागले, जनरेटर स्पेसिफिकेशननुसार डीटीओ तयार करतो आणि क्लायंट आणि सर्व्हरना त्यांच्यासोबत काम करायला शिकवतो. पिढी दोन भाषांमध्ये जाते - गोलंग आणि php. हे लायब्ररी सुसंगत ठेवण्यास मदत करते. जनरेटर गोलंगमध्ये लिहिलेला आहे, म्हणूनच त्याला गोगी हे नाव पडले.

काफ्कावर इव्हेंट-सोर्सिंग ही एक वैशिष्ट्यपूर्ण गोष्ट आहे. काफ्का कॉन्फ्लुएंटच्या मुख्य एंटरप्राइझ आवृत्तीमधून एक उपाय आहे, तेथे आहे नाकडी, आमच्या डोमेन बंधू Zalando कडून एक उपाय. आमचे व्हॅनिला काफ्कापासून सुरुवात करण्याची प्रेरणा - याचा अर्थ असा आहे की आम्ही ते सर्वत्र वापरायचे की नाही हे ठरवेपर्यंत समाधान मोकळे सोडणे आणि युक्ती आणि सुधारणांसाठी स्वतःला जागा सोडणे: आम्हाला आमच्यासाठी समर्थन हवे आहे JSON RPC 2.0, दोन भाषांसाठी जनरेटर आणि आणखी काय ते पाहूया.

हे विडंबनात्मक आहे की अशा आनंदी प्रकरणात, जेव्हा ढोबळमानाने समान तोडगा काढणारा झालँडो हा व्यवसाय आहे, तेव्हा आपण त्याचा प्रभावीपणे वापर करू शकत नाही.

लॉन्चच्या वेळी आर्किटेक्चरल पॅटर्न खालीलप्रमाणे आहे: आम्ही थेट काफ्कामधून वाचतो, परंतु फक्त इव्हेंट-बसद्वारे लिहितो. काफ्कामध्ये वाचण्यासाठी बरेच काही तयार आहे: ब्रोकर्स, बॅलन्सर्स आणि ते क्षैतिज स्केलिंगसाठी कमी-अधिक प्रमाणात तयार आहे, मला हे ठेवायचे होते. आम्हाला एका गेटवे उर्फ ​​इव्हेंट-बसद्वारे रेकॉर्डिंग पूर्ण करायचे होते आणि ते येथे आहे.

कार्यक्रम-बस

किंवा इव्हेंट बस. हे फक्त स्टेटलेस http गेटवे आहे, जे अनेक महत्वाच्या भूमिका पार पाडते:

• प्रमाणीकरण निर्मिती - आम्ही तपासतो की इव्हेंट आमच्या वैशिष्ट्यांशी जुळतात.
• इव्हेंट मास्टर सिस्टम, म्हणजे, कंपनीमधील ही मुख्य आणि एकमेव प्रणाली आहे जी कोणत्या स्ट्रक्चर्ससह कोणत्या घटना वैध मानल्या जातात या प्रश्नाचे उत्तर देते. प्रमाणीकरणामध्ये फक्त डेटा प्रकार आणि सामग्री काटेकोरपणे निर्दिष्ट करण्यासाठी एनम्स समाविष्ट असतात.
• हॅश फंक्शन शार्डिंगसाठी - काफ्का मेसेज स्ट्रक्चर ही की-व्हॅल्यू आहे आणि हॅश ऑफ की वापरून ती कुठे ठेवायची हे मोजले जाते.

का

आम्ही एका मोठ्या कंपनीत सुव्यवस्थित प्रक्रियेसह काम करतो. काहीही का बदलायचे? हा एक प्रयोग आहे, आणि आम्हाला अनेक फायदे मिळण्याची अपेक्षा आहे.

1:n+1 एक्सचेंज (एक ते अनेक)

काफ्का नवीन ग्राहकांना API शी जोडणे खूप सोपे करते.

समजा तुमच्याकडे एक निर्देशिका आहे जी तुम्हाला एकाच वेळी अनेक प्रणालींमध्ये अद्ययावत ठेवायची आहे (आणि काही नवीनमध्ये). पूर्वी, आम्ही सेट-एपीआय लागू केलेल्या बंडलचा शोध लावला होता आणि मास्टर सिस्टमला ग्राहकांच्या पत्त्यांबद्दल माहिती दिली होती. आता मास्टर सिस्टम विषयावर अद्यतने पाठवते आणि ज्यांना स्वारस्य आहे ते प्रत्येकजण ते वाचतो. एक नवीन प्रणाली आली आहे - आम्ही या विषयासाठी साइन अप केले आहे. होय, बंडल देखील, परंतु सोपे.

रिफंड-टूलच्या बाबतीत, जे BOB चा एक भाग आहे, ते काफ्काद्वारे समक्रमित ठेवणे आमच्यासाठी सोयीचे आहे. पेमेंट म्हणते की पैसे परत केले गेले: BOB, RT ला याबद्दल माहिती मिळाली, त्यांची स्थिती बदलली, फिस्कलायझेशन सर्व्हिसला याबद्दल माहिती मिळाली आणि चेक जारी केला.

आमची एक युनिफाइड नोटिफिकेशन सर्व्हिस तयार करण्याची योजना आहे जी क्लायंटला त्याच्या ऑर्डर/रिटर्नशी संबंधित बातम्यांबद्दल सूचित करेल. आता ही जबाबदारी यंत्रणांमध्ये पसरली आहे. काफ्का कडून संबंधित माहिती पकडण्यासाठी आणि त्यास प्रतिसाद देण्यासाठी (आणि इतर सिस्टममध्ये या सूचना अक्षम करण्यासाठी) सूचना सेवेला शिकवणे आमच्यासाठी पुरेसे आहे. नवीन थेट देवाणघेवाण आवश्यक नाही.

डेटा-चालित

प्रणालींमधील माहिती पारदर्शक बनते - तुमच्याकडे कोणताही "रक्तरंजित उपक्रम" असला आणि तुमचा अनुशेष कितीही मोठा असला तरीही. Lamoda कडे डेटा अॅनालिटिक्स विभाग आहे जो सिस्टममधून डेटा संकलित करतो आणि व्यवसायासाठी आणि बुद्धिमान प्रणालींसाठी पुन्हा वापरण्यायोग्य स्वरूपात ठेवतो. काफ्का तुम्हाला त्यांना त्वरीत भरपूर डेटा देण्याची आणि ती माहिती अद्ययावत ठेवण्याची परवानगी देतो.

प्रतिकृती लॉग

RabbitMQ प्रमाणे संदेश वाचल्यानंतर अदृश्य होत नाहीत. जेव्हा एखाद्या इव्हेंटमध्ये प्रक्रियेसाठी पुरेशी माहिती असते, तेव्हा आमच्याकडे ऑब्जेक्टमधील अलीकडील बदलांचा इतिहास असतो आणि इच्छित असल्यास, हे बदल लागू करण्याची क्षमता असते.

प्रतिकृती लॉगचा स्टोरेज कालावधी या विषयावर लिहिण्याच्या तीव्रतेवर अवलंबून असतो; काफ्का तुम्हाला स्टोरेज वेळ आणि डेटा व्हॉल्यूमवर लवचिकपणे मर्यादा सेट करण्याची परवानगी देतो. गहन विषयांसाठी, सर्व ग्राहकांना माहिती गायब होण्यापूर्वी वाचण्यासाठी वेळ मिळणे महत्त्वाचे आहे, अगदी अल्पकालीन अक्षमतेच्या बाबतीतही. साठी डेटा संग्रहित करणे शक्य आहे दिवसांची एकके, जे समर्थनासाठी पुरेसे आहे.

पुढे, काफ्काशी परिचित नसलेल्यांसाठी, दस्तऐवजीकरणाचे थोडेसे पुन्हा सांगणे (चित्र देखील दस्तऐवजीकरणातील आहे)

AMQP मध्ये रांगा आहेत: आम्ही ग्राहकांसाठी रांगेत संदेश लिहितो. सामान्यतः, एका रांगेवर समान व्यवसाय तर्कासह एका प्रणालीद्वारे प्रक्रिया केली जाते. तुम्हाला अनेक प्रणालींना सूचित करण्याची आवश्यकता असल्यास, तुम्ही अॅप्लिकेशनला अनेक रांगांवर लिहायला शिकवू शकता किंवा फॅनआउट मेकॅनिझमसह एक्सचेंज कॉन्फिगर करू शकता, जे त्यांना स्वतः क्लोन करते.

काफ्काचेही असेच अमूर्तत्व आहे विषय, ज्यामध्ये तुम्ही संदेश लिहिता, परंतु ते वाचल्यानंतर अदृश्य होत नाहीत. डीफॉल्टनुसार, तुम्ही काफ्काशी कनेक्ट केल्यावर, तुम्हाला सर्व संदेश प्राप्त होतात आणि तुम्ही जिथे सोडले होते ते सेव्ह करण्याचा पर्याय असतो. म्हणजेच, तुम्ही क्रमशः वाचता, तुम्ही मेसेज वाचला म्हणून चिन्हांकित करू शकत नाही, परंतु ज्या आयडीवरून तुम्ही वाचन सुरू ठेवू शकता तो आयडी सेव्ह करा. तुम्ही सेटल केलेल्या आयडीला ऑफसेट म्हणतात आणि यंत्रणा कमिट ऑफसेट आहे.

त्यानुसार वेगवेगळे तर्क लागू करता येतात. उदाहरणार्थ, आमच्याकडे वेगवेगळ्या देशांसाठी 4 घटनांमध्ये BOB आहे - Lamoda रशिया, कझाकस्तान, युक्रेन, बेलारूसमध्ये आहे. ते स्वतंत्रपणे तैनात केल्यामुळे, त्यांच्याकडे थोडे वेगळे कॉन्फिग आणि त्यांचे स्वतःचे व्यवसाय तर्क आहेत. आम्ही संदेशात सूचित करतो की तो कोणत्या देशाचा संदर्भ आहे. प्रत्येक देशातील प्रत्येक BOB ग्राहक वेगळ्या ग्रुपआयडीसह वाचतो आणि जर त्यांना संदेश लागू होत नसेल, तर ते ते वगळतात, उदा. लगेच ऑफसेट +1 कमिट करते. जर हाच विषय आमच्या पेमेंट सेवेद्वारे वाचला असेल, तर तो वेगळ्या गटासह असे करतो आणि त्यामुळे ऑफसेट एकमेकांना छेदत नाहीत.

कार्यक्रम आवश्यकता:

• डेटा पूर्णता. मला इव्हेंटमध्ये पुरेसा डेटा हवा आहे जेणेकरून त्यावर प्रक्रिया करता येईल.

• सचोटी. इव्हेंट सुसंगत आहे आणि ते त्यावर प्रक्रिया करू शकते याची पडताळणी आम्ही इव्हेंट-बसला सोपवतो.
• ऑर्डर महत्वाची आहे. परतीच्या बाबतीत, आम्हाला इतिहासासह काम करण्यास भाग पाडले जाते. सूचनांसह, ऑर्डर महत्त्वाची नसते, जर त्या एकसंध सूचना असतील, तर कोणती ऑर्डर आधी आली याची पर्वा न करता ईमेल समान असेल. परताव्याच्या बाबतीत, एक स्पष्ट प्रक्रिया आहे; आम्ही ऑर्डर बदलल्यास, अपवाद उद्भवतील, परतावा तयार केला जाणार नाही किंवा त्यावर प्रक्रिया केली जाणार नाही - आम्ही वेगळ्या स्थितीत जाऊ.
• सुसंगतता. आमच्याकडे एक स्टोअर आहे आणि आता आम्ही API ऐवजी इव्हेंट तयार करतो. आम्हाला आमच्या सेवांमध्ये नवीन इव्हेंट आणि विद्यमान बदलांबद्दल माहिती जलद आणि स्वस्तपणे प्रसारित करण्याचा मार्ग हवा आहे. हे वेगळ्या गिट रेपॉजिटरी आणि कोड जनरेटरमधील सामान्य तपशीलाद्वारे प्राप्त केले जाते. त्यामुळे विविध सेवांमधील क्लायंट आणि सर्व्हर यांचा समन्वय साधला जातो.

लामोडा मध्ये काफ्का

आमच्याकडे तीन काफ्का स्थापना आहेत:

1. नोंदी;
2. R&D;
3. कार्यक्रम-बस.

आज आपण फक्त शेवटच्या मुद्द्याबद्दल बोलत आहोत. इव्हेंट-बसमध्ये, आमच्याकडे फार मोठी स्थापना नाही - 3 ब्रोकर (सर्व्हर) आणि फक्त 27 विषय. एक नियम म्हणून, एक विषय एक प्रक्रिया आहे. परंतु हा एक सूक्ष्म मुद्दा आहे आणि आम्ही आता त्यावर स्पर्श करू.

वर आरपीएस आलेख आहे. परतावा प्रक्रिया नीलमणी रेषेने (होय, X अक्षावर असलेली) चिन्हांकित केली आहे आणि गुलाबी रेषा सामग्री अद्यतन प्रक्रिया आहे.

Lamoda कॅटलॉगमध्ये लाखो उत्पादने आहेत आणि डेटा नेहमी अपडेट केला जातो. काही संग्रह फॅशनच्या बाहेर जातात, त्यांना पुनर्स्थित करण्यासाठी नवीन सोडले जातात आणि नवीन मॉडेल सतत कॅटलॉगमध्ये दिसतात. उद्या आमच्या ग्राहकांसाठी काय मनोरंजक असेल याचा आम्ही अंदाज लावण्याचा प्रयत्न करतो, म्हणून आम्ही सतत नवीन गोष्टी खरेदी करतो, त्यांचे छायाचित्रण करतो आणि डिस्प्ले केस अपडेट करतो.

गुलाबी शिखरे उत्पादन अद्यतने आहेत, म्हणजे, उत्पादनांमध्ये बदल. हे पाहिले जाऊ शकते की मुलांनी फोटो काढले, फोटो काढले आणि नंतर पुन्हा! — कार्यक्रमांचा एक पॅक लोड केला.

Lamoda इव्हेंट केसेस वापरतात

आम्ही खालील ऑपरेशन्ससाठी तयार केलेले आर्किटेक्चर वापरतो:

• रिटर्न स्टेटस ट्रॅकिंग: सर्व गुंतलेल्या प्रणालींकडून कॉल-टू-अॅक्शन आणि स्थिती ट्रॅकिंग. पेमेंट, स्थिती, वित्तीयकरण, सूचना. येथे आम्ही दृष्टिकोनाची चाचणी केली, साधने बनवली, सर्व बग गोळा केले, कागदपत्रे लिहिली आणि आमच्या सहकाऱ्यांना ते कसे वापरायचे ते सांगितले.
• उत्पादन कार्ड अद्यतनित करणे: कॉन्फिगरेशन, मेटा-डेटा, वैशिष्ट्ये. एक प्रणाली वाचते (जे प्रदर्शित करते), आणि अनेक लिहितात.
• ईमेल, पुश आणि एसएमएस: ऑर्डर गोळा केली गेली आहे, ऑर्डर आली आहे, परतावा स्वीकारला गेला आहे, इत्यादी बरेच आहेत.
• स्टॉक, गोदाम नूतनीकरण — वस्तूंचे परिमाणात्मक अद्यतन, फक्त संख्या: वेअरहाऊसमध्ये आगमन, परत येणे. आरक्षित वस्तूंशी संबंधित सर्व प्रणाली सर्वात वर्तमान डेटासह कार्य करणे आवश्यक आहे. सध्या, स्टॉक अपडेट सिस्टम खूपच क्लिष्ट आहे; काफ्का ते सुलभ करेल.
• डेटा विश्लेषण (R&D विभाग), ML साधने, विश्लेषणे, आकडेवारी. आम्हाला माहिती पारदर्शक हवी आहे - काफ्का यासाठी योग्य आहे.

आता गेल्या सहा महिन्यांत झालेल्या मोठ्या अडथळ्यांबद्दल आणि मनोरंजक शोधांबद्दलचा अधिक मनोरंजक भाग.

डिझाइन समस्या

समजा आम्हाला एक नवीन गोष्ट करायची आहे - उदाहरणार्थ, संपूर्ण वितरण प्रक्रिया काफ्काकडे हस्तांतरित करा. आता प्रक्रियेचा एक भाग BOB मध्ये ऑर्डर प्रोसेसिंगमध्ये लागू केला आहे. ऑर्डर डिलिव्हरी सेवेकडे हस्तांतरित करणे, इंटरमीडिएट वेअरहाऊसमध्ये हालचाल करणे इत्यादी मागे एक स्टेटस मॉडेल आहे. संपूर्ण मोनोलिथ, अगदी दोन, तसेच वितरणासाठी समर्पित API चा एक समूह आहे. त्यांना डिलिव्हरीबद्दल बरेच काही माहित आहे.

हे समान क्षेत्रे आहेत असे दिसते, परंतु BOB मधील ऑर्डर प्रक्रिया आणि शिपिंग सिस्टमची स्थिती भिन्न आहे. उदाहरणार्थ, काही कुरिअर सेवा मध्यवर्ती स्थिती पाठवत नाहीत, परंतु केवळ अंतिम: “वितरित” किंवा “हरवले”. इतर, त्याउलट, वस्तूंच्या हालचालीबद्दल तपशीलवार अहवाल देतात. प्रत्येकाचे स्वतःचे प्रमाणीकरण नियम आहेत: काहींसाठी, ईमेल वैध आहे, याचा अर्थ त्यावर प्रक्रिया केली जाईल; इतरांसाठी ते वैध नाही, परंतु तरीही ऑर्डरवर प्रक्रिया केली जाईल कारण संपर्कासाठी एक फोन नंबर आहे आणि कोणीतरी म्हणेल की अशा ऑर्डरवर अजिबात प्रक्रिया केली जाणार नाही.

डेटा प्रवाह

काफ्काच्या बाबतीत, डेटा प्रवाह आयोजित करण्याचा प्रश्न उद्भवतो. या कार्यामध्ये अनेक मुद्द्यांवर आधारित धोरण निवडणे समाविष्ट आहे; चला त्या सर्वांमधून जाऊ या.

एका विषयात की वेगळ्या विषयात?

आमच्याकडे इव्हेंट स्पेसिफिकेशन आहे. BOB मध्ये आम्ही असे लिहितो की अशा प्रकारची ऑर्डर वितरित करणे आवश्यक आहे आणि सूचित करतो: ऑर्डर क्रमांक, त्याची रचना, काही SKU आणि बार कोड इ. जेव्हा माल गोदामात येतो, तेव्हा डिलिव्हरी स्थिती, टाइमस्टॅम्प आणि आवश्यक असलेली प्रत्येक गोष्ट प्राप्त करण्यास सक्षम असेल. पण नंतर आम्हाला BOB मध्ये या डेटावर अपडेट्स मिळवायचे आहेत. आमच्याकडे डिलिव्हरीमधून डेटा प्राप्त करण्याची उलट प्रक्रिया आहे. हीच घटना आहे का? की हे वेगळे एक्सचेंज स्वतःच्या विषयाला पात्र आहे?

बहुधा, ते खूप समान असतील आणि एक विषय बनवण्याचा मोह निराधार नाही, कारण वेगळा विषय म्हणजे स्वतंत्र ग्राहक, स्वतंत्र कॉन्फिगरेशन, या सर्वांची एक वेगळी पिढी. पण वस्तुस्थिती नाही.

नवीन क्षेत्र किंवा नवीन कार्यक्रम?

पण त्याच इव्हेंट्सचा वापर केल्यास आणखी एक समस्या उद्भवते. उदाहरणार्थ, सर्व डिलिव्हरी सिस्टम BOB तयार करू शकतील अशा प्रकारचे DTO व्युत्पन्न करू शकत नाहीत. आम्ही त्यांना आयडी पाठवतो, पण ते जतन करत नाहीत कारण त्यांना त्याची गरज नसते आणि इव्हेंट-बस प्रक्रिया सुरू करण्याच्या दृष्टिकोनातून, हे फील्ड आवश्यक आहे.

जर आम्ही इव्हेंट-बससाठी नियम लागू केला की हे फील्ड आवश्यक आहे, तर आम्हाला BOB किंवा स्टार्ट इव्हेंट हँडलरमध्ये अतिरिक्त प्रमाणीकरण नियम सेट करण्याची सक्ती केली जाते. प्रमाणीकरण संपूर्ण सेवेमध्ये पसरू लागते - हे फार सोयीचे नाही.

आणखी एक समस्या म्हणजे वाढीव विकासाचा मोह. आम्हाला सांगण्यात आले आहे की इव्हेंटमध्ये काहीतरी जोडले जाणे आवश्यक आहे आणि कदाचित, जर आपण त्याबद्दल विचार केला तर तो एक वेगळा कार्यक्रम असावा. परंतु आमच्या योजनेत, एक वेगळा कार्यक्रम हा एक वेगळा विषय आहे. मी वर वर्णन केलेली संपूर्ण प्रक्रिया हा एक वेगळा विषय आहे. डेव्हलपरला फक्त JSON स्कीमामध्ये दुसरे फील्ड जोडण्याचा आणि तो पुन्हा निर्माण करण्याचा मोह होतो.

परताव्याच्या बाबतीत, आम्ही अर्ध्या वर्षातील कार्यक्रमांच्या ठिकाणी पोहोचलो. आमच्याकडे रिफंड अपडेट नावाचा एक मेटा-इव्हेंट होता, ज्यामध्ये हे अपडेट प्रत्यक्षात काय आहे याचे वर्णन करणारे एक प्रकार फील्ड होते. यामुळे, आमच्याकडे व्हॅलिडेटरसह "अद्भुत" स्विच होते ज्यांनी आम्हाला या प्रकारासह हा कार्यक्रम कसा प्रमाणित करायचा हे सांगितले.

कार्यक्रम आवृत्ती

काफ्कामधील संदेश प्रमाणित करण्यासाठी तुम्ही वापरू शकता AVRO, परंतु त्यावर ताबडतोब घालणे आणि Confluent वापरणे आवश्यक होते. आमच्या बाबतीत, आम्हाला आवृत्ती तयार करताना काळजी घ्यावी लागेल. प्रतिकृती लॉगमधून संदेश पुन्हा वाचणे नेहमीच शक्य होणार नाही कारण मॉडेलमध्ये "डावीकडे" आहे. मूलभूतपणे, ते आवृत्त्या तयार करण्यासाठी बाहेर वळते जेणेकरून मॉडेल मागे सुसंगत असेल: उदाहरणार्थ, फील्ड तात्पुरते पर्यायी बनवा. फरक खूप मजबूत असल्यास, आम्ही नवीन विषयावर लिहायला सुरुवात करतो आणि क्लायंट जुने वाचून संपल्यावर हस्तांतरित करतो.

विभाजनांच्या वाचन क्रमाची हमी

काफ्कामधील विषय विभाजनांमध्ये विभागलेले आहेत. आम्ही संस्था आणि एक्सचेंजेस डिझाइन करत असताना हे फार महत्वाचे नाही, परंतु ते कसे वापरायचे आणि ते कसे मोजायचे हे ठरवताना हे महत्वाचे आहे.

नेहमीच्या बाबतीत, तुम्ही काफ्कामध्ये एक विषय लिहिता. डीफॉल्टनुसार, एक विभाजन वापरले जाते आणि या विषयातील सर्व संदेश त्यावर जातात. आणि परिणामी ग्राहक हे संदेश क्रमाने वाचतात. समजा आता आम्हाला प्रणालीचा विस्तार करण्याची गरज आहे जेणेकरून संदेश दोन भिन्न ग्राहकांद्वारे वाचले जातील. उदाहरणार्थ, जर तुम्ही एसएमएस पाठवत असाल, तर तुम्ही काफ्काला अतिरिक्त विभाजन करण्यास सांगू शकता आणि काफ्का संदेशांना दोन भागांमध्ये विभाजित करण्यास सुरवात करेल - अर्धा येथे, अर्धा येथे.

काफ्का त्यांना कसे विभाजित करतो? प्रत्येक संदेशाचा एक मुख्य भाग (ज्यामध्ये आम्ही JSON संग्रहित करतो) आणि एक की असते. तुम्ही या कीशी हॅश फंक्शन संलग्न करू शकता, जे संदेश कोणत्या विभाजनात जाईल हे निर्धारित करेल.

आमच्या परताव्याच्या बाबतीत, हे महत्त्वाचे आहे, जर आम्ही दोन विभाजने घेतली, तर अशी शक्यता आहे की समांतर ग्राहक पहिल्याच्या आधी दुसऱ्या कार्यक्रमावर प्रक्रिया करेल आणि त्रास होईल. हॅश फंक्शन हे सुनिश्चित करते की समान की असलेले संदेश समान विभाजनात समाप्त होतात.

इव्हेंट वि कमांड्स

ही दुसरी समस्या आहे जी आम्हाला आली. इव्हेंट ही एक विशिष्ट घटना आहे: आम्ही म्हणतो की काहीतरी कुठेतरी घडले (something_happened), उदाहरणार्थ, एखादी वस्तू रद्द केली गेली किंवा परतावा आला. जर एखाद्याने या घटना ऐकल्या तर, "आयटम रद्द केला" नुसार, परतावा घटक तयार केला जाईल आणि सेटअपमध्ये कुठेतरी "परतावा आला" असे लिहिले जाईल.

परंतु सहसा, जेव्हा आपण इव्हेंट्स डिझाइन करता तेव्हा आपण ते व्यर्थ लिहू इच्छित नाही - कोणीतरी ते वाचेल यावर आपण अवलंबून असतो. काहीतरी_घडले नाही (आयटम_रद्द केलेले, परतावा_परत) लिहिण्याचा उच्च मोह आहे, परंतु काहीतरी_करले पाहिजे. उदाहरणार्थ, आयटम परत करण्यासाठी तयार आहे.

एकीकडे, इव्हेंटचा वापर कसा केला जाईल हे सूचित करते. दुसरीकडे, हे सामान्य इव्हेंट नावासारखे खूपच कमी वाटते. याशिवाय, do_something कमांड इथून फार दूर नाही. पण हा प्रसंग कोणी वाचला याची खात्री नाही; आणि जर तुम्ही ते वाचले तर तुम्ही ते यशस्वीरित्या वाचले; आणि जर तुम्ही ते यशस्वीरित्या वाचले तर तुम्ही काहीतरी केले आणि काहीतरी यशस्वी झाले. ज्या क्षणी एखादी घटना do_something बनते, फीडबॅक आवश्यक बनतो आणि ही एक समस्या आहे.

RabbitMQ मधील असिंक्रोनस एक्सचेंजमध्ये, जेव्हा तुम्ही संदेश वाचता, http वर जा, तेव्हा तुमच्याकडे प्रतिसाद असेल - किमान तो संदेश प्राप्त झाला होता. जेव्हा तुम्ही काफ्काला लिहीता तेव्हा एक संदेश असतो जो तुम्ही काफ्काला लिहिला होता, परंतु त्याची प्रक्रिया कशी झाली याबद्दल तुम्हाला काहीही माहिती नसते.

म्हणून, आमच्या बाबतीत, आम्हाला प्रतिसाद कार्यक्रम सादर करावा लागला आणि मॉनिटरिंग सेट करावे लागले जेणेकरुन जर इतके कार्यक्रम पाठवले गेले असतील तर अशा आणि अशा वेळेनंतर तितकेच प्रतिसाद कार्यक्रम येतील. तसे झाले नाही तर काहीतरी चुकले आहे असे वाटते. उदाहरणार्थ, आम्ही "item_ready_to_refund" इव्हेंट पाठवल्यास, आम्ही अपेक्षा करतो की परतावा तयार केला जाईल, पैसे क्लायंटला परत केले जातील आणि "money_refunded" इव्हेंट आम्हाला पाठवला जाईल. परंतु हे निश्चित नाही, म्हणून देखरेख आवश्यक आहे.

बारकावे

एक स्पष्ट समस्या आहे: जर तुम्ही एखाद्या विषयावरून क्रमशः वाचले आणि तुमच्याकडे काही वाईट संदेश असेल तर, ग्राहक कमी होईल आणि तुम्ही पुढे जाणार नाही. तुला पाहिजे सर्व ग्राहकांना थांबवा, वाचन सुरू ठेवण्यासाठी पुढे ऑफसेट करा.

आम्हाला त्याबद्दल माहिती होती, आम्ही त्यावर विश्वास ठेवला आणि तरीही ते घडले. आणि हे घडले कारण इव्हेंट-बसच्या दृष्टिकोनातून इव्हेंट वैध होता, इव्हेंट अॅप्लिकेशन व्हॅलिडेटरच्या दृष्टिकोनातून वैध होता, परंतु पोस्टग्रेएसक्यूएलच्या दृष्टिकोनातून तो वैध नव्हता, कारण आमच्या एका प्रणालीमध्ये Unsigned INT सह MySQL, आणि नव्याने लिहिलेल्या प्रणालीमध्ये पोस्टग्रेएसक्यूएल फक्त INT सह होते. त्याचा आकार थोडा लहान आहे, आणि आयडी बसत नाही. सिम्फनी अपवादाने मरण पावला. आम्ही अर्थातच, अपवाद पकडला कारण आम्ही त्यावर अवलंबून होतो आणि हा ऑफसेट कमिट करणार होतो, परंतु त्यापूर्वी आम्हाला समस्या काउंटर वाढवायचा होता, कारण संदेशावर अयशस्वी प्रक्रिया झाली होती. या प्रकल्पातील काउंटर देखील डेटाबेसमध्ये आहेत आणि सिम्फनीने डेटाबेसशी संप्रेषण आधीच बंद केले आहे आणि दुसऱ्या अपवादाने ऑफसेट करण्याची संधी न देता संपूर्ण प्रक्रिया नष्ट केली आहे.

सेवा काही काळ खाली पडली - सुदैवाने, काफ्कासह हे इतके वाईट नाही, कारण संदेश कायम आहेत. जेव्हा कार्य पुनर्संचयित केले जाते, तेव्हा आपण त्यांचे वाचन पूर्ण करू शकता. ते आरामदायक आहे.

काफ्काकडे टूलिंगद्वारे अनियंत्रित ऑफसेट सेट करण्याची क्षमता आहे. परंतु हे करण्यासाठी, आपल्याला सर्व ग्राहकांना थांबविण्याची आवश्यकता आहे - आमच्या बाबतीत, एक स्वतंत्र प्रकाशन तयार करा ज्यामध्ये कोणतेही ग्राहक, पुनर्नियोजन होणार नाहीत. मग काफ्कामध्ये तुम्ही टूलिंगद्वारे ऑफसेट शिफ्ट करू शकता आणि संदेश जाईल.

आणखी एक बारकावे - प्रतिकृती लॉग वि rdkafka.so - आमच्या प्रकल्पाच्या वैशिष्ट्यांशी संबंधित आहे. आम्ही PHP वापरतो, आणि PHP मध्ये, नियमानुसार, सर्व लायब्ररी काफ्काशी rdkafka.so रिपॉझिटरीद्वारे संवाद साधतात आणि नंतर एक प्रकारचा रॅपर असतो. कदाचित या आमच्या वैयक्तिक अडचणी आहेत, परंतु असे दिसून आले की आम्ही आधीच वाचलेल्या गोष्टींचा एक भाग पुन्हा वाचणे इतके सोपे नाही. सर्वसाधारणपणे, सॉफ्टवेअर समस्या होत्या.

विभाजनांसह कार्य करण्याच्या वैशिष्ट्यांकडे परत येताना, ते दस्तऐवजीकरणात लिहिलेले आहे ग्राहक >= विषय विभाजने. पण मला हे आवडले असते त्यापेक्षा खूप नंतर कळले. जर तुम्हाला मोजमाप करायचे असेल आणि दोन ग्राहक असतील तर तुम्हाला किमान दोन विभाजने आवश्यक आहेत. म्हणजेच, जर तुमच्याकडे एक विभाजन असेल ज्यामध्ये 20 हजार संदेश जमा झाले असतील आणि तुम्ही नवीन केले तर, संदेशांची संख्या लवकरच समान होणार नाही. म्हणून, दोन समांतर ग्राहक असण्यासाठी, तुम्हाला विभाजनांचा सामना करावा लागेल.

देखरेख

मला वाटते की आम्ही ज्या प्रकारे त्याचे निरीक्षण करतो ते अधिक स्पष्ट होईल विद्यमान दृष्टिकोनामध्ये कोणत्या समस्या आहेत.

उदाहरणार्थ, डेटाबेसमधील किती उत्पादनांनी अलीकडे त्यांची स्थिती बदलली आहे, आणि त्यानुसार, या बदलांच्या आधारे घटना घडल्या पाहिजेत, याची आम्ही गणना करतो आणि आम्ही हा क्रमांक आमच्या मॉनिटरिंग सिस्टमला पाठवतो. मग काफ्का कडून आपल्याला दुसरा क्रमांक मिळतो, प्रत्यक्षात किती घटनांची नोंद झाली. अर्थात, या दोन संख्यांमधील फरक नेहमी शून्य असावा.

याशिवाय, तुम्हाला निर्माता कसे काम करत आहे, इव्हेंट-बसला संदेश प्राप्त झाले आहेत की नाही आणि ग्राहक कसे करत आहेत याचे निरीक्षण करणे आवश्यक आहे. उदाहरणार्थ, खालील चार्टमध्ये, रिफंड टूल चांगले काम करत आहे, परंतु BOB मध्ये स्पष्टपणे काही समस्या आहेत (ब्लू पीक).

मी आधीच ग्राहक-समूह अंतराचा उल्लेख केला आहे. ढोबळपणे बोलायचे झाल्यास, न वाचलेल्या संदेशांची ही संख्या आहे. सर्वसाधारणपणे, आमचे ग्राहक त्वरीत कार्य करतात, त्यामुळे अंतर सामान्यतः 0 असते, परंतु काहीवेळा अल्पकालीन शिखर असू शकते. काफ्का हे बॉक्सच्या बाहेर करू शकतो, परंतु तुम्हाला एक विशिष्ट मध्यांतर सेट करणे आवश्यक आहे.

एक प्रकल्प आहे बुरोजे तुम्हाला काफ्काबद्दल अधिक माहिती देईल. हा गट कसा काम करत आहे याची स्थिती देण्यासाठी ते फक्त ग्राहक-समूह API वापरते. ओके आणि अयशस्वी व्यतिरिक्त, एक चेतावणी आहे आणि आपण हे शोधू शकता की आपले ग्राहक उत्पादनाच्या गतीचा सामना करू शकत नाहीत - जे लिहिले आहे ते प्रूफरीड करण्यासाठी त्यांच्याकडे वेळ नाही. प्रणाली अतिशय स्मार्ट आणि वापरण्यास सोपी आहे.

API प्रतिसाद असे दिसते. हा ग्रुप bob-live-fifa, partition refund.update.v1, स्टेटस ओके, lag 0 - शेवटचा अंतिम ऑफसेट आहे.

देखरेख अपडेट_एट SLA (अडकले) मी आधीच नमूद केले आहे. उदाहरणार्थ, उत्पादनाची स्थिती बदलली आहे की ते परतीसाठी तयार आहे. आम्ही क्रॉन स्थापित करतो, जे म्हणते की जर 5 मिनिटांत ही वस्तू परत केली गेली नाही (आम्ही पेमेंट सिस्टमद्वारे खूप लवकर पैसे परत करतो), तर नक्कीच काहीतरी चूक झाली आहे आणि हे निश्चितपणे समर्थनासाठी एक केस आहे. म्हणून, आम्ही फक्त क्रोन घेतो, जे अशा गोष्टी वाचते आणि जर ते 0 पेक्षा मोठे असतील तर ते एक इशारा पाठवते.

थोडक्यात, इव्हेंट वापरणे सोयीचे असते तेव्हा:

• माहिती अनेक प्रणालींना आवश्यक आहे;
• प्रक्रियेचा परिणाम महत्त्वाचा नाही;
• काही घटना किंवा लहान घटना आहेत.

असे दिसते की लेखात एक अतिशय विशिष्ट विषय आहे - काफ्कावरील असिंक्रोनस API, परंतु त्याच्या संबंधात मी एकाच वेळी बर्‍याच गोष्टींची शिफारस करू इच्छितो.
प्रथम, पुढील HighLoad++ आम्हाला नोव्हेंबरपर्यंत प्रतीक्षा करावी लागेल; एप्रिलमध्ये सेंट पीटर्सबर्ग आवृत्ती असेल आणि जूनमध्ये आम्ही नोवोसिबिर्स्कमधील उच्च भारांबद्दल बोलू.
दुसरे म्हणजे, अहवालाचे लेखक, सर्गेई झैका, ज्ञान व्यवस्थापनावरील आमच्या नवीन परिषदेच्या कार्यक्रम समितीचे सदस्य आहेत. KnowledgeConf. परिषद एकदिवसीय आहे, 26 एप्रिल रोजी होणार आहे, परंतु त्याचा कार्यक्रम खूप तीव्र आहे.
आणि ते मे मध्ये असेल PHP रशिया и RIT++ (DevOpsConf सह) - तुम्ही तेथे तुमचा विषय सुचवू शकता, तुमच्या अनुभवाबद्दल बोलू शकता आणि तुमच्या भरलेल्या शंकूबद्दल तक्रार करू शकता.

स्त्रोत: www.habr.com