🐥 💃🏻 🏳️ घटना-उन्मुख वास्तुकला के एंटीपैटर्न ❣️ 🍗 🚎

फिर से हैलो! पाठ्यक्रम "सॉफ्टवेयर आर्किटेक्ट" की शुरुआत की प्रत्याशा में , हमने एक और दिलचस्प सामग्री का अनुवाद तैयार किया।

पिछले कुछ वर्षों में माइक्रोसॉर्स्क वास्तुकला की लोकप्रियता में वृद्धि देखी गई है। कई संसाधन हैं जो आपको सिखाते हैं कि इसे सही तरीके से कैसे लागू किया जाए, लेकिन अक्सर लोग इसे चांदी के पूल के रूप में बात करते हैं। माइक्रोसर्विस के उपयोग के खिलाफ कई तर्क हैं, लेकिन उनमें से सबसे महत्वपूर्ण यह है कि इस प्रकार की वास्तुकला अनिश्चित जटिलता से भरा है, जिसका स्तर इस बात पर निर्भर करता है कि आप अपनी सेवाओं और टीमों के बीच संबंध कैसे प्रबंधित करते हैं। आप बहुत सारे साहित्य पा सकते हैं जो बताएंगे कि क्यों (शायद) आपके मामले में, माइक्रोसिस्टर्स सबसे अच्छा विकल्प नहीं होगा।

हम लेगो में एक मोनोलिथ से माइक्रोसर्विस के लिए स्केलेबिलिटी की आवश्यकता को पूरा करने के लिए चले गए, और तुरंत टीमों के काम पर इसके लाभकारी प्रभाव के बारे में आश्वस्त हो गए। जब सही ढंग से उपयोग किया जाता है, तो माइक्रोसिस्टर्स ने हमें कई फायदे दिए हैं, अर्थात्:

: , . ( ..) . ( ) Users.
: , . . , , , , . .

-

सभी microservice आर्किटेक्चर घटना-संचालित नहीं हैं। कुछ लोग HTTP (gRPC, REST, आदि) का उपयोग करते हुए इस आर्किटेक्चर में सेवाओं के बीच समकालिक संचार की वकालत करते हैं। लेगो में, हम इस पैटर्न का पालन नहीं करने का प्रयास करते हैं और एसिंक्रोनस रूप से हमारी सेवाओं को डोमेन ईवेंट के साथ जोड़ते हैं । यहाँ कारण हैं जो हम ऐसा करते हैं:

: . , DDoS . , DDoS . , . .
(bulkheads) – , , .
: . , , , , . , , API, , , , . Users , Chat.

इसके आधार पर, हम लेगो में सेवाओं के बीच अतुल्यकालिक संचार का पालन करने की कोशिश करते हैं, और सिंक्रोनस केवल सुविधा एमवीपी जैसे असाधारण मामलों में काम करता है। हम ऐसा इसलिए करते हैं क्योंकि हम चाहते हैं कि प्रत्येक सेवा अपनी संदेश बस में अन्य सेवाओं द्वारा प्रकाशित डोमेन घटनाओं के आधार पर अपनी इकाइयाँ उत्पन्न करे।

हमारी राय में, माइक्रोसॉस्ट आर्किटेक्चर के कार्यान्वयन में सफलता या विफलता इस बात पर निर्भर करती है कि आप इसकी अंतर्निहित जटिलता से कैसे निपटते हैं और आपकी सेवाएं एक-दूसरे के साथ कैसे संपर्क करती हैं। संचार अवसंरचना को अतुल्यकालिक में स्थानांतरित किए बिना विभाजन कोड आपके आवेदन को वितरित मोनोलिथ में बदल देगा।

लेगो में घटना-संचालित वास्तुकला

