मोनोलिथपासून मायक्रोसर्व्हिसेसमध्ये संक्रमणः इतिहास आणि सराव

या लेखात, मी ज्या प्रकल्पावर काम करत आहे ते एका मोठ्या मोनोलिथमधून मायक्रोसर्व्हिसेसच्या संचामध्ये कसे बदलले याबद्दल मी बोलणार आहे.

2000 च्या सुरुवातीला या प्रकल्पाचा इतिहास खूप पूर्वीपासून सुरू झाला. पहिल्या आवृत्त्या व्हिज्युअल बेसिक 6 मध्ये लिहिल्या गेल्या. कालांतराने, हे स्पष्ट झाले की भविष्यात या भाषेच्या विकासास समर्थन देणे कठीण होईल, कारण IDE आणि भाषा स्वतःच खराब विकसित झाली आहे. 2000 च्या शेवटी, अधिक आशादायक C# वर स्विच करण्याचा निर्णय घेण्यात आला. नवीन आवृत्ती जुन्या आवृत्तीच्या समांतर लिहिली गेली, हळूहळू अधिकाधिक कोड .NET मध्ये लिहिले गेले. C# मधील बॅकएंड सुरुवातीला सर्व्हिस आर्किटेक्चरवर केंद्रित होते, परंतु विकासादरम्यान, लॉजिकसह सामान्य लायब्ररी वापरल्या गेल्या आणि सेवा एकाच प्रक्रियेत सुरू केल्या गेल्या. त्याचा परिणाम असा अर्ज होता ज्याला आम्ही "सेवा मोनोलिथ" म्हणतो.

या संयोजनाच्या काही फायद्यांपैकी एक म्हणजे बाह्य API द्वारे एकमेकांना कॉल करण्याची सेवांची क्षमता. अधिक योग्य सेवा आणि भविष्यात, मायक्रोसर्व्हिस आर्किटेक्चरमध्ये संक्रमणासाठी स्पष्ट पूर्व शर्ती होत्या.

आम्ही 2015 च्या सुमारास विघटन करण्याचे आमचे काम सुरू केले. आम्ही अद्याप एका आदर्श स्थितीत पोहोचलो नाही - अजूनही मोठ्या प्रकल्पाचे काही भाग आहेत ज्यांना क्वचितच मोनोलिथ म्हटले जाऊ शकते, परंतु ते मायक्रोसर्व्हिसेससारखे दिसत नाहीत. तथापि, प्रगती लक्षणीय आहे.
मी लेखात याबद्दल बोलेन.

सामग्री

• आर्किटेक्चर आणि विद्यमान समाधानाच्या समस्या
• मायक्रो सर्व्हिसेसकडून अपेक्षा
• संक्रमण समस्या
• मोनोलिथपासून मायक्रोसर्व्हिसेसमध्ये कसे जायचे
  • प्रथम मार्ग
  • दुसरा मार्ग
  • तिसरा मार्ग
  • चौथा मार्ग
• डेटाबेससह कार्य करणे
  • विद्यमान सारण्यांचे विभाजन करणे
  • प्रक्रिया विभाग
• स्त्रोत कोडसह कार्य करणे
• पायाभूत सुविधांच्या समस्या
  • वातावरणात मॅन्युअल स्थापना
  • स्वतंत्र लॉगिंग
  • संबंधित सेवांची चाचणी आणि डीबगिंग

आर्किटेक्चर आणि विद्यमान समाधानाच्या समस्या

सुरुवातीला, आर्किटेक्चर असे दिसले: UI हा एक वेगळा अनुप्रयोग आहे, मोनोलिथिक भाग व्हिज्युअल बेसिक 6 मध्ये लिहिलेला आहे, .NET ऍप्लिकेशन हा बर्‍यापैकी मोठ्या डेटाबेससह कार्यरत संबंधित सेवांचा संच आहे.

मागील उपायाचे तोटे

अपयशाचा एकच मुद्दा
आमच्याकडे अपयशाचा एकच मुद्दा होता: .NET अनुप्रयोग एकाच प्रक्रियेत चालला. कोणतेही मॉड्यूल अयशस्वी झाल्यास, संपूर्ण अनुप्रयोग अयशस्वी झाला आणि पुन्हा सुरू करावा लागेल. आम्ही वेगवेगळ्या वापरकर्त्यांसाठी मोठ्या प्रमाणात प्रक्रिया स्वयंचलित करत असल्याने, त्यापैकी एकामध्ये बिघाड झाल्यामुळे, प्रत्येकजण काही काळ काम करू शकला नाही. आणि सॉफ्टवेअर त्रुटीच्या बाबतीत, बॅकअप देखील मदत करत नाही.

सुधारणांची रांग
ही कमतरता ऐवजी संघटनात्मक आहे. आमच्या ऍप्लिकेशनचे बरेच ग्राहक आहेत आणि ते सर्व शक्य तितक्या लवकर ते सुधारू इच्छित आहेत. पूर्वी, समांतरपणे हे करणे अशक्य होते आणि सर्व ग्राहक रांगेत उभे होते. ही प्रक्रिया व्यवसायांसाठी नकारात्मक होती कारण त्यांना त्यांचे कार्य मौल्यवान असल्याचे सिद्ध करायचे होते. आणि विकास संघाने ही रांग आयोजित करण्यात वेळ घालवला. यासाठी खूप वेळ आणि मेहनत घेतली गेली आणि उत्पादन शेवटी त्यांना आवडेल तितक्या लवकर बदलू शकले नाही.

संसाधनांचा सर्वोत्कृष्ट वापर
एकाच प्रक्रियेत सेवा होस्ट करताना, आम्ही नेहमी सर्व्हरवरून सर्व्हरवर कॉन्फिगरेशन पूर्णपणे कॉपी करतो. संसाधने वाया जाऊ नयेत आणि आमच्या उपयोजन योजनेवर अधिक लवचिक नियंत्रण मिळवण्यासाठी आम्हाला सर्वात जास्त लोड केलेल्या सेवा स्वतंत्रपणे ठेवायच्या होत्या.

