ආයුබෝවන්! මගේ නම වඩීම් මැඩිසන්, මම Avito පද්ධති වේදිකාවේ සංවර්ධනයට නායකත්වය දෙමි. සමාගම තුළ අපි මොනොලිතික් ගෘහ නිර්මාණ ශිල්පයේ සිට ක්ෂුද්‍ර සේවා එකකට මාරු වන ආකාරය කිහිප වතාවක්ම පවසා ඇත. ක්ෂුද්‍ර සේවාවලින් උපරිම ප්‍රයෝජන ලබා ගැනීමට සහ ඒවායින් අතරමං වීම වළක්වා ගැනීමට අප අපගේ යටිතල පහසුකම් පරිවර්තනය කර ඇති ආකාරය බෙදා ගැනීමට කාලයයි. PaaS අපට මෙහි උපකාර කරන්නේ කෙසේද, අපි යෙදවීම සරල කළ ආකාරය සහ ක්ෂුද්‍ර සේවාවක් නිර්මාණය කිරීම එක් ක්ලික් කිරීමකට අඩු කළ ආකාරය - කියවන්න. මම පහත ලියන සෑම දෙයක්ම Avito හි සම්පූර්ණයෙන්ම ක්‍රියාත්මක නොවේ, සමහර ඒවා අපි අපගේ වේදිකාව සංවර්ධනය කරන ආකාරයයි.

(සහ මෙම ලිපිය අවසානයේ, මම microservice ගෘහ නිර්මාණ ශිල්පී විශේෂඥ Chris Richardson ගේ තුන් දින සම්මන්ත්‍රණයකට සහභාගී වීමේ අවස්ථාව ගැන කතා කරමි).

අපි කොහොමද microservices වලට ආවේ

Avito යනු ලොව විශාලතම වර්ගීකරණය කරන ලද වෙබ් අඩවි වලින් එකකි; දිනකට නව දැන්වීම් මිලියන 15 කට වඩා ප්‍රකාශයට පත් කෙරේ. අපගේ පසුපෙළ තත්පරයකට ඉල්ලීම් 20 කට වඩා පිළිගනී. අප සතුව දැනට ක්ෂුද්‍ර සේවා සිය ගණනක් ඇත.

අපි දැන් වසර කිහිපයක් තිස්සේ ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පයක් ගොඩනඟමින් සිටිමු. හරියටම කෙසේද - අපගේ සගයන් විස්තරාත්මකව කිව්වා RIT++ 2017 හි අපගේ කොටසේදී. CodeFest 2017 හි (බලන්න. видео), සර්ජි ඔර්ලොව් සහ මිහායිල් ප්‍රොකොප්චුක් අපට ක්ෂුද්‍ර සේවා වෙත සංක්‍රමණය අවශ්‍ය වූයේ මන්දැයි සහ කුබර්නෙට්ස් මෙහි ඉටු කළ කාර්යභාරය විස්තරාත්මකව පැහැදිලි කළේය. හොඳයි, දැන් අපි සෑම දෙයක්ම කරන්නේ එවැනි ගෘහ නිර්මාණ ශිල්පයකට ආවේණික වූ පරිමාණ පිරිවැය අවම කර ගැනීමටයි.

මුලදී, අපි ක්ෂුද්‍ර සේවා සංවර්ධනය කිරීමට සහ දියත් කිරීමට අපට පුළුල් ලෙස උපකාර වන පරිසර පද්ධතියක් නිර්මාණය කළේ නැත. ඔවුන් හුදෙක් සංවේදී විවෘත මූලාශ්‍ර විසඳුම් එකතු කර, ඒවා නිවසේදී දියත් කර ඒවා සමඟ ගනුදෙනු කිරීමට සංවර්ධකයාට ආරාධනා කළහ. එහි ප්‍රතිඵලයක් වශයෙන්, ඔහු ස්ථාන දුසිමකට (උපකරණ පුවරු, අභ්‍යන්තර සේවා) ගිය පසු, කේත පැරණි ක්‍රමයටම ඒකලිතයකින් කපා හැරීමේ ආශාවෙන් ඔහු ශක්තිමත් විය. පහත රූපසටහන් වල හරිත වර්ණය පෙන්නුම් කරන්නේ සංවර්ධකයා තමාගේම දෑතින් එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් කරන දේ වන අතර කහ පැහැය ස්වයංක්‍රීයකරණය පෙන්නුම් කරයි.

