🧑🏿‍🤝‍🧑🏼 🎑 🏬 माइक्रोसर्विसेस में जेंटल एरर हैंडलिंग 🥥 🔻 👆🏼

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

यह लेख कज़ान में हालिया गो बैठक की एक रिपोर्ट का एक विस्तृत संस्करण है। यदि आप गो में रुचि रखते हैं और आप कज़ान, इन्नोपोलिस, सुंदर योश्कर-ओला या आसपास के किसी अन्य शहर में रहते हैं, तो आपको समुदाय पृष्ठ पर जाना चाहिए: golangkazan.imtqy.com ।

बैठक में, हमारी टीम ने दो रिपोर्टों में दिखाया कि हम गो पर माइक्रोसर्विसेस कैसे विकसित करते हैं - हम किन सिद्धांतों का पालन करते हैं और हम अपने जीवन को कैसे सरल बनाते हैं। यह लेख त्रुटि से निपटने की हमारी अवधारणा पर ध्यान केंद्रित करता है, जिसे अब हम अपने सभी नए माइक्रोसर्विसेज तक बढ़ाते हैं।

माइक्रोसिस्टवर्क संरचना समझौते

त्रुटि से निपटने के नियमों को छूने से पहले, यह तय करने के लायक है कि हम डिजाइन और कोडिंग करते समय किन प्रतिबंधों का पालन करते हैं। ऐसा करने के लिए, यह बताने लायक है कि हमारे माइक्रोसेवर्स किस तरह के दिखते हैं।

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

इस तरह हमारा स्तर दिखता है:

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

यह है कि microservice डायरेक्टरी ट्री कैसा दिखता है (वह भाग जहां Go कोड है):

चित्र: गॉ प्रोजेक्ट उड़ीसा

प्रत्येक अनुप्रयोग संदर्भ (मॉड्यूल) के लिए, पैकेज संरचना इस तरह दिखती है:

ऐप पैकेज एक सेवा इंटरफ़ेस की घोषणा करता है जिसमें किसी दिए गए स्तर पर सभी क्रियाएं संभव होती हैं जो सेवा संरचना इंटरफ़ेस और func NewService(...) Service फ़ंक्शन func NewService(...) Service
डेटाबेस के साथ काम का अलगाव इस तथ्य के कारण प्राप्त होता है कि डोमेन या ऐप पैकेज रिपॉजिटरी इंटरफ़ेस की घोषणा करता है, जिसे पैकेज में बुनियादी ढांचे के स्तर पर दृश्य नाम "mysql" के साथ लागू किया जाता है
परिवहन कोड infrastructure/transport पैकेज में स्थित है
- हम GRPC का उपयोग करते हैं, इसलिए सर्वर स्टब्स प्रोटो फाइल (यानी सर्वर इंटरफेस, रिस्पांस / रिक्वेस्ट स्ट्रक्चर और सभी क्लाइंट इंटरैक्शन कोड) से उत्पन्न होते हैं।

यह सब चित्र में दिखाया गया है:

चित्र: सरकार प्रोजेक्ट पैकेज

सिद्धांतों को संभालने में त्रुटि

यहाँ सब कुछ सरल है:

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

हम पैनिक्स पर ध्यान केंद्रित नहीं करेंगे: बस हर गोरोइन में घबराहट को संभालने के लिए मत भूलना और प्रत्येक अनुरोध के प्रसंस्करण के दौरान, प्रत्येक संदेश, अनुरोध द्वारा शुरू किए गए प्रत्येक अतुल्यकालिक कार्य। लगभग हमेशा, संपूर्ण एप्लिकेशन को पूरा होने से रोकने के लिए आतंक को एक त्रुटि में बदल दिया जा सकता है।

मुहावरा प्रहरी त्रुटियाँ

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

 package app import "errors" var ErrNoCake = errors.New("no cake found")

एक वैश्विक चर यहां घोषित किया गया है, जो हमारे सज्जन समझौते से, हमें कहीं भी नहीं बदलना चाहिए। यदि आप वैश्विक चर की तरह नहीं हैं और उन्हें पता लगाने के लिए लिंटर का उपयोग करते हैं, तो आप कुछ स्थिरांक के साथ प्राप्त कर सकते हैं, जैसा कि डेव चेनी लगातार त्रुटियों के बाद सुझाव देते हैं :

 package app type Error string func (e Error) Error() string { return string(e) } const ErrNoCake = Error("no cake found")