आधुनिक तंत्रज्ञानाची अंमलबजावणी करणे कठीण आहे
सर्व विकसकांना परिचित समस्या: प्रकल्पात आधुनिक तंत्रज्ञानाचा परिचय करून देण्याची इच्छा आहे, परंतु संधी नाही. मोठ्या मोनोलिथिक सोल्यूशनसह, वर्तमान लायब्ररीचे कोणतेही अद्यतन, नवीनमध्ये संक्रमणाचा उल्लेख न करता, एक क्षुल्लक कार्यात बदलते. टीम लीडरला हे सिद्ध करण्यासाठी बराच वेळ लागतो की यामुळे वाया गेलेल्या नसांपेक्षा अधिक बोनस मिळेल.

बदल जारी करण्यात अडचण
ही सर्वात गंभीर समस्या होती - आम्ही दर दोन महिन्यांनी रिलीज रिलीज करत होतो.
विकासकांच्या चाचणी आणि प्रयत्नांना न जुमानता प्रत्येक रिलीझ बँकेसाठी एक वास्तविक आपत्ती बनली. व्यवसायाला समजले की आठवड्याच्या सुरुवातीला त्याची काही कार्यक्षमता कार्य करणार नाही. आणि विकसकांना समजले की गंभीर घटनांचा एक आठवडा त्यांची वाट पाहत आहे.
प्रत्येकाला परिस्थिती बदलण्याची इच्छा होती.

मायक्रो सर्व्हिसेसकडून अपेक्षा

तयार झाल्यावर घटकांचा मुद्दा. द्रावणाचे विघटन करून आणि विविध प्रक्रिया विभक्त करून तयार झाल्यावर घटकांचे वितरण.

लहान उत्पादन संघ. हे महत्त्वाचे आहे कारण जुन्या मोनोलिथवर काम करणाऱ्या मोठ्या संघाचे व्यवस्थापन करणे कठीण होते. अशा संघाला कठोर प्रक्रियेनुसार काम करण्यास भाग पाडले गेले, परंतु त्यांना अधिक सर्जनशीलता आणि स्वातंत्र्य हवे होते. हे फक्त लहान संघांनाच परवडणारे होते.

स्वतंत्र प्रक्रियांमध्ये सेवांचे पृथक्करण. आदर्शपणे, मला ते कंटेनरमध्ये वेगळे ठेवायचे आहे, परंतु .NET फ्रेमवर्कमध्ये लिहिलेल्या मोठ्या संख्येने सेवा केवळ अंतर्गत चालतात. Windows.NET Core वर आधारित सेवा आता उपलब्ध होत आहेत, पण त्यांची संख्या अजूनही कमी आहे.

उपयोजन लवचिकता. आम्‍हाला सेवा संयोजित करण्‍याची आमच्‍या गरज आहे, आणि कोडच्‍या प्रकारे सक्ती करत नाही.

नवीन तंत्रज्ञानाचा वापर. हे कोणत्याही प्रोग्रामरसाठी मनोरंजक आहे.

संक्रमण समस्या

अर्थात, मायक्रोसर्व्हिसेसमध्ये मोनोलिथ मोडणे सोपे असते, तर कॉन्फरन्समध्ये याबद्दल बोलण्याची आणि लेख लिहिण्याची गरज नसते. या प्रक्रियेत अनेक तोटे आहेत; मी मुख्य गोष्टींचे वर्णन करेन ज्याने आम्हाला अडथळा आणला.

पहिली समस्या बहुतेक मोनोलिथ्ससाठी वैशिष्ट्यपूर्ण: व्यवसाय तर्कसंगतता. जेव्हा आम्ही मोनोलिथ लिहितो, तेव्हा आम्हाला आमचे वर्ग पुन्हा वापरायचे आहेत जेणेकरून अनावश्यक कोड लिहू नये. आणि मायक्रोसर्व्हिसेसकडे जाताना, ही एक समस्या बनते: सर्व कोड अगदी घट्ट जोडलेले आहेत आणि सेवा वेगळे करणे कठीण आहे.

कामाच्या सुरूवातीच्या वेळी, रेपॉजिटरीमध्ये 500 हून अधिक प्रकल्प आणि 700 हजारांहून अधिक कोड लाइन्स होत्या. हा खूप मोठा निर्णय आहे आणि दुसरी समस्या. ते फक्त घेणे आणि मायक्रोसर्व्हिसेसमध्ये विभागणे शक्य नव्हते.

तिसरी समस्या - आवश्यक पायाभूत सुविधांचा अभाव. खरं तर, आम्ही सर्व्हरवर स्त्रोत कोड मॅन्युअली कॉपी करत होतो.

मोनोलिथपासून मायक्रोसर्व्हिसेसमध्ये कसे जायचे

सूक्ष्म सेवांची तरतूद करणे

प्रथम, आम्ही ताबडतोब स्वतःसाठी ठरवले की मायक्रोसर्व्हिसेस वेगळे करणे ही एक पुनरावृत्ती प्रक्रिया आहे. आम्हाला नेहमी समांतरपणे व्यवसाय समस्या विकसित करणे आवश्यक होते. आम्ही हे तांत्रिकदृष्ट्या कसे अंमलात आणणार हे आधीच आमची समस्या आहे. म्हणून, आम्ही पुनरावृत्ती प्रक्रियेची तयारी केली. तुमच्याकडे मोठा अर्ज असल्यास आणि तो सुरुवातीला पुन्हा लिहिण्यास तयार नसल्यास ते इतर कोणत्याही प्रकारे कार्य करणार नाही.

मायक्रो सर्व्हिसेस वेगळे करण्यासाठी आम्ही कोणत्या पद्धती वापरतो?

प्रथम मार्ग - सेवा म्हणून विद्यमान मॉड्यूल हलवा. या संदर्भात, आम्ही भाग्यवान होतो: आधीच नोंदणीकृत सेवा होत्या ज्यांनी WCF प्रोटोकॉल वापरून कार्य केले. ते स्वतंत्र असेंब्लीमध्ये विभागले गेले. आम्ही प्रत्येक बिल्डमध्ये एक लहान लाँचर जोडून त्यांना स्वतंत्रपणे पोर्ट केले. हे आश्चर्यकारक टॉपशेल्फ लायब्ररी वापरून लिहिले गेले होते, जे तुम्हाला सेवा आणि कन्सोल म्हणून अनुप्रयोग चालविण्यास अनुमती देते. हे डीबगिंगसाठी सोयीचे आहे कारण सोल्यूशनमध्ये कोणतेही अतिरिक्त प्रकल्प आवश्यक नाहीत.

