Yii ढांचे के आधार पर स्तरित वास्तुकला

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

ऐसे वातावरण के अच्छे उदाहरण हैं यैंडेक्स (खोज, प्रत्यक्ष, नक्शे, मेल, ऊर्ध्वाधर और आंतरिक सेवाएं) या Google। यह स्पष्ट है कि सूचीबद्ध दिग्गजों के पास प्रत्येक उत्पाद में प्रौद्योगिकियां हैं, लेकिन अगर हम एक छोटी कंपनी लेते हैं और एक संकीर्ण विषय क्षेत्र में काम करते हैं, तो हम यह मान सकते हैं कि वेब उत्पादों को एक ही प्रौद्योगिकियों (प्रोग्रामिंग भाषाओं, रूपरेखाओं आदि) पर निष्पादित किया जाएगा।

यह ऐसी कंपनी के संपूर्ण उत्पाद लाइन की वास्तुकला को व्यवस्थित करने के अनुभव के बारे में है जिसे मैं बताना चाहता हूं।

हमारे बाहरी वेब उत्पाद एक ऑनलाइन संस्करण , एक खुला संदर्भ एपीआई और एक कार्टोग्राफिक, फीडबैक सेवा हैं । आंतरिक: सीआरएम, बिलिंग, एल्गोरिथम गणना, सांख्यिकी प्रणाली और
निर्यात-आयात डेटा।

हम दो अवधारणाएँ प्राप्त करते हैं:

वेब इन्फ्रास्ट्रक्चर - कंपनी के वेब उत्पादों का एक समूह, परस्पर संबंधित क्षेत्रों में काम करना।

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

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

• परियोजनाओं के बीच मॉड्यूल और घटकों का पुन: उपयोग;
• संपूर्ण प्रणाली को फिर से लिखने के बिना पहले से ही लिखे गए मॉड्यूल की कार्यक्षमता की व्यापकता;
• एकीकृत उत्पाद परिनियोजन योजना;
• स्केलेबिलिटी लोड करें।

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

• पीएचपी;
• आवेदन की रूपरेखा - yii;
• परिनियोजन और अनुप्रयोग परिनियोजन के लिए रूपरेखा - फ़िंग;
• इकाई परीक्षण लिखने के लिए रूपरेखा - phpUnit;
• निरंतर एकीकरण प्रणाली - जेनकींस;
• कार्यात्मक और UI परीक्षण - सेलेनियम;
• DBMS पोस्टग्रेज;
• की-वैल्यू स्टोरेज मेमस्कैक्ड, रेडिस;
• nginx वेब सर्वर।

(हमने इन प्रणालियों को क्यों चुना, हम चर्चा नहीं करेंगे, यह एक अलग प्रकाशन के लिए एक विषय है।)

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

• प्रत्येक परत पर बाद की (उच्चतर) परतों के गुणों (और यहां तक ​​कि अस्तित्व) के बारे में कुछ भी ज्ञात नहीं है;
• प्रत्येक परत पूर्ववर्ती इंटरफ़ेस के माध्यम से तुरंत पूर्ववर्ती (निचली) परत के साथ नियंत्रण (एक्सेस घटकों) को इंटरैक्ट कर सकती है, पिछली सभी परतों की आंतरिक संरचना के बारे में कुछ भी नहीं जानती;
• प्रत्येक परत के पास कुछ संसाधन होते हैं जो या तो अन्य परतों से छिपते हैं, या अपने कुछ सार को सीधे अगली परत (निर्दिष्ट इंटरफ़ेस के माध्यम से) प्रदान करते हैं।

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

नेटवर्क और सर्वर पर विचार किए बिना, जो स्वयं में अलग-अलग परतें हैं, हम डिवाइस तकनीकी प्लेटफॉर्म पर विचार करते हैं। इसमें तीन परतों को प्रतिष्ठित किया जा सकता है:


अंजीर। 1. प्रौद्योगिकी मंच वास्तुकला की परतें

अंजीर में। 1, तीन परतों पर प्रकाश डाला गया है:

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

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

आइए हम एप्लिकेशन परत में एप्लिकेशन के फ़ाइल संगठन पर अधिक विस्तार से विचार करें, yii की बारीकियों को ध्यान में रखते हुए।

  आवेदन
 	 ढांचा - यहां ढांचा तैनात है
 	 लिबर - कोर और साझा से घटक।  Yii कॉन्फिग में इस फोल्डर के लिए अलग उपनाम		
		 घटकों
		 एक्सटेंशन
		 ...
	 संरक्षित
		 घटकों
		 एक्सटेंशन
		 ...
	 सार्वजनिक
	 विषयों
	 config

आंकड़ा 2. फ़ाइल संगठन yii अनुप्रयोगों

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

इसलिए, हम अपने वेब इन्फ्रास्ट्रक्चर के लिए एक लचीला आधार निर्धारित करते हैं, लेकिन क्या यह पर्याप्त है? नहीं। दो महत्वपूर्ण बातें याद आ रही हैं:

• आवेदन वास्तुकला कमजोर रूप से जाली और साझा किया जाना चाहिए;
• तैनाती प्रणाली और उत्पाद विधानसभा।

अब प्रत्येक आइटम के लिए और अधिक विस्तार से।

अनुप्रयोग वास्तुकला

एप्लीकेशन आर्किटेक्चर भी परतों पर आधारित होगा। हम निम्नलिखित स्तरों को अलग करते हैं:

चित्रा 3. yii आवेदन के परतें

