සැප්තැම්බර් 19 මොස්කව්හිදී ක්ෂුද්ර සේවා සඳහා කැප වූ පළමු තේමාත්මක රැස්වීම HUG (Higload++ පරිශීලක කණ්ඩායම). "ක්‍රියාකාරී ක්ෂුද්ර සේවා: ප්‍රමාණය වැදගත්, ඔබට කුබර්නෙට්ස් තිබුණත්" ඉදිරිපත් කිරීමක් එහි විය, එහි අපි ක්ෂුද්ර සේවා ගෘහ නිර්මාණ ශිල්පය සමඟ ව්යාපෘති ක්‍රියාත්මක කිරීමේදී ෆ්ලැන්ට්ගේ පුළුල් අත්දැකීම් බෙදා ගත්තෙමු. පළමුවෙන්ම, ඔවුන්ගේ වර්තමාන හෝ අනාගත ව්‍යාපෘතියේ මෙම ප්‍රවේශය භාවිතා කිරීම ගැන සිතන සියලුම සංවර්ධකයින්ට එය ප්රයෝජනවත් වනු ඇත.
හඳුන්වා දෙමින් (විනාඩි 50, ලිපියට වඩා බොහෝ තොරතුරු), මෙන්ම එහි ප්රධාන උපුටා ගැනීම පෙළ ආකාරයෙන්.
සැ.යු: මෙම සටහන අවසානයේ වීඩියෝ සහ ඉදිරිපත් කිරීම් ද ඇත.
හැඳින්වීම
සාමාන්‍යයෙන් හොඳ කතාවක ආරම්භයක්, ප්රධාන කුමන්ත්‍රණයක් සහ විභේදනයක් ඇත. මෙම වාර්තාව පෙරවදනක් හා සමාන වන අතර එය ඛේදජනක එකකි. එය ක්ෂුද්ර සේවා පිළිබඳ බාහිර දෘෂ්ටිකෝණයක් සපයන බව ද සැලකිල්ලට ගැනීම වැදගත්ය. සූරාකෑම.
මම මෙම ප්‍රස්ථාරයෙන් ආරම්භ කරමි, එහි කතුවරයා (2015 දී) මාටින් ෆෝලර්:
නිශ්චිත අගයකට ළඟා වන මොනොලිතික් යෙදුමක දී, ඵලදායිතාව පහත වැටීමට පටන් ගන්නා ආකාරය පෙන්නුම් කරයි. Microservices වෙනස් වන්නේ ඒවා සමඟ ආරම්භක ඵලදායිතාව අඩු නමුත් සංකීර්ණත්වය වැඩි වන විට කාර්යක්ෂමතාවයේ පිරිහීම ඔවුන් සඳහා එතරම් කැපී පෙනෙන්නේ නැත.
Kubernetes භාවිතා කිරීමේ අවස්ථාව සඳහා මම මෙම ප්‍රස්ථාරයට එක් කරමි:
ක්ෂුද්ර සේවා සහිත යෙදුමක් වඩා හොඳ වන්නේ ඇයි? මක්නිසාද යත් එවැනි ගෘහ නිර්මාණ ශිල්පයක් ගෘහ නිර්මාණ ශිල්පය සඳහා බරපතල අවශ්‍යතා ඉදිරිපත් කරන අතර ඒවා කුබර්නෙටේස්ගේ හැකියාවන්ගෙන් පරිපූර්ණ ලෙස ආවරණය වී ඇත. අනෙක් අතට, මෙම ක්‍රියාකාරීත්වයේ සමහරක් මොනොලිත් සඳහා ප්රයෝජනවත් වනු ඇත, විශේෂයෙන් අද සාමාන්ය මොනොලිතය හරියටම මොනොලිතයක් නොවන නිසා (විස්තර පසුව වාර්තාවේ ඇත).
ඔබට පෙනෙන පරිදි, අවසාන ප්‍රස්ථාරය (මොනොලිතික් සහ ක්ෂුද්ර සේවා යෙදුම් දෙකම කුබර්නෙටස් සමඟ යටිතල ව්‍යුහයේ ඇති විට) මුල් ප්‍රස්ථාරයට වඩා බෙහෙවින් වෙනස් නොවේ. මීළඟට අපි Kubernetes භාවිතයෙන් ක්‍රියාත්මක වන යෙදුම් ගැන කතා කරමු.
ප්රයෝජනවත් සහ හානිකර ක්ෂුද්ර සේවා
සහ ප්රධාන අදහස මෙන්න:
මොකක්ද සාමාන්ය ක්ෂුද්ර සේවා ගෘහ නිර්මාණ ශිල්පය? එය ඔබට සැබෑ ප්‍රතිලාභ ගෙන දිය යුතුය, ඔබේ වැඩ කාර්යක්ෂමතාව වැඩි කරයි. අපි නැවත ප්‍රස්ථාරය වෙත ගියහොත්, මෙන්න එය:
ඔබ ඇයව ඇමතුවොත් ප්රයෝජනවත්, එවිට ප්රස්ථාරයේ අනෙක් පැත්තේ වනු ඇත හානිකර ක්ෂුද්ර සේවා (වැඩ වලට බාධා කරයි):
"ප්රධාන අදහස" වෙත ආපසු යාම: මම මගේ අත්දැකීම් කිසිසේත් විශ්වාස කළ යුතුද? මේ අවුරුද්දේ මුල ඉඳන් බැලුවා ව්යාපෘති 85 ක්. ඒවා සියල්ලම ක්ෂුද්ර සේවා නොවේ (ඒවායින් තුනෙන් එකකට හෝ අඩකට පමණ එවැනි ගෘහ නිර්මාණ ශිල්පයක් තිබුණි), නමුත් මෙය තවමත් විශාල සංඛ්‍යාවකි. අපි (Flant සමාගම) බාහිරින් ලබාගන්නන් ලෙස කුඩා සමාගම්වල (සංවර්ධකයින් 5 දෙනෙකු සමඟ) සහ විශාල සමාගම්වල (~ 500 සංවර්ධකයින්) සංවර්ධනය කරන ලද විවිධාකාර යෙදුම් දැකීමට සමත් වේ. අමතර ප්‍රතිලාභයක් නම්, මෙම යෙදුම් වසර ගණනාවක් පුරා සජීවීව සහ පරිණාමය වන බව අපට පෙනේ.
ක්ෂුද්ර සේවා ඇයි?
ක්ෂුද්ර සේවාවල ප්‍රතිලාභ පිළිබඳ ප්‍රශ්නයට තිබේ දැනටමත් සඳහන් කර ඇති මාටින් ෆෝලර් වෙතින්:
- මොඩියුලයේ පැහැදිලි මායිම්;
- ස්වාධීන යෙදවීම;
- තාක්ෂණය තෝරා ගැනීමේ නිදහස.
මම මෘදුකාංග ගෘහ නිර්මාණ ශිල්පීන් සහ සංවර්ධකයින් සමඟ බොහෝ දේ කතා කර ඇති අතර ඔවුන්ට ක්ෂුද්ර සේවා අවශ්‍ය වන්නේ මන්දැයි විමසා ඇත. ඒ වගේම මම ඔවුන්ගේ අපේක්ෂාවන් ලැයිස්තුවක් හැදුවා. සිදු වූ දේ මෙන්න:
අපි "සංවේදනයන්" සමහර කරුණු විස්තර කරන්නේ නම්:
- මොඩියුලවල පැහැදිලි මායිම්: මෙන්න අපට භයානක මොනොලිත් එකක් ඇත, දැන් සියල්ල Git ගබඩාවල පිළිවෙලට සකසා ඇත, එහි සෑම දෙයක්ම “රාක්කවල” ඇත, උණුසුම් හා මෘදු මිශ්‍ර නොවේ;
- යෙදවීමේ ස්වාධීනත්වය: සංවර්ධනය වේගවත් වන පරිදි අපට ස්වාධීනව සේවා දියත් කිරීමට හැකි වනු ඇත (සමාන්තරව නව විශේෂාංග ප්‍රකාශයට පත් කිරීම);
- සංවර්ධන ස්වාධීනත්වය: අපට මෙම ක්ෂුද්ර සේවාව එක් කණ්ඩායමකට/සංවර්ධකයෙකුට ලබා දිය හැකි අතර එය තවත් කෙනෙකුට ලබා දිය හැකිය, එයට ස්තූතිවන්ත වන්නට අපට වේගයෙන් සංවර්ධනය කළ හැකිය;
- боවැඩි විශ්වසනීයත්වය: අර්ධ වශයෙන් පිරිහීමක් සිදුවුවහොත් (වැටීම් 20 න් එක් ක්ෂුද්ර සේවාවක්), එවිට එක් බොත්තමක් පමණක් ක්‍රියා කිරීම නවත්වන අතර සමස්තයක් ලෙස පද්ධතිය දිගටම ක්‍රියාත්මක වේ.
සාමාන්ය (හානිකර) ක්ෂුද්ර සේවා ගෘහ නිර්මාණ ශිල්පය
යථාර්ථය අප අපේක්ෂා කරන දේ නොවන්නේ මන්දැයි පැහැදිලි කිරීමට, මම ඉදිරිපත් කරමි සාමූහික විවිධ ව්යාපෘති ගණනාවක අත්දැකීම් මත පදනම් වූ ක්ෂුද්ර සේවා ගෘහ නිර්මාණ ශිල්පයක රූපයක්.
උදාහරණයක් ලෙස ඇමේසන් හෝ අවම වශයෙන් OZON සමඟ තරඟ කිරීමට යන වියුක්ත අන්තර්ජාල වෙළඳසැලක් විය හැකිය. එහි ක්ෂුද්ර සේවා ගෘහ නිර්මාණ ශිල්පය මේ වගේ ය:
හේතු කිහිපයක් නිසා, මෙම ක්ෂුද්ර සේවා විවිධ වේදිකාවල ලියා ඇත:
සෑම ක්ෂුද්ර සේවාවකටම ස්වයං පාලනයක් තිබිය යුතු බැවින්, ඔවුන්ගෙන් බොහෝ දෙනෙකුට තමන්ගේම දත්ත සමුදාය සහ හැඹිලිය අවශ්‍ය වේ. අවසාන ගෘහ නිර්මාණ ශිල්පය පහත පරිදි වේ:
එහි විපාක මොනවාද?
ෆෝලර්ටත් මේක තියෙනවා - ක්ෂුද්ර සේවා භාවිතා කිරීම සඳහා "ගෙවීම්" ගැන:
ඒ වගේම අපි බලමු අපේ බලාපොරොත්තු ඉටු වුණාද කියලා.
මොඩියුලවල මායිම් පැහැදිලි කරන්න...
නමුත් අපි ඇත්තටම microservices කීයක් හදන්න ඕනද?වෙනස් කිරීම සිදු කිරීමට? බෙදා හරින ලද ලුහුබැඳීමකින් තොරව සියල්ල ක්‍රියා කරන්නේ කෙසේදැයි අපට සොයා ගත හැකිද (සියල්ලට පසු, ඕනෑම ඉල්ලීමක් ක්ෂුද්ර සේවා වලින් අඩකින් සකසනු ලැබේ)?
රටාවක් තියෙනවා"“, මෙහි එය බෙදා හරින ලද අපිරිසිදු ගැටිත්තක් බවට පත් විය. මෙය තහවුරු කිරීම සඳහා, ඉල්ලීම් යන ආකාරය පිළිබඳ ආසන්න නිදර්ශනයක් මෙන්න:
යෙදවීමේ ස්වාධීනත්වය...
තාක්ෂණික වශයෙන්, එය සාක්ෂාත් කර ගෙන ඇත: අපට එක් එක් ක්ෂුද්ර සේවාව වෙන වෙනම රෝල් කළ හැකිය. නමුත් ප්රායෝගිකව ඔබ එය සෑම විටම පෙරළෙන බව සැලකිල්ලට ගත යුතුය බොහෝ ක්ෂුද්ර සේවා, සහ අපි සැලකිල්ලට ගත යුතුය ඔවුන්ගේ පෙරළීමේ අනුපිළිවෙල. හොඳ ආකාරයකින්, අපි සාමාන්‍යයෙන් නිකුතුව නිවැරදි අනුපිළිවෙලට පෙරළන්නේද යන්න වෙනම පරිපථයකින් පරීක්ෂා කිරීමට අවශ්‍ය වේ.
තාක්ෂණය තෝරා ගැනීමේ නිදහස...
ඇය තමයි. නිදහස බොහෝ විට මායිම් වන්නේ අවනීතිය මත බව මතක තබා ගන්න. ඔවුන් සමඟ "සෙල්ලම්" කිරීමට පමණක් තාක්ෂණයන් තෝරා නොගැනීම මෙහි ඉතා වැදගත් වේ.
සංවර්ධනයේ ස්වාධීනත්වය...
සම්පූර්ණ යෙදුම සඳහා (මෙතරම් සංරචක සහිත) පරීක්ෂණ ලූපයක් සාදා ගන්නේ කෙසේද? නමුත් ඔබ තවමත් එය යාවත්කාලීනව තබා ගත යුතුය. මේ සියල්ල යන කාරණයට මඟ පාදයි සත්‍ය පරීක්ෂණ පරිපථ ගණන, අපට ප්‍රතිපත්තිමය වශයෙන් අඩංගු විය හැකි, අවම වශයෙන් හැරෙනවා.
මේ සියල්ල දේශීයව යෙදවීම ගැන කුමක් කිව හැකිද?.. එය බොහෝ විට සංවර්ධකයා ස්වාධීනව තම කාර්යය ඉටු කරයි, නමුත් "අහඹු ලෙස", ඔහු පරිපථය පරීක්ෂා කිරීම සඳහා නිදහස් වන තෙක් බලා සිටීමට බල කරන නිසා.
වෙනම පරිමාණය...
ඔව්, නමුත් එය භාවිතා කරන DBMS ප්‍රදේශයේ සීමා වේ. ලබා දී ඇති ගෘහනිර්මාණ උදාහරණයේ දී, Cassandra හට ගැටළු ඇති නොවනු ඇත, නමුත් MySQL සහ PostgreSQL වනු ඇත.
Боවැඩි විශ්වසනීයත්වයක්...
යථාර්ථයේ දී එක් ක්ෂුද්ර සේවාවක් අසාර්ථක වීම බොහෝ විට සමස්ත පද්ධතියේ නිවැරදි ක්‍රියාකාරිත්වය බිඳ දමයි, නමුත් නව ගැටළුවක් ද ඇත: සෑම ක්ෂුද්ර සේවාවක්ම දෝෂ ඉවසා සිටීම ඉතා අපහසුය. ක්ෂුද්ර සේවා විවිධ තාක්ෂණයන් (memcache, Redis, ආදිය) භාවිතා කරන බැවින්, ඔබ සෑම දෙයක්ම සිතා බලා එය ක්‍රියාත්මක කළ යුතුය, එය ඇත්ත වශයෙන්ම හැකි නමුත් විශාල සම්පත් අවශ්‍ය වේ.
බර මැනීමේ හැකියාව...
මේක ඇත්තටම හොඳයි.
ක්ෂුද්ර සේවා වල "සැහැල්ලු බව"...
අපට විශාල පමණක් නොවේ ජාල පොදු කාර්ය (DNS සඳහා වන ඉල්ලීම් ගුණ කිරීම යනාදිය), නමුත් අප ආරම්භ කළ බොහෝ උප විමසුම් නිසාද දත්ත පිටපත් කරන්න (ගබඩා හැඹිලි), එය සැලකිය යුතු ගබඩා ප්‍රමාණයකට හේතු විය.
අපගේ අපේක්ෂාවන් සපුරාලීමේ ප්‍රතිඵලය මෙන්න:
නමුත් එය පමණක් නොවේ!
නිසා:
- බොහෝ දුරට අපට පණිවිඩ බසයක් අවශ්‍ය වනු ඇත.
- නියමිත වේලාවට ස්ථාවර උපස්ථයක් සාදා ගන්නේ කෙසේද? එකම එක реальный විකල්පය වන්නේ මේ සඳහා ගමනාගමනය විසන්ධි කිරීමයි. නමුත් නිෂ්පාදනයේදී මෙය කරන්නේ කෙසේද?
- අපි කතා කරන්නේ කලාප කිහිපයකට සහයෝගය දැක්වීම ගැන නම්, ඒ සෑම එකක් තුළම තිරසාරභාවය සංවිධානය කිරීම ඉතා ශ්‍රම-දැඩි කාර්යයකි.
- මධ්යගත වෙනස්කම් සිදු කිරීමේ ගැටලුව පැන නගී. උදාහරණයක් ලෙස, අපට PHP අනුවාදය යාවත්කාලීන කිරීමට අවශ්‍ය නම්, අපි එක් එක් ගබඩාව සඳහා කැපවීමට අවශ්‍ය වනු ඇත (සහ ඒවා දුසිම් ගණනක් ඇත).
- මෙහෙයුම් සංකීර්ණත්වයේ වර්ධනය, අක්‍රිය, ඝාතීය වේ.
මේ සියල්ල සමඟ කුමක් කළ යුතුද?
මොනොලිතික් යෙදුමකින් ආරම්භ කරන්න. ෆෝලර්ගේ අත්දැකීම සාර්ථක ක්ෂුද්ර සේවා යෙදුම් සියල්ලම පාහේ මොනොලිතයක් ලෙස ආරම්භ වූ අතර එය ඉතා විශාල වී පසුව කැඩී ගියේය. ඒ අතරම, ආරම්භයේ සිටම ක්ෂුද්ර සේවා ලෙස ගොඩනගා ඇති සියලුම පද්ධති පාහේ ඉක්මනින් හෝ පසුව බරපතල ගැටළු වලට මුහුණ දුන්නේය.
තවත් වටිනා අදහසක් නම්, microservice architecture එකක් සහිත ව්‍යාපෘතියක් සාර්ථක වීමට නම්, ඔබ හොඳින් දැන සිටිය යුතුය සහ විෂය ක්ෂේත්‍රය, සහ ක්ෂුද්ර සේවා සාදන ආකාරය. ඒ වගේම විෂය ක්ෂේත්‍රයක් ඉගෙන ගන්න හොඳම ක්‍රමය තමයි ඒකලිතයක් සෑදීම.
නමුත් අපි දැනටමත් මෙම තත්වයේ සිටින්නේ නම් කුමක් කළ යුතුද?
ඕනෑම ගැටලුවක් විසඳීමේ පළමු පියවර වන්නේ එයට එකඟ වී එය ගැටලුවක් බව තේරුම් ගැනීමයි, අපට තවදුරටත් දුක් විඳීමට අවශ්‍ය නැත.
දත වැඩුණු මොනොලිත් අවස්ථාවක (ඒ සඳහා අමතර සම්පත් මිලදී ගැනීමට අපට අවස්ථාව නැති වූ විට), අපි එය කපා දමන්නේ නම්, මේ අවස්ථාවේ දී ප්‍රතිවිරුද්ධ කතාව හැරෙනවා: අධික ක්ෂුද්ර සේවා තවදුරටත් උදව් නොකරන විට, නමුත් බාධා කරන විට - අතිරික්තය කපා විශාල කරන්න!
උදාහරණයක් ලෙස, ඉහත සාකච්ඡා කළ සාමූහික රූපය සඳහා ...
වඩාත්ම සැක සහිත ක්ෂුද්ර සේවාවලින් මිදෙන්න:
ඉදිරිපස උත්පාදනය සඳහා වගකිව යුතු සියලුම ක්ෂුද්ර සේවා ඒකාබද්ධ කරන්න:
... එක් ක්ෂුද්ර සේවාවකට, එකකින් ලියා ඇත (නුතන සහ සාමාන්ය, ඔබම සිතන පරිදි) භාෂාව/රාමුව:
එයට එක් ORM එකක් (එක් DBMS) සහ පළමුව යෙදුම් කිහිපයක් ඇත:
... නමුත් පොදුවේ ඔබට පහත ප්‍රතිඵලය ලබා ගනිමින් තවත් බොහෝ දේ එහි මාරු කළ හැක:
එපමණක් නොව, Kubernetes හි අපි මේ සියල්ල වෙනම අවස්ථා වලදී ධාවනය කරමු, එයින් අදහස් කරන්නේ අපට තවමත් බර මැනිය හැකි අතර ඒවා වෙන වෙනම පරිමාණය කළ හැකි බවයි.
සාරාංශ ගත කිරීමට
විශාල පින්තූරය දෙස බලන්න. බොහෝ විට, ක්ෂුද්ර සේවා සමඟ ඇති මෙම ගැටළු සියල්ලම පැන නගින්නේ යමෙකු ඔවුන්ගේ කාර්යය භාර ගත් නමුත් “ක්ෂුද්ර සේවා සමඟ සෙල්ලම් කිරීමට” අවශ්‍ය වූ බැවිනි.
"ක්ෂුද්ර සේවා" යන වචනයේ "ක්ෂුද්ර" කොටස අතිරික්ත වේ.. ඒවා "ක්ෂුද්ර" වන්නේ ඒවා විශාල මොනොලිතයකට වඩා කුඩා නිසා පමණි. හැබැයි ඒවා පොඩි දේවල් කියලා හිතන්න එපා.
අවසාන සිතුවිල්ල සඳහා, අපි මුල් වගුව වෙත ආපසු යමු:
එහි ලියා ඇති සටහනකි (ඉහළ දකුණේ) යන කාරනය දක්වා උනු ඔබේ ව්‍යාපෘතිය කරන කණ්ඩායමේ කුසලතා සෑම විටම ප්‍රාථමික වේ — ඔවුන් microservices සහ monolith අතර ඔබේ තේරීමෙහි ප්රධාන භූමිකාවක් ඉටු කරනු ඇත. කණ්ඩායමට ප්‍රමාණවත් කුසලතා නොමැති නමුත් එය ක්ෂුද්ර සේවා සෑදීමට පටන් ගන්නේ නම්, කතාව නියත වශයෙන්ම මාරාන්තික වනු ඇත.
වීඩියෝ සහ විනිවිදක
කතාවෙන් වීඩියෝව (~ විනාඩි 50; අවාසනාවකට, එය අමුත්තන්ගේ බොහෝ හැඟීම් ප්‍රකාශ නොකරයි, එය වාර්තාවේ මනෝභාවය බොහෝ දුරට තීරණය කරයි, නමුත් එය එසේ ය):
වාර්තාව ඉදිරිපත් කිරීම:
ප්රාදේශීය සභා
අපගේ බ්ලොග් අඩවියේ වෙනත් වාර්තා:
- «» (Dmitry Stolyarov; මැයි 28, 2018 RootConf හිදී);
- «» (Dmitry Stolyarov; නොවැම්බර් 7, 2017 HighLoad++ මත);
- «» (Dmitry Stolyarov; ජූනි 6, 2017 RootConf හිදී);
- «» (Dmitry Stolyarov; නොවැම්බර් 8, 2016 HighLoad++ මත);
- «» (Dmitry Stolyarov; මැයි 31, 2016 RootConf හිදී).
ඔබ පහත ප්‍රකාශන ගැනද උනන්දු විය හැකිය:
- «»;
- «»;
- «".
මූලාශ්රය: www.habr.com