😃 💋 🦂 माइक्रोसर्विसेस या मॉड्यूलर सिस्टम? ग्राहक किसी उत्पाद के आईटी आर्किटेक्चर के लिए एक दृष्टिकोण कैसे चुन सकता है 🥙 ⛱️ 🍦

माइक्रोसैस सर्विस और मॉड्यूलर सिस्टम आईटी सॉल्यूशन आर्किटेक्चर के प्रकार हैं।

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

बॉक्सिंग संस्करण से हमारा मतलब एक मोनोलिथ है, एक कोर के साथ एक तैयार-निर्मित प्रणाली जो सभी ग्राहकों को उसी तरह वितरित की जाती है, "जैसा है"।

लापता कार्यक्षमता के साथ मॉड्यूल बनाने में शोधन शामिल हैं।

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

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

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

मॉड्यूलर वास्तुकला के लाभ

सभी CMS सिस्टम (Bitrix, Magento, Drupal, Hybris, इत्यादि), CRM, ERP, WMS, और कई अन्य बॉक्सिंग संस्करण हैं। वे अच्छी तरह से बेचते हैं और उच्च मांग में हैं।
आइए उन उद्देश्य कारणों को देखें कि ग्राहक अक्सर एक मॉड्यूलर वास्तुकला और स्वेच्छा से बॉक्सिंग समाधानों के साथ काम करना क्यों चुनते हैं।

कार्यान्वयन की उच्च गति

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

छोटे व्यवसायों के लिए, यह अवधि केवल कुछ दिन हो सकती है।
. , enterprise- .
. . , , , .
,

. , .

अन्य व्यक्तिपरक कारक हैं जो बक्से और मॉड्यूल का उपयोग करने के निर्णय को भ्रामक और प्रभावित कर सकते हैं।

1. निर्माताओं

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

2. सुधार की जटिलता के बारे में गलत धारणा।

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

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

यदि आपकी कंपनी एक छोटा व्यवसाय है और सॉफ्टवेयर आपकी मुख्य संपत्ति नहीं है, तो सबसे अधिक संभावना है, एक लोकप्रिय बॉक्सिंग (या बेहतर - एक क्लाउड) समाधान आपको सूट करेगा।

आइए देखें कि एक मॉड्यूलर वास्तुकला के साथ काम करते समय आपको किन समस्याओं का सामना करना पड़ सकता है और इससे बचने के लिए माइक्रोसर्विस कैसे मदद करते हैं।

मॉड्यूलर सिस्टम की समस्याएं

मुख्य समस्या यह है कि सभी मॉड्यूलर सिस्टम को गंभीरता से परिभाषित करने के लिए डिज़ाइन नहीं किया गया है। उनके पास एक बॉक्स, तैयार-निर्मित मॉड्यूल हैं - जो उनका उपयोग करना बेहतर है।

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

समस्या नंबर 1. सिस्टम का मूल एक मंदी बिंदु बन जाता है, और मॉड्यूलरिटी एक अनावश्यक जटिलता बन जाती है।

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

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

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

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

समस्या नंबर 2. स्व-प्रलेखन का सिद्धांत मॉड्यूलर सिस्टम में समर्थित नहीं है।

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

एक नियम के रूप में, इस तरह के काम करने के लिए कोई नहीं है: इस पर मूल्यवान आईटी-विशेषज्ञों का समय बिताने का मतलब केवल बजट को खत्म करना है। यहां तक कि कोड (PHPDoc) में प्रलेखन भंडारण का उपयोग इसकी विश्वसनीयता की गारंटी नहीं देता है। अंत में, यदि प्रलेखन कार्यान्वयन से भिन्न हो सकता है, तो यह आवश्यक रूप से अलग होगा।

समस्या नंबर 3. कोड का अधिक सुसंगतता - प्रतिगमन का मार्ग: "उन्होंने इसे यहां बदल दिया, यह बंद हो गया"

मॉड्यूलर सिस्टम की क्लासिक समस्याएं प्रतिगमन के खिलाफ लड़ाई में हैं।

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

कार्यात्मक परीक्षण उतने ही बड़े हो जाते हैं, जितने कि अर्थहीन। वे समानांतर में भी, घंटों तक चलते हैं।

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

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

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