सेवा व्यवसाय तर्कानुसार जोडल्या गेल्या होत्या, कारण त्यांनी सामान्य असेंब्ली वापरल्या आणि सामान्य डेटाबेससह कार्य केले. त्यांना त्यांच्या शुद्ध स्वरूपात सूक्ष्म सेवा म्हणता येणार नाही. तथापि, आम्ही या सेवा स्वतंत्रपणे, वेगवेगळ्या प्रक्रियांमध्ये प्रदान करू शकतो. यामुळेच त्यांचा एकमेकांवरील प्रभाव कमी करणे, समांतर विकासाची समस्या आणि अपयशाचा एकच मुद्दा कमी करणे शक्य झाले.

होस्टसह असेंब्ली ही प्रोग्राम क्लासमधील कोडची फक्त एक ओळ आहे. आम्ही सहाय्यक वर्गात टॉपशेल्फसह काम लपवले.

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

मायक्रोसर्व्हिसेस वाटप करण्याचा दुसरा मार्ग आहे: नवीन समस्या सोडवण्यासाठी त्यांना तयार करा. जर त्याच वेळी मोनोलिथ वाढत नसेल तर हे आधीच उत्कृष्ट आहे, याचा अर्थ आपण योग्य दिशेने जात आहोत. नवीन समस्यांचे निराकरण करण्यासाठी, आम्ही स्वतंत्र सेवा तयार करण्याचा प्रयत्न केला. जर अशी संधी असेल, तर आम्ही आणखी "प्रामाणिक" सेवा तयार केल्या ज्या पूर्णपणे त्यांचे स्वतःचे डेटा मॉडेल, एक स्वतंत्र डेटाबेस व्यवस्थापित करतात.

आम्ही, अनेकांप्रमाणे, प्रमाणीकरण आणि अधिकृतता सेवांनी सुरुवात केली. ते यासाठी योग्य आहेत. ते स्वतंत्र आहेत, नियमानुसार, त्यांच्याकडे स्वतंत्र डेटा मॉडेल आहे. ते स्वतः मोनोलिथशी संवाद साधत नाहीत, फक्त काही समस्या सोडवण्यासाठी त्यांच्याकडे वळतात. या सेवांचा वापर करून, तुम्ही नवीन आर्किटेक्चरमध्ये संक्रमण सुरू करू शकता, त्यावरील पायाभूत सुविधा डीबग करू शकता, नेटवर्क लायब्ररीशी संबंधित काही दृष्टिकोन वापरून पाहू शकता इ. आमच्या संस्थेमध्ये आमच्याकडे कोणतेही संघ नाहीत जे प्रमाणीकरण सेवा तयार करू शकले नाहीत.

मायक्रोसर्व्हिसेस वाटप करण्याचा तिसरा मार्गआम्ही वापरतो तो आमच्यासाठी थोडा विशिष्ट आहे. हे UI लेयरमधून व्यवसाय तर्क काढून टाकणे आहे. आमचा मुख्य UI अनुप्रयोग डेस्कटॉप आहे; तो, बॅकएंड प्रमाणे, C# मध्ये लिहिलेला आहे. विकासकांनी वेळोवेळी चुका केल्या आणि तर्कशास्त्राचे भाग UI मध्ये हस्तांतरित केले जे बॅकएंडमध्ये अस्तित्वात असले पाहिजेत आणि ते पुन्हा वापरले गेले पाहिजेत.

जर तुम्ही UI भागाच्या कोडमधील एक वास्तविक उदाहरण पाहिले तर तुम्ही पाहू शकता की यापैकी बहुतेक सोल्यूशनमध्ये वास्तविक व्यवसाय लॉजिक आहे जे केवळ UI फॉर्म तयार करण्यासाठीच नाही तर इतर प्रक्रियांमध्ये उपयुक्त आहे.

वास्तविक UI लॉजिक फक्त शेवटच्या दोन ओळींमध्ये आहे. आम्ही ते सर्व्हरवर हस्तांतरित केले जेणेकरून ते पुन्हा वापरता येईल, ज्यामुळे UI कमी होईल आणि योग्य आर्किटेक्चर साध्य होईल.

मायक्रोसर्व्हिसेस वेगळे करण्याचा चौथा आणि सर्वात महत्त्वाचा मार्ग, ज्यामुळे मोनोलिथ कमी करणे शक्य होते, प्रक्रियेसह विद्यमान सेवा काढून टाकणे. जेव्हा आम्ही विद्यमान मॉड्यूल जसेच्या तसे बाहेर काढतो, तेव्हा त्याचा परिणाम नेहमी विकासकांच्या पसंतीस उतरत नाही आणि कार्यक्षमता तयार केल्यापासून व्यवसाय प्रक्रिया जुनी झालेली असू शकते. रिफॅक्टरिंगसह, आम्ही नवीन व्यवसाय प्रक्रियेस समर्थन देऊ शकतो कारण व्यवसाय आवश्यकता सतत बदलत असतात. आम्ही स्त्रोत कोड सुधारू शकतो, ज्ञात दोष दूर करू शकतो आणि एक चांगले डेटा मॉडेल तयार करू शकतो. अनेक फायदे जमा होत आहेत.

प्रक्रियांपासून सेवा विभक्त करणे हे बंधनकारक संदर्भाच्या संकल्पनेशी अतूटपणे जोडलेले आहे. ही डोमेन चालित डिझाइनची संकल्पना आहे. याचा अर्थ डोमेन मॉडेलचा एक विभाग आहे ज्यामध्ये एकाच भाषेच्या सर्व संज्ञा अद्वितीयपणे परिभाषित केल्या आहेत. उदाहरण म्हणून विमा आणि बिलांचा संदर्भ पाहू. आमच्याकडे एक मोनोलिथिक ऍप्लिकेशन आहे आणि आम्हाला विमा खात्यासह कार्य करणे आवश्यक आहे. आम्ही अपेक्षा करतो की विकासकाने दुसर्‍या असेंब्लीमध्ये विद्यमान खाते वर्ग शोधून काढावा, विमा वर्गाकडून त्याचा संदर्भ घ्यावा आणि आमच्याकडे कार्यरत कोड असेल. DRY तत्त्वाचा आदर केला जाईल, विद्यमान कोड वापरून कार्य जलद केले जाईल.

