कुछ पाठकों ने शायद पहले सेंट्रीफ्यूगो के बारे में सुना होगा। यह आलेख सर्वर के दूसरे संस्करण के विकास पर और गो भाषा के लिए नए रीयल-टाइम लाइब्रेरी पर ध्यान केंद्रित करेगा जो इसे रेखांकित करता है।

मेरा नाम अलेक्जेंडर एमेलिन है। पिछली गर्मियों में, मैं एविटो टीम में शामिल हो गया, जहां मैं अब एविटो मैसेंजर बैकएंड को विकसित करने में मदद कर रहा हूं। नया काम, सीधे उपयोगकर्ताओं को संदेशों की त्वरित डिलीवरी से संबंधित है, और नए सहयोगियों ने मुझे ओपन-सोर्स सेंट्रीफुगो परियोजना पर काम करना जारी रखने के लिए प्रेरित किया।

संक्षेप में - यह एक सर्वर है जो आपके एप्लिकेशन के उपयोगकर्ताओं से निरंतर कनेक्शन रखने का कार्य करता है। Websocket या SockJS पॉलीफ़िल का उपयोग परिवहन के रूप में किया जाता है; यह, यदि Websocket कनेक्शन स्थापित करना संभव नहीं है, तो Eventource, XHR- स्ट्रीमिंग, लंबे समय से मतदान और अन्य HTTP- आधारित परिवहन के माध्यम से काम कर सकते हैं। ग्राहक उन चैनलों की सदस्यता लेते हैं जिनमें सेंट्रीफ़्यूज एपीआई के माध्यम से बैकएंड उठते ही नए संदेश प्रकाशित करता है - जिसके बाद उन संदेशों को चैनल में सब्सक्राइब किए गए उपयोगकर्ताओं तक पहुँचाया जाता है। दूसरे शब्दों में, यह PUB / SUB सर्वर है।

वर्तमान में, सर्वर का उपयोग काफी बड़ी संख्या में परियोजनाओं में किया जाता है। उनमें से, उदाहरण के लिए, कुछ Mail.Ru प्रोजेक्ट्स (इंट्रानेट, टेक्नोपार्क / टेक्नोस्फीयर ट्रेनिंग प्लेटफॉर्म्स, सर्टिफिकेशन सेंटर, आदि) हैं, सेंट्रीफुगो की मदद से, एक सुंदर डैशबोर्ड, दफ्तर मॉस्को में रिसेप्शन पर काम करता है, और 350 हजार उपयोगकर्ता एक साथ स्पॉट से जुड़े हैं। अपकेंद्रित्र करने के लिए।

सर्वर पर पिछले लेख के कुछ लिंक और उन लोगों के लिए इसका आवेदन जो पहले प्रोजेक्ट के बारे में सुनते हैं:

• सेंट्रीफ्यूगो में गोता लगाएँ ,
• सेंट्रीफ्यूगो - 3.5 मिलियन आरपीएम ,
• साथ ही परियोजना के इतिहास और इसके स्वरूप के लिए प्रेरणा के बारे में बता रहे अंग्रेजी में एक लेख ।

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

गो के लिए वास्तविक समय पुस्तकालय

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

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

मैं इस तरह के पुस्तकालय के अस्तित्व के एक और प्लस को सही ठहराने की कोशिश करूंगा। अधिकांश सेंट्रीफ्यूगो उपयोगकर्ता डेवलपर्स हैं जो कमजोर संगामिति समर्थन (उदाहरण के लिए, Django / फ्लास्क / लारवेल / ...) के साथ भाषाओं / चौखटों में एक बैकेंड लिखते हैं: यदि संभव हो तो, एक असंबद्ध या अक्षम तरीके से बहुत सारे लगातार कनेक्शन के साथ काम करने के लिए। तदनुसार, सभी उपयोगकर्ता गो में लिखे गए सर्वर के विकास में मदद नहीं कर सकते (भाषा के ज्ञान की कमी के कारण कॉर्न)। इसलिए, लाइब्रेरी के आसपास गो डेवलपर्स का एक बहुत छोटा समुदाय भी इसका उपयोग करके सेंट्रीफुगो सर्वर को विकसित करने में मदद कर सकेगा।

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

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

• अपकेंद्रित्र - गो भाषा के लिए एक पुस्तकालय,
• सेंट्रीफ्यूगो एक टर्नकी समाधान है, एक अलग सेवा, जो संस्करण 2 में सेंट्रीफ्यूज लाइब्रेरी पर बनाई जाएगी।

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

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

आप हमेशा की तरह चला सकते हैं:

git clone https://gist.github.com/2f1a38ae2dcb21e2c5937328253c29bf.git cd 2f1a38ae2dcb21e2c5937328253c29bf go get -u github.com/centrifugal/centrifuge go run main.go 

और फिर http: // localhost: 8000 पर जाएं , कई ब्राउज़र टैब खोलें।

जैसा कि आप देख सकते हैं, आवेदन के व्यापार तर्क के लिए प्रवेश बिंदु On().Connect() होता है On().Connect() कॉलबैक फ़ंक्शन:

 node.On().Connect(func(ctx context.Context, client *centrifuge.Client, e centrifuge.ConnectEvent) centrifuge.ConnectReply { client.On().Disconnect(func(e centrifuge.DisconnectEvent) centrifuge.DisconnectReply { log.Printf("client disconnected") return centrifuge.DisconnectReply{} }) log.Printf("client connected via %s", client.Transport().Name()) return centrifuge.ConnectReply{} }) 

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

यह एक बहुत ही सरल उदाहरण है जो पुस्तकालय की सभी विशेषताओं को प्रदर्शित नहीं करता है। कोई यह नोट कर सकता है कि ऐसे उद्देश्यों के लिए वेबसोकेट के साथ काम करने के लिए पुस्तकालय लेना आसान है। उदाहरण के लिए, गोरिल्ला वेबसैट। यह वास्तव में ऐसा है। हालांकि, इस मामले में भी, आपको गोरिल्ला वेबसोकेट रिपॉजिटरी में उदाहरण से सर्वर कोड का एक सभ्य टुकड़ा कॉपी करना होगा। क्या होगा अगर:

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

अपकेंद्रित्र पुस्तकालय इसमें आपकी मदद कर सकता है - वास्तव में, यह उन सभी बुनियादी विशेषताओं को विरासत में मिला है जो पहले सेंट्रीफ्यूगो में उपलब्ध थे। ऊपर बताए गए बिंदुओं को दिखाने वाले अधिक उदाहरण गिथूब पर पाए जा सकते हैं।

सेंट्रीफ्यूगो की मजबूत विरासत एक माइनस हो सकती है, क्योंकि पुस्तकालय ने सभी सर्वर यांत्रिकी को अपनाया है, जो काफी मूल हैं और, शायद, किसी के लिए अनावश्यक सुविधाओं के साथ अस्पष्ट या अतिभारित हो सकते हैं। मैंने कोड को इस तरह से व्यवस्थित करने का प्रयास किया कि अप्रयुक्त सुविधाओं ने समग्र प्रदर्शन को प्रभावित नहीं किया।

पुस्तकालय में कुछ अनुकूलन हैं जो संसाधनों के अधिक कुशल उपयोग की अनुमति देते हैं। यह लिखें सिस्टम कॉल पर सहेजने के लिए एक वेबसोकेट फ्रेम में कई संदेशों को जोड़ रहा है या, उदाहरण के लिए, प्रोटोगुफ संदेश और अन्य को अनुक्रमित करने के लिए गोगोप्रोटोबॉफ़ का उपयोग करना। प्रोटोबॉफ़ की बात कर रहे हैं।

बाइनरी प्रोटॉब प्रोटोकॉल

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

मुझे लगता है कि आपको लंबे समय तक यह बताने की जरूरत नहीं है कि जेएसएन - कॉम्पैक्टनेस, क्रमबद्धता गति, सख्त स्कीम पर प्रोटोबॉफ के क्या फायदे हैं। अवैधता के रूप में एक खामी है, लेकिन अब उपयोगकर्ताओं के पास यह तय करने का अवसर है कि किसी विशेष स्थिति में उनके लिए अधिक महत्वपूर्ण क्या है।

सामान्य तौर पर, JSON के बजाय Protobuf का उपयोग करते समय Centrifugo प्रोटोकॉल द्वारा उत्पन्न ट्रैफ़िक ~ 2 गुना (एप्लिकेशन डेटा को छोड़कर) घटाना चाहिए। मेरे सिंथेटिक लोड परीक्षणों में CPU खपत JSON की तुलना में एक ही ~ 2 गुना कम हो गया। ये संख्या वास्तव में क्या बात करती है, व्यवहार में, सब कुछ एक विशेष एप्लिकेशन के लोड प्रोफाइल पर निर्भर करेगा।