आज मैं एक उदाहरण साझा करना चाहता हूं कि हम लेगो में डोमेन ईवेंट और अतुल्यकालिक संचार का उपयोग कैसे करते हैं: हमारी उपयोगकर्ता इकाई कई सेवाओं में मौजूद है, लेकिन इसका निर्माण और संपादन शुरू में उपयोगकर्ता सेवा द्वारा संसाधित किया जाता है। उपयोगकर्ता सेवा के डेटाबेस में, हम बहुत से डेटा संग्रहीत करते हैं, जैसे नाम, ईमेल पता, अवतार, देश, आदि। हमारी चैट सेवा में, हमारे पास एक उपयोगकर्ता अवधारणा भी है, लेकिन हमें उस डेटा की आवश्यकता नहीं है जो उपयोगकर्ता सेवा के उपयोगकर्ता इकाई के पास है। संवाद की सूची में उपयोगकर्ता का नाम, अवतार और आईडी (प्रोफ़ाइल का लिंक) प्रदर्शित किया जाता है। हम कहते हैं कि एक चैट में केवल उपयोगकर्ता इकाई का एक प्रक्षेपण होता है, जिसमें आंशिक डेटा होता है। वास्तव में, चैट में हम उपयोगकर्ताओं के बारे में बात नहीं कर रहे हैं, हम उन्हें "वार्ताकार" कहते हैं। यह प्रक्षेपण चैट सेवा को संदर्भित करता है और उन घटनाओं पर बनाया जाता है जो चैट उपयोगकर्ता सेवा से प्राप्त करता है।

हम लिस्टिंग के साथ भी ऐसा ही करते हैं। उत्पाद सेवा में, हम प्रत्येक सूची के n चित्रों को संग्रहीत करते हैं, लेकिन संवादों की सूची दृश्य में हम एक मुख्य चित्र दिखाते हैं, इसलिए उत्पाद से चैट के लिए हमारे प्रक्षेपण को n के बजाय केवल एक चित्र की आवश्यकता होती है।

हमारी चैट में संवादों की सूची देखें। यह दिखाता है कि बैकएंड पर कौन सी विशिष्ट सेवा जानकारी प्रदान करती है।

यदि आप फिर से संवादों की सूची को देखते हैं, तो आप देखेंगे कि लगभग सभी डेटा जो हम दिखाते हैं, वह चैट सेवा द्वारा नहीं बनाया गया है, बल्कि इसके अंतर्गत आता है, क्योंकि उपयोगकर्ता और चैट अनुमान चैट के स्वामित्व में हैं। पहुंच और अनुमानों की निरंतरता के बीच एक व्यापार बंद है, जिस पर हम इस लेख में चर्चा नहीं करेंगे, लेकिन मैं केवल यह कहूंगा कि एक बड़े से कई छोटे डेटाबेस को स्केल करना स्पष्ट रूप से आसान है।

लेगो वास्तुकला का सरल दृश्य

Antipatterns

कुछ सहज समाधान अक्सर गलतियाँ हो गईं। यहां हमारे डोमेन-संबंधित आर्किटेक्चर में सबसे महत्वपूर्ण एंटीपैटर्न की सूची दी गई है।

1. मोटी घटनाएँ
हम अपने डोमेन के आयोजनों को यथासंभव कम करने की कोशिश करते हैं, जबकि उनके डोमेन मूल्य को कम नहीं करते हैं। हमें बड़ी संस्थाओं के साथ विरासत कोडबेस को फिर से व्यवस्थित करने और इवेंट आर्किटेक्चर पर स्विच करने पर सावधान रहना चाहिए। इस तरह की इकाइयाँ हमें मोटी घटनाओं की ओर ले जा सकती हैं, लेकिन चूँकि हमारे डोमेन इवेंट सार्वजनिक अनुबंध में बदल जाते हैं, इसलिए हमें उन्हें यथासंभव सरल बनाने की आवश्यकता थी। इस मामले में, रिफैक्टरिंग को पक्ष से सबसे अच्छा देखा जाता है। शुरू करने के लिए, हम ईवेंट तूफान तकनीक का उपयोग करके अपनी घटनाओं को डिज़ाइन करते हैंऔर फिर हमारी घटनाओं के लिए इसे अनुकूलित करने के लिए सेवा कोड को रिफलेक्टर करें।

