హలో! నా పేరు వాడిమ్ మాడిసన్, నేను Avito సిస్టమ్ ప్లాట్‌ఫారమ్ అభివృద్ధికి నాయకత్వం వహిస్తున్నాను. కంపెనీలో మేము ఏకశిలా నిర్మాణం నుండి మైక్రోసర్వీస్‌కి ఎలా మారుతున్నామో ఒకటి కంటే ఎక్కువసార్లు చెప్పబడింది. మైక్రోసర్వీస్‌ల నుండి అత్యధిక ప్రయోజనాలను పొందడానికి మరియు వాటిలో మనం కోల్పోకుండా నిరోధించడానికి మేము మా మౌలిక సదుపాయాలను ఎలా మార్చుకున్నామో పంచుకోవడానికి ఇది సమయం. PaaS ఇక్కడ మాకు ఎలా సహాయపడుతుంది, మేము విస్తరణను ఎలా సులభతరం చేసాము మరియు మైక్రోసర్వీస్ సృష్టిని ఒక క్లిక్‌కి ఎలా తగ్గించాము - చదవండి. నేను క్రింద వ్రాసే ప్రతిదీ Avitoలో పూర్తిగా అమలు చేయబడదు, వాటిలో కొన్ని మేము మా ప్లాట్‌ఫారమ్‌ను ఎలా అభివృద్ధి చేస్తాము.

(మరియు ఈ వ్యాసం చివరలో, మైక్రోసర్వీస్ ఆర్కిటెక్చర్ నిపుణుడు క్రిస్ రిచర్డ్‌సన్ నుండి మూడు రోజుల సెమినార్‌కు హాజరయ్యే అవకాశం గురించి నేను మాట్లాడతాను).

మేము మైక్రోసర్వీస్‌కి ఎలా వచ్చాము

Avito ప్రపంచంలోని అతిపెద్ద వర్గీకృత సైట్లలో ఒకటి; రోజుకు 15 మిలియన్లకు పైగా కొత్త ప్రకటనలు ప్రచురించబడతాయి. మా బ్యాకెండ్ సెకనుకు 20 వేల కంటే ఎక్కువ అభ్యర్థనలను అంగీకరిస్తుంది. మేము ప్రస్తుతం అనేక వందల మైక్రోసర్వీస్‌లను కలిగి ఉన్నాము.

మేము ఇప్పుడు చాలా సంవత్సరాలుగా మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌ని నిర్మిస్తున్నాము. ఎలా సరిగ్గా - మా సహోద్యోగులు వివరంగా చెప్పారు RIT++ 2017లో మా విభాగంలో. CodeFest 2017లో (చూడండి. видео), సెర్గీ ఓర్లోవ్ మరియు మిఖాయిల్ ప్రోకోప్‌చుక్ మైక్రోసర్వీస్‌లకు ఎందుకు మారాలి మరియు ఇక్కడ కుబెర్నెట్స్ ఏ పాత్ర పోషించారో వివరంగా వివరించారు. బాగా, ఇప్పుడు మేము అటువంటి నిర్మాణంలో అంతర్లీనంగా ఉన్న స్కేలింగ్ ఖర్చులను తగ్గించడానికి ప్రతిదీ చేస్తున్నాము.

ప్రారంభంలో, మైక్రోసర్వీస్‌లను అభివృద్ధి చేయడానికి మరియు ప్రారంభించడంలో మాకు సమగ్రంగా సహాయపడే పర్యావరణ వ్యవస్థను మేము సృష్టించలేదు. వారు సెన్సిబుల్ ఓపెన్ సోర్స్ సొల్యూషన్స్‌ని సేకరించి, ఇంట్లోనే లాంచ్ చేసారు మరియు వాటితో వ్యవహరించడానికి డెవలపర్‌ని ఆహ్వానించారు. ఫలితంగా, అతను డజను ప్రదేశాలకు (డ్యాష్‌బోర్డ్‌లు, అంతర్గత సేవలు) వెళ్ళాడు, ఆ తర్వాత అతను కోడ్‌ను పాత పద్ధతిలో, ఏకశిలాగా కత్తిరించాలనే కోరికలో బలపడ్డాడు. దిగువ రేఖాచిత్రాలలో ఆకుపచ్చ రంగు డెవలపర్ తన స్వంత చేతులతో ఒక మార్గం లేదా మరొకదానిని ఏమి చేస్తుందో సూచిస్తుంది మరియు పసుపు రంగు ఆటోమేషన్‌ను సూచిస్తుంది.

ఇప్పుడు PaaS CLI యుటిలిటీలో, ఒక కమాండ్‌తో కొత్త సేవ సృష్టించబడుతుంది మరియు మరో రెండింటితో కొత్త డేటాబేస్ జోడించబడింది మరియు స్టేజ్‌కి అమలు చేయబడుతుంది.

"మైక్రో సర్వీస్ ఫ్రాగ్మెంటేషన్" యుగాన్ని ఎలా అధిగమించాలి

ఒక ఏకశిలా నిర్మాణంతో, ఉత్పత్తిలో మార్పుల స్థిరత్వం కొరకు, డెవలపర్లు తమ పొరుగువారితో ఏమి జరుగుతుందో గుర్తించవలసి వచ్చింది. కొత్త ఆర్కిటెక్చర్‌పై పని చేస్తున్నప్పుడు, సేవా సందర్భాలు ఒకదానిపై ఒకటి ఆధారపడవు.

అదనంగా, మైక్రోసర్వీస్ ఆర్కిటెక్చర్ ప్రభావవంతంగా ఉండాలంటే, అనేక ప్రక్రియలను ఏర్పాటు చేయాలి, అవి:

• లాగింగ్;
• అభ్యర్థన ట్రేసింగ్ (జేగర్);
• ఎర్రర్ అగ్రిగేషన్ (సెంట్రీ);
• స్థితిలు, సందేశాలు, కుబెర్నెట్స్ నుండి ఈవెంట్‌లు (ఈవెంట్ స్ట్రీమ్ ప్రాసెసింగ్);
• జాతి పరిమితి / సర్క్యూట్ బ్రేకర్ (మీరు Hystrix ఉపయోగించవచ్చు);
• సర్వీస్ కనెక్టివిటీ నియంత్రణ (మేము నేత్రమేష్ ఉపయోగిస్తాము);
• పర్యవేక్షణ (గ్రాఫానా);
• అసెంబ్లీ (టీమ్‌సిటీ);
• కమ్యూనికేషన్ మరియు నోటిఫికేషన్ (స్లాక్, ఇమెయిల్);
• టాస్క్ ట్రాకింగ్; (జిరా)
• డాక్యుమెంటేషన్ తయారీ.

సిస్టమ్ దాని సమగ్రతను కోల్పోకుండా మరియు అది స్కేల్ చేస్తున్నప్పుడు ప్రభావవంతంగా ఉండేలా చూసుకోవడానికి, మేము Avitoలో మైక్రోసర్వీస్‌ల సంస్థను పునరాలోచించాము.

మేము మైక్రోసర్వీస్‌లను ఎలా నిర్వహిస్తాము

అనేక Avito మైక్రోసర్వీస్‌లలో ఏకీకృత "పార్టీ విధానం" అమలు చేయడానికి క్రింది సహాయం:

• మౌలిక సదుపాయాలను పొరలుగా విభజించడం;
• ఒక సేవ (PaaS) కాన్సెప్ట్‌గా ప్లాట్‌ఫారమ్;
• మైక్రోసర్వీస్‌తో జరిగే ప్రతిదాన్ని పర్యవేక్షిస్తుంది.

ఇన్‌ఫ్రాస్ట్రక్చర్ అబ్‌స్ట్రాక్షన్ లేయర్‌లు మూడు లేయర్‌లను కలిగి ఉంటాయి. పై నుండి క్రిందికి వెళ్దాం.

A. టాప్ - సర్వీస్ మెష్. మొదట మేము ఇస్టియోని ప్రయత్నించాము, కానీ ఇది చాలా ఎక్కువ వనరులను ఉపయోగిస్తుందని తేలింది, ఇది మా వాల్యూమ్‌లకు చాలా ఖరీదైనది. అందువల్ల, ఆర్కిటెక్చర్ బృందంలోని సీనియర్ ఇంజనీర్ అలెగ్జాండర్ లుక్యాంచెంకో తన సొంత పరిష్కారాన్ని అభివృద్ధి చేశాడు - నేత్రమేష్ (ఓపెన్ సోర్స్‌లో అందుబాటులో ఉంది), మేము ప్రస్తుతం ఉత్పత్తిలో ఉపయోగిస్తున్నాము మరియు ఇది ఇస్టియో కంటే చాలా రెట్లు తక్కువ వనరులను వినియోగిస్తుంది (కానీ ఇస్టియో గొప్పగా చెప్పుకునే ప్రతిదాన్ని చేయదు).
బి. మీడియం - కుబెర్నెట్స్. మేము దానిపై మైక్రోసర్వీస్‌లను అమలు చేస్తాము మరియు నిర్వహిస్తాము.
C. దిగువ - బేర్ మెటల్. మేము మేఘాలు లేదా OpenStack వంటి వాటిని ఉపయోగించము, కానీ పూర్తిగా బేర్ మెటల్‌పై ఆధారపడతాము.

అన్ని లేయర్‌లు PaaS ద్వారా మిళితం చేయబడ్డాయి. మరియు ఈ వేదిక, క్రమంగా, మూడు భాగాలను కలిగి ఉంటుంది.

I. జనరేటర్లు, CLI యుటిలిటీ ద్వారా నియంత్రించబడుతుంది. మైక్రోసర్వీస్‌ను సరైన మార్గంలో మరియు కనీస ప్రయత్నంతో రూపొందించడంలో డెవలపర్‌కి సహాయపడేది ఆమె.

II. ఏకీకృత కలెక్టర్ సాధారణ డాష్‌బోర్డ్ ద్వారా అన్ని సాధనాల నియంత్రణతో.

III. నిల్వ. ముఖ్యమైన చర్యల కోసం స్వయంచాలకంగా ట్రిగ్గర్‌లను సెట్ చేసే షెడ్యూలర్‌లతో కనెక్ట్ అవుతుంది. అటువంటి వ్యవస్థకు ధన్యవాదాలు, ఎవరైనా జిరాలో టాస్క్‌ను సెటప్ చేయడం మరచిపోయినందున ఒక్క పని కూడా తప్పిపోదు. ఇందుకోసం అట్లాస్ అనే ఇంటర్నల్ టూల్‌ని ఉపయోగిస్తాం.

Avitoలో మైక్రోసర్వీస్ అమలు కూడా ఒకే పథకం ప్రకారం నిర్వహించబడుతుంది, ఇది అభివృద్ధి మరియు విడుదల యొక్క ప్రతి దశలో వాటిపై నియంత్రణను సులభతరం చేస్తుంది.

ప్రామాణిక మైక్రోసర్వీస్ డెవలప్‌మెంట్ పైప్‌లైన్ ఎలా పని చేస్తుంది?

