🗻 🐿️ 🌙 वेब डेवलपमेंट में माइक्रोसर्विस डीबग करने पर दर्द और पीड़ा ⌛️ 👦🏼 🏩

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

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

ट्रांसेक्शनल डेटा अखंडता कैसे प्राप्त करें

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

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

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

माइक्रोसर्विस के साथ काम करने में मुख्य समस्या यह है कि वे स्थानीय रूप से चलाने के लिए बेहद आसान हैं (उदाहरण के लिए, spring.io और intellij विचार का उपयोग करना , यह सिर्फ 5 मिनट में या इससे भी कम किया जा सकता है)। हालांकि, जब कुबेरनेट्स में ऐसा ही करने की कोशिश की जा रही हैक्लस्टर (यदि आपके पास पहले इसके साथ थोड़ा अनुभव था), एक विशिष्ट समापन बिंदु तक पहुँचने पर नियंत्रक "हैलो वर्ल्ड" का एक सरल लॉन्चिंग में आधा दिन लग सकता है। एक मोनोलिथ के मामले में, स्थिति सरल है। प्रत्येक डेवलपर के पास एक स्थानीय अनुप्रयोग सर्वर होता है। तैनाती की प्रक्रिया भी काफी सरल है - आपको अंतिम युद्ध / कान की कलाकृतियों को एप्लिकेशन सर्वर में मैन्युअल रूप से या आईडीई का उपयोग करके सही जगह पर कॉपी करने की आवश्यकता है । आमतौर पर यह कोई समस्या नहीं है।

डिबगिंग Nuances

दूसरा महत्वपूर्ण बिंदु डिबगिंग है । एक मोनोलिथ के साथ स्थितियों में, यह माना जाता है कि डेवलपर के पास अपनी मशीन पर एक एप्लिकेशन सर्वर है, जिस पर उसका युद्ध / कान तैनात है। आप हमेशा डिबग कर सकते हैं, क्योंकि आपको जो कुछ भी चाहिए वह हाथ में है। माइक्रोसर्विस के साथ, सब कुछ थोड़ा अधिक जटिल है, एक सेवा आमतौर पर अपने आप में एक चीज है। एक नियम के रूप में, उसकी अपनी डेटाबेस योजना है, जिसमें उसका डेटा स्थित है, उसके लिए विशिष्ट कार्य करता है, अन्य सेवाओं के साथ सभी संचार सिंक्रोनस HTTP कॉल (जैसे RestTemplate या Feign के माध्यम से), अतुल्यकालिक (जैसे Kafka या RabbitMQ) द्वारा आयोजित किया जाता है। इसलिए, एक निश्चित वस्तु को सहेजने या मान्य करने का अनिवार्य रूप से सरल कार्य जो पहले एक जगह पर लागू किया गया था, एक एकल युद्ध / कान फ़ाइल के अंदर, एक सामान्य मामले में एक माइक्रोसॉर्फ़ दृष्टिकोण के साथ, फॉर्म में प्रतिनिधित्व करने योग्य हो जाता है: एक या एन आसन्न सेवाओं पर जाएं, यह डेटा अधिग्रहण संचालन हो। , उदाहरण के लिए, कुछ संदर्भ मान, या आसन्न संस्थाओं को बचाने का संचालन,जिनकी डेटा को हमारी सेवा में व्यावसायिक तर्क करने के लिए आवश्यक है। इस मामले में व्यावसायिक तर्क लिखना अधिक कठिन हो जाता है।

तदनुसार, समाधान विकल्प निम्नानुसार हैं :

अपना व्यवसाय तर्क कोड लिखें। उसी समय, सभी बाहरी कॉलों का मजाक उड़ाया जाता है - बाहरी अनुबंधों का अनुकरण किया जाता है, परीक्षण इस धारणा के तहत लिखे जाते हैं कि बाहरी अनुबंध ठीक उसी तरह हैं, उसके बाद सत्यापन के लिए सर्किट में एक तैनाती होती है। कभी-कभी यह भाग्यशाली होता है, और एकीकरण तुरंत काम करता है, कभी-कभी यह अशुभ होता है - आपको व्यवसाय तर्क कोड को कई बार nth संख्या में फिर से करना होगा, क्योंकि उस समय के दौरान जब हमने कार्यक्षमता को लागू किया था, आसन्न सेवा में कोड अपडेट किया गया था, एपीआई विज्ञापन बदल गए और हमें इसे फिर से करना होगा। कार्य का एक हिस्सा इसके पक्ष में है।
. , , Kubernetes, . . , — , remote debug . , runtime , , . -, , 2–5 , . . , Kubernetes , . -, (Per thread), , .

Kubernetes