परिणामी, असे दिसून आले की खाती आणि विमा यांचे संदर्भ जोडलेले आहेत. नवीन गरजा उदयास येत असताना, हे जोडणी विकासामध्ये व्यत्यय आणेल, आधीच जटिल व्यावसायिक तर्काची जटिलता वाढवेल. या समस्येचे निराकरण करण्यासाठी, आपल्याला कोडमधील संदर्भांमधील सीमा शोधणे आणि त्यांचे उल्लंघन काढून टाकणे आवश्यक आहे. उदाहरणार्थ, विमा संदर्भात, हे शक्य आहे की 20-अंकी सेंट्रल बँक खाते क्रमांक आणि खाते उघडल्याची तारीख पुरेशी असेल.

हे बांधलेले संदर्भ एकमेकांपासून वेगळे करण्यासाठी आणि मायक्रोसर्व्हिसेसला एका मोनोलिथिक सोल्यूशनपासून विभक्त करण्याची प्रक्रिया सुरू करण्यासाठी, आम्ही ऍप्लिकेशनमध्ये बाह्य API तयार करण्यासारखा दृष्टिकोन वापरला. जर आम्हाला माहित असेल की काही मॉड्यूल मायक्रोसर्व्हिस बनले पाहिजेत, प्रक्रियेत कसेतरी सुधारित केले जावे, तर आम्ही ताबडतोब बाह्य कॉलद्वारे दुसर्या मर्यादित संदर्भाशी संबंधित असलेल्या लॉजिकला कॉल केले. उदाहरणार्थ, REST किंवा WCF द्वारे.

वितरीत व्यवहारांची आवश्यकता असेल असे कोड आम्ही टाळणार नाही असे आम्ही ठामपणे ठरवले. आमच्या बाबतीत, हा नियम पाळणे अगदी सोपे असल्याचे दिसून आले. आम्ही अद्याप अशा परिस्थितींचा सामना केला नाही जेथे कठोर वितरित व्यवहारांची खरोखर आवश्यकता आहे - मॉड्यूल्समधील अंतिम सुसंगतता पुरेसे आहे.

चला एक विशिष्ट उदाहरण पाहू. आमच्याकडे ऑर्केस्ट्रेटरची संकल्पना आहे - एक पाइपलाइन जी "अनुप्रयोग" च्या अस्तित्वावर प्रक्रिया करते. तो बदल्यात एक क्लायंट, एक खाते आणि एक बँक कार्ड तयार करतो. जर क्लायंट आणि खाते यशस्वीरित्या तयार केले गेले, परंतु कार्ड तयार करणे अयशस्वी झाले, तर अनुप्रयोग "यशस्वी" स्थितीकडे जात नाही आणि "कार्ड तयार नाही" स्थितीत राहतो. भविष्यात, पार्श्वभूमी क्रियाकलाप ते उचलेल आणि पूर्ण करेल. प्रणाली काही काळ विसंगतीच्या स्थितीत आहे, परंतु आम्ही सर्वसाधारणपणे याबद्दल समाधानी आहोत.

डेटाचा काही भाग सातत्याने सेव्ह करणे आवश्यक असताना एखादी परिस्थिती उद्भवल्यास, आम्ही बहुधा एका प्रक्रियेत प्रक्रिया करण्यासाठी सेवेचे एकत्रीकरण करू.

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

सर्व प्रथम, आम्ही कोड पुन्हा लिहून मायक्रोसर्व्हिस तयार करतो. आम्ही काही पैलू सुधारत आहोत ज्यांबद्दल आम्हाला आनंद नव्हता. आम्ही ग्राहकांकडून नवीन व्यवसाय आवश्यकता लागू करतो. आम्ही UI आणि बॅकएंडमधील कनेक्शनसाठी API गेटवे जोडतो, जो कॉल फॉरवर्डिंग प्रदान करेल.

पुढे, आम्ही हे कॉन्फिगरेशन ऑपरेशनमध्ये सोडतो, परंतु प्रायोगिक स्थितीत. आमचे बरेच वापरकर्ते अजूनही जुन्या व्यवसाय प्रक्रियेसह कार्य करतात. नवीन वापरकर्त्यांसाठी, आम्ही मोनोलिथिक ऍप्लिकेशनची नवीन आवृत्ती विकसित करत आहोत ज्यामध्ये यापुढे ही प्रक्रिया नाही. मूलत:, आमच्याकडे मोनोलिथ आणि पायलट म्हणून काम करणारी मायक्रोसर्व्हिस यांचे संयोजन आहे.

यशस्वी पायलटसह, आम्हाला समजते की नवीन कॉन्फिगरेशन खरोखर कार्यक्षम आहे, आम्ही समीकरणातून जुने मोनोलिथ काढून टाकू शकतो आणि जुन्या सोल्यूशनच्या जागी नवीन कॉन्फिगरेशन सोडू शकतो.

एकूणच, मोनोलिथचा स्त्रोत कोड विभाजित करण्यासाठी आम्ही जवळजवळ सर्व विद्यमान पद्धती वापरतो. ते सर्व आम्हाला अनुप्रयोगाच्या भागांचा आकार कमी करण्यास आणि त्यांना नवीन लायब्ररींमध्ये अनुवादित करण्याची परवानगी देतात, अधिक चांगला स्त्रोत कोड बनवतात.

डेटाबेससह कार्य करणे

डेटाबेस स्त्रोत कोडपेक्षा वाईट विभागला जाऊ शकतो, कारण त्यात केवळ वर्तमान स्कीमाच नाही तर संचित ऐतिहासिक डेटा देखील आहे.

आमच्या डेटाबेसमध्ये, इतर अनेकांप्रमाणे, आणखी एक महत्त्वाचा दोष होता - त्याचा प्रचंड आकार. हा डेटाबेस एका मोनोलिथच्या क्लिष्ट व्यावसायिक तर्कानुसार आणि विविध बद्ध संदर्भांच्या सारण्यांमध्ये जमा झालेल्या संबंधांनुसार तयार केला गेला होता.

