Feathers: माइक्रोसर्विसेस: सेवाओं को विभाजित करके ऐप को रीफ़्रैक्टर करने का अनुशंसित तरीका?

आप सही हैं, अभी तक बहुत अधिक दस्तावेज नहीं हैं और हमने उस पर नज़र रखने के लिए थोड़ी देर पहले https://github.com/feathersjs/feathers/issues/157 बनाया। यहाँ मेरे दो विषयों पर आपके कुछ विचार हैं:

मान लें कि हमारे पास शुरू में दो सेवाओं वाला एक सर्वर है, शायद कुछ ऐसा है

app.use('/users', memory())
  .use('/todos', memory());

उपयोगकर्ता सेवा को एक सर्वर से अधिक ट्रैफ़िक मिल रहा है, इसलिए हम इसके लिए एक और ऐप बनाकर इसे दूसरे सिस्टम में ले जाना चाहते हैं:

// server1
app.use('/users', memory());
// server2
app.use('/todos', memory());

/todos सेवा के लिए अब दूरस्थ सेवा के साथ संवाद करने के लिए हम इसे कनेक्ट करने के लिए क्लाइंट के रूप में पंख का उपयोग कर सकते हैं (Websockets तेज़ और द्विदिश हैं इसलिए उन्हें सर्वर-से-सर्वर संचार के लिए उपयोग क्यों नहीं किया जाता?)?

// server2
const client = require('feathers/client')
const socketClient = require('feathers-socketio/client');
const io = require('socket.io-client');

const socket = io('http://other-server.com');
const otherApp = client().configure(socketClient(socket));

app.use('/todos', memory())
 .use('/users', otherApp.service('users'));

यह मूल रूप से एक वेबसोकेट कनेक्शन के माध्यम से उपयोगकर्ता सेवा को दूरस्थ सेवा में स्थानांतरित करेगा। मूल /users समापन बिंदु का उपयोग करके कुछ भी बदलना नहीं होगा।

प्रमाणीकरण के लिए, कई अलग-अलग विकल्प हैं। उपरोक्त परिदृश्य में server1 लिए सबसे आसान तरीका होगा अन्य सर्वरों के आईपी पते को server2 से अभी भी ग्राहकों के लिए संचार का एकमात्र बिंदु। अंततः server2 केवल एक गेटवे बन सकता है जो उपयोगकर्ता प्रमाणीकरण को संभालता है और फिर अन्य सर्वर के माध्यम से सेवा कॉल पास करता है (जो मूल आईपी पते की जांच के अलावा प्रमाणीकरण के बारे में चिंता करने की आवश्यकता नहीं है)।

जवाब के लिए धन्यवाद! क्या आप इस विषय को आधिकारिक डॉक्स (शायद गाइड का एक उप-भाग) पर कवर करने की योजना बना रहे हैं? मुझे बताएं कि क्या मैं इस संबंध में योगदान कर सकता हूं।

निश्चित रूप से। और हम निश्चित रूप से कुछ मदद का उपयोग कर सकते हैं। हो सकता है कि पहले हम एक गाइड में क्या देखना चाहते हैं और फिर कुछ डेमो एप्लिकेशन बनाएं?

💯 @ डफ्ल पर धमाका है। यह कुछ ऐसा है जिसे मैं अगले महीने आधिकारिक तौर पर निपटने की योजना बना रहा हूं या जैसा कि मैंने इस पर एक प्रस्तुति देने के लिए प्रतिबद्ध किया है।

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

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

पंखों के अनुप्रयोगों के रूप में @daffl @ekryski वितरित हो जाते हैं, हमें कम से कम-एक बार वितरण (acks), आलंबन, लेन-देन, बैकप्रेशर (कतारें), आदि जैसे मुद्दों पर ध्यान देना होगा। कार्यकर्ता? ”.. अर्थात। बाहरी प्रक्रियाएँ जो टिकाऊ अम्बप (अर्थात खरगोश) से घटनाओं का उपभोग करती हैं कतार (या क्यूई) का उपयोग करती हैं?

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

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

इस पर कोई प्रगति? मैं वास्तव में कुछ प्रलेखन / एक काम करने का उदाहरण देखना पसंद करूंगा। विशेष रूप से इस बात के संबंध में कि प्रमाणीकरण कैसे संभाला जाता है।

@ हम इस पर काम कर रहे हैं। मैंने उदाहरण के लिए काम करना शुरू किया और एक ऐप को विभाजित किया और हमने महसूस किया कि कुछ सीमाएँ हैं कि कैसे सेट अप किया जाता है। इसलिए हम वर्तमान में इसको बेहतर समर्थन देने के लिए पुन: निर्माण कर रहे हैं। भूमि के लिए लगभग एक सप्ताह होना चाहिए।

ओह यार, मैं अभी इतना बुरा इस्तेमाल कर सकता हूं: डी

जिज्ञासा से बाहर आप कई सामने के छोर के साथ भी काम करने के लिए काम कर रहे हैं? मुझे लगता है कि आजकल के कई बड़े ऐप बैकएंड पर एक माइक्रोसैस सर्विस का उपयोग करते हैं, लेकिन उनके फ्रंट-एंड ऐप्स को भी तोड़ देते हैं।

यदि आपके पास कुछ अतिरिक्त रुपये हैं, तो मुझे लगता है कि इस पुस्तक को पढ़ने की सिफारिश की जा सकती है: https://www.amazon.com/Building-Microservices-Sam-Newman/dp/1491950358/ref=sr_1_1 ? = = UTF8 & qid = 1469071253 & sr =? 8-1 और कीवर्ड = माइक्रोसिस्टम्स

दोस्तों, इस पर कोई अपडेट? धन्यवाद।

