कैसे दलिया को माइक्रोसर्विस से पकाना है

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

और मैं जिम्मेदारियों के विभाजन के विभिन्न पैटर्न और एंटीपैर्टर्न के बारे में बात करना चाहूंगा।

एंटीटर्न के रूप में सेवा इकाई

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

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

उदाहरण के लिए, एक ऑनलाइन स्टोर लें। हमने सेवाओं "उत्पाद", "आदेश", "ग्राहक" को उजागर करने का निर्णय लिया।

होम डिलीवरी को जोड़ने के लिए मुझे क्या परिवर्तन और सेवाएं करनी चाहिए?
उदाहरण के लिए, आप यह कर सकते हैं:

• सेवा में "आदेश" वितरण पता, वांछित समय और वितरण आदमी जोड़ें
• ग्राहक सेवा में ग्राहक के लिए चयनित वितरण पतों की एक सूची जोड़ें
• "उत्पाद" सेवा में माल की एक इकाई सूची जोड़ें

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

या प्रोमोशनल कोड पर छूट जोड़ने के लिए मुझे क्या और किन सेवाओं में बदलाव करने की आवश्यकता है?
कम से कम आपको चाहिए:

• "आदेश" सेवा के लिए एक प्रचारक कोड जोड़ें
• "उत्पाद" सेवा में जोड़ें कि क्या छूट इस उत्पाद के प्रचारक कोड पर लागू होती है
• क्लाइंट सेवा में ग्राहक को जारी किए गए प्रचार कोड की एक सूची जोड़ें

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

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

दूसरे शब्दों में, कई सेवाओं में फैले व्यावसायिक तर्क में बदलाव से कई सेवाओं में निर्भर परिवर्तन होते हैं। और एक ही समय में एक सेवा में एक कोड है जो एक दूसरे से जुड़ा नहीं है।

भंडारण सेवाएँ

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

यदि डेटा अलग-अलग डेटाबेस में, विभिन्न मशीनों पर संग्रहीत किया जाता है, तो हम

• हम प्रदर्शन खो देते हैं क्योंकि हम डेटाबेस से सीधे डेटा नहीं देते हैं, लेकिन सेवा स्तर के माध्यम से
• हम लचीलापन खो देते हैं क्योंकि सेवा एपीआई आमतौर पर SQL या किसी अन्य क्वेरी भाषा की तुलना में बहुत कम लचीली होती है
• हम लचीलेपन में खो जाते हैं, क्योंकि विभिन्न सेवाओं से डेटा मर्ज करना मुश्किल है
  

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

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

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

समस्या क्षेत्रों द्वारा अलगाव

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

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

एक ही समय में कई समस्या क्षेत्रों को प्रभावित करने वाले परिवर्तन उन परिवर्तनों से कम होते हैं जो कई संस्थाओं को प्रभावित करते हैं।

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

उदाहरण के लिए, हम सेवाओं में विभाजित कर सकते हैं:

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

एक दूसरे के साथ बातचीत करने के लिए, सेवाएं ईवेंट मॉडल का उपयोग कर सकती हैं या एक दूसरे के साथ सरल वस्तुओं का आदान-प्रदान कर सकती हैं (बाकी एपी, जीआरपीसी, आदि)। सच है, यह ध्यान देने योग्य है कि ऐसी सेवाओं के बीच बातचीत को सही ढंग से व्यवस्थित करना आसान नहीं है। कम से कम, डेटा विकेन्द्रीकरण में कुछ समय के लिए समस्याएँ होती हैं (कुछ समय के लिए निरंतरता) और लेन-देन (मामले में जब यह महत्वपूर्ण होता है)।

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

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

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

एक आदर्श विभाजन केवल तभी संभव है जब आपके पास दो पूरी तरह से स्वतंत्र उत्पाद हों। किसी भी व्यवसाय में आपके पास सब कुछ सब कुछ के साथ जुड़ा हुआ है, एकमात्र सवाल यह है कि कितना जुड़ा हुआ है।

और सवाल जिम्मेदारियों के पृथक्करण और बाधाओं की ऊंचाई में है।

डिजाइन सेवा एपीआई

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

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

CRUD जटिल व्यावसायिक तर्क वाली सेवाओं के लिए इंटरफेस करता है

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

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

यदि हम इंटरफ़ेस में बदलाव किए बिना, व्यापार तर्क को सेवा में स्थानांतरित करने का प्रयास करते हैं, तो हमें एक बहुत ही सार्वभौमिक और बहुत जटिल विधि मिल जाएगी।

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