आमच्या बाबतीत, सर्व समस्या (मोठा डेटाबेस, अनेक कनेक्शन्स, कधीकधी टेबलांमधील अस्पष्ट सीमा) वर जाण्यासाठी, एक समस्या उद्भवली जी अनेक मोठ्या प्रकल्पांमध्ये उद्भवते: सामायिक डेटाबेस टेम्पलेटचा वापर. डेटा टेबलमधून दृश्याद्वारे, प्रतिकृतीद्वारे घेतला गेला आणि इतर सिस्टममध्ये पाठवला गेला जिथे ही प्रतिकृती आवश्यक होती. परिणामी, आम्ही टेबल्स वेगळ्या स्कीमामध्ये हलवू शकलो नाही कारण ते सक्रियपणे वापरले गेले होते.

कोडमधील मर्यादित संदर्भांमध्ये समान विभागणी आपल्याला वेगळे करण्यात मदत करते. हे सहसा डेटाबेस स्तरावर आम्ही डेटा कसा खंडित करतो याची एक चांगली कल्पना देते. कोणती सारणी एका बद्ध संदर्भाशी संबंधित आहेत आणि कोणती दुसर्‍याशी संबंधित आहेत हे आम्हाला समजते.

आम्ही डेटाबेस विभाजनाच्या दोन जागतिक पद्धती वापरल्या: विद्यमान सारण्यांचे विभाजन आणि प्रक्रियेसह विभाजन.

डेटा स्ट्रक्चर चांगली असल्यास, व्यवसायाच्या आवश्यकता पूर्ण करत असल्यास आणि प्रत्येकजण त्यावर खूश असल्यास विद्यमान सारण्यांचे विभाजन करणे ही एक चांगली पद्धत आहे. या प्रकरणात, आम्ही विद्यमान सारण्या वेगळ्या स्कीमामध्ये विभक्त करू शकतो.

जेव्हा व्यवसाय मॉडेल मोठ्या प्रमाणात बदललेले असते तेव्हा प्रक्रिया असलेल्या विभागाची आवश्यकता असते आणि टेबल्स यापुढे आम्हाला अजिबात संतुष्ट करत नाहीत.

विद्यमान सारण्यांचे विभाजन करणे. आपण काय वेगळे करू हे ठरवावे लागेल. या ज्ञानाशिवाय, काहीही कार्य करणार नाही, आणि येथे कोडमधील बंधनकारक संदर्भांचे पृथक्करण आम्हाला मदत करेल. नियमानुसार, जर आपण स्त्रोत कोडमधील संदर्भांच्या सीमा समजू शकत असाल तर, विभागासाठी यादीमध्ये कोणती सारणी समाविष्ट करावी हे स्पष्ट होते.

चला कल्पना करूया की आपल्याकडे एक उपाय आहे ज्यामध्ये दोन मोनोलिथ मॉड्यूल एका डेटाबेसशी संवाद साधतात. आम्हाला हे सुनिश्चित करणे आवश्यक आहे की फक्त एक मॉड्यूल विभक्त सारण्यांच्या विभागाशी संवाद साधतो आणि दुसरा त्याच्याशी API द्वारे संवाद साधू लागतो. सुरुवातीला, एपीआयद्वारे फक्त रेकॉर्डिंग केले जाते हे पुरेसे आहे. मायक्रो सर्व्हिसेसच्या स्वातंत्र्याबद्दल बोलण्यासाठी ही एक आवश्यक अट आहे. जोपर्यंत कोणतीही मोठी समस्या येत नाही तोपर्यंत वाचन कनेक्शन राहू शकतात.

पुढची पायरी म्हणजे आम्ही कोडचा विभाग जो विभक्त टेबलसह काम करतो, प्रक्रिया न करता, वेगळ्या मायक्रोसर्व्हिसमध्ये वेगळे करू शकतो आणि वेगळ्या प्रक्रियेत, कंटेनरमध्ये चालवू शकतो. मोनोलिथ डेटाबेस आणि त्याच्याशी थेट संबंध नसलेल्या सारण्यांशी जोडलेली ही एक वेगळी सेवा असेल. मोनोलिथ अजूनही विलग करण्यायोग्य भागासह वाचनासाठी संवाद साधतो.

नंतर आम्ही हे कनेक्शन काढून टाकू, म्हणजेच, विभक्त सारण्यांमधून मोनोलिथिक ऍप्लिकेशनमधील डेटा वाचणे देखील API मध्ये हस्तांतरित केले जाईल.

पुढे, आम्ही सामान्य डेटाबेसमधून टेबल निवडू ज्यामध्ये फक्त नवीन मायक्रोसर्व्हिस कार्य करते. आम्ही टेबल्स वेगळ्या स्कीमामध्ये किंवा वेगळ्या भौतिक डेटाबेसमध्ये देखील हलवू शकतो. मायक्रोसर्व्हिस आणि मोनोलिथ डेटाबेसमध्ये अद्याप वाचन कनेक्शन आहे, परंतु काळजी करण्यासारखे काहीही नाही, या कॉन्फिगरेशनमध्ये ते बराच काळ जगू शकते.

शेवटची पायरी म्हणजे सर्व कनेक्शन पूर्णपणे काढून टाकणे. या प्रकरणात, आम्हाला मुख्य डेटाबेसमधून डेटा स्थलांतरित करण्याची आवश्यकता असू शकते. काहीवेळा आम्‍हाला अनेक डेटाबेसमध्‍ये बाह्य सिस्‍टममधून प्रतिरूपित केलेला काही डेटा किंवा निर्देशिकांचा पुनर्वापर करायचा असतो. हे आपल्या बाबतीत अधूनमधून घडते.

प्रक्रिया विभाग. ही पद्धत पहिल्यासारखीच आहे, फक्त उलट क्रमाने. आम्ही ताबडतोब एक नवीन डेटाबेस आणि नवीन मायक्रोसर्व्हिस वाटप करतो जे API द्वारे मोनोलिथशी संवाद साधते. परंतु त्याच वेळी, डेटाबेस सारण्यांचा एक संच शिल्लक आहे जो आम्हाला भविष्यात हटवायचा आहे. आम्हाला यापुढे त्याची गरज नाही; आम्ही ते नवीन मॉडेलमध्ये बदलले.

ही योजना कार्य करण्‍यासाठी, आम्‍हाला बहुधा संक्रमण कालावधी लागेल.

त्यानंतर दोन संभाव्य दृष्टिकोन आहेत.