यदि आप इस दृष्टिकोण को पसंद करते हैं, तो आप अपने कॉरपोरेट गो भाषा पुस्तकालय में ConstError प्रकार जोड़ना चाह सकते हैं।

त्रुटियों की संरचना

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

एक्सरियर्स पैकेज, जो कि गो 1.13 में प्रयोग के तौर पर मानक पुस्तकालय में शामिल किया जाएगा
डेव चेनी द्वारा github.com/pkg/errors पैकेज
- पैकेज जमे हुए है और विस्तार नहीं करता है, लेकिन फिर भी यह अच्छा है

हमारी टीम अभी भी github.com/pkg/errors और errors.WithStack का उपयोग करती है। errors.WithStack फ़ंक्शन (जब हमारे पास जोड़ने के लिए कुछ नहीं है, स्टैकट्रेस को छोड़कर) या errors.Wrap (जब हमें इस त्रुटि के बारे में कुछ कहना है)। दोनों फ़ंक्शन इनपुट में एक त्रुटि स्वीकार करते हैं और एक नई त्रुटि लौटाते हैं, लेकिन स्टैकट्रेस के साथ। बुनियादी ढांचे की परत से उदाहरण:

 package mysql import "github.com/pkg/errors" func (r *repository) FindOne(...) { row := r.client.QueryRow(sql, params...) switch err := row.Scan(...) { case sql.ErrNoRows: //     stacktrace return nil, errors.WithStack(app.ErrNoCake) } }

हम अनुशंसा करते हैं कि प्रत्येक त्रुटि को केवल एक बार लपेटा जाए। यदि आप नियमों का पालन करते हैं तो यह करना आसान है:

किसी भी बुनियादी त्रुटियों को एक बार बुनियादी ढांचे के पैकेज में लपेटा जाता है
व्यावसायिक तर्क नियमों द्वारा उत्पन्न कोई भी त्रुटियां सृजन के समय स्टैकट्रेस द्वारा पूरक होती हैं

त्रुटि का मूल कारण

सभी त्रुटियों को उम्मीद और अप्रत्याशित रूप से विभाजित किया गया है। अपेक्षित त्रुटि को संभालने के लिए, आपको रचना के प्रभावों से छुटकारा पाने की आवश्यकता है। Xerrors और github.com/pkg/errors पैकेज में वह सब कुछ है जो आपको चाहिए: विशेष रूप से, त्रुटियों के पैकेज में त्रुटियाँ हैं। फ़ंक्शन को errors.Cause , जो त्रुटि का मूल कारण देता है। लूप में यह फ़ंक्शन, एक के बाद एक, पहले की त्रुटियों को पुनर्प्राप्त करता है जबकि अगली निकाली गई त्रुटि का Cause() error विधि है।

एक उदाहरण जिसका हम मूल कारण निकालते हैं और सीधे इसकी तुलना संतरी त्रुटि से करते हैं:

 func (s *service) SaveCake(...) error { state, err := s.repo.FindOne(...) if errors.Cause(err) == ErrNoCake { err = nil // No cake is OK, create a new one // ... } else if err != nil { // ... } }

डिफरेंस से निपटने में त्रुटि

शायद आप लिंटर का उपयोग कर रहे हैं, जो आपको सभी त्रुटियों के लिए मैन्युअल रूप से जांच करता है। इस मामले में, आप शायद तब क्रोधित होते हैं जब लिंटर आपको .Close() विधियों और अन्य तरीकों से त्रुटियों की जांच करने के लिए कहता है जिन्हें आप केवल defer । क्या आपने कभी त्रुटि को सही ढंग से टालने की कोशिश की है, खासकर अगर इससे पहले कोई और त्रुटि हुई थी? और हमने कोशिश की है और नुस्खा साझा करने की जल्दी में हैं।

कल्पना करें कि हमारे पास डेटाबेस के साथ सभी कार्य लेन-देन के माध्यम से कड़ाई से हैं। निर्भरता नियम के अनुसार, ऐप और डोमेन का स्तर बुनियादी या एसक्यूएल तकनीक पर प्रत्यक्ष या अप्रत्यक्ष रूप से निर्भर नहीं होना चाहिए। इसका मतलब यह है कि ऐप और डोमेन के स्तर पर "लेनदेन" शब्द नहीं है ।

सबसे सरल समाधान कुछ सार के साथ "लेनदेन" शब्द को बदलना है; इस प्रकार यूनिट ऑफ वर्क पैटर्न का जन्म होता है। हमारे कार्यान्वयन में, ऐप पैकेज में सेवा UnitOfWorkFactory इंटरफ़ेस के माध्यम से कारखाना प्राप्त करती है, और प्रत्येक ऑपरेशन के दौरान एक UnitOfWork ऑब्जेक्ट बनाता है जो लेनदेन को छुपाता है। UnitOfWork ऑब्जेक्ट आपको एक रिपॉजिटरी प्राप्त करने की अनुमति देता है।

UnitOfWork पर अधिक

कार्य की इकाई के उपयोग को बेहतर ढंग से समझने के लिए, आरेख पर एक नज़र डालें:

काम की छवि जाओ इकाई

रिपॉजिटरी एक परिभाषित प्रकार के ऑब्जेक्ट्स (उदाहरण के लिए, डोमेन स्तर समुच्चय) के एक निरंतर निरंतर संग्रह का प्रतिनिधित्व करती है
UnitOfWork लेनदेन को छुपाता है और रिपॉजिटरी ऑब्जेक्ट बनाता है
UnitOfWorkFactory बस सेवा को लेनदेन के बारे में कुछ भी जाने बिना नए लेनदेन बनाने की अनुमति देता है।

क्या हर ऑपरेशन के लिए एक लेन-देन बनाना अत्यधिक नहीं है, यहां तक कि शुरू में परमाणु भी? यह आप पर निर्भर है; हमारा मानना है कि लेन-देन बनाने से बचाने के बजाय व्यावसायिक तर्क की स्वतंत्रता को बनाए रखना अधिक महत्वपूर्ण है।

क्या UnitOfWork और Repository को संयोजित करना संभव है? यह संभव है, लेकिन हमारा मानना है कि यह एकल उत्तरदायित्व के सिद्धांत का उल्लंघन करता है।

यह इंटरफ़ेस कैसा दिखता है:

 type UnitOfWork interface { Repository() Repository Complete(err *error) }

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

UnitOfWork के साथ उदाहरण संचालन:

सावधानी: त्रुटि को नाम वापसी मूल्य घोषित किया जाना चाहिए। यदि नामांकित वापसी मूल्य के बजाय आप स्थानीय चर का उपयोग गलत तरीके से करते हैं, तो आप इसे डिफर में उपयोग नहीं कर सकते हैं! और एक भी लिंटर इसका पता नहीं लगाएगा - गो-आलोचक # 801 देखें

 func (s *service) CookCake() (err error) { unitOfWork, err := s.unitOfWorkFactory.New() if err != nil { return err } defer unitOfWork.Complete(&err) repo := unitOfWork.Repository() } // ...

तो पूरा होने का एहसास है ~~लेन-देन~~ UnitOfWork:

 func (u *unitOfWork) Complete(err *error) { if *err == nil { //     -  commit txErr := u.tx.Commit() *err = errors.Wrap(txErr, "cannot complete transaction") } else { //    -  rollback txErr := return u.tx.Rollback() //  rollback   ,    *err = mergeErrors(*err, errors.Wrap(txErr, "cannot rollback transaction")) } }

mergeErrors फ़ंक्शन दो त्रुटियों को मर्ज करता है, लेकिन यह एक या दोनों त्रुटियों के बजाय समस्याओं के बिना शून्य को संसाधित करता है। उसी समय, हम मानते हैं कि दोनों त्रुटियां अलग-अलग चरणों में एक ऑपरेशन के निष्पादन के दौरान हुईं, और पहली त्रुटि अधिक महत्वपूर्ण है - इसलिए, जब दोनों त्रुटियां शून्य नहीं होती हैं, तो हम पहले को बचाते हैं, और दूसरी त्रुटि से हम केवल संदेश को बचाते हैं:

 package errors func mergeErrors(err error, nextErr error) error { if err == nil { err = nextErr } else if nextErr != nil { err = errors.Wrap(err, nextErr.Error()) } return err }

हो सकता है कि आपको Go के लिए अपनी कॉर्पोरेट लाइब्रेरी में mergeErrors फ़ंक्शन को जोड़ना चाहिए।

लॉगिंग सबसिस्टम

अनुच्छेद चेकलिस्ट: ठेस में सलाह देने से पहले आपको क्या करना था :

लॉग stderr में लिखे गए हैं
लॉग JSON में होना चाहिए, प्रति पंक्ति एक JSON ऑब्जेक्ट
खेतों का एक मानक सेट होना चाहिए:
- टाइमस्टैम्प - मिलीसेकंड में घटना का समय, अधिमानतः आरएफसी 3339 प्रारूप में (उदाहरण: "1985-04-12T23: 20: 50.52Z")
- स्तर - महत्व स्तर, उदाहरण के लिए, "जानकारी" या "त्रुटि"
- app_name - आवेदन नाम
- और अन्य क्षेत्र

हम त्रुटि संदेशों में दो और फ़ील्ड जोड़ना पसंद करते हैं: "error" और "stacktrace" ।

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

 package log type Logger interface { WithField(string, interface{}) Logger WithFields(Fields) Logger Debug(...interface{}) Info(...interface{}) Error(error, ...interface{}) }

यदि प्रोग्रामर लॉग लिखना चाहता है, तो उसे लॉगर इंटरफ़ेस बाहर से प्राप्त करना चाहिए, और यह बुनियादी ढांचे के स्तर पर किया जाना चाहिए, न कि ऐप या डोमेन पर। लकड़हारा इंटरफ़ेस संक्षिप्त है:

जैसा कि लेख सलाह देता है, यह डिबग, सूचना और त्रुटि की गंभीरता के स्तर को कम करता है । लॉगिंग के बारे में बात करते हैं।
यह त्रुटि विधि के लिए विशेष नियमों का परिचय देता है: विधि हमेशा एक त्रुटि वस्तु को स्वीकार करती है

इस तरह की सख्ती से प्रोग्रामर को सही दिशा में निर्देशित करने की अनुमति मिलती है: यदि कोई व्यक्ति लॉगिंग सिस्टम में सुधार करना चाहता है, तो उसे अपने संग्रह और प्रसंस्करण के पूरे बुनियादी ढांचे को ध्यान में रखना चाहिए, जो कि केवल माइक्रो सर्विस में शुरू होता है (और आमतौर पर किबाना में कहीं और समाप्त होता है) Zabbix)।

हालांकि, लॉग पैकेज में एक और इंटरफ़ेस है जो आपको प्रोग्राम को बाधित करने की अनुमति देता है जब एक घातक त्रुटि होती है और इसलिए केवल मुख्य पैकेज में उपयोग किया जा सकता है:

 package log type MainLogger interface { Logger FatalError(error, ...interface{}) }

Jsonlog पैकेज

लकड़हारा इंटरफ़ेस हमारे jsonlog पैकेज को लागू करता है, जो लॉगरस लाइब्रेरी को कॉन्फ़िगर करता है और इसके साथ काम को अमूर्त करता है। योजनाएं इस तरह दिखती हैं:

छवि लकड़ाहारा पैकेज

एक मालिकाना पैकेज आपको माइक्रोसर्विस ( log.Logger इंटरफ़ेस द्वारा व्यक्त), लॉगरस लाइब्रेरी की क्षमताओं, और आपके बुनियादी ढांचे की विशेषताओं से जुड़ने की अनुमति देता है।

उदाहरण के लिए, हम ELK (Elastic Search, Logstash, Kibana) का उपयोग करते हैं, और इसलिए jsonlog पैकेज में हम:

logrus.JSONFormatter स्वरूप के लिए logrus.JSONFormatter सेट करें
- उसी समय, हम फ़ील्ड मैप विकल्प चुनते हैं, जिसके साथ हम "time" फ़ील्ड को "@timestamp" , और "msg" फ़ील्ड को "message"
लॉग स्तर का चयन करें
Error(error, ...interface{}) विधि में पारित Error(error, ...interface{}) ऑब्जेक्ट से स्टैकट्रेस निकालने वाला हुक जोड़ें

मुख्य कार्य में माइक्रोसेस्टर ने लकड़हारे को आरंभीकृत किया है:

 func initLogger(config Config) (log.MainLogger, error) { logLevel, err := jsonlog.ParseLevel(config.LogLevel) if err != nil { return nil, errors.Wrap(err, "failed to parse log level") } return jsonlog.NewLogger(&jsonlog.Config{ Level: logLevel, AppName: "cookingservice" }), nil }

मिडिलवेयर के साथ हैंडलिंग और लॉगिंग में त्रुटि

हम गो पर अपने माइक्रोसर्विसेज में जीआरपीसी पर स्विच कर रहे हैं। लेकिन भले ही आप HTTP API का उपयोग करते हों, लेकिन सामान्य सिद्धांत आपके लिए हैं।

सबसे पहले, ट्रांसपोर्टेशन के लिए जिम्मेदार पैकेज में infrastructure लेवल पर एरर हैंडलिंग और लॉगिंग होनी चाहिए, क्योंकि यह वह है जो ट्रांसपोर्ट प्रोटोकॉल के नियमों और app.Service ज्ञान को app.Service है। app.Service इंटरफेस के app.Service । याद रखें कि पैकेज संबंध कैसा दिखता है:

जीआरपी पैकेज पैकेज

मिडिलवेयर पैटर्न का उपयोग करके त्रुटियों को संसाधित करना और लॉग बनाए रखना सुविधाजनक है (मिडलवेयर गोलंग और नोड्स की दुनिया में डेकोरेटर पैटर्न का नाम है)

मिडलवेयर को कहां जोड़ें? कितने होने चाहिए?

मिडलवेयर जोड़ने के लिए अलग-अलग विकल्प हैं, आप चुनते हैं:

आप app.Service इंटरफ़ेस को सजाने कर सकते हैं, लेकिन हम ऐसा करने की अनुशंसा नहीं करते क्योंकि इस इंटरफ़ेस को क्लाइंट लेयर जैसे ट्रांसपोर्ट लेयर की जानकारी प्राप्त नहीं होती है
जीआरपीसी के साथ आप सभी अनुरोधों पर एक हैंडलर लटका सकते हैं (अधिक सटीक, दो - एकात्मक और भाप), लेकिन फिर सभी एपीआई तरीकों को एक ही शैली में एक ही फ़ील्ड के साथ लॉग किया जाएगा।
जीआरपीसी के साथ, कोड जनरेटर हमारे लिए एक सर्वर इंटरफ़ेस बनाता है जिसमें हम app.Service कहते हैं। app.Service पद्धति - हम इस इंटरफ़ेस को सजाते हैं क्योंकि इसमें परिवहन-स्तर की जानकारी और विभिन्न तरीकों से अलग-अलग एपीआई तरीकों को लॉग करने की क्षमता होती है।

योजनाएं इस तरह दिखती हैं:

छवि जीआरपी मिडिलवेयर पैकेज एग्री

आप एरर हैंडलिंग (और पैनिक) के लिए और लॉगिंग के लिए अलग-अलग मिडलवेयर बना सकते हैं। आप सब कुछ एक में पार कर सकते हैं। हम एक उदाहरण पर विचार करेंगे जिसमें सब कुछ एक मिडलवेयर में पार किया जाता है, जो इस तरह बनाया गया है:

 func NewMiddleware(next api.BackendService, logger log.Logger) api.BackendService { server := &errorHandlingMiddleware{ next: next, logger: logger, } return server }

हम एक api.BackendService रूप में api.BackendService इंटरफ़ेस प्राप्त करते हैं और इसे एक api.BackendService रूप में api.BackendService इंटरफ़ेस के हमारे कार्यान्वयन को वापस करते हुए api.BackendService ।

Middleware में एक मनमाना एपीआई विधि इस प्रकार लागू की गई है:

 func (m *errorHandlingMiddleware) ListCakes( ctx context.Context, req *api.ListCakesRequest) (*api.ListCakesResponse, error) { start := time.Now() res, err := m.next.ListCakes(ctx, req) m.logCall(start, err, "ListCakes", log.Fields{ "cookIDs": req.CookIDs, }) return res, translateError(err) }

यहाँ हम तीन कार्य करते हैं:

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

त्रुटि अनुवाद पर बाद में चर्चा की जाएगी। और logCall विधि द्वारा किया जाता है, जिसे बस सही लॉगर इंटरफ़ेस विधि कहते हैं:

 func (m *errorHandlingMiddleware) logCall(start time.Time, err error, method string, fields log.Fields) { fields["duration"] = fmt.Sprintf("%v", time.Since(start)) fields["method"] = method logger := m.logger.WithFields(fields) if err != nil { logger.Error(err, "call failed") } else { logger.Info("call finished") } }

अनुवाद में त्रुटि

हमें त्रुटि का मूल कारण प्राप्त करना चाहिए और इसे एक त्रुटि में बदलना चाहिए जो परिवहन स्तर पर समझ में आता है और आपकी सेवा के एपीआई में प्रलेखित है।

GRPC में, यह सरल है - स्टेटस कोड के साथ एक एरर बनाने के लिए status.Errorf उपयोग करें। status.Errorf फंक्शन। यदि आपके पास HTTP API (REST API) है, तो आप अपनी स्वयं की प्रकार की त्रुटि बना सकते हैं, जिसके बारे में ऐप और डोमेन स्तरों को पता नहीं होना चाहिए।

पहले सन्निकटन में, त्रुटि अनुवाद इस तरह दिखता है:

 // ! ! -   err  status.Error func translateError(err error) error { switch errors.Cause(err) { case app.ErrNoCake: err = status.Errorf(codes.NotFound, err.Error()) default: err = status.Errorf(codes.Internal, err.Error()) } return err }

इनपुट तर्कों को मान्य करते समय, सजाया गया इंटरफ़ेस status.Status की एक त्रुटि लौटा सकता है। स्टेटस कोड के साथ status.Status प्रकार, और ट्रांसलेर का पहला संस्करण इस स्टेटस कोड को खो देगा।

आइए एक इंटरफ़ेस प्रकार (लंबे समय तक लाइव टाइपिंग) पर कास्टिंग करके एक बेहतर संस्करण बनाएं:

 type statusError interface { GRPCStatus() *status.Status } func isGrpcStatusError(er error) bool { _, ok := err.(statusError) return ok } func translateError(err error) error { if isGrpcStatusError(err) { return err } switch errors.Cause(err) { case app.ErrNoCake: err = status.Errorf(codes.NotFound, err.Error()) default: err = status.Errorf(codes.Internal, err.Error()) } return err }

translateError फ़ंक्शन आपके माइक्रोस सर्विस में प्रत्येक संदर्भ (स्वतंत्र मॉड्यूल) के लिए व्यक्तिगत रूप से बनाया गया है और ट्रांसपोर्ट-स्तरीय त्रुटियों में व्यावसायिक तर्क त्रुटियों का अनुवाद करता है।

संक्षेप में देना

हम आपको त्रुटियों से निपटने और लॉग के साथ काम करने के लिए कई नियम प्रदान करते हैं। उनका पालन करना या न करना आपके ऊपर है।

क्लीन आर्किटेक्चर के सिद्धांतों का पालन करें, प्रत्यक्ष या अप्रत्यक्ष रूप से निर्भरता के नियम को न तोड़ें। व्यावसायिक तर्क केवल एक प्रोग्रामिंग भाषा पर निर्भर होना चाहिए, न कि बाहरी प्रौद्योगिकियों पर।
एक पैकेज का उपयोग करें जो त्रुटि रचना और स्टैकट्रेस निर्माण प्रदान करता है। उदाहरण के लिए, "github.com/pkg/errors" या xerrors पैकेज, जो जल्द ही गो मानक पुस्तकालय का हिस्सा होगा।
माइक्रो-सर्विस में थर्ड-पार्टी लॉगिंग लाइब्रेरी का उपयोग न करें - लॉग और जॉन्सलॉग पैकेज के साथ अपनी खुद की लाइब्रेरी बनाएं, जो लॉगिंग कार्यान्वयन के विवरण को छिपाएगा
त्रुटियों को संभालने और कार्यक्रम के बुनियादी ढांचे के स्तर की परिवहन दिशा पर लॉग लिखने के लिए मिडिलवेयर पैटर्न का उपयोग करें

यहां हमने क्वेरी ट्रेसिंग टेक्नोलॉजी (उदाहरण के लिए, OpenTracing), मैट्रिक्स मॉनिटरिंग (उदाहरण के लिए, डेटाबेस क्वेरी प्रदर्शन) और लॉगिंग जैसी अन्य चीजों के बारे में कुछ नहीं कहा। आप खुद इससे निपटेंगे, हमें आप पर विश्वास है।

माइक्रोसर्विसेस में जेंटल एरर हैंडलिंग