@ जुआनपुजोल नवीनतम जानकारी हमेशा इस टिकट में रहेगी। जाँच के लिए धन्यवाद, यद्यपि।

(यहाँ marcfawzi)

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

कुछ भी नहीं वास्तव में रोकता है, मैं कहूंगा कि यह आप पर है कि ऐसा न करें। यह वास्तव में केवल एक समस्या होगी यदि आप अपने मॉडल और संबंधों को ओआरएम स्तर पर परिभाषित करते हैं। मुझे नहीं लगता कि अन्य सेवाओं के लिए कॉल करके सेवा स्तर पर रिश्ते प्राप्त करना माइक्रोसेस्टर एब्सट्रैक्शन का उल्लंघन करता है।

हाँ बिल्कुल मेरा मतलब है। मुझे लगता है कि सेवाओं का अलगाव जहां प्रत्येक सेवा की अपनी डीबी है, ओआरएम स्तर पर सेवा इंटरफेस के माध्यम से रचना को मजबूर करने का एक निश्चित तरीका है।

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

बस मैंने सोचा था कि मैं यहां इसका उल्लेख करूंगा कि यह कुछ समस्याओं को हल करता है जो सूक्ष्म सेवाओं के वातावरण में पंख का उपयोग करने के साथ आती हैं। यह केवल पहला कार्यान्वयन है, लेकिन अगर आपके पास यहां मुफ्त में योगदान देने के लिए कुछ भी है तो https://github.com/zapur1/feathers-rabbitmq/issues/1

@ zapur1 जो आशाजनक लग रहा है ... मैंने चर्चा शुरू करने के लिए एक टिप्पणी पोस्ट की है

आप इन सभी को समन्‍वयित रखने के लिए सेवाओं के बीच संदेश दलालों के रूप में rabgMQ, Redis, या MongoDB के साथ https://github.com/feathersjs/feathers-sync का भी उपयोग कर सकते हैं।

@ekryski feathers-sync एक अलग समस्या का एक सा हल करता है, क्या होगा यदि आप केवल एक नामांकित सेवा के दायरे में एक बार प्राप्त होने वाली घटना चाहते हैं (एक पंख सेवा नहीं, बल्कि एक माइक्रोसिस्ट सेवा शैली)? यदि आपके पास एकल API ऐप से ईवेंट प्राप्त करने वाली एकल सेवा के कई उदाहरण हैं, तो प्रत्येक ईवेंट को उन क्रियाओं की डुप्लिकेट करने की संभावना प्राप्त होगी जो उस इवेंट को उसी कोड के कई इंस्टेंसेस में प्राप्त होने पर होती हैं।

@ekryski मैं बस एक बार फिर से रेपो और zapur1 / पंखों पर नजर

अगर मैं सॉकेटक्लाइंट द्वारा एक सेवा 1 को सेवा 2 से जोड़ता हूं, तो अगर मेरी सेवा 2 में बहु उदाहरण हैं, तो मैं लोड संतुलन कैसे लागू कर सकता हूं:

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

मैं इस पर https://github.com/kalisio/feathers-distributed के साथ अपने 2 सेंट जोड़ता हूं, इसका उद्देश्य विभिन्न सेवाओं को एक साथ रखने वाले एन पंख ऐप को तैनात करना है, ताकि आप प्रत्येक को स्वतंत्र रूप से विकसित कर सकें। यह https://github.com/feathersjs/feathers-sync से अलग है, जिसका उद्देश्य जहां तक ​​मेरी समझ में है, उतनी ही सेवाएं रखने वाले N f पंख ऐप को तैनात करना है। यह सब इस तरह के सवालों का एक सेट उठाता है:

• प्रमाणीकरण प्रबंधन
• एपीआई गेटवे और लोड संतुलन
• दूरस्थ हुक चालान
• ...

@ daffl उदाहरण पर, जिसमें आपने सर्वर 1 और सर्वर 2 को शामिल किया है, आप सर्वर 2 में /users सेवा को कैसे सुरक्षित करेंगे? यदि हमारे पास सर्वर 2 में परिभाषित की गई सेवा है, तो हम विशिष्ट सेवा हुक फ़ाइल में हुक का उपयोग कर सकते हैं, लेकिन जब से हम app.use('/users', otherApp.service('users')); कर रहे हैं, हम यह कैसे सुनिश्चित करेंगे कि सर्वर 2 से उस सेवा को कॉल केवल किया जाएगा। यदि उपयोगकर्ता पहले प्रमाणित है?

संपादित करें:
Nvm, मुझे लगता है कि मेरे पास एक विचार है: हम const usersService = app.service('users') और फिर usersService.hooks(hooks) कुछ ऐसा कर सकते हैं जहां हुक के लिए एंडपॉइंट को सुरक्षित करने के लिए हुक की आवश्यकता होती है?

मैंने इस बारे में और लिखा है कि कैसे वितरित प्रमाणीकरण https://stackoverflow.com/questions/41076627/evaluating-featherjs-authentication-needs/41095638#41095638 में किया जा सकता है:

सेवाओं को विभाजित करने के कई तरीके हैं जिनमें से प्रत्येक अपने फायदे और कमियां हैं। पंख के लिए एक आम तौर पर महत्वपूर्ण बात यह है कि कोई सत्र नहीं हैं, सिर्फ JSON वेब टोकन। JWTs स्टेटलेस होते हैं और इन्हें किसी भी सर्वर द्वारा पढ़ा जा सकता है जो एक ही सीक्रेट शेयर करता है इसलिए इसमें सेंट्रल सेशन स्टोर नहीं होना चाहिए। मेरे विचार से दो मुख्य विकल्प हैं:

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

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