पहिला: आम्ही नवीन आणि जुन्या डेटाबेसमधील सर्व डेटा डुप्लिकेट करतो. या प्रकरणात, आमच्याकडे डेटा रिडंडंसी आहे आणि सिंक्रोनाइझेशन समस्या उद्भवू शकतात. पण आम्ही दोन वेगवेगळे क्लायंट घेऊ शकतो. एक नवीन आवृत्तीसह कार्य करेल, दुसरा जुन्या आवृत्तीसह.

सेकंद: आम्ही काही व्यवसाय निकषांनुसार डेटा विभाजित करतो. उदाहरणार्थ, आमच्याकडे सिस्टममध्ये 5 उत्पादने होती जी जुन्या डेटाबेसमध्ये संग्रहित होती. आम्ही नवीन डेटाबेसमध्ये नवीन व्यवसाय कार्यामध्ये सहावा स्थान देतो. परंतु आम्हाला API गेटवेची आवश्यकता असेल जो हा डेटा समक्रमित करेल आणि क्लायंटला कोठून आणि काय मिळवायचे ते दर्शवेल.

दोन्ही पध्दती कार्य करतात, परिस्थितीनुसार निवडा.

सर्वकाही कार्य करते याची आम्हाला खात्री झाल्यानंतर, जुन्या डेटाबेस स्ट्रक्चर्ससह कार्य करणारा मोनोलिथचा भाग अक्षम केला जाऊ शकतो.

शेवटची पायरी म्हणजे जुन्या डेटा स्ट्रक्चर्स काढून टाकणे.

थोडक्यात, आम्ही असे म्हणू शकतो की आम्हाला डेटाबेसमध्ये समस्या आहेत: स्त्रोत कोडच्या तुलनेत त्याच्यासह कार्य करणे कठीण आहे, ते सामायिक करणे अधिक कठीण आहे, परंतु ते केले जाऊ शकते आणि केले पाहिजे. आम्हाला असे काही मार्ग सापडले आहेत जे आम्हाला हे सुरक्षितपणे करण्याची परवानगी देतात, परंतु स्त्रोत कोडपेक्षा डेटासह चुका करणे अद्याप सोपे आहे.

स्त्रोत कोडसह कार्य करणे

जेव्हा आम्ही मोनोलिथिक प्रकल्पाचे विश्लेषण करण्यास सुरुवात केली तेव्हा स्त्रोत कोड आकृती असे दिसते.

हे ढोबळमानाने तीन स्तरांमध्ये विभागले जाऊ शकते. हा लॉन्च केलेला मॉड्यूल, प्लगइन, सेवा आणि वैयक्तिक क्रियाकलापांचा एक स्तर आहे. किंबहुना, हे मोनोलिथिक सोल्यूशनमधील प्रवेश बिंदू होते. त्या सर्वांना कॉमन लेयरने घट्ट बंद केले होते. यात सेवा सामायिक केल्याचा व्यवसाय तर्क होता आणि बरेच कनेक्शन होते. प्रत्येक सेवा आणि प्लगइन 10 किंवा अधिक सामान्य असेंब्ली वापरतात, त्यांचा आकार आणि विकासकांच्या विवेकानुसार.

स्वतंत्रपणे वापरता येणार्‍या पायाभूत लायब्ररीमुळे आम्ही भाग्यवान होतो.

कधीकधी अशी परिस्थिती उद्भवली जेव्हा काही सामान्य वस्तू प्रत्यक्षात या स्तराशी संबंधित नसल्या, परंतु पायाभूत लायब्ररी होत्या. हे नाव बदलून सोडवले गेले.

सर्वात मोठी चिंता होती ती सीमाबद्ध संदर्भांची. असे घडले की एका कॉमन असेंब्लीमध्ये 3-4 संदर्भ मिसळले गेले आणि समान व्यावसायिक कार्यांमध्ये एकमेकांचा वापर केला गेला. हे कुठे आणि कोणत्या सीमांवर विभागले जाऊ शकते आणि स्त्रोत कोड असेंब्लीमध्ये या विभाजनाचे मॅपिंग करून पुढे काय करावे हे समजून घेणे आवश्यक होते.

आम्ही कोड स्प्लिटिंग प्रक्रियेसाठी अनेक नियम तयार केले आहेत.

पहिला: आम्ही यापुढे सेवा, क्रियाकलाप आणि प्लगइन यांच्यामध्ये व्यवसाय तर्क सामायिक करू इच्छित नाही. आम्हाला मायक्रो सर्व्हिसेसमध्ये व्यवसायाचे तर्कशास्त्र स्वतंत्र करायचे होते. दुसरीकडे, मायक्रोसर्व्हिसेस, पूर्णपणे स्वतंत्रपणे अस्तित्वात असलेल्या सेवा म्हणून विचार केला जातो. माझा विश्वास आहे की हा दृष्टीकोन काहीसा व्यर्थ आहे, आणि ते साध्य करणे कठीण आहे, कारण, उदाहरणार्थ, C# मधील सेवा कोणत्याही परिस्थितीत मानक लायब्ररीद्वारे जोडल्या जातील. आमची प्रणाली C# मध्ये लिहिलेली आहे; आम्ही अद्याप इतर तंत्रज्ञान वापरलेले नाही. म्हणून, आम्ही ठरवले की आम्हाला सामान्य तांत्रिक असेंब्ली वापरणे परवडेल. मुख्य गोष्ट अशी आहे की त्यामध्ये व्यावसायिक तर्काचे कोणतेही तुकडे नाहीत. तुम्ही वापरत असलेल्या ORM वर तुमच्याकडे सोयीचे आवरण असल्यास, ते सेवा ते सेवेत कॉपी करणे खूप महाग आहे.

आमचा कार्यसंघ डोमेन-चालित डिझाइनचा चाहता आहे, म्हणून कांदा आर्किटेक्चर आमच्यासाठी योग्य आहे. आमच्या सेवांचा आधार डेटा ऍक्सेस लेयर नसून डोमेन लॉजिक असलेली असेंब्ली आहे, ज्यामध्ये फक्त व्यवसाय लॉजिक आहे आणि पायाभूत सुविधांशी कोणताही संबंध नाही. त्याच वेळी, फ्रेमवर्कशी संबंधित समस्यांचे निराकरण करण्यासाठी आम्ही स्वतंत्रपणे डोमेन असेंब्लीमध्ये बदल करू शकतो.