आपको यह स्वीकार करना चाहिए कि प्रतिगमन के साथ ऐसी स्थिति "स्थिर उद्यम" की तरह नहीं है क्योंकि यह ग्राहक के सपने और सपने में होना चाहिए।

अंक # 4: कोड कनेक्टिविटी और प्लेटफ़ॉर्म अपडेट

कोड कनेक्टिविटी के साथ एक और समस्या प्लेटफॉर्म को अपडेट करने में कठिनाई है।

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

यहाँ Magento के लिए एक जीवंत उदाहरण है।
2018 के अंत में, Magento 2.3 मंच का एक नया संस्करण जारी किया गया था। ओपन सोर्स संस्करण में मल्टीस्टोर्स और इलास्टिक्स को जोड़ा गया है। इसके अलावा, कर्नेल में हजारों बग तय किए गए थे और ओएमएस में कुछ अच्छाइयों को जोड़ा गया था।

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

अब कल्पना करें: इस तरह के एक अपडेट पर कितना समय व्यतीत किया जाएगा और एकीकरण परीक्षणों के बिना यह कैसे परीक्षण किया जा सकता है, जो लिखना मुश्किल है?

यह आश्चर्य की बात नहीं है कि कई लोगों के लिए, प्लेटफ़ॉर्म अपग्रेड बिना रिफैक्टरिंग के होता है, लेकिन दोहराव में वृद्धि के साथ, या (यदि टीम फेंग शुई द्वारा सब कुछ करना चाहती है) तो रिफैक्टरिंग और ऑर्डर को बहाल करने के लिए लंबे समय तक "छोड़" देती है।

समस्या संख्या 5. व्यावसायिक प्रक्रियाओं की अस्पष्टता

परियोजना प्रबंधन में सबसे महत्वपूर्ण समस्याओं में से एक यह है कि ग्राहक परियोजना के सभी तर्क और सभी व्यावसायिक प्रक्रियाओं को नहीं देखता है। उन्हें केवल कोड से या प्रलेखन से बहाल किया जा सकता है (जिसकी प्रासंगिकता, जैसा कि हमने पहले कहा था, न्यूनाधिक प्रणालियों में बनाए रखने के लिए समस्याग्रस्त है)।

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

समस्या 6. सिस्टम स्केलिंग की जटिलता

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

अधिक मेमोरी और प्रोसेसर चाहिए, जो क्लस्टर की लागत को बहुत बढ़ाता है।

माईक्रोसर्विस ग्राहकों को मॉड्यूलर विकास की विशिष्ट खामियों से कैसे बचाते हैं। कैमुंडा और जेबीपीएम में माइक्रोसिस्ट ऑर्केस्ट्रेशन

Spoiler: पिछले पैराग्राफ में सूचीबद्ध समस्याओं का समाधान BPMS और ऑर्केस्ट्रेटिंग microservice सिस्टम का उपयोग करके संभव है।

BPMS (अंग्रेजी व्यवसाय प्रक्रिया प्रबंधन प्रणाली) एक कंपनी में व्यावसायिक प्रक्रियाओं के प्रबंधन के लिए सॉफ्टवेयर है। लोकप्रिय बीपीएमएस जो हम काम करते हैं, वे हैं कैमुंडा और जेबीपीएम।

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

एक उदाहरण के रूप में, हम अक्सर सामना की जाने वाली प्रक्रिया लेते हैं - वितरण के लिए एक आदेश भेजते हैं।

किसी भी संदेश या प्रत्यक्ष कॉल के द्वारा, हम वितरण विधि चुनने की प्रक्रिया के साथ ऑर्डर प्रोसेसिंग शुरू करते हैं। चयन तर्क सेट है।

परिणामस्वरूप, प्रक्रियाएं, सेवाएं और विकास:

जल्दी से पठनीय बन जाओ;
स्व-दस्तावेजीकरण (वे ठीक वैसे ही काम करते हैं जैसे वे खींचे जाते हैं, और प्रलेखन और कोड के वास्तविक कार्य के बीच कोई रस्सिनक्रिन नहीं है);
बस डिबग किया गया (यह देखना आसान है कि यह या यह प्रक्रिया कैसे जाती है और यह समझती है कि त्रुटि क्या है)।