දැන් PaaS CLI උපයෝගිතා තුළ, එක් විධානයක් සමඟ නව සේවාවක් සාදනු ලබන අතර, තවත් දෙකක් සමඟ නව දත්ත සමුදායක් එකතු කර අදියර වෙත යොදවනු ලැබේ.

"ක්ෂුද්‍ර සේවා ඛණ්ඩනය" යුගය ජය ගන්නේ කෙසේද?

මොනොලිතික් ගෘහනිර්මාණ ශිල්පයක් සමඟ, නිෂ්පාදනයේ වෙනස්කම්වල අනුකූලතාව සඳහා, සංවර්ධකයින්ට ඔවුන්ගේ අසල්වැසියන් සමඟ සිදුවන්නේ කුමක්දැයි සොයා බැලීමට බල කෙරුනි. නව ගෘහ නිර්මාණ ශිල්පය මත වැඩ කරන විට, සේවා සන්දර්භය තවදුරටත් එකිනෙකා මත රඳා නොපවතී.

මීට අමතරව, ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පයක් ඵලදායී වීමට නම්, බොහෝ ක්‍රියාවලි ස්ථාපිත කළ යුතුය, එනම්:

• ලොග් කිරීම;
• ඉල්ලීම් ලුහුබැඳීම (ජේගර්);
• දෝෂ එකතු කිරීම (Sentry);
• තත්ත්ව, පණිවිඩ, Kubernetes වෙතින් සිදුවීම් (සිදුවීම් ප්‍රවාහ සැකසීම);
• ධාවන සීමාව / පරිපථ කඩනය (ඔබට Hystrix භාවිතා කළ හැක);
• සේවා සම්බන්ධතා පාලනය (අපි Netramesh භාවිතා කරමු);
• අධීක්ෂණ (Grafana);
• එකලස් කිරීම (TeamCity);
• සන්නිවේදනය සහ දැනුම්දීම (ස්ලැක්, ඊමේල්);
• කාර්ය ලුහුබැඳීම; (ජිරා)
• ලේඛන සකස් කිරීම.

පද්ධතිය එහි අඛණ්ඩතාව අහිමි නොවන බව සහතික කිරීම සහ එය පරිමාණය ලෙස ඵලදායීව පවතින බව සහතික කිරීම සඳහා, අපි Avito හි ක්ෂුද්ර සේවා සංවිධානය කිරීම ගැන නැවත සිතා බැලුවෙමු.

අපි ක්ෂුද්‍ර සේවා කළමනාකරණය කරන ආකාරය

බොහෝ Avito ක්ෂුද්‍ර සේවා අතර ඒකාබද්ධ “පක්ෂ ප්‍රතිපත්තියක්” ක්‍රියාත්මක කිරීමට පහත සඳහන් උපකාර වේ:

• යටිතල පහසුකම් ස්ථරවලට බෙදීම;
• සේවා (PaaS) සංකල්පයක් ලෙස වේදිකාව;
• microservices සමඟ සිදු වන සෑම දෙයක්ම නිරීක්ෂණය කිරීම.

යටිතල පහසුකම් වියුක්ත ස්ථරවලට ස්ථර තුනක් ඇතුළත් වේ. අපි ඉහළ සිට පහළට යමු.

A. ඉහළ - සේවා දැලක්. මුලදී අපි ඉස්ටියෝ උත්සාහ කළ නමුත් එය අපගේ වෙළුම් සඳහා මිල අධික වන සම්පත් ඕනෑවට වඩා භාවිතා කරන බව පෙනී ගියේය. එබැවින්, ගෘහ නිර්මාණ කණ්ඩායමේ ජ්යෙෂ්ඨ ඉංජිනේරු ඇලෙක්සැන්ඩර් ලුක්යාන්චෙන්කෝ ඔහුගේම විසඳුමක් නිර්මාණය කළේය - නේත්‍රමේෂ් (Open Source හි ඇත), අපි දැනට නිෂ්පාදනයේදී භාවිතා කරන සහ Istio ට වඩා කිහිප ගුණයකින් අඩු සම්පත් පරිභෝජනය කරන (නමුත් Istio පුරසාරම් දෙඩීමට හැකි සෑම දෙයක්ම නොකරයි).
B. මධ්යම - Kubernetes. අපි එය මත ක්ෂුද්‍ර සේවා යොදවා ක්‍රියාත්මක කරමු.
C. පහළ - හිස් ලෝහ. අපි වලාකුළු හෝ OpenStack වැනි දේවල් භාවිතා නොකරමු, නමුත් සම්පූර්ණයෙන්ම හිස් ලෝහ මත රඳා සිටිමු.

