सर्विस गवर्नेंस पर क्यों बात करनी चाहिए?
इंटरनेट की बढ़ती लोकप्रियता के साथ, पारंपरिक एमवीसी वास्तुकला अधिक से अधिक फूली हुई है और बनाए रखना बहुत मुश्किल है क्योंकि अनुप्रयोगों के पैमाने का विस्तार जारी है।
हमें व्यावसायिक विशेषताओं के अनुसार एक बड़ी प्रणाली को कई अनुप्रयोगों में विभाजित करने के लिए कार्रवाई करने की आवश्यकता है। उदाहरण के लिए, एक बड़ी ई-कॉमर्स प्रणाली में उपयोगकर्ता प्रणाली, उत्पाद प्रणाली, आदेश प्रणाली, मूल्यांकन प्रणाली आदि शामिल हो सकते हैं, और हम उन्हें कई व्यक्तिगत अनुप्रयोगों में अलग कर सकते हैं। मल्टी-एप्लिकेशन आर्किटेक्चर की विशेषताएं स्वतंत्र रूप से चलने वाले अनुप्रयोग हैं और वे एक-दूसरे को कॉल करने में असमर्थ हैं।
हालाँकि कई अनुप्रयोग फूला हुआ अनुप्रयोग की समस्या को हल करते हैं, फिर भी अनुप्रयोग एक दूसरे से स्वतंत्र होते हैं और सामान्य सेवाओं या कोडों का पुन: उपयोग नहीं किया जा सकता है।
आधिकारिक लिंक
एक बड़ी इंटरनेट प्रणाली के लिए, इसमें आमतौर पर सामान्य सेवाओं के साथ कई अनुप्रयोग होते हैं, और प्रत्येक अनुप्रयोग में एक दूसरे के बीच कॉल संबंध होते हैं। इसके अलावा, बड़े पैमाने पर इंटरनेट प्रणाली के लिए अन्य चुनौतियां हैं, जैसे कि तेजी से बढ़ते उपयोगकर्ताओं से कैसे निपटें, सिस्टम के विकास को जल्दी से व्यवस्थित करने के लिए आर एंड डी टीमों का प्रबंधन कैसे करें, सिस्टम को स्थिर तरीके से अपग्रेड कैसे रखें, और इसी तरह।
इसलिए, सेवाओं का अच्छी तरह से पुन: उपयोग करने और आसानी से विस्तार करने के लिए मॉड्यूल बनाए रखने के लिए। हम चाहते हैं कि सेवाओं को एप्लिकेशन से अलग किया जाए। एक सेवा अब एक आवेदन में नहीं है, लेकिन एक अलग सेवा के रूप में बनी हुई है। एप्लिकेशन स्वयं अब एक फूला हुआ मॉड्यूल स्टैक नहीं है, बल्कि एक मॉड्यूलर सेवा घटक है।
Servitization
विशेषताएं
तो "सेवाकरण" का उपयोग करने की विशेषता क्या है?
- व्यवसायों द्वारा सेवाओं में एक अनुप्रयोग विभाजित होता है
- व्यक्तिगत सेवा को स्वतंत्र रूप से तैनात किया जा सकता है
- सेवा को कई अनुप्रयोगों द्वारा साझा किया जा सकता है
- सेवाओं में एक दूसरे के बीच संचार हो सकता है
- प्रणाली की वास्तुकला अधिक स्पष्ट है
- कोर मॉड्यूल स्थिर हैं, और इकाइयों में सेवा घटकों के उन्नयन से लगातार नए रिलीज के जोखिम से बचा जा सकता है
- विकास और प्रबंधन के लिए आसान
- व्यक्तिगत टीम द्वारा स्पष्ट कार्य प्रवाह और जिम्मेदारियों के साथ रखरखाव किया जा सकता है
- सेवाओं का पुन: उपयोग, कोड का पुन: उपयोग
- विस्तार करना बहुत आसान है
सर्विसिंग की चुनौती
सिस्टम सेवाकरण के बाद, सिस्टम की निर्भरता जटिल है, और सेवाओं के बीच बातचीत की संख्या बढ़ जाती है। fpm के विकास मोड में, क्योंकि निवासी मेमोरी प्रदान नहीं की जा सकती है, प्रत्येक अनुरोध को शून्य से शुरू करना चाहिए, प्रक्रिया से बाहर निकलने के लिए एक प्रक्रिया शुरू करने के लिए, बहुत सारे बेकार ओवरहेड जोड़कर। इसके अलावा, डेटाबेस कनेक्शन का पुन: उपयोग नहीं किया जा सकता है और इसे संरक्षित नहीं किया जा सकता है क्योंकि fpm प्रक्रिया-आधारित है और fpm प्रक्रिया की संख्या भी समवर्ती की संख्या निर्धारित करती है। ये fpm विकास के सरल द्वारा हमें दी गई समस्याएं हैं। तो, यही कारण है कि .NET और PHP तुलना में इंटरनेट प्लेटफ़ॉर्म में Java अब अधिक लोकप्रिय है। PHP non-memory resident , कई अन्य मुद्दों पर ध्यान देने की आवश्यकता है।
- अधिक सेवाएं, कॉन्फ़िगरेशन प्रबंधन की अधिक जटिलता
- जटिल सेवा निर्भरता
- सेवाओं के बीच लोड संतुलन
- सेवा विस्तार
- सेवा की निगरानी
- सेवा में गिरावट
- सेवा प्रमाणीकरण
- सेवा ऑनलाइन और ऑफलाइन
- सेवा प्रलेखन
......
आप उन लाभों की कल्पना कर सकते हैं जो निवासी स्मृति हमारे लिए लाती है।
केवल प्रोसेसिंग शुरू करने पर ही हम फ्रेमवर्क इनिशियलाइज़ेशन शुरू कर सकते हैं क्योंकि फ्रेमवर्क को केवल एक बार निवासी मेमोरी में स्टार्टअप पर मेमोरी में इनिशियलाइज़ किया जा सकता है
कनेक्शन मल्टीप्लेक्सिंग , कुछ इंजीनियरों को समझ नहीं आ रहा है कि क्या कनेक्शन पूल का उपयोग नहीं किया जा रहा है, हर अनुरोध के लिए कनेक्शन बनाने का परिणाम क्या है? यह कनेक्शन में बहुत अधिक बैकएंड संसाधन का कारण बनता है। कुछ बुनियादी सेवाओं के लिए, जैसे कि रेडिस, डेटाबेस, कनेक्शन एक महंगी नाली हैं।
तो, क्या कोई अच्छा उपाय है? इसका उत्तर हां में है, और कई लोग Swoft नामक ढांचे का उपयोग कर रहे हैं। Swoft एक RPC फ्रेमवर्क है जो Service Governance सुविधा के साथ है। Swoft पहली PHP निवासी मेमोरी Swoft फुल-स्टैक फ्रेमवर्क है, जो Spring Boot की मुख्य अवधारणा के आधार पर, कॉन्फ़िगरेशन से अधिक है।
Swoft RPC सेवाओं का उपयोग करने के लिए एक अधिक सुरुचिपूर्ण तरीका प्रदान करता है जैसे Swoft और Swoft में Swoft प्रदर्शन के समान शानदार प्रदर्शन है। यहां मेरे PC में होने वाले Swoft प्रदर्शन का तनाव परीक्षण परिणाम है।
ab स्ट्रेस टेस्ट में प्रोसेसिंग स्पीड बहुत ही अद्भुत है। i7 generation 8 CPU और 16GB मेमोरी के साथ, 100000 अनुरोध केवल 5s उपयोग करते हैं। मूल रूप से fpm विकास मोड में हासिल करने के लिए समय असंभव है। परीक्षण भी उच्च प्रदर्शन और Swoft स्थिरता को प्रदर्शित करने के लिए पर्याप्त है।
सुरुचिपूर्ण सेवा शासन
माइक्रोसर्विस गवर्नेंस प्रोसेस में, थर्ड-पार्टी क्लस्टर्स, जैसे कि कौंसुल / वल्ड, से शुरू की गई सेवाओं का पंजीकरण अक्सर शामिल होता है। यह अध्याय सेवा पंजीकरण और खोज को लागू करने के लिए Swoft के ढांचे में Swoft-consul घटक का उपयोग करता है।
कार्यान्वयन तर्क
<?php declare(strict_types=1); namespace App\Common; use ReflectionException; use Swoft\Bean\Annotation\Mapping\Bean; use Swoft\Bean\Annotation\Mapping\Inject; use Swoft\Bean\Exception\ContainerException; use Swoft\Consul\Agent; use Swoft\Consul\Exception\ClientException; use Swoft\Consul\Exception\ServerException; use Swoft\Rpc\Client\Client; use Swoft\Rpc\Client\Contract\ProviderInterface; class RpcProvider implements ProviderInterface { private $agent; public function getList(Client $client): array {
एक वितरित वातावरण में, विशेष रूप से माइक्रोसोसवर्क वास्तुकला की एक वितरित प्रणाली, एक सॉफ्टवेयर सिस्टम के लिए दूसरे दूरस्थ सिस्टम को कॉल करना बहुत आम है। इस तरह के रिमोट कॉल की तसल्ली एक और प्रक्रिया या नेटवर्क में एक और होस्ट हो सकती है। इस दूरस्थ कॉल और प्रक्रिया की आंतरिक कॉल के बीच सबसे बड़ा अंतर यह है कि दूरस्थ कॉल विफल या लटका हो सकता है। टाइमआउट तक कोई प्रतिक्रिया नहीं। इससे भी बदतर, अगर एक ही निलंबित सेवा को कॉल करने वाले कई कॉलर्स हैं, तो यह बहुत संभावना है कि किसी सेवा का टाइमआउट पूरी तरह से वितरित सिस्टम में फैलता है, जिससे एक श्रृंखला प्रतिक्रिया होती है जो पूरे वितरित संसाधनों में बड़ी मात्रा में संसाधनों का उपभोग करती है। आखिरकार, यह सिस्टम पक्षाघात का कारण बन सकता है।
सर्किट ब्रेकर मोड वितरित सिस्टम में इस तरह के झरना जैसी श्रृंखला प्रतिक्रियाओं के कारण होने वाली आपदाओं को रोकने के लिए डिज़ाइन किया गया है।
बुनियादी सर्किट ब्रेकर मोड में, यह सुनिश्चित करने के लिए आपूर्तिकर्ता को नहीं बुलाया जाता है कि सर्किट ब्रेकर खुले राज्य में है, लेकिन हमें आपूर्तिकर्ता फिर से शुरू होने के बाद सर्किट ब्रेकर को रीसेट करने के लिए अतिरिक्त विधि की भी आवश्यकता है। एक संभावित समाधान यह है कि सर्किट ब्रेकर समय-समय पर पता लगाता है कि क्या आपूर्तिकर्ता की सेवा फिर से शुरू हो गई है। एक बार फिर से शुरू होने के बाद, स्थिति बंद होने के लिए तैयार है। राज्य एक आधा खुला राज्य है जब सर्किट ब्रेकर पुन: प्रयास करता है।
फ्यूज का उपयोग सरल और शक्तिशाली है। इसे @Breaker साथ एनोटेट किया जा सकता है। Swoft का फ्यूज किसी भी परिदृश्य में उपयोग किया जा सकता है, जैसे कि एक सेवा कहा जाता है। तृतीय पक्ष सेवा का अनुरोध करने पर इसे डाउनग्रेड किया जा सकता है या नहीं बुलाया जा सकता है।
<?php declare(strict_types=1); namespace App\Model\Logic; use Exception; use Swoft\Bean\Annotation\Mapping\Bean; use Swoft\Breaker\Annotation\Mapping\Breaker; class BreakerLogic { public function loop(): string {
फ्लो प्रतिबंध, सर्किट ब्रेकर, सेवा डाउनग्रेड इन पर बार-बार जोर दिया जा सकता है क्योंकि ये वास्तव में महत्वपूर्ण हैं। जब सेवा काम नहीं कर रही है, तो इसे तोड़ना होगा। प्रवाह प्रतिबंध स्वयं को बचाने के लिए एक उपकरण है। यदि कोई स्व-सुरक्षा तंत्र नहीं है और कनेक्शन प्राप्त नहीं किए गए हैं तो वे कितने भी हों, सामने का अंत निश्चित रूप से तब लटका होगा जब ट्रैफ़िक बहुत बड़ा हो, जबकि बैक-एंड सभी कनेक्शनों को नहीं संभाल सकता।
प्रवाह प्रतिबंध समवर्ती संसाधनों की संख्या को सीमित करने और अनुरोधों की संख्या को सीमित करने के लिए है, जैसे कि फ्लैश बिक्री के सामान, ताकि प्रभावी रूप से चोटी काट सकें और प्रवाह वक्र को चिकना कर सकें। प्रवाह प्रतिबंध का उद्देश्य समवर्ती पहुंच और समवर्ती अनुरोधों की दर को सीमित करना है, या सिस्टम की सुरक्षा के लिए समय की एक खिड़की के भीतर अनुरोध की गति को सीमित करना है। एक बार दर की सीमा पार हो जाने या अधिक हो जाने पर, अनुरोधों को अस्वीकार या पंक्तिबद्ध किया जा सकता है।
Swoft के प्रवाह प्रतिबंध की निचली परत टोकन बाल्टी एल्गोरिथ्म का उपयोग करती है, और अंतर्निहित परत वितरित प्रवाह प्रतिबंध को लागू करने के लिए Swoft पर निर्भर करती है।
स्विफ्ट प्रवाह प्रतिबंध न केवल नियंत्रकों को सीमित करता है, यह किसी भी बीन में विधियों को भी सीमित करता है और विधियों की पहुंच दर को नियंत्रित करता है। निम्नलिखित उदाहरण विस्तार से व्याख्या है।
<?php declare(strict_types=1); namespace App\Model\Logic; use Swoft\Bean\Annotation\Mapping\Bean; use Swoft\Limiter\Annotation\Mapping\RateLimiter; class LimiterLogic { public function requestLimiter2(Request $request): array { $uri = $request->getUriPath(); return ['requestLimiter2', $uri]; } public function limiterFallback(Request $request): array { $uri = $request->getUriPath(); return ['limiterFallback', $uri]; } }
यह symfony/expression-language अभिव्यक्ति का समर्थन करता है। यदि गति सीमित है, तो fallback में परिभाषित limiterFallback विधि को कहा जाएगा।
इससे पहले कि हम कॉन्फ़िगरेशन केंद्र के बारे में बात करते हैं, चलो कॉन्फ़िगरेशन फ़ाइल के बारे में बात करते हैं। हम इसके लिए कोई अजनबी नहीं हैं। यह हमें कार्यक्रम को गतिशील रूप से संशोधित करने की क्षमता प्रदान करता है। किसी से एक उद्धरण है:
सिस्टम रनटाइम की उड़ान रवैया का गतिशील समायोजन!
मैं तेजी से उड़ने वाले हवाई जहाजों पर भागों की मरम्मत के लिए हमारे काम को बुला सकता हूं। हम मनुष्य हमेशा सब कुछ नियंत्रित करने और भविष्यवाणी करने में असमर्थ हैं। हमारी प्रणाली के लिए, हमें सिस्टम की दिशा (जैसे ग्रे नियंत्रण, प्रवाह प्रतिबंध समायोजन) को नियंत्रित करने के लिए कुछ नियंत्रण रेखाओं को समायोजित करने की आवश्यकता होती है, जो बदलावों को अपनाने वाले इंटरनेट उद्योग के लिए विशेष रूप से महत्वपूर्ण है।
स्टैंड-अलोन संस्करण के लिए, हम इसे कॉन्फ़िगरेशन (फ़ाइल) कहते हैं; वितरित क्लस्टर प्रणाली के लिए, हम इसे कॉन्फ़िगरेशन केंद्र (सिस्टम) कहते हैं;
वास्तव में एक वितरित कॉन्फ़िगरेशन केंद्र क्या है?
व्यवसाय के विकास और माइक्रो-सर्विस आर्किटेक्चर के उन्नयन के साथ, सेवाओं की संख्या और कार्यक्रमों का कॉन्फ़िगरेशन बढ़ रहा है (विभिन्न माइक्रो-सर्विसेज, विभिन्न सर्वर पते, विभिन्न पैरामीटर), और पारंपरिक कॉन्फ़िगरेशन फ़ाइल विधि और डेटाबेस विधि कॉन्फ़िगरेशन प्रबंधन में डेवलपर्स की जरूरतों को पूरा नहीं कर सकते:
- सुरक्षा: कॉन्फ़िगरेशन कोड बेस में संग्रहीत स्रोत कोड का अनुसरण करता है, जो कॉन्फ़िगरेशन लीक का कारण बनना आसान है;
- समयबद्धता: कॉन्फ़िगरेशन को संशोधित करें और प्रभावी होने के लिए सेवा को पुनरारंभ करें।
- सीमाएं: गतिशील समायोजन का समर्थन नहीं किया जा सकता है: उदाहरण के लिए, लॉग स्विच, फ़ंक्शन स्विच;
इसलिए, हमें कॉन्फ़िगरेशन को प्रबंधित करने के लिए केंद्र को कॉन्फ़िगर करने की आवश्यकता है! व्यवसाय डेवलपर्स को जटिल और बोझिल विन्यास से मुक्त करना, उन्हें केवल व्यवसाय कोड पर ही ध्यान केंद्रित करने की आवश्यकता है, जो विकास और परिचालन दक्षता में काफी सुधार कर सकता है। इसी समय, पैकेज का कॉन्फ़िगरेशन और रिलीज़, रिलीज़ की सफलता की दर को और बढ़ा देगा, और ऑपरेशन और रखरखाव की ठीक धुन नियंत्रण और आपातकालीन संचालन के लिए मजबूत समर्थन प्रदान करेगा।
वितरित कॉन्फ़िगरेशन केंद्रों के बारे में, वेब पर कई खुले स्रोत समाधान हैं, जैसे:
अपोलो एक वितरित विन्यास केंद्र है जो Ctrip के फ्रेमवर्क विभाग द्वारा विकसित किया गया है। यह विभिन्न वातावरणों और अनुप्रयोगों के विभिन्न समूहों के विन्यास को केंद्रीय रूप से प्रबंधित कर सकता है। इसे कॉन्फ़िगरेशन संशोधन के बाद वास्तविक समय में एप्लिकेशन के अंत तक धकेल दिया जा सकता है। इसमें मानकीकृत प्राधिकरण और प्रक्रिया प्रबंधन की विशेषताएं हैं, और यह माइक्रोसॉफ़्ट विन्यास और प्रबंधन के परिदृश्यों के लिए उपयुक्त है।
यह अध्याय Apollo का उपयोग कॉन्फ़िगरेशन को खींचने और दूरस्थ कॉन्फ़िगरेशन केंद्र से पुनरारंभ सेवाओं को सुरक्षित करने के लिए एक उदाहरण के रूप में करता है। यदि आप Apollo अपरिचित हैं, तो आप सबसे पहले Swoft एक्सटेंशन Apollo घटक को देख सकते हैं और Apollo आधिकारिक दस्तावेज पढ़ सकते हैं।
यह अध्याय एक उदाहरण के रूप में Swoft में Apollo का उपयोग करता है। जब Apollo कॉन्फ़िगरेशन बदलता है, तो सेवा (http-server / rpc-server / ws-server) को पुनरारंभ करें। निम्नलिखित एक एजेंट का एक उदाहरण है:
<?php declare(strict_types=1); namespace App\Model\Logic; use Swoft\Apollo\Config; use Swoft\Apollo\Exception\ApolloException; use Swoft\Bean\Annotation\Mapping\Bean; use Swoft\Bean\Annotation\Mapping\Inject; class ApolloLogic { private $config; public function pull(): void { $data = $this->config->pull('application');
ऊपर एक सरल अपोलो कॉन्फ़िगरेशन पुल है, इस विधि के अलावा, Swoft-Apollo उपयोग करने के लिए और अधिक तरीके प्रदान करता है।
आधिकारिक लिंक