या टप्प्यावर आम्हाला आमची पहिली गंभीर समस्या आली. सेवेला एका डोमेन असेंब्लीचा संदर्भ घ्यायचा होता, आम्हाला तर्कशास्त्र स्वतंत्र करायचे होते आणि DRY तत्त्वाने आम्हाला येथे मोठ्या प्रमाणात अडथळा आणला. डुप्लिकेशन टाळण्यासाठी डेव्हलपरना शेजारील असेंब्लीमधील वर्ग पुन्हा वापरायचे होते आणि परिणामी, डोमेन पुन्हा एकत्र जोडले जाऊ लागले. आम्ही परिणामांचे विश्लेषण केले आणि ठरवले की कदाचित समस्या स्त्रोत कोड स्टोरेज डिव्हाइसच्या क्षेत्रात देखील आहे. आमच्याकडे सर्व स्त्रोत कोड असलेले एक मोठे भांडार होते. संपूर्ण प्रकल्पासाठी उपाय स्थानिक मशीनवर एकत्र करणे खूप कठीण होते. म्हणून, प्रकल्पाच्या भागांसाठी स्वतंत्र लहान उपाय तयार केले गेले आणि कोणीही त्यांना काही सामान्य किंवा डोमेन असेंब्ली जोडण्यास आणि त्यांचा पुन्हा वापर करण्यास मनाई केली नाही. कोड पुनरावलोकन हे एकमेव साधन ज्याने आम्हाला हे करण्याची परवानगी दिली नाही. पण कधी कधी ते अयशस्वीही होते.

मग आम्ही वेगळ्या रेपॉजिटरीजसह मॉडेलकडे जाऊ लागलो. बिझनेस लॉजिक आता सेवेकडून सेवेकडे जात नाही, डोमेन खऱ्या अर्थाने स्वतंत्र झाले आहेत. बंधनकारक संदर्भ अधिक स्पष्टपणे समर्थित आहेत. आम्ही पायाभूत लायब्ररींचा पुनर्वापर कसा करू? आम्ही त्यांना वेगळ्या भांडारात विभक्त केले, नंतर त्यांना Nuget पॅकेजमध्ये ठेवले, जे आम्ही आर्टिफॅक्टरीमध्ये ठेवले. कोणत्याही बदलासह, असेंब्ली आणि प्रकाशन आपोआप होते.

आमच्या सेवा बाह्य संकुलांप्रमाणेच अंतर्गत पायाभूत सुविधा पॅकेजेसचा संदर्भ देऊ लागल्या. आम्ही Nuget वरून बाह्य लायब्ररी डाउनलोड करतो. आर्टिफॅक्टरीसह काम करण्यासाठी, जिथे आम्ही ही पॅकेजेस ठेवली, आम्ही दोन पॅकेज व्यवस्थापक वापरले. छोट्या रेपॉजिटरीजमध्येही आम्ही Nuget वापरतो. एकाधिक सेवांसह भांडारांमध्ये, आम्ही Paket वापरले, जे मॉड्यूल्समध्ये अधिक आवृत्ती सुसंगतता प्रदान करते.

अशा प्रकारे, स्त्रोत कोडवर कार्य करून, आर्किटेक्चरमध्ये किंचित बदल करून आणि भांडार वेगळे करून, आम्ही आमच्या सेवा अधिक स्वतंत्र बनवतो.

पायाभूत सुविधांच्या समस्या

मायक्रोसर्व्हिसेसकडे जाण्याचे बहुतेक तोटे पायाभूत सुविधांशी संबंधित आहेत. तुम्हाला स्वयंचलित उपयोजनाची आवश्यकता असेल, तुम्हाला पायाभूत सुविधा चालवण्यासाठी नवीन लायब्ररीची आवश्यकता असेल.

वातावरणात मॅन्युअल स्थापना

सुरुवातीला, आम्ही पर्यावरणासाठी उपाय स्वहस्ते स्थापित केले. ही प्रक्रिया स्वयंचलित करण्यासाठी, आम्ही एक CI/CD पाइपलाइन तयार केली. आम्ही सतत वितरण प्रक्रिया निवडली कारण व्यवसाय प्रक्रियेच्या दृष्टिकोनातून सतत उपयोजन अद्याप आम्हाला मान्य नाही. म्हणून, ऑपरेशनसाठी पाठवणे बटण वापरून केले जाते आणि चाचणीसाठी - स्वयंचलितपणे.

आम्ही स्त्रोत कोड स्टोरेजसाठी अटलासियन, बिटबकेट आणि बिल्डिंगसाठी बांबू वापरतो. आम्हाला केकमध्ये बिल्ड स्क्रिप्ट लिहायला आवडते कारण ते C# सारखेच आहे. रेडीमेड पॅकेजेस आर्टिफॅक्टरीमध्ये येतात आणि अॅन्सिबल आपोआप चाचणी सर्व्हरवर पोहोचतात, त्यानंतर त्यांची त्वरित चाचणी केली जाऊ शकते.

स्वतंत्र लॉगिंग

एकेकाळी, मोनोलिथच्या कल्पनांपैकी एक म्हणजे सामायिक लॉगिंग प्रदान करणे. डिस्कवर असलेल्या वैयक्तिक लॉगचे काय करायचे हे देखील आम्हाला समजून घेणे आवश्यक आहे. आमचे लॉग मजकूर फायलींवर लिहिलेले आहेत. आम्ही मानक ELK स्टॅक वापरण्याचा निर्णय घेतला. आम्ही प्रदात्यांद्वारे थेट ELK ला लिहिले नाही, परंतु आम्ही मजकूर लॉग सुधारित करू आणि त्यामध्ये ट्रेस आयडी एक अभिज्ञापक म्हणून लिहू, सेवेचे नाव जोडू, जेणेकरून हे लॉग नंतर विश्लेषित केले जाऊ शकतील असे ठरवले.

फाइलबीटसह आम्ही आमचे लॉग गोळा करू शकतो सर्व्हर, नंतर त्यांचे रूपांतर करा, UI मध्ये क्वेरी तयार करण्यासाठी Kibana वापरा आणि सेवांमध्ये कॉल कसा राउट झाला ते पहा. यासाठी ट्रेस आयडी खूप उपयुक्त आहेत.

संबंधित सेवांची चाचणी आणि डीबगिंग

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

