आम्ही मल्टी-थ्रेडेड रस्टसह सिंगल-थ्रेडेड C++ इंटरफेस केले

मल्टी-थ्रेडेड रस्टसह सिंगल-थ्रेडेड C++ कोड इंटरफेस करणे केवळ शक्य नाही — संपूर्ण पुनर्लेखन न करता लेगसी सिस्टमचे आधुनिकीकरण करण्याचा हा सर्वात व्यावहारिक मार्ग आहे. Mewayz येथे, 138,000 वापरकर्त्यांना सेवा देण्यासाठी आमचे 207-मॉड्यूल व्यवसाय OS स्केल करताना आम्ही या अचूक आव्हानाचा सामना केला आणि परिणामांनी मूलभूतपणे सिस्टम इंटरऑपरेबिलिटीबद्दल आमचा विचार बदलला.

तुम्ही मल्टी-थ्रेडेड रस्टसह सिंगल-थ्रेडेड C++ इंटरफेस का कराल?

बहुतांश उत्पादन प्रणाल्यांमध्ये अनेक वर्षांचा युद्ध-चाचणी केलेला C++ कोड असतो. रस्टमध्ये सर्वकाही पुन्हा लिहिणे हे कागदावर आकर्षक वाटते, परंतु ते मोठ्या प्रमाणात जोखीम आणि अभियांत्रिकी कालावधीचा परिचय देते. व्यावहारिक दृष्टीकोन वाढीव अवलंब करणे आहे — रस्टच्या मालकी मॉडेलवर समवर्ती-भारी वर्कलोड ऑफलोड करताना विद्यमान C++ तर्क गुंडाळणे.

आमच्या बाबतीत, कोर बिझनेस लॉजिक मॉड्युल वर्षानुवर्षे सिंगल-थ्रेडेड C++ मध्ये विश्वसनीयपणे चालत होते. त्यांनी अनुक्रमिक कार्य प्रक्रिया, दस्तऐवज निर्मिती आणि आर्थिक गणना हाताळली. पण जसजसा आमचा वापरकर्ता आधार 100K च्या पुढे वाढला, आम्हाला समांतर डेटा प्रोसेसिंग, समवर्ती API हाताळणी आणि सुरक्षित सामायिक-राज्य व्यवस्थापन आवश्यक आहे. रस्टच्या पाठवा आणि सिंक वैशिष्ट्यांमुळे आम्हाला कंपाइल-टाइम कॉन्करन्सीची हमी दिली जाते की C++ विस्तृत मॅन्युअल ऑडिटिंगशिवाय देऊ शकत नाही.

मुख्य प्रेरणा म्हणजे जोखीम कमी करणे. तुम्ही जे कार्य करते ते ठेवता आणि तुम्ही कोणते स्केल जोडता — तुमच्या संपूर्ण कोडबेसला कधीही पूर्ण न होणाऱ्या स्थलांतरावर जुगार न खेळता.

FFI सीमा प्रत्यक्षात कशी कार्य करते?

C++ आणि Rust मधील फॉरेन फंक्शन इंटरफेस (FFI) C-कंपॅटिबल फंक्शन सिग्नेचरद्वारे चालतो. रस्टचे बाह्य "C" ब्लॉक फंक्शन्स उघड करतात जे C++ थेट कॉल करू शकतात आणि त्याउलट. जेव्हा रस्टच्या मल्टी-थ्रेडेड रनटाइमला सिंगल-थ्रेडेड C++ कोड सुरक्षितपणे लागू करणे आवश्यक असते तेव्हा गंभीर आव्हान उद्भवते.

आम्ही समर्पित आर्किटेक्चर वापरून याचे निराकरण केले:

• थ्रेड-सीमित C++ एक्झिक्युटर: सर्व C++ कॉल एकल समर्पित थ्रेडद्वारे संदेश-पासिंग चॅनेल वापरून फनेल केले जातात, एकल-थ्रेड केलेले अपरिवर्तनीय कधीही उल्लंघन होणार नाही याची खात्री करून.
• रस्ट एसिंक ब्रिज लेयर: टोकियो टास्क सी++ एक्झिक्यूटरकडे काम सबमिट करतात आणि रस्ट साइडला पूर्णपणे एसिंक्रोनस ठेवून वनशॉट चॅनेलद्वारे परिणाम प्रतीक्षा करतात.
• अपारदर्शक पॉइंटर मॅनेजमेंट: C++ ऑब्जेक्ट्स रस्ट स्ट्रक्चर्समध्ये गुंडाळले जातात जे डिटरमिनिस्टिक क्लीनअपसाठी ड्रॉप लागू करतात, भाषेच्या सीमा ओलांडून मेमरी लीक रोखतात.
• सीमेवर सीरियलायझेशन: कॉम्प्लेक्स डेटा स्ट्रक्चर्स FFI लेयरवर फ्लॅटबफर्सवर अनुक्रमित केल्या जातात, नाजूक स्ट्रक्चर लेआउट मॅचिंग टाळून आणि प्रत्येक बाजूची स्वतंत्र उत्क्रांती सक्षम करते.
• पॅनिक आयसोलेशन: रस्टचा catch_unwind प्रत्येक FFI एंट्री पॉइंट गुंडाळतो जेणेकरून पॅनिक कधीही भाषेची सीमा ओलांडत नाही, जे अपरिभाषित वर्तन असेल.