సాధారణంగా, మైక్రోసర్వీస్ సృష్టి గొలుసు ఇలా కనిపిస్తుంది:

CLI-పుష్ → నిరంతర ఏకీకరణ → బేక్ → డిప్లాయ్ → కృత్రిమ పరీక్షలు → కానరీ పరీక్షలు → స్క్వీజ్ టెస్టింగ్ → ఉత్పత్తి → నిర్వహణ.

ఈ క్రమంలో సరిగ్గా దాని ద్వారా వెళ్దాం.

CLI-పుష్

• మైక్రోసర్వీస్‌ని సృష్టిస్తోంది.
మైక్రోసర్వీస్‌లు ఎలా చేయాలో ప్రతి డెవలపర్‌కు నేర్పడానికి మేము చాలా కాలం పాటు కష్టపడ్డాము. సంగమంలో వివరణాత్మక సూచనలను వ్రాయడం ఇందులో ఉంది. కానీ పథకాలు మార్చబడ్డాయి మరియు అనుబంధంగా ఉన్నాయి. ఫలితం ఏమిటంటే, ప్రయాణం ప్రారంభంలో ఒక అడ్డంకి కనిపించింది: మైక్రోసర్వీస్‌లను ప్రారంభించడానికి ఇది చాలా ఎక్కువ సమయం పట్టింది మరియు వాటి సృష్టి సమయంలో తరచుగా సమస్యలు తలెత్తుతాయి.

చివరికి, మేము మైక్రోసర్వీస్‌ను సృష్టించేటప్పుడు ప్రాథమిక దశలను ఆటోమేట్ చేసే సాధారణ CLI యుటిలిటీని రూపొందించాము. నిజానికి, ఇది మొదటి git పుష్‌ను భర్తీ చేస్తుంది. సరిగ్గా ఆమె ఏమి చేస్తుందో ఇక్కడ ఉంది.

— టెంప్లేట్ ప్రకారం సేవను సృష్టిస్తుంది — దశల వారీగా, “విజార్డ్” మోడ్‌లో. మేము Avito బ్యాకెండ్‌లో ప్రధాన ప్రోగ్రామింగ్ భాషల కోసం టెంప్లేట్‌లను కలిగి ఉన్నాము: PHP, గోలాంగ్ మరియు పైథాన్.

- ఒక సమయంలో ఒక కమాండ్ నిర్దిష్ట మెషీన్‌లో స్థానిక అభివృద్ధి కోసం వాతావరణాన్ని అమలు చేస్తుంది - మినీక్యూబ్ ప్రారంభించబడింది, హెల్మ్ చార్ట్‌లు స్వయంచాలకంగా రూపొందించబడతాయి మరియు స్థానిక కుబెర్నెట్‌లలో ప్రారంభించబడతాయి.

- అవసరమైన డేటాబేస్ను కనెక్ట్ చేస్తుంది. డెవలపర్ తనకు అవసరమైన డేటాబేస్‌కు యాక్సెస్ పొందడానికి IP, లాగిన్ మరియు పాస్‌వర్డ్ తెలుసుకోవాల్సిన అవసరం లేదు - అది స్థానికంగా, స్టేజ్‌లో లేదా ఉత్పత్తిలో కావచ్చు. అంతేకాకుండా, డేటాబేస్ వెంటనే తప్పు-తట్టుకునే కాన్ఫిగరేషన్‌లో మరియు బ్యాలెన్సింగ్‌తో అమలు చేయబడుతుంది.

- ఇది ప్రత్యక్ష అసెంబ్లీని స్వయంగా నిర్వహిస్తుంది. డెవలపర్ తన IDE ద్వారా మైక్రోసర్వీస్‌లో ఏదైనా సరిదిద్దాడని అనుకుందాం. యుటిలిటీ ఫైల్ సిస్టమ్‌లో మార్పులను చూస్తుంది మరియు వాటి ఆధారంగా అప్లికేషన్‌ను (గోలాంగ్ కోసం) పునర్నిర్మించి పునఃప్రారంభిస్తుంది. PHP కోసం, మేము క్యూబ్ లోపల డైరెక్టరీని ఫార్వార్డ్ చేస్తాము మరియు అక్కడ లైవ్-రీలోడ్ "ఆటోమేటిక్‌గా" పొందబడుతుంది.

- ఆటోటెస్ట్‌లను రూపొందిస్తుంది. ఖాళీల రూపంలో, కానీ ఉపయోగం కోసం చాలా అనుకూలంగా ఉంటుంది.

• మైక్రోసర్వీస్ విస్తరణ.

మైక్రోసర్వీస్‌ని అమలు చేయడం మాకు కొంత పనిగా ఉండేది. కిందివి అవసరం:

I. డాకర్‌ఫైల్.

II. కాన్ఫిగర్.
III. హెల్మ్ చార్ట్, ఇది గజిబిజిగా ఉంటుంది మరియు వీటిని కలిగి ఉంటుంది:

- పటాలు తాము;
- టెంప్లేట్లు;
- వివిధ వాతావరణాలను పరిగణనలోకి తీసుకొని నిర్దిష్ట విలువలు.

మేము Kubernetes మానిఫెస్ట్‌లను మళ్లీ పని చేయడం వల్ల బాధను తొలగించాము కాబట్టి అవి ఇప్పుడు స్వయంచాలకంగా ఉత్పన్నమవుతాయి. కానీ ముఖ్యంగా, వారు పరిమితికి విస్తరణను సరళీకృతం చేశారు. ఇప్పటి నుండి మాకు డాకర్‌ఫైల్ ఉంది మరియు డెవలపర్ మొత్తం కాన్ఫిగరేషన్‌ను ఒకే చిన్న app.toml ఫైల్‌లో వ్రాస్తారు.