हमें "उत्पाद और उपयोगकर्ता" समस्या के साथ अधिक सावधान रहना चाहिए: कई सिस्टम उत्पाद और उपयोगकर्ता संस्थाओं का उपयोग करते हैं, और ये संस्थाएं, एक नियम के रूप में, उनके पीछे के सभी तर्क को खींचती हैं, और इसका मतलब है कि सभी डोमेन घटनाएं उनके साथ जुड़ी हुई हैं।

2. इरादे के रूप में घटनाएँ एक
डोमेन घटना, परिभाषा के अनुसार, एक ऐसी घटना है जो पहले ही घटित हो चुकी है। यदि आप किसी अन्य सेवा में क्या हुआ, यह अनुरोध करने के लिए एक संदेश बस पर कुछ प्रकाशित करते हैं, तो आप डोमेन घटना बनाने के बजाय एक अतुल्यकालिक कमांड चलाने की संभावना रखते हैं। एक नियम के रूप में, हम पिछले डोमेन घटनाओं का उल्लेख करते हैं: ser_registered , product_publishedआदि कम सेवा एक दूसरे के बारे में जानता है, बेहतर है। ईवेंट का उपयोग आदेशों को लिंक सेवाओं के रूप में करने और इस संभावना को बढ़ाता है कि एक सेवा में परिवर्तन अन्य सेवाओं को प्रभावित करेगा।

3. स्वतंत्र क्रमांकन या संपीड़न का अभाव।
हमारे विषय क्षेत्र में घटनाओं के क्रमांकन और संपीड़न की प्रणाली प्रोग्रामिंग भाषा पर निर्भर नहीं होनी चाहिए। आपको यह भी जानने की जरूरत नहीं है कि उपभोक्ता भाषा किस भाषा में लिखी गई है। यही कारण है कि हम उदाहरण के लिए, जावा या PHP सीरियलाइज़र का उपयोग कर सकते हैं। अपनी टीम को एक धारावाहिक के बारे में चर्चा करने और चुनने में समय बिताने दें, क्योंकि भविष्य में इसे बदलना कठिन और समय लेने वाला होगा। हम लेगो पर JSON का उपयोग करते हैं, हालांकि अच्छे प्रदर्शन के साथ कई अन्य क्रमांकन प्रारूप हैं।

4. मानक संरचना का अभाव
जब हमने लेगो बैकएंड को एक इवेंट-ओरिएंटेड आर्किटेक्चर में पोर्ट करना शुरू किया, तो हम डोमेन इवेंट्स के लिए एक कॉमन स्ट्रक्चर पर सहमत हुए। यह कुछ इस तरह दिखता है:

{
  “data”: {
    “id”: [uuid], // event id.
    “type”: “user_registered”,
    “attributes”: {
      “id”: [uuid], // aggregate/entity id, in this case user_id
      “user_name”: “John Doe”,
      …
    }
  },
  “meta” : {
    “created_at”: timestamp, // when was the event created?
    “host”: “users-service” // where was the event created?
    …
  }
}

हमारे डोमेन ईवेंट के लिए एक सामान्य संरचना होने से हमें सेवाओं को जल्दी से एकीकृत करने और कुछ पुस्तकालयों को अमूर्त रूप से लागू करने की अनुमति मिलती है।

5. स्कीमा सत्यापन का अभाव
क्रमांकन के दौरान, हम मजबूत टाइपिंग के बिना प्रोग्रामिंग भाषाओं के साथ अनुभवी अनुभवी समस्याओं का सामना करते हैं।


{
  “null_value_one”: null, // thank god
  “null_value_two”: “null”,
  “null_value_three”: “”,
}

