😭 💰 😕 वास्तुकला देखें? और मैं नहीं देखता, लेकिन वह है 🎷 👩🏻‍🏫 👧🏻

Hh.ru के विकास में आज लगभग 150 लोग हैं। हमारे पास कई दिलचस्प टीमें हैं, और हर एक महत्वपूर्ण योगदान देता है। लेकिन इस लेख में मैं उनमें से केवल एक के बारे में बताऊंगा।

~~क्योंकि मैं उनकी टीम लीडर हूं।~~ और इसके कई कारण हैं:

अक्सर उम्मीदवार समझ नहीं पाते हैं कि हम क्या कर रहे हैं;
कभी-कभी कंपनी के अंदर के कर्मचारियों को भी यह पता नहीं होता है, क्योंकि हमारी टीम के पास उत्पाद प्रबंधक, अपना स्वयं का व्यवसायिक कार्य क्षेत्र और हमारे द्वारा समर्थित सेवाओं की सूची नहीं है ...;
हमारी योग्यताएं अक्सर छाया में रहती हैं;
अंत में, "यदि आप इसका पता लगाना चाहते हैं, तो इसे किसी को समझाने की कोशिश करें" :)

इसलिए, मैं समझने योग्य उदाहरणों के साथ समझने की कोशिश करूंगा कि हमारे काम वास्तव में क्या हैं।

आइए सबसे सामान्य से शुरू करें, अर्थात्, प्राथमिकताओं के साथ, उनमें से दो हैं:

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

इन प्राथमिकताओं से हमारे कार्य की मुख्य दिशाएँ अनुसरण करती हैं:

0. वास्तुकला का समर्थन और विकास

hh.ru उपयोगकर्ताओं से 5-6k rps है, 10k तक पहुंचने वाले शिखर पर, जो परिमाण के एक क्रम से बढ़ता है, बैकएंड तक पहुंचता है। यह 3 डीसी में लगभग 150 सेवाओं को कताई करते हुए 1,500 से अधिक उदाहरण हैं। तो हाँ, सबसे पहले, ये वर्ग, बैंकों और तीरों के साथ बहुत ही शाखाएं हैं: कौन कहाँ जाता है, कहाँ होना चाहिए। बेशक, हम योजनाओं को आकर्षित नहीं करते हैं - हम स्वचालन, लॉगिंग और निगरानी के साथ जरूरतों को कवर करते हैं, लेकिन हम अपने छात्रों को डराते हैं, उदाहरण के लिए, ऐसी चीजों के साथ:

हम वास्तुकला में बाधाओं और अनम्य समाधानों को खोजने और उन्हें समाप्त करने और जरूरतों के अनुसार इसे विकसित करने के लिए वास्तव में जिम्मेदार हैं।

मैं एक उदाहरण दूंगा:

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

सभी कार्यों के लिए विफलता का बिंदु
अद्वितीय विन्यास केवल उत्पादों में पुन: पेश किया
ऐसे कार्य जिनका तर्क एक अलग बोल्ड मशीन पर समर्पित लॉन्च के लिए डिज़ाइन किया गया है और क्षैतिज रूप से पैमाने पर नहीं है

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

1. बैसाखी का मानकीकरण

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

मानकीकरण के ऐसे स्पष्ट उदाहरणों के अलावा, ऐसे भी हैं जिनमें यह विशेष समाधानों को सामान्य बनाने के लिए समझ में आता है।

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

1.0। कीड़े

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

मैंने डेमो स्टेज jpoint 2019 में jvm सेटिंग्स से संबंधित एक और सामान्य बग के बारे में बात की ।

और क्या, उदाहरण के लिए, एक बग के साथ करने के लिए जिसे सप्ताह में एक बार एक उदाहरण पर पुन: पेश किया जाता है, एक पुनरारंभ के साथ व्यवहार किया जाता है, लेकिन न तो लोड और न ही सिंथेटिक्स इसे पुन: पेश करते हैं?

, java- . nuts-and-bolts:

"qtp1778300121-22" #22 prio=5 os_prio=0 cpu=797.67ms elapsed=11737.06s tid=0x00007f5890139000 nid=0x26 waiting for monitor entry [0x00007f58922c7000]
java.lang.Thread.State: BLOCKED (on object monitor)
at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:63)
- waiting to lock <0x00000000e86acad0> (a ru.hh.nab.logging.HhSyslogAppender)
at ru.hh.nab.logging.HhMultiAppender.doAppend(HhMultiAppender.java:47)
at ru.hh.nab.logging.HhMultiAppender.doAppend(HhMultiAppender.java:21)
at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51)

"qtp1778300121-22" #22 prio=5 os_prio=0 cpu=5718.81ms elapsed=7767.14s tid=0x00007f1537dba000 nid=0x24 waiting for monitor entry [0x00007f153d2b9000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(java.base@11.0.4/ConcurrentHashMap.java:1723)
- waiting to lock <0x00000000e976a668> (a java.util.concurrent.ConcurrentHashMap$Node)
at org.springframework.beans.factory.BeanFactoryUtils.transformedBeanName(BeanFactoryUtils.java:86)

jackson:

"qtp1778300121-23" #23 prio=5 os_prio=0 cpu=494.19ms elapsed=7234.32s tid=0x00007f6c01218800 nid=0x25 waiting for monitor entry [0x00007f6c07cfa000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.glassfish.jersey.jackson.internal.jackson.jaxrs.base.ProviderBase._endpointForWriting(ProviderBase.java:711)
- waiting to lock <0x00000000e9f94c38> (a org.glassfish.jersey.jackson.internal.jackson.jaxrs.util.LRUMap)
at org.glassfish.jersey.jackson.internal.jackson.jaxrs.base.ProviderBase.writeTo(ProviderBase.java:588)

Code Cache:

java . java, , - . , .

1.1। सामान्य निर्णय

कभी-कभी यह गंभीर समस्या बनने से पहले मानक समाधान के साथ आना संभव है। उदाहरण के रूप में, हम प्रसंस्करण लॉग्स के कार्य का हवाला दे सकते हैं जो हमारे व्लाद सेनिन ने उसी jpoint 2019 पर बात की थी , या हमारे http क्लाइंट में टाइमआउट के प्रबंधन के कार्य के बारे में।

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

अब तक, ऐसी स्थितियां केवल तनाव परीक्षण के तहत दिखाई देती हैं, लेकिन मैं इससे पहले कि यह समस्या बन जाए, मैं उन्हें हल करना चाहता हूं।

1.2। खुले मामले

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

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

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

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

2. हम कैसे काम करते हैं

हमारे काम की दिशाओं के बारे में कहानी अधूरी होगी कि हम इस सब के साथ कैसे काम करेंगे।

शुरू करने के लिए, मुझे "आर्किटेक्चर" में काम करने के लिए क्या आकर्षित किया और हमें क्या प्रेरित किया: हम वास्तव में गुणवत्ता के लिए काम करते हैं।

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

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

समापन के करीब, मैं उन बाधाओं के बारे में बात करना चाहूंगा जो अभी भी हमारे रास्ते में उत्पन्न होती हैं। इसके बिना, हमारे काम के बारे में एक कहानी बेईमानी होगी। इसलिए।

2.0। मूल्यांकन कार्यों में कठिनाई

जैसा कि मैंने ऊपर कहा, हम सभी कार्यों के लिए लाभकारी प्रभाव का मूल्यांकन नहीं कर सकते हैं। जब किसी फंक्शन के लिए "बॉक्सिंग" सॉल्यूशन निकलता है तो टास्क रिलीज़ का समय कितना घट जाएगा? कोड के दो समस्याग्रस्त खंडों में से किसको पहले रिफैक्ट किया जाना चाहिए? कार्यों के आकलन के लिए एक पर्याप्त प्रणाली विकसित करने के लिए, हम कई महीनों के लिए सप्ताह में एक-दो बार मिले, लेकिन यह एक अलग पद का विषय है।

2.1। सामूहिक रूप से बेहोश

150 लोगों के लिए कुछ समन्वय करना कोई आसान काम नहीं है। हमारी बहुत विकेन्द्रीकृत संगठनात्मक संरचना सबसे अधिक बार अपने सबसे अच्छे पक्षों के साथ खुद को प्रकट करती है, लेकिन "वास्तुकला" के लिए यह कभी-कभी एक गंभीर बाधा है। ऐसे बहुत कम समझौते होते हैं, जिन पर किसी समझौते पर पहुंचना संभव होता है, यहां तक कि उन लोगों से भी जिनकी अनुपालन पर नजर रखी जा सकती है।

और सभी परिवर्तनों को सुचारू रूप से रोल किया जाना चाहिए। सेवा को महीनों तक अपडेट नहीं किया जा सकता है, लेकिन अभी भी एक अखंड है ... खैर, काफी दुख की बात है।

तो हमने बात की

मुझे उम्मीद है कि मेरी कहानी के बाद मैंने थोड़ा स्पष्ट किया कि hh.ru में "आर्किटेक्चर" क्या करता है। और अगर मैं हमारे काम में आपकी दिलचस्पी जगाने में कामयाब रहा, तो यह आम तौर पर शानदार है। इसके अलावा, अभी हमारी टीम में एक वैकेंसी खुली है । हम नए विचारों के लिए बहुत खुश होंगे जो हमें बेकार की झलकियों से छुपाने में मदद करेंगे, लेकिन इस तरह की महत्वपूर्ण जीत।

ps मूल केडीपीवी है, यह पता चला है, इस आदमी का एक चित्रण है । मुझे आशा है कि वह केडीपीवी के रूप में अपनी छवियों के उपयोग के खिलाफ नहीं हैं

वास्तुकला देखें? और मैं नहीं देखता, लेकिन वह है