गो टू गो! कैसे PHP टीम microservices लिखने के लिए ले लिया

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

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

हमारे सिस्टम में एक ऑर्डर में संबंधित घटक होते हैं: एक डिलीवरी यूनिट और एक टोकरी, छूट और भुगतान इकाइयाँ होती हैं, और सबसे अंत में एक बटन होता है जो वेयरहाउस में एकत्रित किए जाने के लिए ऑर्डर भेजता है। यह इस समय है कि ऑर्डर प्रोसेसिंग सिस्टम का काम शुरू होता है, जहां सभी ऑर्डर डेटा को मान्य किया जाएगा और जानकारी एकत्र की जाएगी।

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

स्थापत्य विरासत

जैसा कि मैंने पहले ही कहा, हमारी टीम के गठन के समय, ऑर्डर प्रोसेसिंग सिस्टम एक मोनोलिथ था - कोड की लगभग 100 हजार लाइनें जो सीधे व्यापारिक तर्क का वर्णन करती थीं। मुख्य भाग को क्लासिक मल्टी-लेयर MVC आर्किटेक्चर का उपयोग करके 2011 में लिखा गया था। यह PHP (ZF1 फ्रेमवर्क) पर आधारित था, जिसे धीरे-धीरे विभिन्न सेवाओं के साथ बातचीत के लिए एडेप्टर और सिम्फनी घटकों के साथ उखाड़ दिया गया था। अपने अस्तित्व के दौरान, सिस्टम में 50 से अधिक योगदानकर्ता थे, और यद्यपि हम कोड लिखने की एक एकीकृत शैली को बनाए रखने में कामयाब रहे, इसने इसकी सीमाएं भी लागू कीं। इसके अलावा, मिश्रित संदर्भों की एक बड़ी संख्या उत्पन्न हुई - विभिन्न कारणों से, कुछ तंत्र प्रणाली में लागू किए गए थे जो सीधे आदेश प्रसंस्करण से संबंधित नहीं थे। यह सब इस तथ्य को जन्म देता है कि इस समय हमारे पास 1 टेराबाइट से बड़ा एक MySQL डेटाबेस है।

योजनाबद्ध रूप से, प्रारंभिक वास्तुकला को निम्नानुसार दर्शाया जा सकता है:

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

इसलिए, हमने ऑर्डर प्रोसेसिंग सिस्टम से कस्टमर ऑर्डर के संदर्भ को एक अलग माइक्रोसॉर्क्स में स्थानांतरित करने का फैसला किया, जिसे ऑर्डर मैनेजमेंट कहा जाता था।

आवश्यकताएँ और उपकरण

उस संदर्भ को निर्धारित करने के बाद, जिसे हमने पहली जगह में मोनोलिथ से हटाने का फैसला किया था, हमने अपनी भविष्य की सेवा के लिए आवश्यकताओं का गठन किया:

• उत्पादकता
• डेटा संगति
• स्थिरता
• पूर्वानुमान
• पारदर्शिता
• परिवर्तन की वृद्धि

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

नतीजतन, हम एक निश्चित संरचना में आए, जिसका उपयोग हम सभी नए माइक्रोसर्विसेस में करते हैं:

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

मौजूदा बुनियादी ढांचे और उपकरण। लामोदा में गो को लागू करने की शुरुआत करने वाली हम पहली टीम नहीं हैं; हमसे पहले पायनियर थे - गो टीम ही, जिसने इंफ्रास्ट्रक्चर तैयार किया:

1. गोगी (स्वैगर) एक स्वैगर स्पेसिफिकेशन जनरेटर है।
2. गोनकी (परीक्षण) - कार्यात्मक परीक्षणों के लिए।
3. हम Json-rpc का उपयोग करते हैं और स्वैगर द्वारा एक क्लाइंट / सर्वर बाइंडिंग उत्पन्न करते हैं। हम यह सब कुबेरनेट्स के लिए भी तैनात करते हैं, प्रोमेथियस में मेट्रिक्स इकट्ठा करते हैं, ट्रेसिंग के लिए ईएलके / जैगर का उपयोग करते हैं - यह सब उस बंडल में शामिल है जिसे विनिर्देश द्वारा प्रत्येक नए माइक्रोसॉर्क्स के लिए बनाया जाता है।