అవును, మరియు app.toml లోనే ఒక నిమిషం పాటు ఏమీ చేయాల్సిన పని లేదు. మేము సేవ యొక్క ఎక్కడ మరియు ఎన్ని కాపీలను (దేవ్ సర్వర్‌లో, స్టేజింగ్‌లో, ఉత్పత్తిలో) పెంచాలి మరియు దాని డిపెండెన్సీలను సూచిస్తాము. [ఇంజిన్] బ్లాక్‌లో లైన్ పరిమాణం = "చిన్నది" గమనించండి. ఇది Kubernetes ద్వారా సేవకు కేటాయించబడే పరిమితి.

అప్పుడు, కాన్ఫిగరేషన్ ఆధారంగా, అవసరమైన అన్ని హెల్మ్ చార్ట్‌లు స్వయంచాలకంగా ఉత్పత్తి చేయబడతాయి మరియు డేటాబేస్‌లకు కనెక్షన్‌లు సృష్టించబడతాయి.

• ప్రాథమిక ధ్రువీకరణ. ఇటువంటి తనిఖీలు కూడా స్వయంచాలకంగా ఉంటాయి.
ట్రాక్ అవసరం:
— డాకర్ ఫైల్ ఉందా;
— app.toml ఉందా;
- డాక్యుమెంటేషన్ అందుబాటులో ఉందా?
- డిపెండెన్సీ క్రమంలో ఉందా?
- హెచ్చరిక నియమాలు సెట్ చేయబడిందా.
చివరి పాయింట్ వరకు: సేవ యొక్క యజమాని స్వయంగా ఏ ఉత్పత్తి కొలమానాలను పర్యవేక్షించాలో నిర్ణయిస్తారు.

• డాక్యుమెంటేషన్ తయారీ.
ఇప్పటికీ సమస్యాత్మక ప్రాంతం. ఇది చాలా స్పష్టంగా కనిపిస్తుంది, కానీ అదే సమయంలో ఇది "తరచుగా మరచిపోయే" రికార్డ్ కూడా, మరియు అందువల్ల గొలుసులో హాని కలిగించే లింక్.
ప్రతి మైక్రోసర్వీస్ కోసం డాక్యుమెంటేషన్ ఉండటం అవసరం. ఇది క్రింది బ్లాక్‌లను కలిగి ఉంటుంది.

I. సేవ యొక్క సంక్షిప్త వివరణ. ఇది ఏమి చేస్తుంది మరియు ఎందుకు అవసరమవుతుంది అనే దాని గురించి అక్షరాలా కొన్ని వాక్యాలు.

II. ఆర్కిటెక్చర్ రేఖాచిత్రం లింక్. మీరు రెడిస్‌ని కాషింగ్ కోసం ఉపయోగిస్తున్నారా లేదా పెర్‌సిస్టెంట్ మోడ్‌లో మెయిన్ డేటా స్టోర్‌గా ఉపయోగిస్తున్నారా అనే విషయాన్ని శీఘ్ర చూపుతో అర్థం చేసుకోవడం చాలా ముఖ్యం. అవిటోలో ప్రస్తుతానికి ఇది సంగమానికి లింక్.

III. రన్‌బుక్. సేవను ప్రారంభించడం మరియు దానిని నిర్వహించడంలో ఉన్న చిక్కుల గురించి ఒక చిన్న గైడ్.

IV. ఎఫ్ ఎ క్యూ, సేవతో పని చేస్తున్నప్పుడు మీ సహోద్యోగులు ఎదుర్కొనే సమస్యలను ముందుగా ఊహించడం మంచిది.

V. API కోసం ముగింపు పాయింట్ల వివరణ. అకస్మాత్తుగా మీరు గమ్యస్థానాలను పేర్కొనకపోతే, మీ మైక్రోసర్వీస్‌లకు సంబంధించిన సహోద్యోగులు దాదాపు ఖచ్చితంగా దాని కోసం చెల్లిస్తారు. ఇప్పుడు మేము స్వాగర్‌ని ఉపయోగిస్తాము మరియు దీని కోసం సంక్షిప్తంగా పిలువబడే మా పరిష్కారాన్ని ఉపయోగిస్తాము.

VI. లేబుల్స్. లేదా సేవ ఏ ఉత్పత్తి, కార్యాచరణ లేదా కంపెనీ నిర్మాణ విభాగానికి చెందినదో చూపే మార్కర్‌లు. మీ సహోద్యోగులు ఒక వారం క్రితం అదే వ్యాపార యూనిట్ కోసం రూపొందించిన కార్యాచరణను మీరు తగ్గించుకుంటున్నారా లేదా అనే విషయాన్ని త్వరగా అర్థం చేసుకోవడంలో అవి మీకు సహాయపడతాయి.

VII. సేవ యొక్క యజమాని లేదా యజమానులు. చాలా సందర్భాలలో, ఇది — లేదా వాటిని — PaaSని ఉపయోగించి స్వయంచాలకంగా నిర్ణయించబడుతుంది, అయితే సురక్షితంగా ఉండటానికి, డెవలపర్ వాటిని మాన్యువల్‌గా పేర్కొనవలసి ఉంటుంది.

చివరగా, కోడ్ రివ్యూ మాదిరిగానే డాక్యుమెంటేషన్‌ను సమీక్షించడం మంచి పద్ధతి.

నిరంతర ఇంటిగ్రేషన్

