सरल और सी ++ में। उपयोगकर्ता की मूल बातें - अतुल्यकालिक माइक्रोसर्विसेज लिखने के लिए एक रूपरेखा

Yandex.Taxi microservice वास्तुकला का पालन करता है। माइक्रोसर्विस की संख्या में वृद्धि के साथ, हमने देखा कि डेवलपर्स बॉयलरप्लेट और विशिष्ट समस्याओं पर बहुत समय बिताते हैं, जबकि समाधान हमेशा इष्टतम रूप से काम नहीं करते हैं।

हमने C ++ 17 और कोरटाइन के साथ अपना ढांचा बनाने का फैसला किया। यह कैसे एक विशिष्ट microservice कोड अब लग रहा है:

Response View::Handle(Request&& request, const Dependencies& dependencies) { auto cluster = dependencies.pg->GetCluster(); auto trx = cluster->Begin(storages::postgres::ClusterHostType::kMaster); const char* statement = "SELECT ok, baz FROM some WHERE id = $1 LIMIT 1"; auto row = psql::Execute(trx, statement, request.id)[0]; if (!row["ok"].As<bool>()) { LOG_DEBUG() << request.id << " is not OK of " << GetSomeInfoFromDb(); return Response400(); } psql::Execute(trx, queries::kUpdateRules, request.foo, request.bar); trx.Commit(); return Response200{row["baz"].As<std::string>()}; } 

और यहां क्यों यह बेहद प्रभावी और तेज है - हम कटौती के तहत बताएंगे।

उपयोगकर्ता - अतुल्यकालिक

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

माइक्रोसर्विसेस को इनपुट / आउटपुट की अपेक्षा के द्वारा विशेषता दी जाती है: अक्सर एक माइक्रोसैस की प्रतिक्रिया अन्य मिक्रोसर्विसेज और डेटाबेस से कई प्रतिक्रियाओं से बनती है। कुशल I / O प्रतीक्षा की समस्या को अतुल्यकालिक विधियों और कॉलबैक के माध्यम से हल किया जाता है: अतुल्यकालिक संचालन के साथ, निष्पादन थ्रेड्स का उत्पादन करने की कोई आवश्यकता नहीं है, और तदनुसार, प्रवाह स्विच करने के लिए कोई बड़ा ओवरहेड नहीं है ... बस कोड लिखना और बनाए रखना काफी मुश्किल है:

 void View::Handle(Request&& request, const Dependencies& dependencies, Response response) { auto cluster = dependencies.pg->GetCluster(); cluster->Begin(storages::postgres::ClusterHostType::kMaster, [request = std::move(request), response](auto& trx) { const char* statement = "SELECT ok, baz FROM some WHERE id = $1 LIMIT 1"; psql::Execute(trx, statement, request.id, [request = std::move(request), response, trx = std::move(trx)](auto& res) { auto row = res[0]; if (!row["ok"].As<bool>()) { if (LogDebug()) { GetSomeInfoFromDb([id = request.id](auto info) { LOG_DEBUG() << id << " is not OK of " << info; }); } *response = Response400{}; } psql::Execute(trx, queries::kUpdateRules, request.foo, request.bar, [row = std::move(row), trx = std::move(trx), response]() { trx.Commit([row = std::move(row), response]() { *response = Response200{row["baz"].As<std::string>()}; }); }); }); }); } 

और यहाँ स्टैकफुल-कोरटाइन बचाव के लिए आते हैं। फ्रेमवर्क के उपयोगकर्ता को लगता है कि वह सामान्य तुल्यकालिक कोड लिखता है:

  auto row = psql::Execute(trx, queries::kGetRules, request.id)[0]; 

हालांकि, लगभग हुड के नीचे होता है:

1. टीसीपी पैकेट उत्पन्न होते हैं और डेटाबेस के लिए अनुरोध के साथ भेजे जाते हैं;
2. कोरटाइन का निष्पादन, जिसमें दृश्य :: हैंडल फ़ंक्शन वर्तमान में चल रहा है, निलंबित है;
3. हम ओएस के कर्नेल से कहते हैं: "डेटाबेस से पर्याप्त टीसीपी पैकेट आते ही निष्पादन के लिए तैयार किए गए कार्यों की कतार में निलंबित कोरआउट को रख दें";
4. पिछले चरण की प्रतीक्षा किए बिना, हम कतार से निष्पादन के लिए तैयार एक और कोरटाइन लेते हैं और लॉन्च करते हैं।

दूसरे शब्दों में, पहले उदाहरण से फ़ंक्शन असिंक्रोनस रूप से काम करता है और C ++ 20 Coroutines का उपयोग करके ऐसे कोड के करीब है:

 Response View::Handle(Request&& request, const Dependencies& dependencies) { auto cluster = dependencies.pg->GetCluster(); auto trx = co_await cluster->Begin(storages::postgres::ClusterHostType::kMaster); const char* statement = "SELECT ok, baz FROM some WHERE id = $1 LIMIT 1"; auto row = co_await psql::Execute(trx, statement, request.id)[0]; if (!row["ok"].As<bool>()) { LOG_DEBUG() << request.id << " is not OK of " << co_await GetSomeInfoFromDb(); co_return Response400{"NOT_OK", "Please provide different ID"}; } co_await psql::Execute(trx, queries::kUpdateRules, request.foo, request.bar); co_await trx.Commit(); co_return Response200{row["baz"].As<std::string>()}; } 