या पॅटर्नने आम्हाला सिद्ध C++ लॉजिकच्या विश्वासार्हतेसह मल्टी-थ्रेडेड रस्टचा थ्रूपुट दिला — मूळ व्यवसाय नियमांची एक ओळ पुन्हा न लिहिता.

टाळण्यासाठी सर्वात मोठे नुकसान कोणते?

सी++ कोड नसताना तो थ्रेड-सेफ आहे असे गृहीत धरणे ही सर्वात धोकादायक चूक आहे. ग्लोबल स्टेट, स्टॅटिक व्हेरिएबल्स आणि नॉन-एंट्रंट लायब्ररी कॉल्समुळे डेटा रेस होऊ शकतात ज्या रस्टचे कंपाइलर FFI सीमा ओलांडून शोधू शकत नाही. रस्टच्या सुरक्षिततेची हमी असुरक्षित ब्लॉकवर थांबते — आत सर्व काही तुमची जबाबदारी आहे.

मुख्य अंतर्दृष्टी: रस्ट त्याच्या स्वतःच्या कोडमध्ये मेमरी सुरक्षिततेची हमी देतो, परंतु ज्या क्षणी तुम्ही C++ मध्ये FFI सीमा ओलांडता, तेव्हा तुम्हाला C++ असलेली प्रत्येक थ्रेड-सुरक्षा समस्या वारशाने मिळते. त्या सीमेच्या आजूबाजूची वास्तुकला तिच्या दोन्ही बाजूंच्या कोडपेक्षा अधिक महत्त्वाची आहे.

💡 DID YOU KNOW?

Mewayz replaces 8+ business tools in one platform

CRM · Invoicing · HR · Projects · Booking · eCommerce · POS · Analytics. Free forever plan available.

Start Free →

दुसरा सामान्य त्रास म्हणजे आजीवन व्यवस्थापन. C++ वस्तू रस्टच्या कर्ज तपासकामध्ये सहभागी होत नाहीत. C++ कडे पॉइंटर असताना रस्टने संदर्भ सोडल्यास, तुम्हाला वापर-नंतर-मुक्त बग मिळतात ज्यांचे निदान करणे अत्यंत कठीण असते. आम्ही कठोर मालकी शब्दार्थ लागू करून हे संबोधित केले: C++ ऑब्जेक्ट्स नेहमी एका रस्ट रॅपरच्या मालकीच्या असतात आणि सामायिक प्रवेश कमान-आधारित संदर्भ मोजणीद्वारे रस्ट बाजूला जातो.

कार्यप्रदर्शनानुसार, अत्यधिक FFI कॉल्स कॉन्टेक्स्ट स्विचिंग आणि सीरियलायझेशनमधून ओव्हरहेड तयार करतात. वैयक्तिक क्रॉस-भाषा कॉल करण्याऐवजी आम्ही C++ एक्झिक्युटरला कामाच्या वस्तूंची रांग पाठवून शक्य तिथे ऑपरेशन्स करतो.

या दृष्टिकोनाने उत्पादनात कसे कार्य केले?

आमच्या प्लॅटफॉर्मवर हायब्रीड आर्किटेक्चर उपयोजित केल्यानंतर, आम्ही ठोस सुधारणा मोजल्या. अनुक्रमिक C++ प्रक्रियेवर आधी अडथळे आणलेल्या मॉड्यूल्ससाठी विनंती थ्रूपुट 3.4x ने वाढले. टेल लेटन्सी (p99) 61% ने कमी झाली कारण C++ त्याच्या समर्पित थ्रेडवर गणना-जड कार्ये हाताळत असताना Rust चे async रनटाइम स्वतंत्र विनंत्यांवर एकाच वेळी प्रक्रिया करू शकते.

अधिक महत्त्वाचे म्हणजे, उत्पादनाच्या पहिल्या सहा महिन्यांत आमच्याकडे शून्य समवर्ती-संबंधित बग होते. थ्रेड-कॉन्फिनमेंट पॅटर्नमुळे अनेक थ्रेड्सवरून C++ कोड कॉल करणे रचनात्मकदृष्ट्या अशक्य झाले, तर रस्टच्या प्रकार प्रणालीने सीमेच्या बाजूला डेटा रेस रोखल्या. म्युटेक्ससह C++ मध्ये थ्रेडिंग जोडण्याचा प्रयत्न करण्याच्या आमच्या पूर्वीच्या दृष्टिकोनापेक्षा ही लक्षणीय सुधारणा होती, ज्याने एकाच तिमाहीत तीन रेस-कंडिशन घटना घडल्या होत्या.

