वेब एप्लिकेशन के लिए अलग एपीआई और यूआई सर्वर का उपयोग करने के लाभ


17

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

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

  • सिस्टम सेटअप करने का तरीका यह है कि हमारे पास एक मुख्य वेब एप्लिकेशन (asp.net, AngularJS) है जो ज्यादातर विभिन्न अन्य सेवाओं से डेटा एकत्र करता है। तो मूल रूप से यह एक AngularJS आवेदन के लिए एक मेजबान है; शाब्दिक रूप से एक MVC नियंत्रक है जो क्लाइंट साइड को बूटस्ट्रैप करता है, और फिर हर दूसरा नियंत्रक एक WebAPI नियंत्रक है।

  • क्लाइंट-साइड से कॉल को इन नियंत्रकों द्वारा नियंत्रित किया जाता है, जो हमेशा उन बॉक्सों पर तैनात होते हैं जो वेब एप्लिकेशन को होस्ट करने के अलावा कुछ भी नहीं करते हैं। वर्तमान में हमारे पास 4 ऐसे बॉक्स हैं।

  • हालाँकि, कॉल को अंततः WebAPI अनुप्रयोगों के एक और सेट के माध्यम से रूट किया जाता है (आमतौर पर ये प्रति व्यावसायिक क्षेत्र, जैसे कि सुरक्षा, ग्राहक डेटा, उत्पाद डेटा, आदि)। इन सभी WebAPI को एक साथ समर्पित बक्से में भी तैनात किया जाता है; हमारे पास इनमें से 4 बॉक्स भी हैं।

  • एक एकल अपवाद के साथ, इन WebAPI का उपयोग हमारे संगठन के किसी अन्य भाग द्वारा नहीं किया जाता है।

  • अंत में ये वेबएपीआई "बैक एंड" सेवाओं के लिए कॉल का एक और सेट बनाते हैं, जो आम तौर पर विभिन्न ईआरपी सिस्टम और डेटा स्टोर (जिनके ऊपर हमारा कोई नियंत्रण नहीं है) के शीर्ष पर थप्पड़ मारना asmx या wcf सेवाएँ हैं।

  • हमारे अधिकांश एप्लिकेशन का व्यावसायिक तर्क इन WebApis में है, जैसे कि विरासत डेटा को बदलना, इसे एकत्र करना, व्यावसायिक नियमों को निष्पादित करना, सामान्य प्रकार की बात।

मुझे उलझन में है कि WebApplication और इसे सेवा देने वाले WebAPI के बीच ऐसा अलगाव होने के क्या संभावित लाभ हैं। चूंकि कोई भी उनका उपयोग नहीं कर रहा है, मुझे कोई स्केलेबिलिटी लाभ नहीं दिखता है (अर्थात बढ़ा हुआ लोड संभालने के लिए किसी अन्य 4 एपीआई बॉक्स में डालने का कोई मतलब नहीं है, क्योंकि एपीआई सर्वर पर लोड बढ़ने का मतलब यह होना चाहिए कि वेब सर्वर पर लोड बढ़ गया है - इसलिए Api सर्वर के लिए वेब सर्वर का 1: 1 अनुपात होना चाहिए)

  • मुझे अतिरिक्त HTTP कॉल ब्राउज़र => HTTP => WebApp => HTTP => WebAPI => HTTP => बैकएंड सेवाएं बनाने में कोई लाभ नहीं दिखता है। (WebApp और WebAPI के बीच HTTP कॉल मेरी समस्या है)

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

  • तैनाती-वार, इसका मतलब है कि हमारे पास 4 + 4 के विपरीत 8 "पूर्ण स्टैक" वेब बॉक्स होंगे।

नए दृष्टिकोण के जो लाभ मुझे दिखाई दे रहे हैं

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

तो सवाल यह है: क्या मैं गलत हूं? क्या मुझे अलग किए गए WebApplication और WebAPI बक्से के कुछ मौलिक "जादू" याद हैं?

मैंने कुछ एन-टियर आर्किटेक्चर सामग्री पर शोध किया है, लेकिन उनमें से कुछ भी ऐसा प्रतीत नहीं हो सकता है जो हमारी स्थिति के लिए एक ठोस लाभ दे सके (क्योंकि स्केलेबिलिटी एक मुद्दा नहीं है जहां तक ​​मैं बता सकता हूं, और यह एक आंतरिक ऐप है WebAPI अनुप्रयोगों के संदर्भ में सुरक्षा कोई समस्या नहीं है।)