यह सिर्फ उपयोगकर्ता co_await और co_return के बारे में सोचने की जरूरत नहीं है, सब कुछ "अपने दम पर" काम करता है।

हमारे ढांचे में, कोरटाइन के बीच स्विचिंग std कॉलिंग से तेज है :: this_thread :: यील्ड ()। पूरे माइक्रोसॉर्स्ट में बहुत कम संख्या में धागे होते हैं।

फिलहाल, उपयोगकर्ता के पास अतुल्यकालिक ड्राइवर हैं:
* ओएस सॉकेट्स के लिए;
* http और https (क्लाइंट और सर्वर);
* PostgreSQL;
* MongoDB;
* रेडिस;
* फाइलों के साथ काम करें;
* टाइमर;
* नए coroutines को सिंक्रनाइज़ करने और लॉन्च करने के लिए आदिम।

I / O- बाउंड कार्यों को हल करने के लिए उपरोक्त एसिंक्रोनस दृष्टिकोण गो डेवलपर्स से परिचित होना चाहिए। लेकिन, गो के विपरीत, हम कचरा संग्रहकर्ता से मेमोरी और सीपीयू के लिए ओवरहेड प्राप्त नहीं करते हैं। डेवलपर्स एक समृद्ध भाषा का उपयोग कर सकते हैं, विभिन्न कंटेनरों और उच्च-प्रदर्शन पुस्तकालयों के साथ, निरंतरता, आरएआईआई या टेम्पलेट की कमी के बिना।

उपयोगकर्ता - घटक

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

उपयोगकर्ता - कोड पीढ़ी

आइए अपने उदाहरण की पहली पंक्ति पर वापस जाएं और देखें कि रिस्पांस और अनुरोध के पीछे क्या छिपा है:

 Response Handle(Request&& request, const Dependencies& dependencies); 

उपयोगकर्ता के साथ आप कोई भी माइक्रो-सर्विस लिख सकते हैं, लेकिन हमारे माइक्रोसर्विस के लिए एक आवश्यकता है कि उनके एपीआई को प्रलेखित किया जाना चाहिए (स्वैगर योजनाओं के माध्यम से वर्णित)।

उदाहरण के लिए, उदाहरण के लिए हैंडल के लिए, स्वैगर आरेख इस तरह दिख सकता है:

 paths: /some/sample/{bar}: post: description: |     Habr. summary: | ,  -   . parameters: - in: query name: id type: string required: true - in: header name: foo type: string enum: - foo1 - foo2 required: true - in: path name: bar type: string required: true responses: '200': description: OK schema: type: object additionalProperties: false required: - baz properties: baz: type: string '400': $ref: '#/responses/ResponseCommonError' 

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

इसी समय, कोड पीढ़ी सेवा ग्राहकों के लिए काम करती है। आप संकेत कर सकते हैं कि आपकी सेवा को इस तरह की योजना के अनुसार काम करने वाले ग्राहक की आवश्यकता है, और अतुल्यकालिक अनुरोध बनाने के लिए उपयोग के लिए तैयार एक वर्ग प्राप्त करें:

 Request req; req.id = id; req.foo = foo; req.bar = bar; dependencies.sample_client.SomeSampleBarPost(req); 

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

उपयोगकर्ता - लॉगिंग

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

उदाहरण के लिए, माइक्रोसेवा के सामान्य संचालन के दौरान, लॉगिंग स्तर INFO और संपूर्ण अभिव्यक्ति पर सेट किया जाएगा

  LOG_DEBUG() << request.id << " is not OK of " << GetSomeInfoFromDb(); 

गणना नहीं की जाएगी। संसाधन-गहन फ़ंक्शन के कॉल को शामिल करना GetSomeInfoFromDb () नहीं होगा।

यदि अचानक सेवा "मूर्ख" शुरू होती है, तो डेवलपर हमेशा कार्यशील सेवा को बता सकता है: "लॉग इन डीबग मोड"। और इस स्थिति में प्रविष्टियाँ "ठीक नहीं है" लॉग में दिखाई देने लगेगी, GetSomeInfoFromDb () फ़ंक्शन निष्पादित किया जाएगा।

बजाय योग के

एक लेख में एक बार में सभी विशेषताओं और चाल के बारे में बताना असंभव है। इसलिए, हमने एक संक्षिप्त परिचय के साथ शुरुआत की। टिप्पणियों में लिखें कि उपयोगकर्ता के बारे में आपको किन चीजों के बारे में जानने और पढ़ने में रुचि होगी।

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