API को इस तरह से देखें: POST / PATCH / GET के तरीके, url /api/v1/ticket//telling/idasket.json

तो, आप टिकट को अपडेट कर सकते हैं

PATCH /api/v1/tickets/{ticket_id}.json { "type": "bug", "status": "closed", "description": "   " } 

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

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

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

इसलिए, ऐसी समस्याओं से बचने के लिए, सार्वभौमिक डेटा-केंद्रित लोगों के बजाय इंटरफेस को छोटा, विशिष्ट और यथासंभव समस्या-उन्मुख बनाना बेहतर है।

यह (विरोधी) पैटर्न अधिक बार Restful इंटरफेस की विशेषता है, इस तथ्य के कारण कि डिफ़ॉल्ट रूप से कार्यों को बनाने, हटाने, अद्यतन करने, पढ़ने के लिए केवल कुछ डेटा-केंद्रित "क्रियाएं" हैं। कोई व्यवसाय-विशिष्ट इकाई संचालन नहीं

Restful को अधिक समस्या-उन्मुख बनाने के लिए क्या किया जा सकता है?
सबसे पहले, आप संस्थाओं में विधियाँ जोड़ सकते हैं। इंटरफ़ेस कम बेचैन हो रहा है। लेकिन ऐसा मौका है। हम अभी भी दौड़ की शुद्धता के लिए नहीं लड़ते हैं, लेकिन व्यावहारिक समस्याओं को हल करते हैं

सार्वभौमिक संसाधन के बजाय /api/v1/tickets.json अधिक संसाधन जोड़ें:

/api/v1/tickets/{ticket_id}/migrate.json - एक प्रकार से दूसरे में प्रवास करें
/api/v1/tickets/{ticket_id}/status.json - यदि कोई स्थिति मॉडल है

दूसरे, आप REST के ढांचे के भीतर संसाधन के रूप में किसी भी ऑपरेशन की कल्पना कर सकते हैं। क्या एक प्रकार से दूसरे (या एक परियोजना से दूसरी परियोजना?) के लिए टिकट प्रवासन संचालन है। ठीक है, इसलिए एक संसाधन होगा
/api/v1/tickets/migration.json

क्या ट्रायल सब्सक्रिप्शन बनाने के लिए कोई बिजनेस ऑपरेशन है?
/api/v1/subscriptions/trial.json

क्या मनी ट्रांसफर ऑपरेशन है?
/api/v1/money_transfers.json

आदि

डेटा-केंद्रित API के साथ एंटीपार्टर्न वास्तव में rpc इंटरैक्शन को संदर्भित करता है। उदाहरण के लिए, editAccount (), या editTicket () जैसे बहुत सामान्य तरीकों की उपस्थिति। "किसी ऑब्जेक्ट को संशोधित करें" समस्या क्षेत्र से जुड़े सिमेंटिक लोड को पूरा नहीं करता है। इसका मतलब है कि इस विधि को विभिन्न कारणों से, विभिन्न कारणों से बदलने के लिए कहा जाएगा।

यह ध्यान दिया जाना चाहिए कि डेटा-केंद्रित इंटरफेस काफी ठीक हैं, यदि समस्या क्षेत्र में डेटा को केवल संग्रहीत करना, प्राप्त करना और संशोधित करना शामिल है।

इवेंट मॉडल

कोड को अनटाइट करने का एक तरीका संदेश कतार के माध्यम से सेवाओं के बीच सहभागिता को व्यवस्थित करना है।

उदाहरण के लिए, यदि सेवा में, किसी उपयोगकर्ता का पंजीकरण करते समय, हमें उसे एक स्वागत पत्र भेजने की आवश्यकता होती है, तो क्लाइंट मैनेजर आदि के लिए CRM में एक अनुरोध बनाएं, फिर यह बाहरी सेवा कॉल करने के लिए नहीं, बल्कि "उपयोगकर्ता 123 पंजीकृत है" संदेश को पंजीकरण सेवा में रखना तर्कसंगत है। ”, और सभी आवश्यक सेवाएं इस संदेश को पढ़ेगी और आवश्यक कार्यवाही करेंगी। इसी समय, व्यापार तर्क को बदलने के लिए पंजीकरण सेवा को बदलने की आवश्यकता नहीं होगी।

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

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

माइक्रोसर्विस और प्रदर्शन। CQRS

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

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

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

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

जाहिर है, सेवाओं को पढ़ने और संशोधित करने में एक अनुभवहीन विभाजन हमेशा अच्छा नहीं हो सकता है।

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