दोनों समानांतर MPI की तरह लगते हैं जो प्रक्रियाओं के नेटवर्क का संचार करते हैं। मैं सेवाओं के साथ अभिनेताओं की पहचान करता हूं। क्या अभिनेता अधिक गतिशील हैं (आप उन्हें बना सकते हैं और श्वास के रूप में मार सकते हैं जबकि सेवा नेटवर्क अधिक स्थिर है) या क्या?
जवाबों:
अभिनेता मॉडल - समवर्ती संगणना के लिए गणितीय मॉडल है, और माइक्रोसर्विसेज - सेवा-उन्मुख वास्तुकला का कार्यान्वयन। समानताएं काफी संयोग हैं।
यह निश्चित रूप से कुछ अभिनेता मॉडल के आधार पर microservices का निर्माण करने के लिए संभव है, और अभिनेता मॉडल के साथ कुछ microservice वास्तुकला मॉडल है, लेकिन इसका मतलब यह नहीं है कि यह समकक्ष हैं। "माइक्रोसॉफ़्ट सिस्टम" को "ईमेल सिस्टम" से बदलें, और यह अभी भी सच होगा। "कम्युनिकेटिंग अनुक्रमिक प्रक्रियाओं" (सीएसपी) के साथ "अभिनेता मॉडल" को बदलें, और यह "सच" भी होगा, क्योंकि सीएसपी और अभिनेता मॉडल सिस्टम एक-दूसरे द्वारा मॉडल किए जा सकते हैं।
अभिनेता मॉडल को देखते हुए आप माइक्रोसेर्विस, या एसओए, या यहां तक कि ईमेल का उपयोग करके इसे लागू कर सकते हैं, लेकिन इसका मतलब यह नहीं है कि वे वास्तव में तुलना करने के लिए अमूर्त के समान स्तर पर हैं।
इसके अलावा, अभिनेता मॉडल बफ़र्स पर जोर देता है (इसे माइक्रोसोर्विस की दुनिया में संदेश कतारों के रूप में सोचा जा सकता है), इसलिए कुछ अभिनेता / माइक्रोसिस्ट सेवा तैयार नहीं हो सकते हैं जबकि स्वाभाविक रूप से अतुल्यकालिक संचार अभी भी संभव है।
दूसरे शब्दों में, अभिनेता मॉडल के साथ तुलना कुछ बहुत ही उच्च स्तर के विचार पर कुछ रचनात्मक अंतर्दृष्टि ला सकती है, लेकिन ज्यादातर यह सेब बनाम संतरे हैं।
यदि लक्ष्य SOA / microservices के गणितीय मॉडल की तुलना अभिनेता मॉडल से करना है, तो यह भी तुच्छ नहीं है, क्योंकि: 1) SOA, 2) के लिए गणितीय मॉडल पर कोई सहमति नहीं है , मॉडल में आमतौर पर उद्देश्य शामिल होता है। और SOA / microservices मॉडलिंग अभिनेता मॉडल उद्देश्य से अलग होने की संभावना है। एसओए को यहां मॉडल करने के प्रयास का एक उदाहरण ।
बेशक, कोई माइक्रोसर्विस के साथ अभिनेता मॉडल प्रणाली बना सकता है और प्रत्येक सेवा को एक अभिनेता कह सकता है (अभिनेता मॉडल क्या है इसकी सख्त परिभाषा देखें)। लेकिन इसका मतलब यह नहीं है कि सामान्य अर्थों में दोनों के बीच कोई सार्थक संबंध है।
माइक्रोसर्विसेज चिंता के प्रत्येक क्षेत्र को अपनी स्वयं की तैनाती योग्य कलाकृतियों (निष्पादन योग्य, स्क्रिप्ट, JAR, WAR, आदि) में विभाजित करके सॉफ्टवेयर को व्यवस्थित करने का एक तरीका है। यह आपको लचीलापन देता है, उदाहरण के लिए आपको और उदाहरणों को तैनात करने की अनुमति देता है जहां वे आवश्यक हैं। यह कहें कि उपयोगकर्ता आपकी सूची को देखने में अधिक समय व्यतीत करते हैं, क्योंकि वे खरीदारी की गाड़ी में चीजों को जोड़ते हैं; एक तैनाती योग्य विरूपण साक्ष्य कैटलॉग फ़ंक्शंस संभालता है, दूसरा शॉपिंग कार्ट फ़ंक्शंस संभालता है - आप लोड को संभालने के लिए कैटलॉग सेवाओं की अधिक प्रतियां चला सकते हैं।
यह उन्हें आंतरिक परिवर्तनों से भी अलग करता है। मान लें कि आप किसी रिलेशनल डेटाबेस से डॉक्यूमेंट डेटाबेस में उत्पाद डेटा स्टोर करने के लिए जाते हैं - ऑड्स आपकी शॉपिंग कार्ट सेवाओं को बदलने की आवश्यकता नहीं होगी।
एक्टर मॉडल तैनाती योग्य विरूपण साक्ष्य से एक निम्न स्तर है, इस बारे में अधिक जानकारी है कि आपने किस प्रकार की वस्तुओं के साथ सेवा को लागू किया है। उपरोक्त उदाहरण के साथ जारी रखते हुए, आपके पास आपके सिस्टम में अभिनेताओं द्वारा प्रतिनिधित्व की गई शॉपिंग कार्ट हो सकती हैं, इसलिए प्रत्येक उपयोगकर्ता की कार्ट एक अलग अभिनेता है, और संदेश इसे आइटम जोड़ने, आइटम हटाने, वर्तमान सामग्री के साथ प्रतिक्रिया करने, शिपिंग जोड़ने, चेक आउट करने के लिए कहते हैं। , आदि इस मामले में, आपके पास अभी भी एक माइक्रोसेवा है, और यह अभिनेता मॉडल के साथ लागू किया गया है।
मैं कहूंगा कि मुख्य अंतर ग्रैन्युलैरिटी में से एक है।
अभिनेता मॉडल के लिए यह अपेक्षाकृत ठीक है, इसमें एक अभिनेता OOP में एक वस्तु के बराबर का प्रतिनिधित्व करता है।
सूक्ष्म सेवाओं के लिए यह अपेक्षाकृत मोटे होते हैं, जिनमें एक एकल सूक्ष्म सेवा में बड़ी संख्या में अभिनेता या ऑब्जेक्ट शामिल हो सकते हैं।
ध्यान दें कि आपको वास्तव में अपनी कल्पना को बहुत लंबा खींचने की आवश्यकता नहीं है कि आधुनिक वेब एक ही बड़ा ग्रैन्युलैरिटी ("मैक्रो-सर्विसेज") में एक ही बात है; और वह (जैसे) एक HTTP सर्वर एक मैक्रो-सेवा है, एक डेटाबेस सर्वर एक मैक्रो-सेवा है, एक वेब ब्राउज़र एक मैक्रो-सेवा है, आदि।
यह सभी लगभग एक ही अलग-थलग टुकड़े हैं जो संवाद करते हैं। यह केवल टुकड़ों का आकार है (और इसलिए टुकड़ों की संख्या) जो बदलते हैं।
कई प्रतिकृतियां बनाकर सूक्ष्म स्तर को क्षैतिज रूप से स्केल किया जाता है, जिनमें से प्रत्येक सेवा की स्टेटलेस प्रकृति के कारण अनुरोधों को पूरा करने में सक्षम है । वे अपने स्थिर स्वभाव के आधार पर असफलता के लिए लचीला हैं।
अभिनेता उन्हें कम लोड या अधिक उपलब्ध संसाधनों के साथ विभाजन में ले जाते हैं। वे स्टेटफुल हैं । वे विफलता के लिए लचीला हैं क्योंकि - अभिनेता के ढांचे के आधार पर - किसी अन्य अभिनेता को गतिशील रूप से काटा जा सकता है या प्राथमिक अभिनेता के असफल होने से निपटने के लिए हर समय अभिनेता का एक गर्म बैकअप बनाए रखा जा सकता है।
फिर से, microservices स्टेटफुल भी हो सकता है, लेकिन यह microservices के डिजाइन सिद्धांतों के खिलाफ जाता है।