हम उन सिद्धांतों से परिचित होंगे जिनके द्वारा व्यवसाय प्रक्रिया प्रबंधन प्रणाली काम करती है।

BPMS सिद्धांत संख्या 1. विकास दृश्य और प्रक्रिया बन जाता है

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

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

सभी माइक्रोसर्विसेज प्रोसेस क्यूब्स बन जाते हैं जिन्हें स्नैप से व्यावसायिक उपयोगकर्ता में जोड़ा जा सकता है। व्यवसाय प्रक्रिया का प्रबंधन करता है, और डेवलपर एक विशेष माइक्रोसैस सर्विस की उपलब्धता और सही संचालन के लिए जिम्मेदार है। इसके अलावा, सभी पक्ष प्रक्रिया के सामान्य तर्क और उद्देश्य को समझते हैं।

BPMS सिद्धांत नंबर 2. प्रत्येक सेवा में स्पष्ट इनपुट और आउटपुट हैं।

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

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

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

BPMS सिद्धांत संख्या 3. कतार प्रसंस्करण की संगामिति

प्रोसेसिंग ऑर्डर की प्रक्रिया की कल्पना करें: हमें कुछ मार्केट प्लेस पर जाने की जरूरत है, सभी अच्छे ऑर्डर उठाएं और उन्हें प्रोसेस करना शुरू करें।

आरेख (आरेख का हिस्सा) को देखें। यहां यह निर्धारित किया जाता है कि प्रत्येक 10 मिनट में हम बाज़ार के सभी आदेशों की जांच करते हैं, फिर समानांतर में चलते हैं (जैसा कि प्रक्रिया क्रम में ऊर्ध्वाधर "हैमबर्गर" द्वारा दर्शाया गया है) प्रत्येक आदेश का प्रसंस्करण। सफल होने पर, सभी डेटा को ईआरपी में स्थानांतरित करें और प्रसंस्करण को पूरा करें।

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

BPMS सिद्धांत नंबर 4। त्रुटि और वृद्धि

कल्पना कीजिए कि वितरण प्रक्रिया के दौरान एक त्रुटि हुई। उदाहरण के लिए (वैसे, यह एक वास्तविक मामला है), परिवहन कंपनी ने आदेश लिया, और फिर गोदाम जल गया। एक और वास्तविक कहानी: नए साल की पूर्व संध्या पर, पहले उत्पाद में देरी हुई थी, और फिर, शायद, यह खो गया था।

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

ऐसे सभी अपवाद न केवल बीपीएमएस (उदाहरण के लिए, एक टाइमर में एक टाइमर) के बाहर कार्यक्रम के लिए कठिन हैं, बल्कि पूरी प्रक्रिया के संदर्भ में भी समझा जा सकता है।

BPMS सिद्धांत संख्या 5। घटनाओं और इंटरप्रोसेस विकल्पों में से एक के लिए कार्यों का विकल्प

डिलीवरी में समान ऑर्डर जमा करें।

कुल मिलाकर, हमारे पास तीन परिदृश्य हैं:

माल उम्मीद के अनुसार दिया गया था;
माल उम्मीद के मुताबिक नहीं दिया गया था;
आइटम खो गया है।

सीधे BPMS में, हम परिवहन कंपनी को माल के लदान की प्रक्रिया निर्धारित कर सकते हैं और आदेश द्वारा घटनाओं में से एक की उम्मीद कर सकते हैं:

सफल डिलीवरी (उत्पाद वितरण प्रक्रिया से संदेश जो सब कुछ दिया गया था);
या कुछ समय की शुरुआत।

