👨🏾‍🏭 🗳️ 🤴🏻 Microservice फ्रंटेंड - सामने के अलगाव के लिए एक आधुनिक दृष्टिकोण 🧙🏿 👩‍👩‍👦‍👦 🥖

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

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

आज मैं आपको बताऊंगा कि हमने अपने सास समाधान में माइक्रोसर्विस कैसे किया और हमें किन समस्याओं का सामना करना पड़ा।

समस्याओं

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

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

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

काटने का दृश्य

आलोचनात्मक द्रव्यमान के संचय का एक क्षण आया, और उन्होंने सामने के छोर को ... सामने के अंत के सर्वर्स में विभाजित करने का निर्णय लिया। चलो परिभाषित करते हैं कि फ्रंट-एंड माइक्रोसेवक क्या है:

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

लेकिन हम और आगे बढ़े और विभाजन का एक और स्तर पेश किया।

खंडन की अवधारणा

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

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

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

ऐसे मामलों में जहां टुकड़े को एक ही पृष्ठ पर अन्य लोगों के साथ "कॉहबिट" करने का अवसर नहीं होता है, एक फॉलबैक स्क्रिप्ट होती है जिसमें हम एक iframe में टुकड़ा खींचते हैं (संबंधित समस्याओं का समाधान इस लेख के दायरे से परे है)।

एक डेवलपर जो एक पृष्ठ पर मौजूदा स्निपेट का उपयोग करना चाहता है, वह यह है:

पृष्ठ पर माइक्रोसेफ़ प्लेटफ़ॉर्म स्क्रिप्ट कनेक्ट करें।
```
 <script src="//{URL to static cache service}/api/v1/mui-platform/muiPlatform.js"></script> 
```

पृष्ठ पर एक खंड जोड़ने की विधि को कॉल करें।

 window.MUI.createFragment( // fragment name "hello-label", // fragment model { text: "HelloLabelFragment text from run time" }, // fragment position { selector: ".hello-label-placeholder", position: "afterend" }) .then(callback);

इसके अलावा, टुकड़ों के बीच संचार के लिए, Observable और rxjs पर निर्मित एक बस है। यह NativeJS पर लिखा गया है। इसके अलावा, एसडीके विभिन्न चौखटों के लिए रैपर के साथ आता है जो इस बस को मूल रूप से उपयोग करने में मदद करते हैं। कोणीय 6 के लिए एक उदाहरण एक उपयोगिता विधि है जो rxjs/Observable :

 import {fromEvent} from "@netcracker/mui-platform/angular2-factory/modules/shared/utils/event-utils" fromEvent("<event-name>"); fromEvent(EventClassType);

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

सामने वाले को मिलाना

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

हम एक टुकड़े के विचार को विकसित करते हैं

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

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

अक्सर ऐसा होता है कि एक पृष्ठ पर कई टुकड़े होते हैं जो पृष्ठ पर कुछ सामान्य डेटा को बदलते समय अपने राज्य को बदलना चाहिए। ऐसा करने के लिए, उनके पास एक वैश्विक (NativeJS) इवेंट बस है जिसके माध्यम से वे संचार कर सकते हैं और परिवर्तनों का जवाब दे सकते हैं।

साझा सेवाएँ

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

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

इसके अलावा, रैपर को विभिन्न सेवाओं के लिए हमारी सेवाओं पर विकसित किया गया था ताकि उनका उपयोग बहुत ही स्वाभाविक (DI, निश्चित इंटरफ़ेस) किया जा सके।

फ्रंट-एंड माइक्रोसर्विस के पेशेवरों

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

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

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

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

फ्रंट-एंड माइक्रोसर्विस की विपक्ष

आप मरहम में एक मक्खी के बिना कभी नहीं कर सकते।

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

निष्कर्ष

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

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

Microservice फ्रंटेंड - सामने के अलगाव के लिए एक आधुनिक दृष्टिकोण