पतली नियंत्रकों की परत में न्यूनतम तर्क होता है और यह एक्सटेंशन एपीआई पर काम करता है। व्यापार तर्क परत में विस्तार परत और डेटा मॉडल परत शामिल हैं। Yii एक्सटेंशन और डेटा मॉडल की परत में कनेक्टिविटी की बहुत मजबूत डिग्री है, यह आरेख में मोटा तीर द्वारा दिखाया गया है।

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

कॉन्फ़िगरेशन घटकों और एक्सटेंशन के सेट को जोड़ता है जो हमें चाहिए। एक्सटेंशन जोड़ने का एक उदाहरण:

'जियोइप' => एरे ( 'क्लास' => 'एप्लीकेशन . टेक्सटेश.जीओआईपी.सीजीओआईपी ' ) ,

एप्लिकेशन में प्रारंभिक एक्सटेंशन को जियोइप कुंजी का उपयोग करके एक्सेस किया जा सकता है। उदाहरण के लिए:

Yii :: $ ऐप -> जियोइप ;

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

इस लचीलेपन के आधार पर, हम आसानी से एप्लिकेशन और व्यावसायिक तर्क की परत के बीच कनेक्टिविटी का प्रबंधन कर सकते हैं।

एक्सटेंशन में एक निश्चित एप्लिकेशन सार के साथ काम करने के तर्क को समूहीकृत करके, हम इसे अलग करते हैं। सभी मॉडलों को इस प्रकार विस्तार में समझाया जाता है और एप्लिकेशन कंट्रोलर एक्सटेंशन एपीआई के माध्यम से डेटा के साथ काम करता है।

एक्सटेंशन हमारे लिए एक अतिरिक्त स्तर का अमूर्त हिस्सा है, जिसके पीछे हम विभिन्न एक्सटेंशन एपीआई विधियों के आंतरिक कार्य के लिए आवश्यक डेटा स्रोतों को छिपा सकते हैं।

आइए थोड़ा कल्पना करें और एक आवेदन के साथ आएं:


चित्रा 4. उदाहरण yii आवेदन वास्तुकला

हमारा एप्लिकेशन कई एक्सटेंशन के साथ काम करता है। एक्सटेंशन एक डेटासेट पर काम करते हैं और मॉडल परत के साथ निकटता से संबंधित हैं। एक महत्वपूर्ण बिंदु: शहद की परतों के बीच संबंध की सीमा ऊपर से नीचे तक बढ़ जाती है। डेटा मॉडल सबसे अधिक निकटता से संबंधित हैं।

अब आइए कल्पना करें कि सभी उत्पादों के लिए एक एकल उपयोगकर्ता प्राधिकरण सेवा बनाने की आवश्यकता थी। हम इस तरह की परियोजना को एक अलग आवेदन के रूप में आसानी से लागू कर सकते हैं। नए एप्लिकेशन के साथ काम करने के लिए, हम एक्सटेंशन लिखते हैं - बाकी क्लाइंट UserServiceRestClient। ग्राहक के पास उसी API का होगा जो UserExtension API का है। हम स्पष्टता के लिए तस्वीर को देखते हैं:


अंजीर। 5

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

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

तैनाती और विधानसभा प्रणाली

तैनाती प्रणाली क्या करना चाहिए:

• सर्वर पर निर्दिष्ट निर्देशिका को कोड वितरित करें;
• सभी आवेदन निर्भरता (साझा स्तर के एक्सटेंशन और ढांचे) को ऊपर खींचें;
• एप्लिकेशन कॉन्फ़िगरेशन उत्पन्न करें;
• SQL डेटाबेस माइग्रेशन निष्पादित करें।

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

सामान्य तौर पर, कार्य सामान्य होते हैं: फ़ाइल संचालन, संस्करण नियंत्रण प्रणालियों के साथ काम करना, तीसरे पक्ष के उपयोगिताओं (PHPUnit, उदाहरण के लिए, या Doxygen) को लॉन्च करना, आदि। ध्यान पीढ़ी को कॉन्फ़िगर करने के लिए भुगतान किया जाना चाहिए। हमने इसे मेटा-कॉन्फ़िगरेशन फ़ाइल के साथ टेम्पलेट के अनुसार बनाया है:

  आवेदन
	 संरक्षित
		 config
		 main.php.template - yii config टेम्प्लेट
	 सार्वजनिक
	 विषयों
	 build.prop - मेटा कॉन्फ़िगरेशन फ़ाइल
	 build.xml - फिंग कॉन्फिग 

अंजीर। 6

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

## एक्सटेंशन, घटकों और आदि की सूची ## स्थापित करने के लिए
उदाहरण = myExt, myExt2
घटक = घटक 1, घटक 2
HELPERS = myHeper, myTextHelper
कमांड =

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

इस प्रकार, मेटा-कॉन्फ़िगरेशन फ़ाइल हमारे आवेदन में कॉन्फ़िगरेशन के प्रारूप और संख्या से अमूर्तता की एक परत है।

नतीजतन, Yii कॉन्फ़िगरेशन लचीलापन + बिल्ड सिस्टम = आसानी से कॉन्फ़िगर करने योग्य और इकट्ठे उत्पादों।

परिणाम

तो, वर्ष के दौरान इस तरह की कार्य योजना का उपयोग करने का हमें क्या अनुभव रहा?

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

पुनश्च और हाँ, हम नोवोसिबिर्स्क और कीव में yii- डेवलपर्स के लिए देख रहे हैं । साथ आओ! :-)