पोर्ट बाइंडिंग http://12factor.net/port-binding पर 12 फैक्टर लेख में एक आवश्यकता है कि प्रत्येक ऐप स्वयं निहित हो और रनटाइम इंजेक्शन न हो। बिलाव। के लिए यह क्या कारण है ... माइक्रोस्कोप के लिए स्वयं निहित ऐप्स के फायदे क्या हैं?एक 12 फैक्टर ऐप स्वयं निहित क्यों होना चाहिए?
मुझे लगता है क्योंकि यह आपके ऐप को स्केल करने का समय आने पर आपको लचीलापन का एक बड़ा सौदा देता है। यदि आप टोमकैट का उपयोग करते हैं तो आपको अपने .war की प्रतिलिपि बनाना होगा और उसे किसी अन्य टोमकैट के अंदर छोड़ना होगा और फिर उनमें से किसी के लिए अपने अनुरोधों को संतुलित करना होगा।
इसके बजाय यदि आपके ऐप में स्वयं सर्वर http सर्वर है, तो आप केवल एक अन्य बंदरगाह में एक और उदाहरण चलाते हैं और उस टॉमकैट सामान को भूल जाते हैं। आपको अभी भी अपने ऐप उदाहरणों में से किसी एक को अपने अनुरोधों को संतुलित करना होगा, लेकिन अधिक सीधे आगे लगता है।
पोर्ट बाध्यकारी और स्वयं निहित ऐप्स के आसपास नियमों को समझने के लिए, Heroku या Deis जैसे 12-कारक ऐप्स चलाने के लिए डिज़ाइन किए गए प्लेटफॉर्म के परिप्रेक्ष्य से चीजों को देखने में मददगार है।
ये प्लेटफ़ॉर्म प्रक्रिया स्तर पर अनुप्रयोग स्केल कर रहे हैं। जब प्रक्रियाओं को बढ़ाया जाता है, तो मंच इन अतिरिक्त श्रमिकों को रूटिंग जाल के पीछे रखने की कोशिश करता है ताकि वे यातायात की सेवा शुरू कर सकें। यदि ऐप स्वयं निहित नहीं है और, उदाहरण के लिए, mod_jk का उपयोग कर फ्रंट-एंड अपाचे सर्वर से कसकर जोड़ दिया गया है - अधिक पृथक कार्यकर्ता प्रक्रियाओं को चलाकर स्केल करना संभव नहीं है।
प्लेटफार्म स्तर पर "पोर्ट ब्रोकिंग" की समस्या को हल करने के लिए पोर्ट बाध्यकारी मौजूद है। यदि पोर्ट 80 पर सुनाई गई प्रत्येक एप्लिकेशन कर्मचारी वहां संघर्ष करेंगे। इसे हल करने के लिए, पोर्ट बाइंडिंग एक सम्मेलन है जिससे एप्लिकेशन पोर्ट को आवंटित पोर्ट पर सुनता है - और जिसे $PORT पर्यावरण चर के रूप में पास किया जाता है। यह सुनिश्चित करता है कि) एप्लिकेशन कार्यकर्ता सही बंदरगाह पर सुनता है और बी) मंच जानता है कि उस कार्यकर्ता के लिए निर्धारित यातायात को रूट करना है।
आप अपनी सेवा का पर्दाफाश करने के लिए एम्बेडेड टॉमकैट या एम्बेडेड जेटी का उपयोग कर सकते हैं –