यह हमारा नया ऑर्डर प्रबंधन माइक्रोसेवा जैसा दिखता है:

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

प्रतिमान बदलाव

गो चुनना, हमें तुरंत कई फायदे हुए:

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

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

1. अमूर्तता के निर्माण पर गो कठिन है।
2. गो को ऑब्जेक्ट-बेस्ड कहा जा सकता है, लेकिन ऑब्जेक्ट-ओरिएंटेड भाषा नहीं, क्योंकि प्रत्यक्ष विरासत और कुछ अन्य चीजें नहीं हैं।
3. गो अमूर्तता के पीछे वस्तुओं को छिपाने के बजाय स्पष्ट रूप से लिखने में मदद करता है।
4. गो में पाइपलाइनिंग है। इसने हमें डेटा प्रोसेसर चेन बनाने के लिए प्रेरित किया।

परिणामस्वरूप, हमें समझ में आया कि गो एक प्रक्रियात्मक प्रोग्रामिंग भाषा है।

पहले डेटा

मैं सोच रहा था कि जिस समस्या का हम सामना कर रहे हैं उसकी कल्पना कैसे करें और इस तस्वीर के सामने आए:

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

हमने इस दृष्टिकोण को छोड़ दिया, और पहले स्थान पर संस्थाओं को डाल दिया, बिना सार के अस्पष्ट हो गए।

इस तरह से तर्क करना, हमने पहले स्थान पर डेटा डाला, और इस तरह की पाइपलाइन सेवा में प्राप्त की:

प्रारंभ में, हम एक डेटा मॉडल को परिभाषित करते हैं जो हैंडलर पाइपलाइन में प्रवेश करता है। डेटा परिवर्तनशील है, और परिवर्तन क्रमिक और संक्षिप्त रूप से दोनों हो सकते हैं। इसके साथ, हम गति में जीतते हैं।

वापस भविष्य के लिए

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

हम अनुक्रम / चयन / साक्षात्कार का भी उपयोग करते हैं - एक संरचनात्मक प्रोग्रामिंग प्रतिमान जिसके अनुसार सभी प्रोग्राम कोड संबंधित नियंत्रण संरचनाओं से बना हो सकते हैं।

खैर, प्रक्रियात्मक प्रोग्रामिंग, जो 70 के दशक में मुख्यधारा थी :)

परियोजना की संरचना

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

नतीजतन, हमारे पास एक सपाट वास्तुकला है: एक छोटा एपीआई परत प्लस डेटा मॉडल। और सभी तर्क (जो हमारे संदर्भ में एक microservice की व्यावसायिक आवश्यकताओं द्वारा सीमित है) प्रोसेसर (हैंडलर) में संग्रहीत किया जाता है।

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

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

इस प्रकार, सेवा के प्रोसेसर में आंतरिक एपीआई के लिए, इंटरैक्शन किसी भी तरह से नहीं बदलता है।

स्थिरता

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

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

गो टू गो!

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

हमारा मुख्य कार्य सेवा की स्थिरता को बढ़ाना था। बेशक, गो केवल बॉक्स के बाहर बढ़ी हुई स्थिरता प्रदान नहीं करता है। लेकिन, मेरी राय में, गो पारिस्थितिकी तंत्र में, तीसरे पक्ष के पुस्तकालयों का सहारा लिए बिना, अपने हाथों से भी सभी आवश्यक विश्वसनीयता किट बनाना आसान हो गया।

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

क्या हम गो पर पूरी तरह से सब कुछ फिर से लिखने और PHP को त्यागने जा रहे हैं?

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