बीपीएम शैली एकीकरण

Привет, Habr!

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

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

исклеймер

लेख में वर्णित वास्तु और तकनीकी समाधान मेरे द्वारा विशिष्ट कार्यों के संदर्भ में व्यक्तिगत अनुभव के आधार पर प्रस्तुत किए गए हैं। ये समाधान सार्वभौमिक होने का दावा नहीं करते हैं और उपयोग की अन्य शर्तों के तहत इष्टतम नहीं हो सकते हैं।

बीपीएम का इससे क्या लेना-देना है?

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

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

• कॉनवे के कानून के प्रभाव में;
• अन्य उत्पादों के लिए पहले विकसित उप-प्रणालियों के पुन: उपयोग के परिणामस्वरूप;
• जैसा कि वास्तुकार द्वारा तय किया गया है, गैर-कार्यात्मक आवश्यकताओं के आधार पर।

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

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

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

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

परियोजना की शुरुआत में यह प्रक्रिया कैसी दिखती है

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

आवश्यकताओं को स्पष्ट करने के कई पुनरावृत्तियों के बाद यह प्रक्रिया कैसी दिखती है

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

एक जटिल व्यवसाय प्रक्रिया का एक छोटा सा हिस्सा

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

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

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

एकीकरण पैटर्न के रूप में सिंक्रोनस कॉल के नुकसान

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

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

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

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

वास्तुकला के दृष्टिकोण से, एकीकरण के दौरान ब्लॉकिंग कॉल के उपयोग से व्यक्तिगत सबसिस्टम के गुणवत्ता नियंत्रण का नुकसान होता है: एक सबसिस्टम के गुणवत्ता लक्ष्यों को दूसरे सबसिस्टम के गुणवत्ता लक्ष्यों से अलगाव में सुनिश्चित करना असंभव है। यदि सबसिस्टम अलग-अलग टीमों द्वारा विकसित किए जाते हैं, तो यह एक बड़ी समस्या है।

चीजें और भी दिलचस्प हो जाती हैं यदि उप-प्रणालियों को एकीकृत किया जा रहा है जो विभिन्न अनुप्रयोगों में हैं और दोनों पक्षों में तुल्यकालिक परिवर्तन किए जाने की आवश्यकता है। इन परिवर्तनों को लेन-देन कैसे करें?

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

वितरित लेन-देन भी दिमाग में आते हैं, लेकिन हम उन्हें अपने समाधान में उपयोग नहीं करते हैं: विश्वसनीयता सुनिश्चित करना मुश्किल है।

लेन-देन की समस्या के समाधान के रूप में "सागा"

माइक्रोसर्विसेज की बढ़ती लोकप्रियता के साथ, इसकी मांग भी बढ़ रही है सागा पैटर्न.

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

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

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

लेकिन इस समाधान की अपनी "कीमत" भी है:

• व्यापार तर्क अधिक जटिल हो जाता है: आपको मुआवजे का काम करने की जरूरत है;
• पूर्ण स्थिरता को त्यागना आवश्यक होगा, जो विशेष रूप से अखंड प्रणालियों के लिए संवेदनशील हो सकता है;
• वास्तुकला थोड़ी अधिक जटिल हो जाती है, एक संदेश दलाल की अतिरिक्त आवश्यकता होती है;
• अतिरिक्त निगरानी और प्रशासन उपकरण की आवश्यकता होगी (हालांकि सामान्य तौर पर यह और भी अच्छा है: सिस्टम सेवा की गुणवत्ता में वृद्धि होगी)।

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

माइक्रोसर्विसेज में बिजनेस लॉजिक का इनकैप्सुलेशन

जब हमने माइक्रोसर्विसेज के साथ प्रयोग करना शुरू किया, तो एक वाजिब सवाल उठा: डोमेन डेटा दृढ़ता प्रदान करने वाली सेवा के संबंध में डोमेन बिजनेस लॉजिक को कहां रखा जाए?

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

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