සියලුම ස්ථර PaaS මගින් සංයුක්ත වේ. තවද මෙම වේදිකාව කොටස් තුනකින් සමන්විත වේ.

I. ජනක යන්ත්ර, CLI උපයෝගීතාව හරහා පාලනය වේ. නිවැරදි ආකාරයෙන් සහ අවම උත්සාහයකින් ක්ෂුද්‍ර සේවාවක් නිර්මාණය කිරීමට සංවර්ධකයාට උදව් කරන්නේ ඇයයි.

II. ඒකාබද්ධ එකතු කරන්නා පොදු උපකරණ පුවරුව හරහා සියලු මෙවලම් පාලනය කිරීම සමඟ.

III. ගබඞා. සැලකිය යුතු ක්‍රියා සඳහා ප්‍රේරක ස්වයංක්‍රීයව සකසන උපලේඛන සමඟ සම්බන්ධ වේ. එහෙම සිස්ටම් එකකට පින්සිද්ධ වෙන්න ජිරා එකේ ටාස්ක් එකක් සෙට් කරන්න අමතක උන පලියට එක වැඩක්වත් අතපසු වෙන්නේ නෑ. අපි මේ සඳහා භාවිතා කරන්නේ Atlas නම් අභ්‍යන්තර මෙවලමයි.

Avito හි ක්ෂුද්‍ර සේවා ක්‍රියාත්මක කිරීම ද තනි යෝජනා ක්‍රමයකට අනුව සිදු කරනු ලබන අතර එමඟින් සංවර්ධනයේ සහ මුදා හැරීමේ සෑම අදියරකදීම ඒවා පාලනය කිරීම සරල කරයි.

සම්මත ක්ෂුද්‍ර සේවා සංවර්ධන නල මාර්ගයක් ක්‍රියා කරන්නේ කෙසේද?

පොදුවේ ගත් කල, ක්ෂුද්‍ර සේවා නිර්මාණ දාමය මේ ආකාරයෙන් පෙනේ:

CLI-තල්ලු → අඛණ්ඩ ඒකාබද්ධ කිරීම → පිළිස්සීම → යෙදවීම → කෘතිම පරීක්ෂණ → කැනරි පරීක්ෂණ → මිරිකීම පරීක්ෂා කිරීම → නිෂ්පාදනය → නඩත්තු කිරීම.

අපි එය හරියටම මෙම අනුපිළිවෙල හරහා යමු.

CLI-තල්ලු

• ක්ෂුද්‍ර සේවාවක් නිර්මාණය කිරීම.
සෑම සංවර්ධකයෙකුටම ක්ෂුද්‍ර සේවා කරන ආකාරය ඉගැන්වීමට අපි දිගු කලක් අරගල කළෙමු. Confluence හි සවිස්තරාත්මක උපදෙස් ලිවීම මෙයට ඇතුළත් විය. නමුත් යෝජනා ක්රම වෙනස් වූ අතර අතිරේක විය. ප්‍රති result ලය නම් ගමනේ ආරම්භයේදීම බාධාවක් ඇති වීමයි: ක්ෂුද්‍ර සේවා දියත් කිරීමට වැඩි කාලයක් ගත වූ අතර ඒවා නිර්මාණය කිරීමේදී බොහෝ විට ගැටළු මතු විය.

අවසානයේදී, අපි ක්ෂුද්‍ර සේවාවක් නිර්මාණය කිරීමේදී මූලික පියවර ස්වයංක්‍රීය කරන සරල CLI උපයෝගීතාවයක් ගොඩනඟා ගත්තෙමු. ඇත්ත වශයෙන්ම, එය පළමු git තල්ලුව ප්රතිස්ථාපනය කරයි. මෙන්න ඇය හරියටම කරන දේ.

- අච්චුවකට අනුව සේවාවක් නිර්මාණය කරයි - පියවරෙන් පියවර, "විශාරද" ආකාරයෙන්. Avito පසුබිමේ ප්‍රධාන ක්‍රමලේඛන භාෂා සඳහා සැකිලි අප සතුව ඇත: PHP, Golang සහ Python.

- වරකට එක් විධානයක් නිශ්චිත යන්ත්‍රයක් මත දේශීය සංවර්ධනය සඳහා පරිසරයක් යොදවයි - Minikube දියත් කෙරේ, Helm ප්‍රස්ථාර ස්වයංක්‍රීයව ජනනය කර දේශීය kubernetes තුළ දියත් කෙරේ.

- අවශ්ය දත්ත සමුදාය සම්බන්ධ කරයි. සංවර්ධකයාට අවශ්‍ය දත්ත සමුදායට ප්‍රවේශය ලබා ගැනීම සඳහා IP, පිවිසුම සහ මුරපදය දැන ගැනීමට අවශ්‍ය නොවේ - එය දේශීයව, වේදිකාවේදී හෝ නිෂ්පාදනයේදී වේවා. එපමනක් නොව, දත්ත සමුදාය දෝෂ-ඉවසිය හැකි වින්‍යාසයකින් සහ සමතුලිතතාවයකින් වහාම යොදවනු ලැබේ.

- එය සජීවී එකලස් කිරීම සිදු කරයි. අපි හිතමු සංවර්ධකයෙක් එයාගේ IDE එක හරහා microservice එකක යමක් සවි කළා කියලා. උපයෝගීතාව ගොනු පද්ධතියේ වෙනස්කම් දකින අතර, ඒවා මත පදනම්ව, යෙදුම (Golang සඳහා) නැවත ගොඩනඟා නැවත ආරම්භ කරයි. PHP සඳහා, අපි හුදෙක් කියුබ් තුළ ඇති නාමාවලිය යොමු කරන අතර එහිදී සජීවී-නැවත පූරණය "ස්වයංක්‍රීයව" ලබා ගනී.

- ස්වයං පරීක්ෂණ උත්පාදනය කරයි. හිස් ස්වරූපයෙන්, නමුත් භාවිතයට බෙහෙවින් සුදුසු ය.

• ක්ෂුද්‍ර සේවා යෙදවීම.

ක්ෂුද්‍ර සේවාවක් යෙදවීම අපට ටිකක් වෙහෙසකර කාර්යයක් විය. පහත සඳහන් දෑ අවශ්‍ය විය.

I. ඩොකර්ෆයිල්.

II. වින්යාසය.
III. හෙල්ම් ප්‍රස්ථාරය, එයම අපහසු වන අතර එයට ඇතුළත් වන්නේ:

- ප්රස්ථාර ම;
- සැකිලි;
- විවිධ පරිසරයන් සැලකිල්ලට ගනිමින් නිශ්චිත අගයන්.

අපි Kubernetes මැනිෆෙස්ටස් ප්‍රතිනිර්මාණය කිරීමේ වේදනාව ඉවත් කර ඇති නිසා ඒවා දැන් ස්වයංක්‍රීයව ජනනය වේ. නමුත් වඩාත්ම වැදගත් දෙය නම්, ඔවුන් යෙදවීම සීමාව දක්වා සරල කර ඇත. මෙතැන් සිට අපට Dockerfile එකක් ඇති අතර, සංවර්ධකයා සම්පූර්ණ වින්‍යාසය එකම කෙටි app.toml ගොනුවක ලියයි.

ඔව්, සහ app.toml තුළම විනාඩියකට කිරීමට කිසිවක් නැත. සේවාවේ පිටපත් කීයක් (dev සේවාදායකයේ, වේදිකාගත කිරීමේදී, නිෂ්පාදනයේදී) ඉහළ නැංවිය යුතු ස්ථානය සහ කොපමණ දැයි අපි සඳහන් කර එහි පරායත්තතා දක්වන්නෙමු. [එන්ජිම] බ්ලොක් එකේ රේඛා ප්‍රමාණය = "කුඩා" යන්න සැලකිල්ලට ගන්න. Kubernetes හරහා සේවාව සඳහා වෙන් කරනු ලබන සීමාව මෙයයි.

ඉන්පසුව, වින්‍යාසය මත පදනම්ව, අවශ්‍ය සියලුම හෙල්ම් ප්‍රස්ථාර ස්වයංක්‍රීයව උත්පාදනය වන අතර දත්ත සමුදායන් වෙත සම්බන්ධතා නිර්මාණය වේ.

• මූලික වලංගුකරණය. එවැනි චෙක්පත් ද ස්වයංක්රීය වේ.
නිරීක්ෂණය කිරීමට අවශ්ය:
- Dockerfile එකක් තිබේද;
- app.toml තිබේද;
- ලියකියවිලි තිබේද?
- යැපීම පිළිවෙලට තිබේද?
- අනතුරු ඇඟවීමේ නීති සකස් කර තිබේද යන්න.
අවසාන කරුණ දක්වා: සේවාවේ හිමිකරු විසින්ම නිරීක්ෂණය කළ යුතු නිෂ්පාදන ප්‍රමිතික තීරණය කරයි.

• ලේඛන සකස් කිරීම.
තවමත් ගැටළු සහිත ප්රදේශයකි. එය වඩාත්ම පැහැදිලි බව පෙනේ, නමුත් ඒ සමඟම එය "බොහෝ විට අමතක වූ" වාර්තාවක් ද වන අතර, එබැවින් දාමයේ අවදානමට ලක්විය හැකි සම්බන්ධකයකි.
එක් එක් ක්ෂුද්‍ර සේවා සඳහා ලියකියවිලි තිබීම අවශ්‍ය වේ. එයට පහත කොටස් ඇතුළත් වේ.

I. සේවාව පිළිබඳ කෙටි විස්තරයක්. එය කරන්නේ කුමක්ද සහ එය අවශ්‍ය වන්නේ ඇයිද යන්න පිළිබඳ වාක්‍ය ඛණ්ඩ කිහිපයක්.

II. ගෘහ නිර්මාණ රූප සටහන සබැඳිය. එය ක්ෂණිකව බැලීමෙන් එය තේරුම් ගැනීමට පහසු වීම වැදගත් වේ, උදාහරණයක් ලෙස, ඔබ Redis භාවිතා කරන්නේ හැඹිලිගත කිරීම සඳහාද නැතහොත් ප්‍රධාන දත්ත ගබඩාව ලෙස ස්ථිර ප්‍රකාරයේදීද යන්න. Avito හි දැනට මෙය Confluence වෙත සබැඳියකි.

III. ධාවන පොත. සේවාව ආරම්භ කිරීම සහ එය හැසිරවීමේ සංකීර්ණතා පිළිබඳ කෙටි මාර්ගෝපදේශයක්.

IV. නිති අසන පැණ, සේවාව සමඟ වැඩ කිරීමේදී ඔබේ සගයන් මුහුණ දෙන ගැටළු අපේක්ෂා කිරීම හොඳ වනු ඇත.

V. API සඳහා අන්ත ලක්ෂ්‍ය විස්තරය. හදිසියේම ඔබ ගමනාන්තයන් සඳහන් නොකළේ නම්, ඔබේ ක්ෂුද්‍ර සේවා සම්බන්ධ සගයන් නිසැකවම ඒ සඳහා ගෙවනු ඇත. දැන් අපි Swagger සහ මේ සඳහා කෙටි නම් අපගේ විසඳුම භාවිතා කරමු.

VI ලේබල්. නැතහොත් සේවාව අයත් වන්නේ කුමන නිෂ්පාදනයක්, ක්‍රියාකාරීත්වයක් හෝ සමාගමේ ව්‍යුහාත්මක අංශයක් ද යන්න පෙන්වන සලකුණු. උදාහරණයක් වශයෙන්, ඔබ ඔබේ සගයන් සතියකට පෙර එම ව්‍යාපාර ඒකකය සඳහා ක්‍රියාත්මක කළ ක්‍රියාකාරීත්වය කපා හරින්නේද යන්න ඉක්මනින් තේරුම් ගැනීමට ඒවා ඔබට උපකාර කරයි.

VII. සේවාවේ හිමිකරු හෝ හිමිකරුවන්. බොහෝ අවස්ථාවලදී, එය - හෝ ඒවා - PaaS භාවිතයෙන් ස්වයංක්‍රීයව තීරණය කළ හැක, නමුත් ආරක්ෂිත පැත්තේ සිටීමට නම්, සංවර්ධකයා විසින් ඒවා අතින් නියම කිරීමට අපට අවශ්‍ය වේ.

අවසාන වශයෙන්, කේත සමාලෝචනයට සමාන ලේඛන සමාලෝචනය කිරීම හොඳ පුරුද්දකි.

අඛණ්ඩ ඒකාබද්ධතාව

• ගබඩා සකස් කිරීම.
• TeamCity හි නල මාර්ගයක් නිර්මාණය කිරීම.
• හිමිකම් සැකසීම.
• සේවා හිමිකරුවන් සොයන්න. මෙහි දෙමුහුන් යෝජනා ක්රමයක් ඇත - අතින් සලකුණු කිරීම සහ PaaS වෙතින් අවම ස්වයංක්රීයකරණය. වෙනත් සංවර්ධන කණ්ඩායමකට සහාය සඳහා සේවා මාරු කළ විට හෝ, උදාහරණයක් ලෙස, සේවා සංවර්ධකයා ඉවත් වුවහොත් සම්පූර්ණයෙන්ම ස්වයංක්‍රීය යෝජනා ක්‍රමයක් අසාර්ථක වේ.
• ඇට්ලස් හි සේවාවක් ලියාපදිංචි කිරීම (ඉහළ බලන්න). එහි සියලුම අයිතිකරුවන් සහ යැපීම් සමඟ.
• සංක්රමණයන් පරීක්ෂා කිරීම. ඒවායින් එකක් භයානක විය හැකිදැයි අපි පරීක්ෂා කරමු. උදාහරණයක් ලෙස, ඒවායින් එකක වෙනස් කිරීමේ වගුවක් හෝ සේවාවේ විවිධ අනුවාද අතර දත්ත යෝජනා ක්‍රමයේ ගැළපුම බිඳ දැමිය හැකි වෙනත් දෙයක් උත්පතන වේ. එවිට සංක්‍රමණය සිදු නොකෙරේ, නමුත් දායකත්වයක තබා ඇත - එය භාවිතා කිරීමට ආරක්ෂිත වන විට PaaS සේවා හිමිකරුට සංඥා කළ යුතුය.

පිළිස්සීම

ඊළඟ අදියර වන්නේ යෙදවීමට පෙර ඇසුරුම් සේවා වේ.

• යෙදුම ගොඩනැගීම. සම්භාව්යයට අනුව - ඩොකර් රූපයක.
• සේවාවම සහ අදාළ සම්පත් සඳහා හෙල්ම් ප්‍රස්ථාර උත්පාදනය කිරීම. දත්ත සමුදායන් සහ හැඹිලි සඳහා ඇතුළුව. CLI-push අදියරේදී ජනනය කරන ලද app.toml config එකට අනුකූලව ඒවා ස්වයංක්‍රීයව නිර්මාණය වේ.
• වරායන් විවෘත කිරීම සඳහා පරිපාලකයින් සඳහා ප්‍රවේශපත්‍ර නිර්මාණය කිරීම (අවශ්ය විට).
• ඒකක පරීක්ෂණ ධාවනය කිරීම සහ කේත ආවරණය ගණනය කිරීම. කේත ආවරණය නිශ්චිත සීමාවට වඩා අඩු නම්, බොහෝ විට සේවාව තවදුරටත් ඉදිරියට නොයනු ඇත - යෙදවීමට. එය පිළිගත හැකි අද්දර තිබේ නම්, සේවාවට “අශුභවාදී” සංගුණකයක් පවරනු ලැබේ: එවිට, කාලයත් සමඟ දර්ශකයේ වැඩි දියුණුවක් නොමැති නම්, පරීක්ෂණ අනුව ප්‍රගතියක් නොමැති බවට සංවර්ධකයාට දැනුම් දීමක් ලැබෙනු ඇත ( සහ ඒ ගැන යමක් කළ යුතුය).
• මතකය සහ CPU සීමාවන් සඳහා ගිණුම්කරණය. අපි ප්‍රධාන වශයෙන් Golang හි microservices ලියන අතර Kubernetes හි ධාවනය කරන්නෙමු. එබැවින් Golang භාෂාවේ විශේෂත්වය හා සම්බන්ධ එක් සූක්ෂ්මතාවයක්: පෙරනිමියෙන්, ආරම්භයේදී, ඔබ 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 කම්කරුවන්;
- Sentry හි දෝෂ;
- ප්රතිචාර තත්ත්වයන්;
- ප්රතිචාර කාලය, නිශ්චිත සහ සාමාන්යය;
- ප්රමාදය;
- ව්යතිරේක, සැකසූ සහ හසුරුවා නොගත්;
- නිෂ්පාදන මිනුම්.

මිරිකීම පරීක්ෂා කිරීම

මිරිකීම පරීක්ෂා කිරීම "මිරිකීම" පරීක්ෂණය ලෙසද හැඳින්වේ. තාක්ෂණයේ නම Netflix වෙත හඳුන්වා දෙන ලදී. එහි සාරය නම් පළමුව අපි එක් අවස්ථාවක් සැබෑ ගමනාගමනයෙන් අසාර්ථක වන ස්ථානයට පුරවා එහි සීමාව සකස් කිරීමයි. ඉන්පසු අපි තවත් අවස්ථාවක් එකතු කර මෙම යුගලය පටවන්නෙමු - නැවතත් උපරිමයට; අපි ඔවුන්ගේ සිවිලිම සහ ඩෙල්ටා පළමු "මිරිකීම" සමඟ දකිමු. එබැවින් අපි වරකට එක් අවස්ථාවක් සම්බන්ධ කර වෙනස්වීම් රටාව ගණනය කරමු.
"මිරිකීම" හරහා පරීක්ෂණ දත්ත ද පොදු ප්‍රමිතික දත්ත ගබඩාවකට ගලා යයි, එහිදී අපි ඒවා සමඟ කෘතිම බර ප්‍රතිඵල පොහොසත් කරන්නෙමු, නැතහොත් ඒවා සමඟ “කෘතිම” ප්‍රතිස්ථාපනය කරන්නෙමු.

නිෂ්පාදනය

• පරිමාණය. අපි නිෂ්පාදනයට සේවාවක් දියත් කරන විට, එය පරිමාණය කරන ආකාරය අපි නිරීක්ෂණය කරමු. අපගේ අත්දැකීම් අනුව, CPU දර්ශක පමණක් නිරීක්ෂණය කිරීම අකාර්යක්ෂමයි. එහි පිරිසිදු ස්වරූපයෙන් RPS මිණුම් සලකුණු සමඟ ස්වයං පරිමාණය ක්‍රියා කරයි, නමුත් සබැඳි ප්‍රවාහය වැනි ඇතැම් සේවාවන් සඳහා පමණි. එබැවින් අපි මුලින්ම බලන්නේ යෙදුම්-විශේෂිත නිෂ්පාදන ප්‍රමිතික.

ප්රතිඵලයක් වශයෙන්, පරිමාණය කිරීමේදී අපි විශ්ලේෂණය කරමු:
- CPU සහ RAM දර්ශක,
- පෝලිමේ ඇති ඉල්ලීම් ගණන,
- ප්රතිචාර කාලය,
- සමුච්චිත ඓතිහාසික දත්ත මත පදනම්ව අනාවැකි.

සේවාවක් පරිමාණය කිරීමේදී, එහි පරායත්තතා නිරීක්ෂණය කිරීම ද වැදගත් වන අතර එමඟින් අපි දාමයේ පළමු සේවාව පරිමාණය නොකිරීමට සහ එයට ප්‍රවේශ වන ඒවා බර යටතේ අසමත් වේ. සම්පූර්ණ සේවා සංචිතය සඳහා පිළිගත හැකි බරක් ස්ථාපිත කිරීම සඳහා, අපි "ආසන්නම" යැපෙන සේවාවේ ඓතිහාසික දත්ත (CPU සහ RAM දර්ශකවල එකතුවක් මත පදනම්ව, යෙදුම් විශේෂිත මිනුම් දණ්ඩ සමඟින්) සහ ඒවා ඓතිහාසික දත්ත සමඟ සංසන්දනය කරමු. ආරම්භක සේවාවේ, සහ යනාදිය "යැපුම් දාමය" ", ඉහළ සිට පහළට.

සේවාව

ක්ෂුද්‍ර සේවාව ක්‍රියාත්මක වූ පසු, අපට එයට ප්‍රේරක අමුණන්න පුළුවන්.

ප්‍රේරක සිදුවන සාමාන්‍ය තත්වයන් මෙන්න.
- අනතුරුදායක සංක්‍රමණ අනාවරණය විය.
- ආරක්ෂක යාවත්කාලීන නිකුත් කර ඇත.
- සේවාවම දිගු කලක් යාවත්කාලීන කර නොමැත.
— සේවාව මත පැටවීම සැලකිය යුතු ලෙස අඩු වී ඇත හෝ එහි සමහර නිෂ්පාදන මිමි සාමාන්‍ය පරාසයෙන් පිටත ඇත.
— සේවාව තවදුරටත් නව වේදිකා අවශ්‍යතා සපුරාලන්නේ නැත.

සමහර ප්‍රේරක ක්‍රියාකාරිත්වයේ ස්ථායිතාව සඳහා වගකිව යුතු ය, සමහරක් - පද්ධති නඩත්තු කිරීමේ කාර්යයක් ලෙස - උදාහරණයක් ලෙස, සමහර සේවාව දිගු කාලයක් යොදවා නොමැති අතර එහි මූලික ප්‍රතිරූපය ආරක්ෂක චෙක්පත් සමත් වීම නතර කර ඇත.

උපකරණ පුවරුව

කෙටියෙන් කිවහොත්, උපකරණ පුවරුව අපගේ සම්පූර්ණ PaaS හි පාලන පැනලය වේ.

• සේවාව පිළිබඳ තනි තොරතුරු, එහි පරීක්ෂණ ආවරණය පිළිබඳ දත්ත, එහි රූප ගණන, නිෂ්පාදන පිටපත් ගණන, අනුවාද ආදිය.
• සේවා සහ ලේබල අනුව දත්ත පෙරීම සඳහා මෙවලමක් (ව්‍යාපාර ඒකකවලට අයත් සලකුණු, නිෂ්පාදන ක්‍රියාකාරීත්වය, ආදිය)
• ලුහුබැඳීම, ලොග් කිරීම සහ අධීක්ෂණය සඳහා යටිතල පහසුකම් මෙවලම් සමඟ ඒකාබද්ධ කිරීම සඳහා මෙවලමක්.
• සේවා ලියකියවිලි වල තනි ලක්ෂ්යයක්.
• සේවා හරහා සියලුම සිදුවීම් පිළිබඳ තනි දෘෂ්ටිකෝණය.

එකතුව

PaaS හඳුන්වා දීමට පෙර, නව සංවර්ධකයෙකුට නිෂ්පාදනයේදී ක්ෂුද්‍ර සේවාවක් දියත් කිරීමට අවශ්‍ය සියලුම මෙවලම් අවබෝධ කර ගැනීමට සති කිහිපයක් ගත කළ හැකිය: Kubernetes, Helm, අපගේ අභ්‍යන්තර TeamCity විශේෂාංග, දත්ත සමුදායන් සහ හැඹිලි සඳහා දෝෂ-ඉවසන ආකාරයෙන් සම්බන්ධතා සැකසීම යනාදිය. ඉක්මන් ආරම්භය කියවා සේවාවම නිර්මාණය කිරීමට පැය කිහිපයක් ගතවේ.

මම HighLoad++ 2018 සඳහා මෙම මාතෘකාව පිළිබඳ වාර්තාවක් ලබා දුන්නා, ඔබට එය නැරඹිය හැකිය видео и ඉදිරිපත් කිරීම.

අවසානය දක්වා කියවන අය සඳහා බෝනස් ධාවන පථය

Avito හි අපි සංවර්ධකයින් සඳහා අභ්‍යන්තර තෙදින පුහුණුවක් සංවිධානය කරමු ක්රිස් රිචඩ්සන්, ක්ෂුද්ර සේවා ගෘහ නිර්මාණ ශිල්පය පිළිබඳ විශේෂඥයෙක්. මෙම සටහන කියවන පාඨකයෙකුට එයට සහභාගී වීමට අවස්ථාව ලබා දීමට අපි කැමැත්තෙමු. එය පුහුණු වැඩසටහන පළ කර ඇත.

පුහුණුව අගෝස්තු 5 සිට 7 දක්වා මොස්කව්හිදී පැවැත්වේ. මේවා සම්පූර්ණයෙන්ම වාඩි වී සිටින වැඩ කරන දින වේ. දිවා ආහාරය සහ පුහුණුව අපගේ කාර්යාලයේ ඇති අතර, තෝරාගත් සහභාගිවන්නා ගමන් සහ නවාතැන් සඳහා ගෙවනු ඇත.

ඔබට සහභාගීත්වය සඳහා අයදුම් කළ හැකිය මෙම ගූගල් පෝරමයේ. ඔබෙන් - ඔබ පුහුණුවට සහභාගී විය යුත්තේ මන්දැයි යන ප්‍රශ්නයට පිළිතුර සහ ඔබව සම්බන්ධ කර ගන්නේ කෙසේද යන්න පිළිබඳ තොරතුරු. ඉංග්‍රීසියෙන් පිළිතුරු දෙන්න, මන්ද ක්‍රිස් විසින්ම පුහුණුවට සහභාගී වන සහභාගිකයා තෝරා ගනු ඇත.
සංවර්ධකයින් සඳහා (AvitoTech in ෆේස්බුක්, Vkontakte, ට්විටර්) ජූලි 19 ට පසුව නොවේ.

මූලාශ්රය: www.habr.com