अभियांत्रिकी संघाने वेगवान पुनरावृत्ती चक्र देखील नोंदवले. नवीन वैशिष्ट्ये रस्टमध्ये पूर्ण समवर्ती समर्थनासह तयार केली जाऊ शकतात, तर विद्यमान C++ मॉड्युल बदलाशिवाय चालत राहिले. या वाढीव धोरणाचा अर्थ असा होतो की आमच्याकडे कधीही उच्च-जोखीम असलेले "बिग बँग" स्थलांतर नव्हते - फक्त स्थिर, मोजता येण्याजोगी सुधारणा.

वारंवार विचारले जाणारे प्रश्न

रस्ट एकल-थ्रेडेड C++ लायब्ररीला बदल न करता कॉल करू शकते?

होय, पण तुम्ही त्या लायब्ररीतील सर्व कॉल्स एकाच थ्रेडवरून झाल्याचे सुनिश्चित केले पाहिजे. स्टँडर्ड पॅटर्न म्हणजे एक समर्पित एक्झिक्युटर थ्रेड तयार करणे जो चॅनेलद्वारे सर्व C++ कॉल्स सीरियलाइज करतो. Rust च्या async कार्ये विनंत्या सबमिट करतात आणि बहु-थ्रेडेड रनटाइम अवरोधित न करता प्रतिसादांची प्रतीक्षा करतात. C++ कोडला स्वतःच कोणत्याही बदलांची आवश्यकता नाही — सुरक्षा मर्यादा पूर्णपणे रस्ट बाजूला लागू केली जाते.

अनुप्रयोग कार्यप्रदर्शन प्रभावित करण्यासाठी FFI ओव्हरहेड पुरेसे महत्त्वपूर्ण आहे का?

वैयक्तिक FFI कॉलमध्ये किमान ओव्हरहेड असते — सामान्यत: साध्या फंक्शन कॉलसाठी 10 नॅनोसेकंदांपेक्षा कमी. तथापि, क्लिष्ट डेटा स्ट्रक्चर्सचे सीरियलायझेशन आणि सीमेवर थ्रेड सिंक्रोनाइझेशन जोडले जाते जर तुम्ही हजारो सुरेख कॉल केले. बॅचिंग ऑपरेशन्स आणि फ्लॅटबफर्स किंवा कॅप'न प्रोटो सारख्या शून्य-कॉपी सीरियलायझेशन फॉरमॅट्स वापरणे, अगदी स्केलवरही ओव्हरहेड नगण्य ठेवते.

आम्ही आमचा C++ कोडबेस इंटरफेस करण्याऐवजी रस्टमध्ये पुन्हा लिहावा का?

बहुतेक संघांसाठी, वाढीव इंटरफेसिंग हा अधिक सुरक्षित आणि जलद मार्ग आहे. पूर्ण पुनर्लेखनामध्ये अभियांत्रिकी जोखीम पूर्ण होईपर्यंत वापरकर्त्याला तोंड द्यावे लागत नाही. इंटरफेसिंगमुळे तुम्हाला तात्काळ सुधारणा पाठवू देते, उत्पादनातील रस्ट पध्दतीचे प्रमाणीकरण करू देते आणि संयोगाचा सर्वाधिक परिणाम कोठे होतो यावर आधारित मॉड्यूल्स एकावेळी स्थलांतरित करता येतात. FFI सीमा राखण्याची किंमत पुनर्लेखनाच्या खर्चापेक्षा जास्त असेल फक्त मॉड्यूल्स पुन्हा लिहा.

Mewayz येथे, आम्ही तांत्रिक आणि ऑपरेशनल अशा दोन्ही प्रकारच्या पायाभूत सुविधा तयार करतो. आमचे 207-मॉड्यूल बिझनेस OS $19/महिना पासून 138,000 संघांना अधिक स्मार्ट वर्कफ्लो चालवण्यास मदत करते. तुम्ही प्रकल्प व्यवस्थापित करत असाल, ऑपरेशन्स स्वयंचलित करत असाल किंवा तुमचा व्यवसाय स्केलिंग करत असाल, Mewayz तुमच्या कामाच्या पद्धतीशी जुळवून घेतो. app.mewayz.com वर तुमची विनामूल्य चाचणी सुरू करा आणि आधुनिक व्यवसाय OS तुमच्या टीमसाठी काय करू शकते ते पहा.