यदि समय समाप्त नहीं हुआ है, तो आपको एक और सेवा शुरू करने की आवश्यकता है: ऑपरेटर के साथ इस विशिष्ट आदेश को पार्स करना (क्लाइंट के आगे की अधिसूचना के साथ यह पता लगाने के लिए कि ओएमएस / सीआरएम प्रणाली में इसके लिए कोई कार्य निर्धारित करने की आवश्यकता है।

लेकिन अगर जांच के दौरान आदेश को फिर भी वितरित किया गया था, तो आपको जांच को बाधित करने और आदेश को पूरा करने की आवश्यकता है।

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

BPMS सिद्धांत संख्या 6। अपने कैमकुंडा में आप सभी लॉग देखेंगे

घटनाओं और इंटरप्रोसेस विकल्प का उपयोग करते हुए, आप:

आप एक विंडो में घटनाओं के पूरे अनुक्रम को देखते हैं (ऑर्डर के साथ क्या हो रहा है, यह किस अपवाद से गुजरता है, आदि - यह देखना आसान है);
आप अकेले बीपीएमएस लॉग के आधार पर बीआई के लिए सभी विश्लेषिकी एकत्र कर सकते हैं (लॉगिंग घटनाओं के साथ माइक्रोसर्विस को ओवरलोड करने की आवश्यकता के बिना)।

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

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

निष्कर्ष: माइक्रोसैस सर्विस और मॉड्यूलर आर्किटेक्चर की तुलना

प्रत्येक प्रकार की वास्तुकला के अपने फायदे और नुकसान हैं। कोई सार्वभौमिक समाधान नहीं है।

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

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

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

परियोजना की शुरुआत में:

microservices के साथ - आपके पास शून्य कार्यक्षमता है, और आपको काम करने के लिए यह सब लिखना होगा;
एक मॉड्यूलर प्रणाली के साथ - बॉक्सिंग संस्करण से बड़ी मात्रा में कार्यक्षमता आपके लिए तुरंत उपलब्ध है, और आप खरीद के तुरंत बाद उत्पाद का उपयोग शुरू कर सकते हैं।

विकास के पहले 3-4 महीनों के बाद (यह पहली एमवीपी के लिए औसत रिलीज की तारीख है) और उससे आगे:

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

निष्कर्ष में, आइए देखें कि विशिष्ट उदाहरणों के साथ माइक्रोसिस्टर्स की ऑर्केस्ट्रेशन कैसे दिखती है।

सेवाओं ऑर्केस्ट्रेशन दृश्य उदाहरण

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

व्यवसाय प्रक्रियाएं इस तरह दिखती हैं:

उदाहरण (आदेश, उपलब्धता सेवा):

यह देखा जा सकता है कि इस क्रम में एक शाखा "कोई सामान नहीं" थी।

आदेश की एक और प्रति (विधानसभा में):

आदेश आगे चला गया और, निर्णय तालिका (DMN) के अनुसार, एक निश्चित डिलीवरी सर्विस ऑपरेटर (बॉक्सबेरी) द्वारा प्रसंस्करण शाखा में गया:

नेस्टेड प्रक्रिया की देखभाल:

नेस्टेड प्रक्रिया ने काम किया:

व्यापार प्रक्रियाओं का इतिहास:

इस दृश्य के गुण:

व्यावसायिक प्रक्रियाएँ एक अप्रस्तुत उपयोगकर्ता द्वारा पढ़ना आसान है;
वे निष्पादन योग्य हैं, अर्थात, वे ठीक वैसे ही काम करते हैं जैसे वे खींचे जाते हैं, "प्रलेखन" और कोड के वास्तविक कार्य के बीच कोई रस्सिनक्रिंस्टम नहीं है;
प्रक्रियाएं पारदर्शी हैं: यह देखना आसान है कि एक विशेष आयात, ऑर्डर, प्रसंस्करण कैसे हुआ, यह देखना आसान है कि गलती कहां की गई थी।

याद रखें कि हम kt.team में मॉड्यूलर और माइक्रोसर्विस दोनों के विकास का उपयोग करते हैं, प्रत्येक उत्पाद के लिए व्यक्तिगत रूप से सही विकल्प चुनते हैं। लेकिन अगर चुनाव पहले से ही माइक्रोसॉर्स्क आर्किटेक्चर के पक्ष में किया गया है, तो हम दृढ़ता से आश्वस्त हैं कि बीपीएम सिस्टम जैसे कैमुंडा या जेबीपीएम के बिना ऐसा करना असंभव है।

यह भी देखें: इस विषय पर वीडियो "माइक्रोसिस्टवर्क या अखंड वास्तुकला: क्या चुनना है?"

माइक्रोसर्विसेस या मॉड्यूलर सिस्टम? ग्राहक किसी उत्पाद के आईटी आर्किटेक्चर के लिए एक दृष्टिकोण कैसे चुन सकता है