एक अधिक विस्तृत अध्ययन से इस दृष्टिकोण की महत्वपूर्ण कमियों का पता चला:

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

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

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

ऐसी वास्तुकला में प्लेटफ़ॉर्म सेवाओं की एक परत भी मौजूद है, लेकिन यह परत अब डोमेन व्यवसाय तर्क को निष्पादित करने के लिए एक कंटेनर नहीं बनाती है, बल्कि केवल इसका वातावरण, सहायक "प्लेटफ़ॉर्म" फ़ंक्शन प्रदान करती है। इस तरह की परत की न केवल डोमेन माइक्रोसर्विसेज की लपट बनाए रखने के लिए, बल्कि प्रबंधन को केंद्रीकृत करने के लिए भी आवश्यक है।

उदाहरण के लिए, व्यावसायिक प्रक्रियाओं में उपयोगकर्ता गतिविधियाँ कार्य उत्पन्न करती हैं। हालाँकि, कार्यों के साथ काम करते समय, उपयोगकर्ता को सामान्य सूची में सभी डोमेन के कार्यों को देखना चाहिए, जिसका अर्थ है कि एक उपयुक्त कार्य पंजीकरण प्लेटफ़ॉर्म सेवा होनी चाहिए, जो डोमेन व्यवसाय तर्क से साफ़ हो। इस संदर्भ में व्यावसायिक तर्क को समेटना काफी समस्याग्रस्त है, और यह इस वास्तुकला का एक और समझौता है।

एप्लिकेशन डेवलपर की दृष्टि से व्यावसायिक प्रक्रियाओं का एकीकरण

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

आइए एक कठिन एकीकरण समस्या को हल करने का प्रयास करें, विशेष रूप से लेख के लिए आविष्कार किया गया। यह एक "गेम" कार्य होगा जिसमें तीन एप्लिकेशन शामिल होंगे, जहां उनमें से प्रत्येक कुछ डोमेन नाम परिभाषित करता है: "एप 1", "एप 2", "एप 3"।

प्रत्येक एप्लिकेशन के अंदर, व्यावसायिक प्रक्रियाएं लॉन्च की जाती हैं जो एकीकरण बस के माध्यम से "प्ले बॉल" शुरू होती हैं। "बॉल" नाम के संदेश बॉल की तरह काम करेंगे।

खेल के नियम:

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

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

ऐप 1 एप्लिकेशन में, पहले खिलाड़ी की व्यावसायिक प्रक्रिया (वह गेम का सर्जक भी है) काम करेगी:

क्लास इनिशियलप्लेयर

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.constraint.UniqueConstraints
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.dsl.taskOperation
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList : ArrayList<PlayerInfo>()

// Это класс экземпляра процесса: инкапсулирует его внутреннее состояние
class InitialPlayer : ProcessImpl<InitialPlayer>(initialPlayerModel) {
    var playerName: String by persistent("Player1")
    var energy: Int by persistent(30)
    var players: PlayersList by persistent(PlayersList())
    var shotCounter: Int = 0
}

// Это декларация модели процесса: создается один раз, используется всеми
// экземплярами процесса соответствующего класса
val initialPlayerModel = processModel<InitialPlayer>(name = "InitialPlayer",
                                                     version = 1) {

    // По правилам, первый игрок является инициатором игры и должен быть единственным
    uniqueConstraint = UniqueConstraints.singleton

    // Объявляем активности, из которых состоит бизнес-процесс
    val sendNewGameSignal = signal<String>("NewGame")
    val sendStopGameSignal = signal<String>("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "Подключилось ${players.size} игроков. Начинаем?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait<String>("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... join player ${signal.data} ...")
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... player ${signal.data} is out ...")
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val throwStartBall = messageSend<Int>("Ball") {
        messageData = { 1 }
        activation = { selectNextPlayer() }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    // Теперь конструируем граф процесса из объявленных активностей
    startFrom(sendNewGameSignal)
            .fork("mainFork") {
                next(startTask)
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut)
                        .branch("checkPlayers") {
                            ifTrue { players.isEmpty() }
                                    .next(sendStopGameSignal)
                                    .terminate()
                            ifElse().next(waitPlayerOut)
                        }
            }
    startTask.fork("afterStart") {
        next(throwStartBall)
                .branch("mainLoop") {
                    ifTrue { energy < 5 }.next(sendPlayerOut).next(waitBall)
                    ifElse().next(waitBall).next(throwBall).loop()
                }
        next(stopTask).next(sendStopGameSignal)
    }

    // Навешаем на активности дополнительные обработчики для логирования
    sendNewGameSignal.onExit { println("Let's play!") }
    sendStopGameSignal.onExit { println("Stop!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<InitialPlayer, Int>.selectNextPlayer() {
    val player = process.players.random()
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

व्यापार तर्क को निष्पादित करने के अलावा, उपरोक्त कोड एक व्यापार प्रक्रिया का एक वस्तु मॉडल तैयार कर सकता है जिसे आरेख के रूप में देखा जा सकता है। हमने अभी तक विज़ुअलाइज़र को लागू नहीं किया है, इसलिए हमें ड्राइंग में कुछ समय बिताना पड़ा (यहाँ मैंने उपरोक्त कोड के साथ आरेख की स्थिरता में सुधार करने के लिए गेट्स के उपयोग के संबंध में BPMN संकेतन को थोड़ा सरल बनाया है):

app2 में दूसरे खिलाड़ी की व्यवसाय प्रक्रिया शामिल होगी:

क्लास रैंडमप्लेयर

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RandomPlayer : ProcessImpl<RandomPlayer>(randomPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RandomPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val randomPlayerModel = processModel<RandomPlayer>(name = "RandomPlayer", 
                                                   version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!,
                    signal.sender.domain,
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RandomPlayer, Int>.selectNextPlayer() {
    val player = if (process.players.isNotEmpty()) 
        process.players.random() 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

आरेख:

ऐप 3 एप्लिकेशन में, हम खिलाड़ी को थोड़ा अलग व्यवहार बनाएंगे: अगले खिलाड़ी को बेतरतीब ढंग से चुनने के बजाय, वह राउंड-रॉबिन एल्गोरिथम के अनुसार कार्य करेगा:

क्लास राउंडरॉबिनप्लेयर

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RoundRobinPlayer : ProcessImpl<RoundRobinPlayer>(roundRobinPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RoundRobinPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var nextPlayerIndex: Int by persistent(-1)
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val roundRobinPlayerModel = processModel<RoundRobinPlayer>(
        name = "RoundRobinPlayer", 
        version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!, 
                    signal.sender.domain, 
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!, 
                signal.sender.domain, 
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RoundRobinPlayer, Int>.selectNextPlayer() {
    var idx = process.nextPlayerIndex + 1
    if (idx >= process.players.size) {
        idx = 0
    }
    process.nextPlayerIndex = idx
    val player = if (process.players.isNotEmpty()) 
        process.players[idx] 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

अन्यथा, खिलाड़ी का व्यवहार पिछले वाले से भिन्न नहीं होता है, इसलिए आरेख नहीं बदलता है।

अब हमें इसे चलाने के लिए एक परीक्षण की जरूरत है। मैं केवल परीक्षण का कोड ही दूंगा, ताकि बॉयलरप्लेट के साथ लेख को अव्यवस्थित न किया जा सके (वास्तव में, मैंने अन्य व्यावसायिक प्रक्रियाओं के एकीकरण का परीक्षण करने के लिए पहले बनाए गए परीक्षण वातावरण का उपयोग किया था):

टेस्टगेम ()

@Test
public void testGame() throws InterruptedException {
    String pl2 = startProcess(app2, "RandomPlayer", playerParams("Player2", 20));
    String pl3 = startProcess(app2, "RandomPlayer", playerParams("Player3", 40));
    String pl4 = startProcess(app3, "RoundRobinPlayer", playerParams("Player4", 25));
    String pl5 = startProcess(app3, "RoundRobinPlayer", playerParams("Player5", 35));
    String pl1 = startProcess(app1, "InitialPlayer");
    // Теперь нужно немного подождать, пока игроки "познакомятся" друг с другом.
    // Ждать через sleep - плохое решение, зато самое простое. 
    // Не делайте так в серьезных тестах!
    Thread.sleep(1000);
    // Запускаем игру, закрывая пользовательскую активность
    assertTrue(closeTask(app1, pl1, "Start"));
    app1.getWaiting().waitProcessFinished(pl1);
    app2.getWaiting().waitProcessFinished(pl2);
    app2.getWaiting().waitProcessFinished(pl3);
    app3.getWaiting().waitProcessFinished(pl4);
    app3.getWaiting().waitProcessFinished(pl5);
}

private Map<String, Object> playerParams(String name, int energy) {
    Map<String, Object> params = new HashMap<>();
    params.put("playerName", name);
    params.put("energy", energy);
    return params;
}

परीक्षण चलाएँ, लॉग देखें:

कंसोल आउटपुट

Взята блокировка ключа lock://app1/process/InitialPlayer
Let's play!
Снята блокировка ключа lock://app1/process/InitialPlayer
Player2: I'm here!
Player3: I'm here!
Player4: I'm here!
Player5: I'm here!
... join player Player2 ...
... join player Player4 ...
... join player Player3 ...
... join player Player5 ...
Step 1: Player1 >>> Player3
Step 2: Player3 >>> Player5
Step 3: Player5 >>> Player3
Step 4: Player3 >>> Player4
Step 5: Player4 >>> Player3
Step 6: Player3 >>> Player4
Step 7: Player4 >>> Player5
Step 8: Player5 >>> Player2
Step 9: Player2 >>> Player5
Step 10: Player5 >>> Player4
Step 11: Player4 >>> Player2
Step 12: Player2 >>> Player4
Step 13: Player4 >>> Player1
Step 14: Player1 >>> Player4
Step 15: Player4 >>> Player3
Step 16: Player3 >>> Player1
Step 17: Player1 >>> Player2
Step 18: Player2 >>> Player3
Step 19: Player3 >>> Player1
Step 20: Player1 >>> Player5
Step 21: Player5 >>> Player1
Step 22: Player1 >>> Player2
Step 23: Player2 >>> Player4
Step 24: Player4 >>> Player5
Step 25: Player5 >>> Player3
Step 26: Player3 >>> Player4
Step 27: Player4 >>> Player2
Step 28: Player2 >>> Player5
Step 29: Player5 >>> Player2
Step 30: Player2 >>> Player1
Step 31: Player1 >>> Player3
Step 32: Player3 >>> Player4
Step 33: Player4 >>> Player1
Step 34: Player1 >>> Player3
Step 35: Player3 >>> Player4
Step 36: Player4 >>> Player3
Step 37: Player3 >>> Player2
Step 38: Player2 >>> Player5
Step 39: Player5 >>> Player4
Step 40: Player4 >>> Player5
Step 41: Player5 >>> Player1
Step 42: Player1 >>> Player5
Step 43: Player5 >>> Player3
Step 44: Player3 >>> Player5
Step 45: Player5 >>> Player2
Step 46: Player2 >>> Player3
Step 47: Player3 >>> Player2
Step 48: Player2 >>> Player5
Step 49: Player5 >>> Player4
Step 50: Player4 >>> Player2
Step 51: Player2 >>> Player5
Step 52: Player5 >>> Player1
Step 53: Player1 >>> Player5
Step 54: Player5 >>> Player3
Step 55: Player3 >>> Player5
Step 56: Player5 >>> Player2
Step 57: Player2 >>> Player1
Step 58: Player1 >>> Player4
Step 59: Player4 >>> Player1
Step 60: Player1 >>> Player4
Step 61: Player4 >>> Player3
Step 62: Player3 >>> Player2
Step 63: Player2 >>> Player5
Step 64: Player5 >>> Player4
Step 65: Player4 >>> Player5
Step 66: Player5 >>> Player1
Step 67: Player1 >>> Player5
Step 68: Player5 >>> Player3
Step 69: Player3 >>> Player4
Step 70: Player4 >>> Player2
Step 71: Player2 >>> Player5
Step 72: Player5 >>> Player2
Step 73: Player2 >>> Player1
Step 74: Player1 >>> Player4
Step 75: Player4 >>> Player1
Step 76: Player1 >>> Player2
Step 77: Player2 >>> Player5
Step 78: Player5 >>> Player4
Step 79: Player4 >>> Player3
Step 80: Player3 >>> Player1
Step 81: Player1 >>> Player5
Step 82: Player5 >>> Player1
Step 83: Player1 >>> Player4
Step 84: Player4 >>> Player5
Step 85: Player5 >>> Player3
Step 86: Player3 >>> Player5
Step 87: Player5 >>> Player2
Step 88: Player2 >>> Player3
Player2: I'm out!
Step 89: Player3 >>> Player4
... player Player2 is out ...
Step 90: Player4 >>> Player1
Step 91: Player1 >>> Player3
Step 92: Player3 >>> Player1
Step 93: Player1 >>> Player4
Step 94: Player4 >>> Player3
Step 95: Player3 >>> Player5
Step 96: Player5 >>> Player1
Step 97: Player1 >>> Player5
Step 98: Player5 >>> Player3
Step 99: Player3 >>> Player5
Step 100: Player5 >>> Player4
Step 101: Player4 >>> Player5
Player4: I'm out!
... player Player4 is out ...
Step 102: Player5 >>> Player1
Step 103: Player1 >>> Player3
Step 104: Player3 >>> Player1
Step 105: Player1 >>> Player3
Step 106: Player3 >>> Player5
Step 107: Player5 >>> Player3
Step 108: Player3 >>> Player1
Step 109: Player1 >>> Player3
Step 110: Player3 >>> Player5
Step 111: Player5 >>> Player1
Step 112: Player1 >>> Player3
Step 113: Player3 >>> Player5
Step 114: Player5 >>> Player3
Step 115: Player3 >>> Player1
Step 116: Player1 >>> Player3
Step 117: Player3 >>> Player5
Step 118: Player5 >>> Player1
Step 119: Player1 >>> Player3
Step 120: Player3 >>> Player5
Step 121: Player5 >>> Player3
Player5: I'm out!
... player Player5 is out ...
Step 122: Player3 >>> Player5
Step 123: Player5 >>> Player1
Player5: I'm out!
Step 124: Player1 >>> Player3
... player Player5 is out ...
Step 125: Player3 >>> Player1
Step 126: Player1 >>> Player3
Player1: I'm out!
... player Player1 is out ...
Step 127: Player3 >>> Player3
Player3: I'm out!
Step 128: Player3 >>> Player3
... player Player3 is out ...
Player3: I'm out!
Stop!
Step 129: Player3 >>> Player3
Player3: I'm out!

इस सब से कई महत्वपूर्ण निष्कर्ष निकाले जा सकते हैं:

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

अगला, आइए हमारे समाधान, समझौता और अन्य बिंदुओं की विभिन्न सूक्ष्मताओं के बारे में बात करें।

सभी संदेश एक कतार में

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

हालाँकि, यहाँ एक सूक्ष्मता है: प्रत्येक एप्लिकेशन अपने डोमेन के नाम से प्रवेश द्वार पर कतार से "अपने" संदेशों को फ़िल्टर करता है। साथ ही, डोमेन को सिग्नल में निर्दिष्ट किया जा सकता है, यदि आपको सिग्नल के "दायरे" को एक ही एप्लिकेशन तक सीमित करने की आवश्यकता है। इससे बस की बैंडविड्थ बढ़नी चाहिए, लेकिन व्यावसायिक तर्क को अब डोमेन नाम के साथ काम करना चाहिए: संदेशों को संबोधित करने के लिए अनिवार्य, संकेतों के लिए वांछनीय।

एकीकरण बस की विश्वसनीयता सुनिश्चित करना

विश्वसनीयता कई चीजों से बनी होती है:

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

व्यापार तर्क की थ्रेड सुरक्षा सुनिश्चित करना

व्यवसाय प्रक्रिया का एक ही उदाहरण एक साथ कई संदेश और घटनाएँ प्राप्त कर सकता है, जिसकी प्रक्रिया समानांतर में शुरू होगी। उसी समय, एक एप्लिकेशन डेवलपर के लिए, सब कुछ सरल और थ्रेड-सुरक्षित होना चाहिए।

प्रक्रिया व्यापार तर्क प्रत्येक बाहरी घटना को संसाधित करता है जो इस व्यवसाय प्रक्रिया को व्यक्तिगत रूप से प्रभावित करता है। ये घटनाएं हो सकती हैं:

• एक व्यवसाय प्रक्रिया उदाहरण लॉन्च करना;
• व्यवसाय प्रक्रिया के अंतर्गत किसी गतिविधि से संबंधित उपयोगकर्ता क्रिया;
• एक संदेश या संकेत की प्राप्ति जिसके लिए एक व्यवसाय प्रक्रिया आवृत्ति की सदस्यता ली गई है;
• व्यवसाय प्रक्रिया उदाहरण द्वारा निर्धारित टाइमर की समाप्ति;
• एपीआई के माध्यम से नियंत्रण कार्रवाई (जैसे प्रक्रिया निरस्त)।

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

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

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

हालाँकि, निराशावादी ताले हमें गतिरोध की धमकी देते हैं, जिसका अर्थ है कि व्यापार तर्क में कुछ गंभीर मामलों पर गतिरोध के मामले में अद्यतन के लिए चयन अभी भी कुछ उचित समय तक सीमित होना चाहिए।

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

हमारे उदाहरणों में, InitialPlayer व्यवसाय प्रक्रिया में एक घोषणा शामिल है

uniqueConstraint = UniqueConstraints.singleton

इसलिए, लॉग में संबंधित कुंजी के लॉक को लेने और जारी करने के बारे में संदेश होते हैं। अन्य व्यावसायिक प्रक्रियाओं के लिए ऐसे कोई संदेश नहीं हैं: UniqueConstraint सेट नहीं है।

लगातार स्थिति के साथ व्यवसाय प्रक्रिया की समस्याएँ

कभी-कभी एक स्थिर अवस्था न केवल मदद करती है, बल्कि वास्तव में विकास में बाधा भी बनती है।
समस्याएँ तब शुरू होती हैं जब आपको व्यवसाय तर्क और / या व्यवसाय प्रक्रिया मॉडल में परिवर्तन करने की आवश्यकता होती है। ऐसा कोई परिवर्तन व्यावसायिक प्रक्रियाओं की पुरानी स्थिति के अनुकूल नहीं पाया गया है। यदि डेटाबेस में कई "लाइव" इंस्टेंसेस हैं, तो असंगत परिवर्तन करने से बहुत परेशानी हो सकती है, जो हमें अक्सर जेबीपीएम का उपयोग करते समय सामना करना पड़ता है।

परिवर्तन की गहराई के आधार पर, आप दो तरह से कार्य कर सकते हैं:

1. एक नया व्यवसाय प्रोसेस प्रकार बनाएँ ताकि पुराने में असंगत परिवर्तन न हों, और नए उदाहरण प्रारंभ करते समय पुराने के बजाय इसका उपयोग करें। पुराने उदाहरण "पुराने तरीके" से काम करना जारी रखेंगे;
2. व्यापार तर्क को अद्यतन करते समय व्यवसाय प्रक्रियाओं की लगातार स्थिति को माइग्रेट करें।

पहला तरीका आसान है, लेकिन इसकी सीमाएं और नुकसान हैं, उदाहरण के लिए:

• कई व्यवसाय प्रक्रिया मॉडल में व्यावसायिक तर्क का दोहराव, व्यावसायिक तर्क की मात्रा में वृद्धि;
• अक्सर एक नए व्यापार तर्क के लिए एक त्वरित परिवर्तन की आवश्यकता होती है (लगभग हमेशा एकीकरण कार्यों के संदर्भ में);
• डेवलपर को यह नहीं पता होता है कि किस बिंदु पर अप्रचलित मॉडलों को हटाना संभव है।

व्यवहार में, हम दोनों दृष्टिकोणों का उपयोग करते हैं, लेकिन हमने अपने जीवन को सरल बनाने के लिए कई निर्णय लिए हैं:

• डेटाबेस में, व्यवसाय प्रक्रिया की लगातार स्थिति को आसानी से पढ़ने योग्य और आसानी से संसाधित रूप में संग्रहीत किया जाता है: JSON प्रारूप स्ट्रिंग में। यह आपको एप्लिकेशन के अंदर और बाहर दोनों जगह माइग्रेशन करने की अनुमति देता है। अत्यधिक मामलों में, आप इसे हैंडल से भी ट्वीक कर सकते हैं (विशेष रूप से डिबगिंग के दौरान विकास में उपयोगी);
• एकीकरण व्यापार तर्क व्यावसायिक प्रक्रियाओं के नामों का उपयोग नहीं करता है, ताकि किसी भी समय भाग लेने वाली प्रक्रियाओं में से किसी एक के कार्यान्वयन को एक नए नाम के साथ बदलना संभव हो (उदाहरण के लिए, "InitialPlayerV2")। बंधन संदेशों और संकेतों के नाम से होता है;
• प्रक्रिया मॉडल में एक संस्करण संख्या होती है, जिसे हम बढ़ाते हैं यदि हम इस मॉडल में असंगत परिवर्तन करते हैं, और यह संख्या प्रक्रिया उदाहरण की स्थिति के साथ संग्रहीत होती है;
• प्रक्रिया की लगातार स्थिति को पहले आधार से एक सुविधाजनक ऑब्जेक्ट मॉडल में पढ़ा जाता है, जिसके साथ माइग्रेशन प्रक्रिया काम कर सकती है यदि मॉडल की संस्करण संख्या बदल गई है;
• माइग्रेशन प्रक्रिया को व्यावसायिक तर्क के बगल में रखा जाता है और डेटाबेस से इसकी बहाली के समय व्यवसाय प्रक्रिया के प्रत्येक उदाहरण के लिए "आलसी" कहा जाता है;
• यदि आपको सभी प्रक्रिया उदाहरणों की स्थिति को जल्दी और समकालिक रूप से माइग्रेट करने की आवश्यकता है, तो अधिक क्लासिक डेटाबेस माइग्रेशन समाधानों का उपयोग किया जाता है, लेकिन आपको वहां JSON के साथ काम करना होगा।

क्या मुझे व्यवसाय प्रक्रियाओं के लिए किसी अन्य ढांचे की आवश्यकता है?

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

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

क्या मुझे व्यवसाय प्रक्रियाओं के लिए किसी अन्य ढांचे की आवश्यकता है?

• 18,8% तक हां, मैं काफी समय से ऐसा कुछ ढूंढ रहा था।

• 12,5% तक आपके कार्यान्वयन के बारे में और जानना दिलचस्प है, यह उपयोगी हो सकता है 2

• 6,2% तक हम मौजूदा ढांचे में से एक का उपयोग करते हैं, लेकिन हम इसे बदलने के बारे में सोच रहे हैं1

• 18,8% तक हम मौजूदा ढांचे में से एक का उपयोग करते हैं, सब कुछ उपयुक्त3

• 18,8% तक ढांचे के बिना मुकाबला करना3

• 25,0% तक अपना खुद का लिखें 4

16 उपयोगकर्ताओं ने मतदान किया। 7 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com