रुचि के लिए, मैंने डेबियन 9.4 और 32 Intel® Xeon® प्लेटिनम 8168 सीपीयू @ 2.70GHz vCPU बेंचमार्क के साथ एक मशीन लॉन्च की, जिसने हमें JB प्रोटोकॉल और Protobuf प्रोटोकॉल का उपयोग करने के मामले में क्लाइंट-सर्वर इंटरैक्शन की बैंडविड्थ की तुलना करने की अनुमति दी। 1 चैनल के 1000 ग्राहक थे। इस चैनल में, संदेश 4 धाराओं में प्रकाशित किए गए और सभी ग्राहकों को वितरित किए गए। प्रत्येक संदेश का आकार 128 बाइट्स था।

JSON के लिए परिणाम:

 $ go run main.go -s ws://localhost:8000/connection/websocket -n 1000 -ns 1000 -np 4 channel Starting benchmark [msgs=1000, msgsize=128, pubs=4, subs=1000] Centrifuge Pub/Sub stats: 265,900 msgs/sec ~ 32.46 MB/sec Pub stats: 278 msgs/sec ~ 34.85 KB/sec [1] 73 msgs/sec ~ 9.22 KB/sec (250 msgs) [2] 71 msgs/sec ~ 9.00 KB/sec (250 msgs) [3] 71 msgs/sec ~ 8.90 KB/sec (250 msgs) [4] 69 msgs/sec ~ 8.71 KB/sec (250 msgs) min 69 | avg 71 | max 73 | stddev 1 msgs Sub stats: 265,635 msgs/sec ~ 32.43 MB/sec [1] 273 msgs/sec ~ 34.16 KB/sec (1000 msgs) ... [1000] 277 msgs/sec ~ 34.67 KB/sec (1000 msgs) min 265 | avg 275 | max 278 | stddev 2 msgs 

Protobuf मामले के लिए परिणाम:

 $ go run main.go -s ws://localhost:8000/connection/websocket?format=protobuf -n 100000 -ns 1000 -np 4 channel Starting benchmark [msgs=100000, msgsize=128, pubs=4, subs=1000] Centrifuge Pub/Sub stats: 681,212 msgs/sec ~ 83.16 MB/sec Pub stats: 685 msgs/sec ~ 85.69 KB/sec [1] 172 msgs/sec ~ 21.57 KB/sec (25000 msgs) [2] 171 msgs/sec ~ 21.47 KB/sec (25000 msgs) [3] 171 msgs/sec ~ 21.42 KB/sec (25000 msgs) [4] 171 msgs/sec ~ 21.42 KB/sec (25000 msgs) min 171 | avg 171 | max 172 | stddev 0 msgs Sub stats: 680,531 msgs/sec ~ 83.07 MB/sec [1] 681 msgs/sec ~ 85.14 KB/sec (100000 msgs) ... [1000] 681 msgs/sec ~ 85.13 KB/sec (100000 msgs) min 680 | avg 680 | max 685 | stddev 1 msgs 

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

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

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

JSON वेब टोकन (JWT)

Centrifugo के रूप में इस तरह के एक स्टैंडअलोन सर्वर का उपयोग करने के साथ समस्याओं में से एक यह है कि यह आपके उपयोगकर्ताओं और उनके प्रमाणीकरण विधि के बारे में कुछ भी नहीं जानता है, और आपके बैकएंड किस प्रकार के सत्र तंत्र का उपयोग करता है। और आपको किसी तरह कनेक्शन को प्रमाणित करने की आवश्यकता है।

ऐसा करने के लिए, पहले संस्करण में सेंट्रीफ्यूज, कनेक्ट करते समय, SHA-256 HMAC हस्ताक्षर का उपयोग किया गया था, जो केवल बैकएंड और सेंट्रीफ्यूज के लिए ज्ञात एक गुप्त कुंजी पर आधारित था। यह सुनिश्चित करता है कि ग्राहक द्वारा प्रेषित उपयोगकर्ता आईडी वास्तव में उसी की है।

शायद कनेक्शन मापदंडों का सही हस्तांतरण और एक टोकन की पीढ़ी परियोजना में सेंट्रीफ्यूगो को एकीकृत करने में मुख्य कठिनाइयों में से एक थी।

जब सेंट्रीफ्यूज दिखाई दिया, JWT मानक अभी तक इतना लोकप्रिय नहीं था। अब, कुछ साल बाद, JWT पीढ़ी के लिए पुस्तकालय अधिकांश लोकप्रिय भाषाओं के लिए उपलब्ध हैं । जेडब्ल्यूटी का मुख्य विचार बिल्कुल वही है जो अपकेंद्रित्र की जरूरत है: प्रेषित डेटा की प्रामाणिकता की पुष्टि। HMAC के दूसरे संस्करण में, मैन्युअल रूप से जेनरेट किए गए हस्ताक्षर ने JWT के उपयोग का रास्ता दिया। इससे विभिन्न भाषाओं के लिए पुस्तकालयों में टोकन की सही पीढ़ी के लिए सहायक कार्यों के लिए समर्थन की आवश्यकता को दूर करना संभव हो गया।

उदाहरण के लिए, पायथन में, सेंट्रीफ्यूगो से जुड़ने के लिए एक टोकन निम्नानुसार उत्पन्न किया जा सकता है:

 import jwt import time token = jwt.encode({"user": "42", "exp": int(time.time()) + 10*60}, "secret").decode() print(token) 

यह ध्यान रखना महत्वपूर्ण है कि यदि आप सेंट्रीफ्यूज लाइब्रेरी का उपयोग करते हैं, तो आप उपयोगकर्ता को मूल गो विधि का उपयोग करके प्रमाणित कर सकते हैं - मिडलवेयर के अंदर। उदाहरण भंडार में हैं।

GRPC

विकास के दौरान, मैंने क्लाइंट और सर्वर के बीच संचार के लिए परिवहन के रूप में GRPC द्विदिश स्ट्रीमिंग की कोशिश की (वेबसोकेट और HTTP- आधारित SockJS कमबैक के अलावा)। मैं क्या कह सकता हूं? उसने काम किया। हालाँकि, मुझे ऐसा एक भी परिदृश्य नहीं मिला, जहाँ द्विदिशीय GRPC स्ट्रीमिंग वेबसोकेट से बेहतर होगी। मैंने मुख्य रूप से सर्वर मेट्रिक्स पर ध्यान दिया: नेटवर्क इंटरफेस के माध्यम से उत्पन्न ट्रैफ़िक, सीपीयू की खपत सर्वर द्वारा बड़ी संख्या में आने वाले कनेक्शन, प्रति कनेक्शन मेमोरी खपत।

जीआरपीसी सभी तरह से वेबसोकेट से हार गया:

• जीआरपीसी समान परिदृश्य में 20% अधिक यातायात उत्पन्न करता है,
• जीआरपीसी 2-3 गुना अधिक सीपीयू खपत करता है (कनेक्शन के कॉन्फ़िगरेशन के आधार पर - सभी को विभिन्न चैनलों की सदस्यता दी जाती है या सभी को एक चैनल के लिए सदस्यता लिया जाता है,)
• जीआरपीसी प्रति कनेक्शन 4 गुना रैम का उपभोग करता है। उदाहरण के लिए, 10k कनेक्शन पर, Websocket सर्वर ने 500Mb मेमोरी और GRPC - 2Gb खाया।

परिणाम काफी ... अपेक्षित थे। सामान्य तौर पर, जीआरपीसी में, एक ग्राहक परिवहन के रूप में, मैंने बहुत समझदारी नहीं दिखाई - और कोड को एक स्पष्ट विवेक के साथ हटा दिया, जब तक, शायद, बेहतर समय।

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

ग्राहकों के साथ कठिनाइयाँ

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

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

मैंने हाल ही में मोज़िला से एमओएसएस अनुदान के लिए एक आवेदन भेजकर अपनी किस्मत आज़माई , जो ग्राहक विकास में निवेश करने का इरादा रखता है, लेकिन मना कर दिया गया। इसका कारण जीथब पर अपर्याप्त रूप से सक्रिय समुदाय है। दुर्भाग्य से, यह सच है, लेकिन जैसा कि आप देख सकते हैं, मैं स्थिति में सुधार के लिए कुछ कदम उठा रहा हूं।

निष्कर्ष

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

यह जज करना मेरे लिए मुश्किल है कि सेंट्रीफ्यूगो वी 2 को अंडरग्राउंड करने वाली सेंट्रीफ्यूज लाइब्रेरी की कितनी डिमांड होगी। फिलहाल, मुझे खुशी है कि मैं इसे अपनी वर्तमान स्थिति में लाने में सक्षम था। मेरे लिए अब सबसे महत्वपूर्ण संकेतक प्रश्न का उत्तर है "क्या मैं स्वयं अपने निजी प्रोजेक्ट में इस पुस्तकालय का उपयोग करूंगा?" मेरा जवाब है हां। काम पर? हां। इसलिए, मुझे विश्वास है कि अन्य डेवलपर्स इसकी सराहना करेंगे।

पीएस मैं उन लोगों को धन्यवाद देना चाहता हूं जिन्होंने काम और सलाह के साथ मदद की - दिमित्री कोरोलकोव, आर्टेम रयाबिंकोव, ओलेग कुज़मिन। यह तुम्हारे बिना तंग होगा।