इस मुद्दे का एक समाधान, वास्तव में, टेलिप्रेसेंस है । इस तरह के शायद अन्य कार्यक्रम हैं, लेकिन व्यक्तिगत अनुभव केवल उसके साथ था, और उसने खुद को सकारात्मक रूप से स्थापित किया। सामान्य तौर पर, ऑपरेशन का सिद्धांत निम्नानुसार है:

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

Sudo telepresence (, Linux- , sudo . , root/). Kubernetes deployment telepresence . deployment Kubernetes.
आपकी सेवा की शुरुआत डेवलपर के स्थानीय कंप्यूटर पर हमेशा की तरह होती है। हालाँकि, इस मामले में, उसके पास कुबेरनेट्स क्लस्टर के पूरे बुनियादी ढांचे तक पहुंच होगी, चाहे वह सेवा डिस्कवरी (यूरेका, कंसल), आपी गेटवे (ज़ूल), काफ्का और इसकी कतारें हों, यदि कोई हो, आदि। यही है, वास्तव में, हमारे पास सभी क्लस्टर पर्यावरण की आवश्यकता है, लेकिन स्थानीय स्तर पर। बोनस स्थानीय डिबगिंग की संभावना है, लेकिन एक क्लस्टर वातावरण में, और यह पहले से ही बहुत तेज हो जाएगा, क्योंकि हम वास्तव में, कुबरनेट्स (सुरंग के माध्यम से) के अंदर हैं , और दूरदराज के बंदरगाह के लिए बंदरगाह के माध्यम से इसे बाहर से एक्सेस नहीं करते हैं।

इस समाधान के कई नुकसान हैं:

Telepresence Linux Mac, Windows VFS, , issue GitHub. . , - Linux/Mac, .
, Service Discovery (Eureka, Consul) — Round Robin , endpoint , , , :

kubernetes -> . telepresence deployment , «» Eureka ip-address:port/service-name dns-name:port/service-name , . . Kubernetes , timeout;
deployment - Kubernetes , ( ) (Round Robin), ;
endpoint, feature, HTTP 404 endpoint Gateway, Service Discovery , Round Robin . Service Discovery endpoint , HTTP 404.
, , .

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

eureka:
  instance:
    preferIpAddress: true
    metadata-map:
      service.label: develop

Service comvery में इस तरह की सेवा को com.netflix.appinfo.InstanceInfo # getMetadata में पंजीकृत करने के बाद मुख्य सेवा के साथ एक लेबल होगा। लैबल और मान विकसित होता है , जिसे रनटाइम में प्राप्त किया जा सकता है। एक सेवा शुरू करने के चरण में एक महत्वपूर्ण बिंदु यह जाँच कर रहा है कि सेवा कोलावरी में ऐसी कोई मेटा-जानकारी मौजूद है या नहीं, संभावित टकरावों से बचने के लिए।

रूटिंग विकल्प

उसके बाद, समस्या के समाधान को दो विकल्पों में घटाया जा सकता है:

API Gateway . , , , , Headers: DestionationService: feature/PRJ-001. , , Header . , — - API Gateway.
API Gateway, , . ., , , Zuul 1 endpoint- /api/users/… user, feature/PRJ-001, Zuul 2 endpoint- /api/users/… user, feature/PRJ-002. , N API Gateway N , . . , . . feature — , , , , , , . API Gateway, , . ., , , — , .

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

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

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

{
  "kind": "ConfigMap",
  "apiVersion": "v1",
  "metadata": {
    ...
  },  
"data": {
    ...        
    "rules.meta.user": "develop",
    "rules.meta.client": "develop",
    "rules.meta.notification": "feature/PRJ-010",
    ...    
  }
}

rules.meta सेवाओं के लिए रूटिंग नियमों से युक्त एक मानचित्र है।
उपयोगकर्ता / ग्राहक / अधिसूचना - उस सेवा का नाम जिसके तहत यह यूरेका के साथ पंजीकृत है।

विकसित / सुविधा / PRJ-010 - संबंधित सेवा के application.yml से सर्विस लेबल , जिसके आधार पर वांछित सेवा को सेवा डिस्कवरी से एक ही नाम के साथ सभी उपलब्ध सेवाओं के बीच चुना जाएगा , अगर ऐसी सेवा के एक से अधिक उदाहरण हैं।

निष्कर्ष

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

मुझे उम्मीद है कि यह सामग्री आपकी समस्या को हल करने में आपकी मदद करेगी। दिलचस्प कार्य और बग के बिना बेचते हैं!

वेब डेवलपमेंट में माइक्रोसर्विस डीबग करने पर दर्द और पीड़ा

ट्रांसेक्शनल डेटा अखंडता कैसे प्राप्त करें

डिबगिंग Nuances

Kubernetes

रूटिंग विकल्प

निष्कर्ष

More articles: