अनेक वर्षांपासून, बॅकएंड संघांना ॲपची रचना कशी करावी हे ठरवावे लागले आहे. एक मोनोलिथ अनुप्रयोगाचे मुख्य भाग एकाच ठिकाणी ठेवतो. हे एक युनिट म्हणून पाठवले जाते.
हे सहसा सुरुवातीला सोपे वाटते, विशेषत: जेव्हा ॲप लहान असते किंवा एक टीम त्याच्या मालकीची असते. पण जसजसे ॲप वाढत जाईल तसतसे मर्यादा दिसून येतात. एक क्षेत्र अद्यतनित करणे म्हणजे संपूर्ण अनुप्रयोग पुनर्बांधणी करणे आणि सोडणे. तरीही, मायक्रोसर्व्हिसेस स्वयंचलितपणे सर्वोत्तम पर्याय नाहीत. ही हालचाल नवीन समस्यांसह येते, त्यामुळे मायक्रोसर्व्हिसेसला डीफॉल्ट उत्तर मानण्यापूर्वी तुम्हाला बदल का हवा आहे याचे तुम्ही मूल्यांकन केले पाहिजे.
सिस्टम ब्रेकिंग का काम करू शकते
लोक मायक्रो सर्व्हिसेसकडे जाण्याचे एक मोठे कारण म्हणजे स्केलिंग अधिक लक्ष्यित केले जाऊ शकते. वास्तविक ॲप्समध्ये, भाग सहसा समान लोड सामायिक करत नाहीत. ऑनलाइन स्टोअर घ्या. शोध पृष्ठे आणि चेकआउट फ्लोला बऱ्याचदा जास्त रहदारी मिळते, तर प्रशासक साधने दीर्घकाळापर्यंत शांत राहू शकतात.
एका मोठ्या मोनोलिथसह, जर तुम्ही एक भाग मोजलात, तर तुम्ही बहुतेक वेळा सर्व काही मोजता. तुम्ही सेवांमध्ये कामाचे विभाजन करता तेव्हा, संघ प्रत्येक भागाला आवश्यक असलेल्या गणने आणि इतर संसाधनांशी जुळवू शकतात. मायक्रोसर्व्हिसेस रिलीझ वेळेत देखील मदत करतात. संघ संबंधित नसलेल्या इतर भागांना स्पर्श न करता त्याच्या सेवेवर अपडेट पाठवू शकतो. मोठ्या अभियांत्रिकी गटांसाठी हे सर्वात महत्त्वाचे आहे. जेव्हा अनेक संघ गुंतलेले असतात, तेव्हा ते क्वचितच एकाच वेगाने पुढे जातात.
सामायिक मालकी आणि जबाबदारी
तुम्ही सिस्टीम कशी डिझाईन करता आणि तुम्ही संघ कसे चालवता ते लिंक केलेले आहेत. जेव्हा बरेच संघ समान कोडवर अवलंबून असतात तेव्हा एक मोठा मोनोलिथ गोंधळू शकतो. जर त्याच भांडारात सर्व काही असेल, तर लोकांनी फक्त एक छोटासा बदल करण्यासाठी त्यांच्या मालकीचा नसलेला कोड शोधला पाहिजे.
सर्वात वाईट म्हणजे, एका संपादनामुळे तुम्हाला अपेक्षित नसलेल्या भागांमध्ये दुष्परिणाम होऊ शकतात. मायक्रोसर्व्हिसेस मालकी पाहणे सोपे करू शकतात. एक संघ प्रमाणीकरणावर लक्ष केंद्रित करू शकतो. दुसरी टीम पेमेंटवर लक्ष केंद्रित करू शकते. दुसरी सूचना चालवू शकते. मुद्दा फक्त अधिक कोडबेसचा नाही. कोण जबाबदार आहे आणि सेवा कशा उपयोजित आणि राखल्या जातात यासाठी स्पष्ट मर्यादा निश्चित करणे हे मुख्य उद्दिष्ट आहे. तरीही, त्या मर्यादा उत्पादनाच्या वास्तविक संरचनेत आणि त्याच्या सिस्टममध्ये बसल्या पाहिजेत.
मायक्रोसर्व्हिसेस एक वितरित प्रणाली तयार करतात
मायक्रोसर्व्हिसेस तुम्हाला वितरित प्रणाली तयार करण्यात मदत करू शकतात, परंतु ते चुकीचे समजणे सोपे आहे. मायक्रोसर्व्हिसेस या मोनोलिथच्या फक्त लहान आवृत्त्या असल्यासारखे कार्य करणे ही एक सामान्य त्रुटी आहे. जेव्हा तुम्ही वैशिष्ट्ये विभाजित करता, तेव्हा काही कार्य जे एका प्रोग्राममध्ये व्हायचे ते आता नेटवर्कवर होऊ शकतात. त्या सेटअपमध्ये, एक विनंती पूर्ण होण्यापूर्वी एकाधिक सेवांमधून जाऊ शकते.
नेटवर्क समस्या नंतर सामान्य ऑपरेशनवर परिणाम करतात. तुम्हाला उशीर, अयशस्वी कॉल, पुन्हा प्रयत्न आणि सेवा बंद असताना वेळा हाताळावे लागतील. त्या वर, संघांना अधिक चांगली दृश्यमानता आवश्यक आहे. अनेक सेवांमधील लॉग जोडलेले असणे आवश्यक आहे जेणेकरून अभियंता एकाच विनंतीचे अनुसरण करू शकेल. मेट्रिक्स आणि ट्रेसिंग देखील महत्त्वाचे आहे, कारण ते संपूर्ण मार्गावर काय घडले ते दर्शवतात.
डेटा हाताळणे देखील कठीण होते
डेटाबेस डिझाइन हा एक कळीचा विषय बनतो. एका मोनोलिथमध्ये, ॲपचे अनेक भाग सहसा थोडासा घर्षण करून समान डेटाबेस वाचू आणि लिहू शकतात. मायक्रोसर्व्हिसेसमध्ये, मालकी हा एक मोठा निर्णय आहे. प्रत्येक डेटा सेटची मालकी कोणत्या सेवेकडे आहे हे तुम्हाला ठरवावे लागेल.
जेव्हा कृती एकापेक्षा जास्त सेवांचा विस्तार करतात, तेव्हा एक प्रक्रियेतील व्यवहाराची जुनी कल्पना यापुढे बसू शकत नाही. सातत्यपूर्ण परिणाम मिळविण्यासाठी अतिरिक्त नमुने आणि अतिरिक्त समन्वय लागू शकतो. याचा अर्थ असा नाही की प्रत्येक सेवेने प्रत्येक बाबतीत स्वतःचा डेटाबेस चालवला पाहिजे. स्पष्ट मालकी आणि दोन सेवा डेटा सामायिक करतात तेव्हा काय होते याचे ठोस आकलन महत्त्वाचे आहे.
मायक्रोसर्व्हिसेस रिलीझ कठिण बनवू शकतात
मायक्रोसर्व्हिसेसचा एक मोठा ड्रॉ म्हणजे संघ स्वतःच तैनात करू शकतात. पकड अशी आहे की अधिक स्वायत्तता म्हणजे जहाजासाठी अधिक भाग. मोनोलिथमध्ये सहसा रिलीज करण्यासाठी एक मुख्य ॲप असतो. मायक्रो सर्व्हिसेससह, अनेक सेवा असू शकतात.
गोष्टी स्थिर ठेवण्यासाठी अधिक टूलिंग जोडण्याकडे संघांचा कल असतो. त्यामध्ये CI किंवा CD रन, कंटेनर, सेवांसाठी नाव शोधणे, क्रेडेन्शियल्स संचयित करण्याचे मार्ग, चेक आणि अलर्ट आणि काही प्रकारचे प्रकाशन समन्वय यांचा समावेश असू शकतो. तो आधार तयार नसल्यास, जोडलेल्या सेवा अतिरिक्त ओझे वाटू शकतात.
प्रत्येक मोनोलिथ विभाजित करू नये
मोनोलिथ नेहमीच खराब अभियांत्रिकीचे लक्षण नसते. लहान संघासह लहान उत्पादनासाठी, स्वच्छ मोनोलिथ तयार करणे, सत्यापित करणे आणि चालवणे सोपे असू शकते. सध्याच्या सेटअपमुळे खरोखर समस्या येत आहेत का हे विचारण्याचा मुख्य मुद्दा आहे. स्पष्ट मुद्दे पहा.
उदाहरणांमध्ये धीमे रिलीझ, स्केलिंग करताना मर्यादा, भागांची अस्पष्ट जबाबदारी किंवा तुम्ही एखादे क्षेत्र बदलण्याचा प्रयत्न करता तेव्हा घर्षण यांचा समावेश होतो. यापैकी काहीही होत नसल्यास, मायक्रोसर्व्हिसेसकडे जाणे केवळ फॅशनमध्ये आहे म्हणून मदत करण्याची शक्यता नाही.
अंतिम विचार
एकल मोनोलिथवरून मायक्रोसर्व्हिसेसवर स्विच करणे हे नवीन आहे म्हणून तुम्ही करता असे नाही. ही सहसा आपल्या संघाला तोंड देत असलेल्या वास्तविक समस्यांवरील प्रतिक्रिया असते. उदाहरणार्थ, बॅकएंड गटांना सिस्टमचे भाग स्वतःच मोजायचे असतील.
एका मोठ्या रिलीझची वाट न पाहता होऊ शकणाऱ्या तैनाती देखील त्यांना हव्या असतील. काही संस्थांमध्ये, स्पष्ट मालकी देखील महत्त्वाची असते, विशेषत: संघ मोठा होत असताना. मायक्रोसर्व्हिसेस तुम्हाला मोठ्या प्लॅटफॉर्मला व्यवसाय क्षेत्राशी जुळणाऱ्या तुकड्यांमध्ये विभाजित करण्यात मदत करू शकतात.
ते म्हणाले, प्रत्येक नवीन सेवा अतिरिक्त काम जोडते. तुम्ही अधिक युनिट्स तैनात कराल, अधिक लॉग पाहाल आणि अधिक सुरक्षा कार्ये हाताळाल. आपल्याला वेळेनुसार अधिक गोष्टी चालू ठेवण्याची देखील आवश्यकता आहे. एकदा सेवा नेटवर्कवर बोलल्या की, तुम्ही एका ॲपमध्ये न पाहिलेले अपयश मोड तुम्हाला वारशाने मिळतात. सामायिक स्थिती देखील कठीण होते, कारण डेटा सर्व सिस्टममध्ये विभाजित केला जातो. वितरित डेटा स्वतःच्या डोकेदुखीचा संच आणतो.
(स्त्रोत)
Comments are closed.