एक अच्छी तरह से स्थापित परीक्षण संस्कृति जो हमारी घटनाओं के क्रमांकन की गारंटी देती है, और क्रमांकन पुस्तकालय कैसे काम करता है, इस बात की समझ है। हम लेगो एवरो और कंफ्लुएंट स्कीमा रजिस्ट्री पर स्विच कर रहे हैं, जो हमें हमारे डोमेन की घटनाओं के ढांचे को निर्धारित करने का एक बिंदु प्रदान करता है और इस प्रकार की त्रुटियों से बचा जाता है, साथ ही अप्रचलित दस्तावेज भी।

6. एनीमिक डोमेन ईवेंट
जैसा कि मैंने पहले कहा था, और जैसा कि नाम से पता चलता है, डोमेन घटनाओं का डोमेन स्तर पर एक मूल्य होना चाहिए। जिस तरह हम अपनी संस्थाओं में राज्यों की असंगति से बचने की कोशिश करते हैं, उसी तरह हमें डोमेन घटनाओं में भी इससे बचना चाहिए। आइए इसे निम्नलिखित उदाहरण के साथ स्पष्ट करें: हमारे सिस्टम के उत्पाद में अक्षांश और देशांतर के साथ जियोलोकेशन है, जो उत्पाद सेवा के उत्पाद तालिका के दो अलग-अलग क्षेत्रों में संग्रहीत हैं। सभी उत्पादों को "स्थानांतरित" किया जा सकता है, इसलिए हमारे पास इस अपडेट को प्रस्तुत करने के लिए डोमेन इवेंट होंगे। पहले, हमारे पास इसके लिए दो इवेंट थे: product_latitude_updated और product_longitude_updated , जो कि शतरंज की बिसात पर अगर आप नहीं होते तो बहुत मायने नहीं रखते थे। इस मामले में, product_location_updated ईवेंट अधिक समझ में आएंगे।या product_moved ।

किश्ती एक शतरंज का टुकड़ा है। इसे टूर कहा जाता था। एक बदमाश केवल किसी भी तरह के निर्जन क्षेत्रों के माध्यम से लंबवत या क्षैतिज रूप से आगे बढ़ सकता है।

7. डिबगिंग टूल्स की कमी
हम लेगो में प्रति मिनट हजारों डोमेन घटनाओं का उत्पादन करते हैं। इन सभी घटनाओं को समझने के लिए एक अत्यंत उपयोगी संसाधन बन गया है कि हमारे सिस्टम में क्या हो रहा है, उपयोगकर्ता गतिविधि को पंजीकृत करना, या यहां तक कि इवेंट खोज का उपयोग करके किसी विशिष्ट बिंदु पर सिस्टम की स्थिति को फिर से संगठित करना। हमें इस संसाधन का कुशलतापूर्वक उपयोग करने की आवश्यकता है, और इसके लिए हमें अपने ईवेंट को जांचने और डीबग करने के लिए उपकरणों की आवश्यकता है। "मुझे पिछले 3 घंटों में जॉन डो द्वारा उत्पन्न सभी घटनाओं को दिखाने" जैसे अनुरोध भी धोखाधड़ी का पता लगाने में उपयोगी हो सकते हैं। इन उद्देश्यों के लिए, हमने ElasticSearch, Kibana और S3 पर कुछ उपकरण विकसित किए हैं।

