इवेंट सोर्सिंग और CQRS को लागू करने के लिए अक्का टूलकिट में जाने से पहले आपको क्या जानना चाहिए

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

2015 के आसपास, हमने अपना पारिस्थितिकी तंत्र डिजाइन करना शुरू किया। विश्लेषण और स्काला और अक्का के साथ अनुभव के आधार पर, हमने अक्का टूलकिट पर रुकने का फैसला किया। हमारे पास CQRS के साथ इवेंट सोर्सिंग टेम्प्लेट का सफल कार्यान्वयन था और ऐसा नहीं है। इस क्षेत्र में विशेषज्ञता का संचय, जिसे मैं पाठकों के साथ साझा करना चाहता हूं। हम देखेंगे कि अक्का इन पैटर्नों को कैसे लागू करता है, साथ ही साथ कौन से उपकरण उपलब्ध हैं और अक्का नुकसान के बारे में बात करते हैं। मुझे उम्मीद है कि इस लेख को पढ़ने के बाद, आपको अक्का टूलकिट पर स्विच करने के जोखिमों के बारे में अधिक समझ होगी।

CQRS और इवेंट सोर्सिंग के विषयों पर हैबे और अन्य संसाधनों पर कई लेख लिखे गए थे। यह लेख उन पाठकों के लिए है जो पहले से ही समझते हैं कि CQRS और Event Sourcing क्या हैं। लेख में मैं अक्का पर ध्यान केंद्रित करना चाहता हूं।

डोमेन संचालित डिजाइन

Domain-Driven Design (DDD) के बारे में बहुत सारी सामग्री लिखी गई है। इस दृष्टिकोण के विरोधी और समर्थक दोनों हैं। मैं अपने आप को जोड़ना चाहता हूं कि यदि आप इवेंट सोर्सिंग और सीक्यूआरएस पर स्विच करने का निर्णय लेते हैं, तो यह डीडीडी का अध्ययन करने के लिए बेहतर नहीं होगा। इसके अलावा, डीडीडी दर्शन सभी अक्का उपकरणों में महसूस किया जाता है।

वास्तव में, इवेंट सोर्सिंग और CQRS डोमेन-ड्रिवेन डिज़ाइन नामक बड़ी तस्वीर का एक छोटा सा हिस्सा हैं। डिजाइन और विकास करते समय, आपके पास इन टेम्प्लेटों को ठीक से लागू करने और पारिस्थितिकी तंत्र में एकीकृत करने के बारे में कई प्रश्न हो सकते हैं, और डीडीडी को जानने से आपका जीवन आसान हो जाएगा।

इस अनुच्छेद में, शब्द इकाई (DDD द्वारा इकाई) का अर्थ एक निरंतरता अभिनेता होगा जिसमें एक विशिष्ट पहचानकर्ता होगा।

स्काला क्यों?

हमसे अक्सर पूछा जाता है कि स्काला, और जावा क्यों नहीं। एक कारण अक्का है। जावा भाषा के समर्थन के साथ स्काला भाषा में लिखा गया फ्रेमवर्क। यहाँ मुझे यह कहना होगा कि .NET पर एक कार्यान्वयन भी है, लेकिन यह एक अन्य विषय है। चर्चा का कारण न बनने के लिए, मैं यह नहीं लिखूंगा कि स्काला जावा से बेहतर या बदतर क्यों है। मैं आपको केवल कुछ उदाहरण बताऊंगा, जो मेरी राय में, अका के साथ काम करने पर स्काला को जावा पर एक फायदा है:

• अपरिवर्तनीय वस्तुएँ। जावा में, आपको स्वयं अपरिवर्तनीय वस्तुओं को लिखने की आवश्यकता है। मेरा विश्वास करो, यह आसान नहीं है और अंतिम मापदंडों को लगातार लिखने के लिए बहुत सुविधाजनक नहीं है। स्काला case class पहले से अंतर्निहित copy फ़ंक्शन के साथ अपरिवर्तनीय है
• कोडिंग शैली। जावा में लागू होने पर, आप अभी भी स्केल शैली में लिखेंगे, अर्थात कार्यात्मक रूप से।

यहाँ स्काला और जावा में अभिनेता का एक उदाहरण कार्यान्वयन है:

स्केला:

 object DemoActor { def props(magicNumber: Int): Props = Props(new DemoActor(magicNumber)) } class DemoActor(magicNumber: Int) extends Actor { def receive = { case x: Int => sender() ! (x + magicNumber) } } class SomeOtherActor extends Actor { context.actorOf(DemoActor.props(42), "demo") // ... } 

जावा:

 static class DemoActor extends AbstractActor { static Props props(Integer magicNumber) { return Props.create(DemoActor.class, () -> new DemoActor(magicNumber)); } private final Integer magicNumber; public DemoActor(Integer magicNumber) { this.magicNumber = magicNumber; } @Override public Receive createReceive() { return receiveBuilder() .match( Integer.class, i -> { getSender().tell(i + magicNumber, getSelf()); }) .build(); } } static class SomeOtherActor extends AbstractActor { ActorRef demoActor = getContext().actorOf(DemoActor.props(42), "demo"); // ... } 

( यहां से लिया गया उदाहरण)

Java भाषा उदाहरण का उपयोग करके createReceive() पद्धति के कार्यान्वयन पर ध्यान दें। आंतरिक रूप से, ReceiveBuilder कारखाने के माध्यम से, पैटर्न-मिलान लागू किया जाता है। receiveBuilder() की एक विधि है जो लैम्ब्डा एक्सप्रेशंस का समर्थन करती है, जिसका नाम जावा में पैटर्न-मैचिंग है। स्काला में, इसे मूल रूप से लागू किया गया है। सहमत हूँ, स्काला का कोड छोटा और पढ़ने में आसान है।

• प्रलेखन और उदाहरण। इस तथ्य के बावजूद कि आधिकारिक दस्तावेज में जावा, इंटरनेट पर उदाहरण हैं, लगभग सभी उदाहरण स्काला में हैं। साथ ही, अक्का पुस्तकालय के स्रोतों में नेविगेट करना आपके लिए आसान होगा।

प्रदर्शन के मामले में, स्काला और जावा के बीच कोई अंतर नहीं होगा, क्योंकि सब कुछ जेवीएम में घूमता है।

कोष

एक्का पर्सिस्टेंस के साथ इवेंट सोर्सिंग को लागू करने से पहले, मेरा सुझाव है कि आप स्थायी डेटा भंडारण के लिए एक डेटाबेस का चयन करें। आधार की पसंद आपकी इच्छाओं और वरीयताओं पर, सिस्टम के लिए आवश्यकताओं पर निर्भर करती है। डेटा को NoSQL और RDBMS, और फ़ाइल सिस्टम में संग्रहीत किया जा सकता है, उदाहरण के लिए, Google से LevelDB।

यह ध्यान रखना महत्वपूर्ण है कि डेटाबेस से डेटा लिखने और पढ़ने के लिए अक्का दृढ़ता ज़िम्मेदार नहीं है, लेकिन क्या यह प्लग-इन के माध्यम से अक्का पर्सिस्टेंस एपीआई को लागू करना चाहिए।

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

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

यह उल्लेखनीय है कि प्लगइन में कई समस्याएं भी हैं। उदाहरण के लिए, अभी भी कोई स्थिर संस्करण नहीं है (इस लेखन के समय, नवीनतम संस्करण 0.97 है)। हमारे लिए, इस प्लगइन का उपयोग करते समय हमने जो सबसे बड़ा उपद्रव किया था वह कुछ संस्थाओं के लिए लगातार प्रश्न पढ़ने के दौरान घटनाओं का नुकसान था। एक पूरी तस्वीर के लिए, नीचे CQRS चार्ट है:

लगातार इकाई हैश एल्गोरिथ्म का उपयोग करके टैग में इकाई घटनाओं को वितरित करता है (उदाहरण के लिए, 10 शार्क):

फिर, Persistent Query इन टैग्स की सदस्यता लेता है और एक स्ट्रीम लॉन्च करता है जो Elastic Search में डेटा जोड़ता है। चूंकि कैसंड्रा एक क्लस्टर में है, इसलिए घटनाओं को नोड्स में बिखेर दिया जाएगा। कुछ नोड्स शिथिल हो सकते हैं और दूसरों की तुलना में अधिक धीमी गति से प्रतिक्रिया करेंगे। इस बात की कोई गारंटी नहीं है कि आप सख्त क्रम में घटनाओं को प्राप्त करेंगे। इस समस्या को हल करने के लिए, प्लगइन को कार्यान्वित किया जाता है ताकि अगर उसे एक अनियंत्रित घटना प्राप्त हो, उदाहरण के लिए, entity-A event NR 2 , तो यह प्रारंभिक घटना के लिए एक निश्चित समय की प्रतीक्षा करता है और यदि यह प्राप्त नहीं होता है, तो यह बस इस इकाई की सभी घटनाओं को अनदेखा कर देगा। इस बारे में भी, गटर पर चर्चा हुई। अगर किसी को दिलचस्पी है, तो आप @kotdv और प्लगइन के डेवलपर्स के बीच पत्राचार पढ़ सकते हैं: Gitter

इस गलतफहमी को कैसे हल किया जा सकता है:

• आपको प्लगइन को नवीनतम संस्करण में अपडेट करना होगा। हाल के संस्करणों में, टाइपसेफ़ डेवलपर्स ने अंततः संगति से संबंधित कई समस्याओं को हल किया है। लेकिन, हम अभी भी एक स्थिर संस्करण की प्रतीक्षा कर रहे हैं
• घटनाओं को प्राप्त करने के लिए जिम्मेदार घटक के लिए अधिक सटीक सेटिंग्स जोड़ी गई हैं। आप प्लगइन के अधिक विश्वसनीय संचालन के लिए assandra-query-journal.events-by-tag.eventual-consistency.delay=10s घटनाओं के लिए समय सीमा बढ़ाने की कोशिश कर सकते हैं: c assandra-query-journal.events-by-tag.eventual-consistency.delay=10s
• डेटास्टैक्स द्वारा अनुशंसित कैसेंड्रा को कॉन्फ़िगर करें। कचरा कलेक्टर G1 रखो और Cassandra के लिए जितना संभव हो उतना मेमोरी आवंटित करें।

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

 object SomeEntity { sealed trait Event { def uuid: String } /** * ,    . */ case class DidSomething(uuid: String) extends Event /** * ,       . */ case class LastEventPublished(uuid: String) extends Event /** * ,     . * @param unpublishedEvents –  ,   . */ case class State(unpublishedEvents: Seq[Event]) object State { def updated(event: Event): State = event match { case evt: DidSomething => copy( unpublishedEvents = unpublishedEvents :+ evt ) case evt: LastEventPublished => copy( unpublishedEvents = unpublishedEvents.filter(_.uuid != evt.uuid) ) } } } class SomeEntity extends PersistentActor { … persist(newEvent) { evt => updateState(evt) publishToEventBus(evt) } … } 

यदि किसी कारण से घटना को प्रकाशित करना संभव नहीं था, तो SomeEntity की अगली शुरुआत में, यह पता चलेगा कि DidSomething घटना बस तक नहीं DidSomething और फिर से डेटा को पुनः प्रकाशित करने का प्रयास करेगी।

serializer

अर्क का उपयोग करने में एक समान रूप से महत्वपूर्ण बिंदु है। उसके पास एक आंतरिक मॉड्यूल है - अक्का सीरियललाइज़ेशन । इस मॉड्यूल का उपयोग संदेशों को अनुक्रमित करने के लिए किया जाता है जब उन्हें अभिनेताओं के बीच आदान-प्रदान करते हैं और जब उन्हें Persistence API के माध्यम से संग्रहीत किया जाता है। डिफ़ॉल्ट रूप से, जावा सीरियलाइज़र का उपयोग किया जाता है, लेकिन इसे दूसरे का उपयोग करने की सिफारिश की जाती है। समस्या यह है कि Java Serializer धीमा है और बहुत अधिक जगह लेता है। दो लोकप्रिय समाधान हैं - ये JSON और Protobuf हैं। JSON, हालांकि धीमी है, इसे लागू करना और बनाए रखना आसान है। यदि आपको क्रमांकन और डेटा भंडारण की लागत को कम करने की आवश्यकता है, तो आप प्रोटोबॉफ़ पर रोक सकते हैं, लेकिन फिर विकास प्रक्रिया धीमी हो जाएगी। डोमेन मॉडल के अलावा, आपको एक और डेटा मॉडल लिखना होगा। डेटा संस्करण के बारे में मत भूलना। डोमेन मॉडल और डेटा मॉडल के बीच लगातार मैपिंग लिखने के लिए तैयार रहें।

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

निष्कर्ष

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