• రిపోజిటరీలను సిద్ధం చేస్తోంది.
• టీమ్‌సిటీలో పైప్‌లైన్ సృష్టిస్తోంది.
• హక్కులను సెట్ చేయడం.
• సేవా యజమానుల కోసం శోధించండి. ఇక్కడ హైబ్రిడ్ పథకం ఉంది - PaaS నుండి మాన్యువల్ మార్కింగ్ మరియు కనిష్ట ఆటోమేషన్. మరొక డెవలప్‌మెంట్ బృందానికి మద్దతు కోసం సేవలు బదిలీ చేయబడినప్పుడు లేదా ఉదాహరణకు, సర్వీస్ డెవలపర్ నిష్క్రమించినప్పుడు పూర్తిగా ఆటోమేటిక్ స్కీమ్ విఫలమవుతుంది.
• అట్లాస్‌లో సేవను నమోదు చేస్తోంది (పైన చుడండి). దాని అన్ని యజమానులు మరియు డిపెండెన్సీలతో.
• వలసలను తనిఖీ చేస్తోంది. వాటిలో ఏవైనా ప్రమాదకరమైనవిగా ఉన్నాయో లేదో మేము తనిఖీ చేస్తాము. ఉదాహరణకు, సేవ యొక్క విభిన్న సంస్కరణల మధ్య డేటా స్కీమా యొక్క అనుకూలతను విచ్ఛిన్నం చేయగల ఆల్టర్ టేబుల్ లేదా మరేదైనా వాటిలో ఒకటి పాపప్ అవుతుంది. అప్పుడు మైగ్రేషన్ నిర్వహించబడదు, కానీ సబ్‌స్క్రిప్షన్‌లో ఉంచబడుతుంది - దానిని ఉపయోగించడానికి సురక్షితంగా ఉన్నప్పుడు సేవా యజమానికి PaaS తప్పనిసరిగా సిగ్నల్ ఇవ్వాలి.

రొట్టెలుకాల్చు

తదుపరి దశ విస్తరణకు ముందు ప్యాకేజింగ్ సేవలు.

• అప్లికేషన్ బిల్డింగ్. క్లాసిక్‌ల ప్రకారం - డాకర్ చిత్రంలో.
• సేవ మరియు సంబంధిత వనరుల కోసం హెల్మ్ చార్ట్‌ల ఉత్పత్తి. డేటాబేస్‌లు మరియు కాష్‌తో సహా. CLI-పుష్ దశలో రూపొందించబడిన app.toml కాన్ఫిగరేషన్‌కు అనుగుణంగా అవి స్వయంచాలకంగా సృష్టించబడతాయి.
• పోర్ట్‌లను తెరవడానికి నిర్వాహకులకు టిక్కెట్‌లను సృష్టిస్తోంది (అవసరమైనప్పుడు).
• యూనిట్ పరీక్షలను అమలు చేయడం మరియు కోడ్ కవరేజీని గణించడం. కోడ్ కవరేజ్ పేర్కొన్న థ్రెషోల్డ్ కంటే తక్కువగా ఉంటే, అప్పుడు సేవ మరింత ముందుకు సాగదు - విస్తరణకు. ఇది ఆమోదయోగ్యమైన అంచున ఉన్నట్లయితే, సేవకు "నిరాశ కలిగించే" గుణకం కేటాయించబడుతుంది: అప్పుడు, కాలక్రమేణా సూచికలో మెరుగుదల లేనట్లయితే, పరీక్షల పరంగా ఎటువంటి పురోగతి లేదని డెవలపర్ నోటిఫికేషన్‌ను అందుకుంటారు ( మరియు దాని గురించి ఏదైనా చేయాలి).
• మెమరీ మరియు CPU పరిమితుల కోసం అకౌంటింగ్. మేము ప్రధానంగా మైక్రోసర్వీస్‌లను గోలాంగ్‌లో వ్రాస్తాము మరియు వాటిని కుబెర్నెట్స్‌లో అమలు చేస్తాము. అందువల్ల గోలాంగ్ భాష యొక్క విశిష్టతతో అనుబంధించబడిన ఒక సూక్ష్మభేదం: డిఫాల్ట్‌గా, ప్రారంభించేటప్పుడు, మెషీన్‌లోని అన్ని కోర్లు ఉపయోగించబడతాయి, మీరు GOMAXPROCS వేరియబుల్‌ను స్పష్టంగా సెట్ చేయకుంటే, మరియు అలాంటి అనేక సేవలు ఒకే మెషీన్‌లో ప్రారంభించబడినప్పుడు, అవి ప్రారంభమవుతాయి. వనరుల కోసం పోటీ పడడం, ఒకరితో ఒకరు జోక్యం చేసుకోవడం. దిగువ గ్రాఫ్‌లు మీరు అప్లికేషన్‌ను వివాదం లేకుండా మరియు వనరుల మోడ్ కోసం రేసులో అమలు చేస్తే అమలు సమయం ఎలా మారుతుందో చూపుతుంది. (గ్రాఫ్‌ల మూలాలు ఇక్కడ).

అమలు సమయం, తక్కువ ఉత్తమం. గరిష్టం: 643ms, కనిష్టం: 42ms. ఫోటో క్లిక్ చేయదగినది.

శస్త్రచికిత్సకు సమయం, తక్కువ సమయం మంచిది. గరిష్టం: 14091 ns, కనిష్టం: 151 ns. ఫోటో క్లిక్ చేయదగినది.

అసెంబ్లీ తయారీ దశలో, మీరు ఈ వేరియబుల్‌ను స్పష్టంగా సెట్ చేయవచ్చు లేదా మీరు లైబ్రరీని ఉపయోగించవచ్చు automaxprocs Uber నుండి వచ్చిన అబ్బాయిల నుండి.

మోహరించేందుకు

• సమావేశాలను తనిఖీ చేస్తోంది. మీరు మీ ఉద్దేశించిన పరిసరాలకు సేవా సమావేశాలను అందించడం ప్రారంభించే ముందు, మీరు ఈ క్రింది వాటిని తనిఖీ చేయాలి:
- API ముగింపు పాయింట్లు.
- స్కీమాతో API ముగింపు పాయింట్ల ప్రతిస్పందనల వర్తింపు.
- లాగ్ ఫార్మాట్.
— సేవకు అభ్యర్థనల కోసం హెడర్‌లను సెట్ చేయడం (ప్రస్తుతం ఇది netramesh ద్వారా చేయబడుతుంది)
- ఈవెంట్ బస్సుకు సందేశాలను పంపేటప్పుడు యజమాని టోకెన్‌ను సెట్ చేయడం. బస్సు అంతటా సేవల కనెక్టివిటీని ట్రాక్ చేయడానికి ఇది అవసరం. మీరు సేవల కనెక్టివిటీని పెంచని (ఇది మంచిది) మరియు సేవల కనెక్టివిటీని బలపరిచే వ్యాపార డేటా (ఇది చాలా చెడ్డది!) రెండింటినీ మీరు బస్సుకు ఐడెంపోటెంట్ డేటాను పంపవచ్చు. మరియు ఈ కనెక్టివిటీ సమస్యగా మారినప్పుడు, బస్సును ఎవరు వ్రాస్తారో మరియు చదివారో అర్థం చేసుకోవడం సేవలను సరిగ్గా వేరు చేయడానికి సహాయపడుతుంది.

Avitoలో ఇంకా చాలా సమావేశాలు లేవు, కానీ వారి పూల్ విస్తరిస్తోంది. అటువంటి ఒప్పందాలు బృందం అర్థం చేసుకోగలిగే మరియు అర్థం చేసుకోగలిగే రూపంలో అందుబాటులో ఉంటే, మైక్రోసర్వీస్‌ల మధ్య స్థిరత్వాన్ని కొనసాగించడం సులభం.

సింథటిక్ పరీక్షలు

• క్లోజ్డ్ లూప్ టెస్టింగ్. దీని కోసం మేము ఇప్పుడు ఓపెన్ సోర్స్ ఉపయోగిస్తున్నాము Hoverfly.io. మొదట, ఇది సేవపై నిజమైన లోడ్‌ను రికార్డ్ చేస్తుంది, ఆపై - కేవలం క్లోజ్డ్ లూప్‌లో - ఇది అనుకరిస్తుంది.

• ఒత్తిడి పరీక్ష. మేము అన్ని సేవలను సరైన పనితీరుకు తీసుకురావడానికి ప్రయత్నిస్తాము. మరియు ప్రతి సేవ యొక్క అన్ని సంస్కరణలు తప్పనిసరిగా లోడ్ పరీక్షకు లోబడి ఉండాలి - ఈ విధంగా మేము సేవ యొక్క ప్రస్తుత పనితీరు మరియు అదే సేవ యొక్క మునుపటి సంస్కరణలతో వ్యత్యాసాన్ని అర్థం చేసుకోవచ్చు. సేవా నవీకరణ తర్వాత, దాని పనితీరు ఒకటిన్నర రెట్లు పడిపోయినట్లయితే, ఇది దాని యజమానులకు స్పష్టమైన సంకేతం: మీరు కోడ్‌ను త్రవ్వి పరిస్థితిని సరిదిద్దాలి.
మేము సేకరించిన డేటాను ఉపయోగిస్తాము, ఉదాహరణకు, ఆటో స్కేలింగ్‌ని సరిగ్గా అమలు చేయడానికి మరియు చివరికి, సేవ ఎంత స్కేలబుల్ అని సాధారణంగా అర్థం చేసుకుంటాము.

లోడ్ పరీక్ష సమయంలో, వనరుల వినియోగం సెట్ పరిమితులకు అనుగుణంగా ఉందో లేదో మేము తనిఖీ చేస్తాము. మరియు మేము ప్రధానంగా విపరీతాలపై దృష్టి పెడతాము.

ఎ) మేము మొత్తం లోడ్‌ను పరిశీలిస్తాము.
- చాలా చిన్నది - లోడ్ అకస్మాత్తుగా చాలా సార్లు పడిపోతే ఏదైనా పని చేయదు.
- చాలా పెద్దది - ఆప్టిమైజేషన్ అవసరం.

బి) మేము RPS ప్రకారం కటాఫ్‌ను చూస్తాము.
ఇక్కడ మేము ప్రస్తుత వెర్షన్ మరియు మునుపటి వెర్షన్ మరియు మొత్తం పరిమాణం మధ్య వ్యత్యాసాన్ని పరిశీలిస్తాము. ఉదాహరణకు, ఒక సేవ 100 rps ఉత్పత్తి చేస్తే, అది పేలవంగా వ్రాయబడింది, లేదా ఇది దాని విశిష్టత, కానీ ఏదైనా సందర్భంలో, సేవను చాలా దగ్గరగా చూడటానికి ఇది ఒక కారణం.
దీనికి విరుద్ధంగా, చాలా ఎక్కువ RPS ఉంటే, బహుశా ఒక రకమైన బగ్ ఉండవచ్చు మరియు కొన్ని ఎండ్‌పాయింట్‌లు పేలోడ్‌ని అమలు చేయడం ఆపివేసి ఉండవచ్చు మరియు మరికొన్ని కేవలం ట్రిగ్గర్ చేయబడి ఉండవచ్చు. return true;

కానరీ పరీక్షలు

మేము సింథటిక్ పరీక్షలలో ఉత్తీర్ణత సాధించిన తర్వాత, మేము తక్కువ సంఖ్యలో వినియోగదారులపై మైక్రోసర్వీస్‌ని పరీక్షిస్తాము. మేము సేవ యొక్క ఉద్దేశించిన ప్రేక్షకులలో తక్కువ వాటాతో జాగ్రత్తగా ప్రారంభిస్తాము - 0,1% కంటే తక్కువ. ఈ దశలో, సరైన సాంకేతిక మరియు ఉత్పత్తి కొలమానాలను పర్యవేక్షణలో చేర్చడం చాలా ముఖ్యం, తద్వారా వారు సేవలో సమస్యను వీలైనంత త్వరగా చూపుతారు. కానరీ పరీక్ష కోసం కనీస సమయం 5 నిమిషాలు, ప్రధానమైనది 2 గంటలు. సంక్లిష్ట సేవల కోసం, మేము మాన్యువల్‌గా సమయాన్ని సెట్ చేస్తాము.
విశ్లేషిద్దాం:
- భాష-నిర్దిష్ట కొలమానాలు, ప్రత్యేకించి, php-fpm కార్మికులు;
- సెంట్రీలో లోపాలు;
- ప్రతిస్పందన స్థితిగతులు;
- ప్రతిస్పందన సమయం, ఖచ్చితమైన మరియు సగటు;
- జాప్యం;
- మినహాయింపులు, ప్రాసెస్ చేయబడినవి మరియు నిర్వహించబడనివి;
- ఉత్పత్తి కొలమానాలు.

స్క్వీజ్ టెస్టింగ్

స్క్వీజ్ టెస్టింగ్‌ను "స్క్వీజింగ్" టెస్టింగ్ అని కూడా అంటారు. టెక్నిక్ పేరు నెట్‌ఫ్లిక్స్‌లో ప్రవేశపెట్టబడింది. దీని సారాంశం ఏమిటంటే, మొదట మనం ఒక ఉదాహరణను నిజమైన ట్రాఫిక్‌తో వైఫల్యం వరకు నింపి, దాని పరిమితిని సెట్ చేస్తాము. అప్పుడు మేము మరొక ఉదాహరణను జోడించి, ఈ జతను లోడ్ చేస్తాము - మళ్లీ గరిష్టంగా; మేము వారి సీలింగ్ మరియు డెల్టాను మొదటి "స్క్వీజ్" తో చూస్తాము. కాబట్టి మేము ఒక సమయంలో ఒక ఉదాహరణను కనెక్ట్ చేస్తాము మరియు మార్పుల నమూనాను గణిస్తాము.
"స్క్వీజింగ్" ద్వారా పరీక్ష డేటా కూడా సాధారణ కొలమానాల డేటాబేస్‌లోకి ప్రవహిస్తుంది, ఇక్కడ మేము వాటితో కృత్రిమ లోడ్ ఫలితాలను మెరుగుపరుస్తాము లేదా వాటితో "సింథటిక్స్"ని కూడా భర్తీ చేస్తాము.

ఉత్పత్తి

• స్కేలింగ్. మేము ఉత్పత్తికి సేవను అందించినప్పుడు, అది ఎలా స్కేల్ అవుతుందో మేము పర్యవేక్షిస్తాము. మా అనుభవంలో, CPU సూచికలను మాత్రమే పర్యవేక్షించడం అసమర్థమైనది. దాని స్వచ్ఛమైన రూపంలో RPS బెంచ్‌మార్కింగ్‌తో ఆటో స్కేలింగ్ పనిచేస్తుంది, కానీ ఆన్‌లైన్ స్ట్రీమింగ్ వంటి కొన్ని సేవలకు మాత్రమే. కాబట్టి మేము ముందుగా అప్లికేషన్-నిర్దిష్ట ఉత్పత్తి కొలమానాలను పరిశీలిస్తాము.

ఫలితంగా, స్కేలింగ్ చేసేటప్పుడు మేము విశ్లేషిస్తాము:
- CPU మరియు RAM సూచికలు,
- క్యూలో అభ్యర్థనల సంఖ్య,
- ప్రతిస్పందన సమయం,
- సేకరించిన చారిత్రక డేటా ఆధారంగా అంచనా.

సేవను స్కేలింగ్ చేసేటప్పుడు, దాని డిపెండెన్సీలను పర్యవేక్షించడం కూడా చాలా ముఖ్యం, తద్వారా మేము గొలుసులోని మొదటి సేవను స్కేల్ చేయము మరియు అది యాక్సెస్ చేసేవి లోడ్‌లో విఫలమవుతాయి. మొత్తం సేవల సమూహానికి ఆమోదయోగ్యమైన లోడ్‌ని ఏర్పాటు చేయడానికి, మేము "సమీప" డిపెండెంట్ సర్వీస్ (CPU మరియు RAM సూచికల కలయిక ఆధారంగా, యాప్-నిర్దిష్ట మెట్రిక్‌లతో కలిపి) చారిత్రక డేటాను పరిశీలిస్తాము మరియు వాటిని చారిత్రక డేటాతో సరిపోల్చండి ప్రారంభ సేవ, మరియు "డిపెండెన్సీ చైన్" "అంతటా, పై నుండి క్రిందికి.

సేవ

మైక్రోసర్వీస్ ఆపరేషన్‌లో ఉంచబడిన తర్వాత, మేము దానికి ట్రిగ్గర్‌లను జోడించవచ్చు.

ట్రిగ్గర్లు సంభవించే సాధారణ పరిస్థితులు ఇక్కడ ఉన్నాయి.
- సంభావ్య ప్రమాదకరమైన వలసలు కనుగొనబడ్డాయి.
- భద్రతా నవీకరణలు విడుదల చేయబడ్డాయి.
- సేవ చాలా కాలం వరకు నవీకరించబడలేదు.
— సేవపై లోడ్ గణనీయంగా తగ్గింది లేదా దాని ఉత్పత్తి కొలమానాలలో కొన్ని సాధారణ పరిధికి వెలుపల ఉన్నాయి.
— సేవ ఇకపై కొత్త ప్లాట్‌ఫారమ్ అవసరాలను తీర్చదు.

కొన్ని ట్రిగ్గర్‌లు ఆపరేషన్ యొక్క స్థిరత్వానికి బాధ్యత వహిస్తాయి, కొన్ని - సిస్టమ్ నిర్వహణ యొక్క విధిగా - ఉదాహరణకు, కొంత సేవ చాలా కాలం పాటు అమలు చేయబడదు మరియు దాని మూల చిత్రం భద్రతా తనిఖీలను పాస్ చేయడం ఆగిపోయింది.

డాష్బోర్డ్

సంక్షిప్తంగా, డ్యాష్‌బోర్డ్ మా మొత్తం PaaS యొక్క నియంత్రణ ప్యానెల్.

• సేవ గురించిన సమాచారం యొక్క ఒకే పాయింట్, దాని పరీక్ష కవరేజ్, దాని చిత్రాల సంఖ్య, ఉత్పత్తి కాపీల సంఖ్య, సంస్కరణలు మొదలైనవి.
• సేవలు మరియు లేబుల్‌ల ద్వారా డేటాను ఫిల్టర్ చేయడానికి ఒక సాధనం (వ్యాపార యూనిట్‌లకు సంబంధించిన గుర్తులు, ఉత్పత్తి కార్యాచరణ మొదలైనవి)
• ట్రేసింగ్, లాగింగ్ మరియు పర్యవేక్షణ కోసం ఇన్‌ఫ్రాస్ట్రక్చర్ టూల్స్‌తో ఏకీకరణ కోసం ఒక సాధనం.
• సర్వీస్ డాక్యుమెంటేషన్ యొక్క ఒకే పాయింట్.
• సేవల్లోని అన్ని ఈవెంట్‌ల యొక్క ఒకే దృక్కోణం.

మొత్తం

PaaSని పరిచయం చేయడానికి ముందు, ఒక కొత్త డెవలపర్ ఉత్పత్తిలో మైక్రోసర్వీస్‌ని ప్రారంభించడానికి అవసరమైన అన్ని సాధనాలను అర్థం చేసుకోవడానికి చాలా వారాలు వెచ్చించవచ్చు: కుబెర్నెట్స్, హెల్మ్, మా అంతర్గత టీమ్‌సిటీ ఫీచర్‌లు, డేటాబేస్‌లు మరియు కాష్‌లకు కనెక్షన్‌లను ఫాల్ట్-టాలరెంట్ పద్ధతిలో సెటప్ చేయడం మొదలైనవి. ఇప్పుడు ఇది శీఘ్రప్రారంభాన్ని చదవడానికి మరియు సేవను సృష్టించడానికి కొన్ని గంటల సమయం పడుతుంది.

నేను HighLoad++ 2018 కోసం ఈ అంశంపై నివేదిక ఇచ్చాను, మీరు దీన్ని చూడవచ్చు видео и ప్రదర్శన.

చివరి వరకు చదివిన వారికి బోనస్ ట్రాక్

మేము Avito వద్ద డెవలపర్‌ల కోసం అంతర్గత మూడు రోజుల శిక్షణను నిర్వహిస్తున్నాము క్రిస్ రిచర్డ్సన్, మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌లో నిపుణుడు. ఈ పోస్ట్ యొక్క పాఠకులలో ఒకరికి ఇందులో పాల్గొనే అవకాశం ఇవ్వాలనుకుంటున్నాము. ఇది శిక్షణ కార్యక్రమం పోస్ట్ చేయబడింది.

శిక్షణ ఆగస్టు 5 నుండి 7 వరకు మాస్కోలో జరుగుతుంది. ఇవి పూర్తిగా ఆక్రమించబడే పని దినాలు. భోజనం మరియు శిక్షణ మా కార్యాలయంలో ఉంటుంది మరియు ఎంపికైన పాల్గొనేవారు ప్రయాణ మరియు వసతి కోసం స్వయంగా చెల్లిస్తారు.

మీరు పాల్గొనడానికి దరఖాస్తు చేసుకోవచ్చు ఈ గూగుల్ రూపంలో. మీ నుండి - మీరు శిక్షణకు ఎందుకు హాజరు కావాలి అనే ప్రశ్నకు సమాధానం మరియు మిమ్మల్ని ఎలా సంప్రదించాలనే దానిపై సమాచారం. ఆంగ్లంలో సమాధానం ఇవ్వండి, ఎందుకంటే క్రిస్ స్వయంగా శిక్షణకు హాజరయ్యే పాల్గొనేవారిని ఎన్నుకుంటారు.
మేము ఈ పోస్ట్‌కి నవీకరణలో శిక్షణలో పాల్గొనేవారి పేరును మరియు డెవలపర్‌ల కోసం Avito సోషల్ నెట్‌వర్క్‌లలో ప్రకటిస్తాము (AvitoTech in ఫేస్బుక్, ట్విట్టర్, ట్విట్టర్) జూలై 19 తర్వాత కాదు.

మూలం: www.habr.com