और यह भी, अगर मैं अपने प्रस्तावित सेटअप में सिस्टम को फिर से व्यवस्थित करने के लिए लाभ के संदर्भ में क्या खो रहा हूं?


यदि सभी 8 बक्से वास्तव में आपके नियंत्रण में हैं, तो मैं अलग होने के किसी भी अच्छे कारण के बारे में नहीं सोच सकता। क्या आप जानते हैं कि अतीत में उनका अलग स्वामित्व था?
Ixrec

@Ixrec - हाँ सभी 8 बॉक्स संगठन के हैं, और आवेदन केवल 100% आंतरिक है। मुझे संदेह है कि अलगाव को मूल रूप से डिजाइन किया गया था क्योंकि एक अन्य आंतरिक समूह के पास बुनियादी ढांचे (बहुत सारी राजनीति) का स्वामित्व था और आंशिक रूप से क्योंकि किसी ने कहा कि "एन-टीयर" और हर कोई बस इसके साथ चला गया।
स्टीफन ब्रेन

जवाबों:


25

एक कारण सुरक्षा है - अगर (हाहा! जब ) एक हैकर आपके फ्रंट-एंड वेबसर्वर तक पहुंच प्राप्त करता है, तो उसे हर उस चीज तक पहुंच मिलती है, जिसकी पहुंच उसके पास है। यदि आपने अपना मिडिल टियर वेब सर्वर में रखा है, तो उसके पास वह सब कुछ है जो आपके पास है - यानी आपका DB, और अगली बात जो आप जानते हैं, वह आपके DB पर "सिलेक्ट * यूजर्स" को चलाएगा और इसे ऑफलाइन से दूर ले जाएगा। पासवर्ड क्रैकिंग।

एक और कारण स्केलिंग है - वेब टियर जहां पृष्ठों का निर्माण किया जाता है और मंगाई जाती है और एक्सएमएल संसाधित होता है और वह सब मध्य टियर की तुलना में बहुत अधिक संसाधन लेता है जो अक्सर डीबी से वेब टियर के डेटा प्राप्त करने की एक कुशल विधि है। वेब सर्वर पर रहने वाले (या कैश्ड) रहने वाले सभी स्थैतिक डेटा को स्थानांतरित करने का उल्लेख नहीं है। अधिक वेब सर्वर जोड़ना एक आसान काम है जो आपको पिछले 1 में मिला है। वेब और लॉजिक स्तरों के बीच 1: 1 का अनुपात नहीं होना चाहिए - मैंने अब से पहले 8: 1 देखा है (और एक 4: 1 लॉजिक के बीच का अनुपात tier और DB)। यह निर्भर करता है कि आपके टीयर हालांकि क्या करते हैं और उनमें कितना कैशिंग होता है।

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

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


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

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

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

2

मुझे लगता है कि यहां कोई सही / गलत जवाब नहीं है। क्या आपने अपने आर्किटेक्चर से इस वास्तुकला के उद्देश्य के बारे में पूछा है?

मैं आपके विवरण को कैसे समझ सकता हूं, आपके आर्किटेक्चर में " वेबएपीआई " स्वयं निर्मित मिडलवेयर के रूप में कार्य करता है। अब आप शोध कर सकते हैं कि किसी मिडलवेयर के उपयोग में क्या फायदे हैं। मूल रूप से यदि आपके बैकऑफ़िस सिस्टम (जब तक वेबएपीआई इंटरफ़ेस समान रहता है) को बदल देने पर आपके वेबएप्प को अपनाने की आवश्यकता नहीं होगी ।

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

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


प्रतिक्रिया के लिए धन्यवाद, अंतिम बैक-एंड सेवाओं का उपयोग पूरे संगठन द्वारा किया जाता है, और अच्छी तरह से परिभाषित किया गया है (यदि थोड़ा सा सरलीकृत) WCF सेवा अनुबंध जो संगठन का मालिक है। इसलिए यदि हमें बैक-एंड (जो वास्तव में, हम करने की प्रक्रिया में हैं, एक ईआरपी से दूसरे में जा रहे हैं) को बदलने की आवश्यकता है, तो बहुत कुछ अप्रत्यक्ष है। लेकिन मेरा मुद्दा हमारे एप्लिकेशन के साथ है जो कि केवल इसके द्वारा उपभोग किए जाने वाले मिडिलवेयर HTTP एपिस का एक अलग सेट प्रदान करता है। ऐसा लगता है जैसे एक स्तरीय बहुत अधिक :)
स्टीफन बर्न
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.