संदर्भ आर्किटेक्चर आणि रनटाइम
ग्राहकाच्या क्लाउडमध्ये काय तयार केले आहे: इनग्रेस, झोनमध्ये पसरलेला तीन-नोड कुबरनेटीस क्लस्टर, त्याच्या स्टँडबाय, ऑब्जेक्ट स्टोरेज, इग्रेससह व्यवस्थापित डेटाबेस, एअर-गॅप व्हॉल्ट आणि साइझिंग नॉब्स.
प्रत्येक डिप्लॉयमेंटची रचना एकाच संदर्भ आर्किटेक्चरच्या आधारे एकदाच केली जाते. त्यामुळे, क्लाउड्समधील फरक — जसे की कनेक्टिव्हिटी उत्पादने, की व्यवस्थापन, डेटाबेस इंजिन्स — हे पुनर्रचनेऐवजी कॉन्फिगरेशनचे पर्याय बनतात.
| डिझाइन | तयार करा | चालवा | नवनिर्मिती करा |
|---|---|---|---|
| प्रत्येक आर्थिक घटनेसाठी एक डेटा मॉडेल आणि एक पोस्टिंग इंजिन. | तीन-नोड, लोड-बॅलन्स्ड कुबरनेटीस क्लस्टरवरील कंटेनरयुक्त सेवा. | डिझाइननुसार अपरिवर्तनीय नोंदी आणि संपूर्ण ऑडिट ट्रेल. | ASK हे TRANXACT च्या स्वतःच्या API द्वारे कार्य करते. |
| रचनेनुसार बहु-संस्था, बहु-चलन, बहु-प्रदेशीय. | ग्राहकाच्या पसंतीचा, उच्च उपलब्धतेसाठी योग्य आकाराचा व्यवस्थापित डेटाबेस. | दुसऱ्या चालू प्रदेशात थेट आपत्कालीन पुनर्प्राप्ती (Live DR), आणि मानक म्हणून एअर-गॅप्ड बॅकअप. | भूमिकेची जाणीव असलेली आणि महत्त्वाच्या गोष्टी शिकणारी ॲक्शन क्यू. |
एका प्रदेशाच्या आत काय आहे
| घटक | ते काय आहे | नोंदी |
|---|---|---|
| लोड बॅलेंसर आणि WAF | erp.<customer domain> वर HTTPS प्रवेश; TLS 1.2 किंवा त्याहून अधिक; DDoS संरक्षण. | सार्वजनिक प्रवेशद्वाराचा एकमेव मार्ग. |
| खाजगी एंडपॉइंट / अंतर्गत लोड बॅलेंसर | व्हीपीएन, खाजगी कनेक्शन किंवा पीअरिंगद्वारे खाजगी ट्रॅफिकसाठी प्रवेश. | खाजगी प्रवेश वापरला जातो तेव्हा उपस्थित असते. |
| कुबरनेट्स क्लस्टर | उपलब्धता क्षेत्रांमध्ये पसरलेले किमान तीन वर्कर नोड्स, TLS एंड-टू-एंड. | वेब आणि एपीआय, पोस्टिंग इंजिन, ASK ऑपरेटर, तसेच वर्कर्स आणि जॉब्स चालवते. |
| व्यवस्थापित डेटाबेस | दुसऱ्या झोनमध्ये सिंक्रोनस एचए स्टँडबायसह एक प्रायमरी. | इंजिन आणि आकार ग्राहकाच्या पसंतीचे आहेत. |
| ऑब्जेक्ट स्टोरेज | दस्तऐवज आणि संलग्नक, आवृत्तीबद्ध, सर्व प्रदेशांमध्ये प्रतिकृती केलेले. | दस्तऐवज डेटाबेसमध्ये साठवले जात नाहीत. |
| NAT निर्गमन | केवळ अनुमत-सूचीतील गंतव्यस्थानांकडेच जाणारी बाह्य रहदारी. | बँका, कर आणि ई-इनव्हॉइसिंग, पेरोल, ईमेल, एआय इंजिन. |
| हवेच्या अंतराचे तिजोरी | अपरिवर्तनीय, एकदाच लिहिता येणारे बॅकअप असलेले एक स्वतंत्र खाते. | उत्पादन फक्त त्यावरच जोर देऊ शकते, बाकी कशावरही नाही. |
वर्कर नोड्स झोनमध्ये पसरलेले असतात, जेणेकरून एक नोड किंवा एक झोन बंद पडल्यास देखील वापरकर्त्यांना सेवा देण्यासाठी क्षमता शिल्लक राहते. प्रत्येक सेवा कोणत्या नोडवर चालते हे मार्गदर्शिकेत उदाहरणादाखल दिले आहे — शेड्युलर त्यांची जागा निश्चित करतो.
क्लस्टरच्या बाहेर
- ASK साठी AI इंजिन — प्रीमियम, बॅलन्स्ड किंवा इकॉनॉमी टियर, किंवा ग्राहकाची स्वतःची चावी (BYOK).
- बाह्य सेवा — बँका, कर आणि ई-इनव्हॉइसिंग, पेरोल, बीआय आणि डेटा प्लॅटफॉर्म, ईमेल.
- दूरस्थ आणि मोबाइल वापरकर्ते, ग्राहकाच्या ओळख प्रदात्याद्वारे साइन इन करत आहेत.
- ग्राहकाचे कॉर्पोरेट नेटवर्क: ऑफिसमधील वापरकर्ते, आयडेंटिटी प्रोव्हायडर, लेगसी आणि शॉप-फ्लोअर सिस्टीम्स — खाजगी कनेक्टिव्हिटी वापरल्यास VPN किंवा खाजगी लिंकद्वारे गाठले जाते.
खाजगी कनेक्टिव्हिटी ऐच्छिक आहे. जेव्हा सर्व ॲक्सेस HTTPS द्वारे असतो, तेव्हा VPN / खाजगी लिंक आणि अंतर्गत लोड बॅलेंसर तयार केलेले नसतात.
आकार देणारे नॉब
- नोडचा आकार.
- नोडची संख्या — किमान तीन.
- डेटाबेस इंजिन आणि आकार.
- Live DR प्रदेश.
- वातावरणांची संख्या.
बाकी सर्व संदर्भ आर्किटेक्चर आहे आणि प्रत्येक ग्राहकासाठी सारखेच आहे. सुरुवातीची मूल्ये निश्चित करणाऱ्या वापराच्या स्तरांसाठी 'करारापूर्वी' (Before the contract) पहा.
कॉन्फिगर करा, सानुकूलित करू नका.
क्लस्टरमध्ये काय चालते, हे देखील त्याच तत्त्वावर चालते. मानकांच्या पलीकडील आवश्यकता या क्रमाने पूर्ण केली जाते: कॉन्फिगरेशनद्वारे (लो-कोड / नो-कोड, प्लॅटफॉर्मसह अपग्रेड केलेले); क्लस्टरच्या बाहेर चालणाऱ्या TRANXACT API द्वारे इंटिग्रेशन करून; आणि त्यानंतरच, सुरक्षा आणि अभियांत्रिकी पुनरावलोकनानंतर, क्लस्टरमधील कोड किंवा एजंटद्वारे — जे मंजूर झाल्यास, सहन केले जाते आणि त्याला ग्राहक-समर्थन दिले जाते. नाकारलेला कोड क्लस्टरच्या बाहेर चालतो. वर्कबुकच्या X अध्यायात प्रत्येक परिणामासाठीची कार्ये सूचीबद्ध आहेत.
कॉन्फिगरेशनद्वारे साध्य करता येणारी कोणतीही गोष्ट कस्टम कोड बनू नये. प्रत्येक प्लॅटफॉर्म रिलीझसोबत कॉन्फिगरेशन बदलते; कस्टम कोड बदलत नाही.