असे सर्व्हर आहेत जे केवळ सेवांच्या उत्पादन आवृत्त्या चालवतात. घटनांच्या बाबतीत, तैनातीपूर्वी वितरण तपासण्यासाठी आणि अंतर्गत प्रशिक्षणासाठी हे सर्व्हर आवश्यक आहेत.

आम्ही लोकप्रिय स्पेकफ्लो लायब्ररी वापरून स्वयंचलित चाचणी प्रक्रिया जोडली आहे. Ansible कडून तैनात केल्यानंतर लगेच NUnit वापरून चाचण्या आपोआप चालतात. कार्य कव्हरेज पूर्णपणे स्वयंचलित असल्यास, मॅन्युअल चाचणीची आवश्यकता नाही. जरी कधीकधी अतिरिक्त मॅन्युअल चाचणी आवश्यक असते. विशिष्ट समस्येसाठी कोणत्या चाचण्या चालवायच्या हे निर्धारित करण्यासाठी आम्ही जिरा मध्ये टॅग वापरतो.

याव्यतिरिक्त, लोड चाचणीची आवश्यकता वाढली आहे; पूर्वी ते केवळ दुर्मिळ प्रकरणांमध्येच केले जात होते. आम्ही चाचण्या चालवण्यासाठी JMeter, ते संग्रहित करण्यासाठी InfluxDB आणि प्रक्रिया आलेख तयार करण्यासाठी Grafana वापरतो.

आम्ही काय साध्य केले?

प्रथम, आम्ही "रिलीझ" च्या संकल्पनेपासून मुक्त झालो. जेव्हा हा कोलोसस उत्पादन वातावरणात तैनात करण्यात आला होता तेव्हा दोन महिन्यांचे राक्षसी प्रकाशन निघून गेले, तात्पुरते व्यवसाय प्रक्रिया व्यत्यय आणत. आता आम्ही सरासरी दर 1,5 दिवसांनी सेवा उपयोजित करतो, त्यांना गटबद्ध करतो कारण त्या मंजूरीनंतर कार्यान्वित होतात.

आमच्या सिस्टममध्ये कोणतेही घातक अपयश नाहीत. जर आम्ही बगसह मायक्रोसर्व्हिस सोडल्यास, त्याच्याशी संबंधित कार्यक्षमता खंडित होईल आणि इतर सर्व कार्यक्षमतेवर परिणाम होणार नाही. हे वापरकर्ता अनुभव मोठ्या प्रमाणात सुधारते.

आम्ही उपयोजन पॅटर्न नियंत्रित करू शकतो. आवश्यक असल्यास, तुम्ही उर्वरित सोल्यूशनमधून स्वतंत्रपणे सेवांचे गट निवडू शकता.

याव्यतिरिक्त, आम्ही सुधारणांच्या मोठ्या रांगेसह समस्या लक्षणीयरीत्या कमी केली आहे. आमच्याकडे आता स्वतंत्र उत्पादन कार्यसंघ आहेत जे काही सेवांसह स्वतंत्रपणे कार्य करतात. स्क्रॅम प्रक्रिया येथे आधीच योग्य आहे. विशिष्ट कार्यसंघाकडे एक वेगळा उत्पादन मालक असू शकतो जो त्यास कार्ये नियुक्त करतो.

सारांश

• सूक्ष्म सेवा विघटित जटिल प्रणालींसाठी योग्य आहेत. प्रक्रियेत, आपल्या सिस्टममध्ये काय आहे, कोणते मर्यादित संदर्भ आहेत, त्यांच्या सीमा कुठे आहेत हे आपल्याला समजू लागते. हे तुम्हाला मॉड्यूल्समध्ये सुधारणा योग्यरित्या वितरित करण्यास आणि कोड गोंधळ टाळण्यास अनुमती देते.
• सूक्ष्म सेवा संस्थात्मक लाभ देतात. ते सहसा केवळ आर्किटेक्चर म्हणून बोलले जातात, परंतु कोणत्याही आर्किटेक्चरची व्यावसायिक गरजा सोडवण्यासाठी आवश्यक असते, स्वतःहून नाही. म्हणून, आम्ही असे म्हणू शकतो की लहान संघांमधील समस्या सोडवण्यासाठी मायक्रोसर्व्हिसेस योग्य आहेत, कारण आता Scrum खूप लोकप्रिय आहे.
• पृथक्करण ही पुनरावृत्ती प्रक्रिया आहे. तुम्ही अर्ज घेऊ शकत नाही आणि ते फक्त मायक्रोसर्व्हिसेसमध्ये विभाजित करू शकत नाही. परिणामी उत्पादन कार्यक्षम असण्याची शक्यता नाही. मायक्रोसर्व्हिसेस समर्पित करताना, विद्यमान वारसा पुन्हा लिहिणे फायदेशीर आहे, म्हणजे, आम्हाला आवडलेल्या कोडमध्ये बदलणे आणि कार्यक्षमता आणि गतीच्या दृष्टीने व्यावसायिक गरजा अधिक चांगल्या प्रकारे पूर्ण करणे.

  एक छोटासा इशारा: मायक्रोसर्व्हिसेसमध्ये जाण्याचा खर्च खूपच लक्षणीय आहे. केवळ पायाभूत सुविधांचा प्रश्न सोडवण्यास बराच वेळ लागला. म्हणून जर तुमच्याकडे एक लहान ऍप्लिकेशन असेल ज्यासाठी विशिष्ट स्केलिंगची आवश्यकता नाही, जोपर्यंत तुमच्याकडे मोठ्या संख्येने ग्राहक तुमच्या टीमचे लक्ष आणि वेळ यासाठी स्पर्धा करत नाहीत, तर मायक्रोसर्व्हिसेस तुम्हाला आज आवश्यक नसतील. ते खूप महाग आहे. जर तुम्ही मायक्रोसर्व्हिसेससह प्रक्रिया सुरू केली, तर तुम्ही मोनोलिथच्या विकासासह समान प्रकल्प सुरू केल्यास खर्च सुरुवातीला जास्त असेल.

  P.S. अधिक भावनिक कथा (आणि जणू आपल्यासाठी वैयक्तिकरित्या) - त्यानुसार दुवा.
  अहवालाची संपूर्ण आवृत्ती येथे आहे.

स्त्रोत: www.habr.com