8. घटना की निगरानी का अभाव
हम सिस्टम के स्वास्थ्य का परीक्षण करने के लिए डोमेन घटनाओं का उपयोग कर सकते हैं। जब हम किसी चीज़ को तैनात करते हैं (जो सेवा के आधार पर दिन में कई बार होती है), तो हमें सही ऑपरेशन को जल्दी से सत्यापित करने के लिए उपकरणों की आवश्यकता होती है। उदाहरण के लिए, यदि हम उत्पादन पर उत्पाद सेवा का नया संस्करण तैनात करते हैं और उत्पाद_प्रकाशित घटनाओं की संख्या में कमी देखते हैं20%, यह कहना सुरक्षित है कि हमने कुछ तोड़ दिया। हम वर्तमान में व्युत्पन्न कार्यों के साथ इसे प्राप्त करने के लिए इन्फ्लक्सडीबी, ग्राफाना और प्रोमेथियस का उपयोग कर रहे हैं। यदि आप गणित के पाठ्यक्रम को याद करते हैं, तो आप समझेंगे कि बिंदु x पर फ़ंक्शन f (x) की व्युत्पत्ति इस बिंदु पर फ़ंक्शन के ग्राफ के लिए खींची गई स्पर्शरेखा के ढलान के बराबर है। यदि आपके पास किसी विशिष्ट क्षेत्र में किसी विशिष्ट घटना की गति को प्रकाशित करने के लिए एक फ़ंक्शन है और आप इससे व्युत्पन्न लेते हैं, तो आप इस फ़ंक्शन की चोटियों को देखेंगे और आप उनके आधार पर सूचनाएं सेट कर सकते हैं। इन सूचनाओं का उपयोग करके, आप "मुझे चेतावनी दें यदि हम प्रति मिनट 200 से कम घटनाओं को 5 मिनट के लिए प्रकाशित करें" जैसे वाक्यांशों से बच सकते हैं और प्रकाशन की गति में महत्वपूर्ण बदलाव पर ध्यान केंद्रित कर सकते हैं।

यहाँ कुछ अजीब हुआ ... या शायद यह सिर्फ एक विपणन अभियान है

9. आशा है कि सबकुछ ठीक हो जाएगा
हम टिकाऊ सिस्टम बनाने और उनकी बहाली की लागत को कम करने की कोशिश कर रहे हैं। बुनियादी ढांचे के मुद्दों और मानव कारक के अलावा, सबसे सामान्य चीजों में से एक जो घटना वास्तुकला को प्रभावित कर सकती है, वह घटनाओं का नुकसान है। हमें एक ऐसी योजना की आवश्यकता है जिसके साथ हम खोई हुई सभी घटनाओं को फिर से संसाधित करके सिस्टम की सही स्थिति को बहाल कर सकें। यहां, हमारी रणनीति दो बिंदुओं पर आधारित है:

: , « , », - , . letgo Data, Backend.
: - . , , , message bus . – , , . , user_registered Users, , MySQL, user_id . user_registered, , . , , - MySQL ( , 30 ). -, DynamoDB. , , , . , , , , .

10. डोमेन घटनाओं पर प्रलेखन की कमी
हमारे डोमेन इवेंट बैकएंड पर सभी प्रणालियों के लिए हमारा सार्वजनिक इंटरफ़ेस बन गए हैं। जिस तरह हम अपने REST API को डॉक्यूमेंट करते हैं, ठीक उसी तरह हमें डोमेन इवेंट्स को भी डॉक्यूमेंट करने की जरूरत है। संगठन के किसी भी कर्मचारी को प्रत्येक सेवा द्वारा प्रकाशित प्रत्येक डोमेन घटना के लिए अद्यतन प्रलेखन देखने में सक्षम होना चाहिए। यदि हम डोमेन घटनाओं की जाँच के लिए योजनाओं का उपयोग करते हैं, तो उन्हें प्रलेखन के रूप में भी उपयोग किया जा सकता है।

11. स्वयं की घटनाओं के उपभोग का प्रतिरोध
आपको अपने सिस्टम में अनुमान बनाने के लिए अपने स्वयं के डोमेन ईवेंट का उपयोग करने की अनुमति दी जाती है और यहां तक कि प्रोत्साहित किया जाता है, जो उदाहरण के लिए, पढ़ने के लिए अनुकूलित हैं। कुछ टीमों ने इस अवधारणा का विरोध किया, क्योंकि वे अन्य लोगों की घटनाओं के उपभोग की अवधारणा तक ही सीमित थे।

कोर्स पर मिलते हैं!

घटना-उन्मुख वास्तुकला के एंटीपैटर्न

-

लेगो में घटना-संचालित वास्तुकला

Antipatterns

More articles: