සටහන. පරිවර්තනය.: සේවා දැලක් යනු රුසියානු භාෂාවට තවමත් ස්ථාවර පරිවර්තනයක් නොමැති සංසිද්ධියකි (මීට වසර 2 කට පෙර අපි “සේවා සඳහා දැලක්” විකල්පය ඉදිරිපත් කළ අතර, මඳ වේලාවකට පසු, සමහර සගයන් “සේවා පෙරනයක්” සංයෝජනය සක්‍රීයව ප්‍රවර්ධනය කිරීමට පටන් ගත්හ) . මෙම තාක්ෂණය පිළිබඳ නිරන්තර කතා කිරීම අලෙවිකරණ සහ තාක්ෂණික සංරචක ඉතා සමීපව බැඳී ඇති තත්වයකට හේතු වී තිබේ. මුල් පදයේ කතුවරයෙකුගේ මෙම අපූරු ද්‍රව්‍යය ඉංජිනේරුවන්ට පමණක් නොව පැහැදිලි බවක් ගෙන ඒමට අදහස් කරයි.
විකට සිට
හැඳින්වීම
ඔබ පසුබිම් පද්ධති ක්ෂේත්‍රයේ කොතැනක හෝ වැඩ කරන මෘදුකාංග ඉංජිනේරුවෙකු නම්, “සේවා දැල්” යන යෙදුම පසුගිය වසර කිහිපය තුළ දැනටමත් ඔබේ මනසෙහි දැඩි ලෙස මුල් බැස තිබේ. අමුතු අහඹු සිදුවීමකට ස්තූතිවන්ත වන්නට, මෙම වාක්‍ය ඛණ්ඩය වැඩි වැඩියෙන් කර්මාන්තය අත්පත් කර ගනිමින් සිටින අතර, උද්දීපනය සහ ඒ හා සම්බන්ධ ප්‍රවර්ධන දීමනා හිමබෝලයක් මෙන් වර්ධනය වෙමින්, කඳුකරයෙන් පියාසර කරමින් සහ මන්දගාමී වීමේ සලකුනු නොපෙන්වයි.
සේවා දැල උපත ලැබුවේ වලාකුළු ස්වදේශික පරිසර පද්ධතියේ අඳුරු, නැඹුරු ජලයේ ය. අවාසනාවන්ත ලෙස, මෙයින් අදහස් කරන්නේ එය වටා ඇති බොහෝ මතභේදයන් "අඩු කැලරි කතාබස්" සිට තාක්ෂණික යෙදුම භාවිතා කිරීම සඳහා - අමූලික ගොන් කතා දක්වා විහිදෙන බවයි. නමුත් ඔබ සියලු ශබ්දය පෙරහන් කළහොත්, සේවා දැල ඉතා සැබෑ, නිශ්චිත සහ වැදගත් කාර්යයක් ඇති බව ඔබට සොයාගත හැකිය.
මෙම පෝස්ටුවේදී, මම එය කිරීමට උත්සාහ කරමි: සේවා දැල සඳහා අවංක, ගැඹුරු, ඉංජිනේරු-නැඹුරු මාර්ගෝපදේශයක් සපයන්න. මම ප්රශ්නයට වඩා පිළිතුරු දෙන්නෙමි: "ඒ මොකක්ද?", - නමුත් ඒවගේම "මන්ද?", මෙන්ම "ඇයි දැන්?". අවසාන වශයෙන්, මෙම විශේෂිත තාක්ෂණය මෙතරම් උමතු ප්‍රබෝධයක් ඇති කළේ මන්දැයි (මගේ මතය අනුව) ගෙනහැර දැක්වීමට මම උත්සාහ කරමි, එයම සිත්ගන්නාසුලු කතාවකි.
මම කවුද?
ආයුබෝවන් සියල්ලටම! මගේ නම වන්නේ . මම නිර්මාණකරුවන්ගෙන් කෙනෙකි - පළමු සේවා දැල් ව්යාපෘතිය සහ පදයේ පෙනුමට දොස් පැවරිය යුතු ව්යාපෘතිය සේවා දැලක් ඒ වගේ (සමාවෙන්න යාලුවනේ!). (සටහන පරිවර්තනය.: මාර්ගය වන විට, මෙම පදයේ ආරම්භයේ දී, වසර 2,5 කට පෙර, අපි දැනටමත් එම කතුවරයාගේ මුල් ද්රව්ය පරිවර්තනය කර ඇත "".) මමත් නායකත්වය දෙනවා Linkerd සහ වැනි සිසිල් සේවා දැලක් ගොඩනඟන ආරම්භකයකි .
මෙම ගැටලුව සම්බන්ධයෙන් මා ඉතා පක්ෂග්‍රාහී සහ ආත්මීය මතයක් දරන බව ඔබට අනුමාන කළ හැකිය. කෙසේ වෙතත්, මම පක්ෂග්‍රාහීත්වය අවම මට්ටමක තබා ගැනීමට උත්සාහ කරමි (එක් කොටසක් හැර: "සේවා දැල ගැන මෙතරම් කතා කරන්නේ ඇයි?", - කෙසේ වෙතත් මම මගේ පූර්ව නිගමනය කළ අදහස් බෙදා ගන්නෙමි). මෙම මාර්ගෝපදේශය හැකි තරම් වෛෂයික කිරීමට මම මගේ උපරිමය කරන්නෙමි. විශේෂිත උදාහරණ වලදී, මම ප්රධාන වශයෙන් Linkerd හි අත්දැකීම් මත රඳා පවතින අතර, වෙනත් ආකාරයේ සේවා දැල් ක්රියාත්මක කිරීමේදී මා දන්නා වෙනස්කම් (ඇත්නම්) පෙන්වා දෙමි.
හොඳයි, සංග්‍රහ වෙත යාමට කාලයයි.
සේවා දැලක් යනු කුමක්ද?
සියලු උද්දීපනය තිබියදීත්, සේවා දැල ව්‍යුහාත්මකව තරමක් සරල ය. එය "ඊළඟ" සේවා පිහිටා ඇති පරිශීලක අවකාශයේ ප්රොක්සි සමූහයකි (අපි "ආසන්න" ගැන පසුව ටිකක් කතා කරමු), සහ පාලන ක්‍රියාවලි සමූහයකි. ප්රොක්සි සාමූහිකව හැඳින්වේ දත්ත තලය, සහ පාලන ක්රියාවලීන් ලෙස හැඳින්වේ පාලක තලය. දත්ත තලය සේවා අතර ඇමතුම් වලට බාධා කරන අතර ඒවා සමඟ "වෙනස් ඕනෑම දෙයක්" කරයි; පාලන තලය, පිළිවෙලින්, ප්‍රොක්සියේ හැසිරීම සම්බන්ධීකරණය කරන අතර ඔබට ප්‍රවේශය සපයයි, i.e. ක්රියාකරු, API වෙත, ජාලය හැසිරවීමට සහ සමස්තයක් ලෙස මැනීමට ඉඩ සලසයි.
මොකක්ද මේ proxy කියන්නේ? මෙය "Layer 7-aware" කාණ්ඩයේ TCP ප්‍රොක්සියකි (එනම් OSI ආකෘතියේ 7 වන ස්ථරය "ගණනයට ගනිමින්") HAProxy සහ NGINX වගේ. ඔබට ඔබේ අභිමතය පරිදි ප්‍රොක්සියක් තෝරා ගත හැකිය; Linkerd භාවිතා කරන්නේ රස්ට් ප්‍රොක්සියක්, සංකීර්ණ නොවන ලෙස නම් කර ඇත . අපි එය සේවා දැල සඳහා විශේෂයෙන් සම්පාදනය කර ඇත. අනෙකුත් දැල් වෙනත් ප්රොක්සි වලට වැඩි කැමැත්තක් දක්වයි (එන්වෝයි යනු පොදු තේරීමකි). කෙසේ වෙතත්, ප්රොක්සි තේරීම ක්රියාත්මක කිරීමේ කාරණයක් පමණි.
මෙම ප්රොක්සි සේවාදායකයන් කරන්නේ කුමක්ද? පැහැදිලිවම, ඔවුන් සේවාවන් වෙත සහ ඉන් ලැබෙන ඇමතුම් ප්රොක්සි කරයි (තදින් කිවහොත්, ඔවුන් ප්රොක්සි සහ ප්රොක්සි ලෙස ක්‍රියා කරයි, එන සහ පිටතට යන ඇමතුම් දෙකම හසුරුවයි). තවද ඔවුන් ඇමතුම් කෙරෙහි අවධානය යොමු කරන විශේෂාංග කට්ටලයක් ක්රියාත්මක කරයි අතර වේ සේවා. සේවා අතර ගමනාගමනය කෙරෙහි මෙම අවධානය යොමු කිරීම සේවා දැල් ප්‍රොක්සියක් API ගේට්වේ හෝ ඉන්ග්‍රෙස් ප්රොක්සි වලින් වෙන්කර හඳුනා ගනී (දෙවැන්න බාහිර ලෝකයෙන් පොකුරට එන ඇමතුම් කෙරෙහි අවධානය යොමු කරයි). (සටහන. පරිවර්තනය.: දැනටමත් සඳහන් කර ඇති නියෝජිතයා භාවිතා කරන, දැනට පවතින Kubernetes Ingress පාලක සංසන්දනය කිරීම සඳහා, බලන්න .)
ඉතින්, අපි දත්ත තලය හදුනාගත්තා. පාලන තලය සරල ය: එය සේවා සොයා ගැනීම, TLS සහතික නිකුත් කිරීම, ප්‍රමිතික එකතු කිරීම යනාදිය ඇතුළුව දත්ත තලයට සම්බන්ධීකරණ ආකාරයෙන් ක්‍රියා කිරීමට අවශ්ය සියලුම යාන්ත්‍ර විද්‍යාව සපයන සංරචක සමූහයකි. දත්ත තලය පාලක තලයට දැනුම් දෙයි. එහි හැසිරීම; අනෙක් අතට, පාලන තලය ඔබට සමස්තයක් ලෙස දත්ත තලයේ හැසිරීම වෙනස් කිරීමට සහ නිරීක්ෂණය කිරීමට ඉඩ සලසන API සපයයි.
පහත දැක්වෙන්නේ Linkerd හි පාලන තලයේ සහ දත්ත තලයේ රූප සටහනකි. ඔබට පෙනෙන පරිදි, පාලන තලයට ප්රොක්සි සේවාදායකයන්ගෙන් ප්‍රමිතික එකතු කරන ප්‍රොමිතියස් අවස්ථාවක් ඇතුළු විවිධ සංරචක ඇතුළත් වේ. destination (සේවා සොයාගැනීම), identity (සහතික අධිකාරිය, CA) සහ public-api (වෙබ් සහ CLI සඳහා අන්ත ලක්ෂ්‍ය). ඊට වෙනස්ව, දත්ත තලය යෙදුම් අවස්ථාවට යාබදව ඇති සරල සම්බන්ධක-ප්‍රොක්සියකි. මෙය තාර්කික රූප සටහනක් පමණි; සැබෑ ලෝකයේ යෙදවීමකදී, ඔබට එක් එක් පාලන තල සංරචකයේ අනුරූ තුනක් සහ දත්ත තලයේ ප්රොක්සි සිය ගණනක් හෝ දහස් ගණනක් තිබිය හැකිය.
(මෙම රූප සටහනේ ඇති නිල් කොටු කුබර්නෙටස් කරල් වල මායිම් නියෝජනය කරයි. ලින්කර්ඩ්-ප්රොක්සි සහිත බහාලුම් යෙදුම් බහාලුම්වල ඇති පොඩ් එකේම ඇති බව ඔබට පෙනේ. මෙම යෝජනා ක්‍රමය හඳුන්වන්නේ සයිඩ්කාර් කන්ටේනරය.)
සේවා දැල් ගෘහ නිර්මාණ ශිල්පය වැදගත් ඇඟවුම් කිහිපයක් ඇත. පළමුව, ප්‍රොක්සියක කාර්යය වන්නේ සේවා අතර ඇමතුම්වලට බාධා කිරීම බැවින්, සේවා දැලක් අර්ථවත් වන්නේ ඔබේ යෙදුම සේවා කට්ටලයක් සඳහා ගොඩනගා ඇත්නම් පමණි. දැලක් හැකි monoliths සමඟ භාවිතා කරන්න, නමුත් තනි ප්‍රොක්සියක් සඳහා මෙය පැහැදිලිවම අතිරික්ත වන අතර එහි ක්‍රියාකාරීත්වය ඉල්ලුමේ තිබිය නොහැක.
තවත් වැදගත් ප්රතිවිපාකයක් වන්නේ සේවා දැලක් අවශ්ය වේ විශාල ප්රොක්සි සංඛ්යාව. ඇත්ත වශයෙන්ම, Linkerd සෑම සේවාවකම සෑම අවස්ථාවකටම සම්බන්ධක-ප්රොක්සි දාමයක් (වෙනත් ක්රියාත්මක කිරීම් සෑම සත්කාරක/සත්කාරක/VM සඳහා ප්‍රොක්සියක් එක් කරයි. කෙසේ වෙතත් එය බොහෝ වේ). එවැනි ප්‍රොක්සියක් සක්‍රීයව භාවිතා කිරීම අමතර සංකූලතා ගණනාවක් දරයි:
- දත්ත තලයේ ප්රොක්සි විය යුතුය ඉක්මනින්, මක්නිසාද යත්, සෑම ඇමතුමක් සඳහාම ප්රොක්සි වෙත ඇමතුම් කිහිපයක් ඇත: එකක් සේවාදායක පැත්තේ, එකක් සේවාදායකයේ පැත්තේ.
- එසේම, ප්රොක්සි විය යුතුය කුඩා и සැහැල්ලු. සෑම එකක්ම මතකය සහ CPU සම්පත් පරිභෝජනය කරන අතර, මෙම පරිභෝජනය යෙදුම සමඟ රේඛීයව වර්ධනය වේ.
- ප්රොක්සි විශාල සංඛ්‍යාවක් යෙදවීමට සහ යාවත්කාලීන කිරීමට ඔබට යාන්ත්‍රණයක් අවශ්ය වනු ඇත. එය අතින් කිරීම විකල්පයක් නොවේ.
සාමාන්‍යයෙන්, සේවා දැල මේ ආකාරයට පෙනේ (අවම වශයෙන් කුරුල්ලෙකුගේ ඇසින්): ඔබ අභ්යන්තර, අන්තර් සේවා ගමනාගමනය සමඟ "යමක් කරන" පරිශීලක අවකාශයේ ප්රොක්සි සමූහයක් යොදවා, ඒවා නිරීක්ෂණය කිරීමට සහ කළමනාකරණය කිරීමට පාලන තලය භාවිතා කරන්න.
"ඇයි?" යන ප්රශ්නයට කාලයයි.
සේවා දැලක් යනු කුමක් සඳහාද?
සේවා දැලක් පිළිබඳ අදහස මුලින්ම මුණගැසුණු අය සඳහා, මඳක් බියට පත්වීමට සමාව දිය හැකිය. සේවා දැල් සැලසුමෙන් අදහස් වන්නේ එය යෙදුම් ප්රමාදය වැඩි කරනවා පමණක් නොව, එය ද වනු ඇති බවයි පරිභෝජනය කරයි සම්පත් හා එකතු කරනු ඇත යටිතල පහසුකම්වල නව යාන්ත්‍රණ පොකුරක්. පළමුව ඔබ සේවා දැලක් සකසන්න, පසුව ඔබට හදිසියේම ප්රොක්සි සිය ගණනක් (දහස් ගණනක් නොවේ නම්) සේවය කිරීමට අවශ්ය වේ. ප්රශ්නය නම් මේ සඳහා ස්වේච්ඡාවෙන් ඉදිරිපත් වන්නේ කවුද?
මෙම ප්රශ්නයට පිළිතුර කොටස් දෙකකින් සමන්විත වේ. පළමුව, පරිසර පද්ධතියේ සිදුවන යම් යම් වෙනස්කම් හේතුවෙන් මෙම ප්රොක්සි යෙදවීම හා සම්බන්ධ ගනුදෙනු පිරිවැය සැලකිය යුතු ලෙස අඩු කළ හැකිය (මේ ගැන වැඩි විස්තර පසුව).
දෙවනුව, එවැනි උපකරණයක් ඇත්ත වශයෙන්ම පද්ධතියට අතිරේක තර්කනය හඳුන්වා දීම සඳහා විශිෂ්ට ක්රමයකි. තවද සේවා දැල භාවිතයෙන් නව විශේෂාංග රාශියක් එක් කළ හැකි නිසා පමණක් නොව, පරිසර පද්ධතියට බාධාවක් නොවන පරිදි එය කළ හැකි බැවිනි. ඇත්ත වශයෙන්ම, සමස්ත සේවා දැල් ආකෘතිය මෙම උපකල්පනය මත පදනම් වේ: බහු සේවා පද්ධතියක, කුමක් වුවත් කරනවා තනි සේවා, ගමනාගමනය ඔවුන් අතර ක්‍රියාකාරීත්වය එක් කිරීමට සුදුසුම ලක්ෂ්‍යය වේ.
උදාහරණයක් ලෙස, Linkerd හි (බොහෝ දැල් වල මෙන්) ක්‍රියාකාරීත්වය මූලික වශයෙන් HTTP/2 සහ gRPC* ඇතුළුව HTTP ඇමතුම් වෙත අවධානය යොමු කෙරේ. ක්‍රියාකාරීත්වය තරමක් පොහොසත් ය - එය පන්ති තුනකට බෙදිය හැකිය:
- අදාළ ලක්ෂණ විශ්වසනීයත්වය. නැවත උත්සාහ කරන්න ඉල්ලීම්, කල් ඉකුත්වීම්, කැනරි ප්‍රවේශය (රථවාහන භේදය/යළි යොමු කිරීම) යනාදිය.
- අදාළ ලක්ෂණ අධීක්ෂණය. එක් එක් සේවාව හෝ තනි ගමනාන්ත සඳහා සාර්ථක අනුපාත, ප්‍රමාදයන් සහ ඉල්ලීම් පරිමාවන් එකතු කිරීම; සේවා ස්ථාන විද්‍යාත්මක සිතියම් ගොඩනැගීම යනාදිය.
- අදාළ ලක්ෂණ ආරක්ෂාව. අන්යෝන්ය TLS, ප්රවේශ පාලනය, ආදිය.
* Linkerd ගේ දෘෂ්ටි කෝණයෙන්, gRPC ප්‍රායෝගිකව HTTP/2 ට වඩා වෙනස් නොවේ: එය ගෙවීමේ ප්‍රෝටෝබුෆ් භාවිතා කරයි. සංවර්ධකයෙකුගේ දෘෂ්ටි කෝණයෙන්, මෙම කරුණු දෙක, ඇත්ත වශයෙන්ම, වෙනස් වේ.
මෙම යාන්ත්‍රණ බොහොමයක් ඉල්ලීම් මට්ටමින් ක්රියාත්මක වේ (එබැවින් "L7 ප්රොක්සි"). උදාහරණයක් ලෙස, සේවා ෆූ විසින් සේවා තීරුව වෙත HTTP ඇමතුමක් ලබා දෙන්නේ නම්, ෆූගේ පැත්තේ ඇති ලින්කර්ඩ්-ප්‍රොක්සියට නිරීක්ෂිත ප්රමාදය මත පදනම්ව ෆූ සිට බාර් දක්වා ඇමතුම් බුද්ධිමත්ව පූරණය කළ හැකිය. එය අවශ්ය නම් (සහ එය දුර්වල නම්) ඉල්ලීම නැවත නැවතත් කළ හැක; ඔහුට ප්‍රතිචාර කේතය සහ කල් ඉකුත්වීම ආදිය වාර්තා කළ හැක. ඒ හා සමානව, තීරුවේ ඇති linkerd-proxy හට ඉල්ලීමක් අවසර නොමැති නම් හෝ ඉල්ලීම් සීමාව ඉක්මවා ඇත්නම් එය ප්‍රතික්ෂේප කළ හැක; එහි කොටසෙහි ප්රමාදය නිවැරදි කළ හැකිය, ආදිය.
ප්රොක්සි වලට සම්බන්ධතා මට්ටමින් "යමක්" කළ හැකිය. උදාහරණයක් ලෙස, Foo පැත්තේ ඇති linkerd-proxy එකකට TLS සම්බන්ධතාවයක් ආරම්භ කළ හැකි අතර, Bar පැත්තේ ඇති linkerd-proxy එකකට එය අවසන් කළ හැකි අතර, දෙපැත්තටම එකිනෙකාගේ TLS සහතික සත්‍යාපනය කළ හැක*. මෙය සේවා අතර සංකේතනය පමණක් නොව, සේවාවන් හඳුනා ගැනීමට ගුප්ත ලේඛන ආරක්ෂිත ක්‍රමයක් ද සපයයි: Foo සහ Bar ඔවුන් පවසන අය බව "ඔප්පු" කළ හැක.
* "මිතුරෙකුගේ මිතුරෙකු" යන්නෙන් අදහස් වන්නේ සේවාදායකයාගේ සහතිකය ද සත්‍යාපනය කර ඇති බවයි (අන්යෝන්ය TLS). "සම්භාව්‍ය" TLS හි, උදාහරණයක් ලෙස, බ්‍රවුසරයක් සහ සේවාදායකයක් අතර, සාමාන්‍යයෙන් සත්‍යාපනය කරනු ලබන්නේ එක් පැත්තක (සේවාදායකය) සහතිකය පමණි.
ඒවා ඉල්ලීම් හෝ සම්බන්ධතා මට්ටමින් ක්රියාත්මක වුවද, සියලුම සේවා දැල් විශේෂාංග බව අවධාරණය කිරීම වැදගත්ය මෙහෙයුම් ස්වභාවය. Linkerd හට JSON ඛණ්ඩයකට ක්ෂේත්‍ර එකතු කිරීම හෝ ප්‍රොටොබෆ් එකකට වෙනස් කිරීම් කිරීම වැනි, ගෙවීමේ අර්ථය පරිවර්තනය කිරීමට නොහැකි වේ. අපි ESB සහ midware ගැන කතා කරන විට මෙම වැදගත් අංගය ගැන පසුව කතා කරමු.
සේවා දැල පිරිනමන විශේෂාංග සමූහය මෙයයි. ප්රශ්නය පැනනගින්නේ: අයදුම්පත්රයේ ඒවා සෘජුවම ක්රියාත්මක නොකරන්නේ මන්ද? සහ ප්‍රොක්සියක් සමඟ කිසිසේත්ම අවුල් කරන්නේ ඇයි?
සේවා දැලක් හොඳ අදහසක් වන්නේ ඇයි?
සේවා දැලෙහි හැකියාවන් ආකර්ශනීය වන අතර, එහි ප්රධාන අගය ඇත්ත වශයෙන්ම විශේෂාංග තුළ පවතින්නේ නැත. අවසානයේ අපි පුළුවන් ඒවා කෙලින්ම යෙදුමේ ක්රියාත්මක කරන්න (මෙය සේවා දැලෙහි මූලාරම්භය බව පසුව අපට පෙනෙනු ඇත). එය එක් වාක්‍යයකින් පැවසුවහොත්, සේවා දැලක වටිනාකම: එය නවීන සේවාදායක මෘදුකාංග ස්ථාවර, තොග-පුළුල්, යෙදුම්-කේත-අඥෙයවාදී ආකාරයෙන් ක්රියාත්මක කිරීම සඳහා තීරණාත්මක ක්‍රියාකාරීත්වයක් සපයයි..
අපි මෙම යෝජනාව විශ්ලේෂණය කරමු.
«නවීන සේවාදායක මෘදුකාංග ක්රියාත්මක කිරීමට තීරණාත්මක කාර්යයන්". ඔබ බාහිර ලෝකයෙන් ඉල්ලීම් පිළිගෙන කෙටි කාලයක් තුළ ඒවාට ප්‍රතිචාර දක්වන පොදු අන්තර්ජාලයට සම්බන්ධ ගනුදෙනු සේවාදායක යෙදුමක් ගොඩනඟන්නේ නම් - උදාහරණයක් ලෙස, වෙබ් යෙදුමක්, API සේවාදායකයක් සහ අනෙකුත් නවීන යෙදුම්වලින් අතිමහත් බහුතරයක් - සහ ඔබ එය එකිනෙකා සමඟ සමමුහුර්තව අන්තර්ක්‍රියා කරන සේවා සමූහයක් ලෙස ක්රියාත්මක කරන්නේ නම් සහ ඔබ නිරන්තරයෙන් මෙම මෘදුකාංගය යාවත්කාලීන කරන්නේ නම්, නව විශේෂාංග එකතු කරන්නේ නම් සහ වෙනස් කිරීමේ ක්‍රියාවලියේදී මෙම පද්ධතිය ක්‍රියාකාරී තත්ත්වයේ තබා ගැනීමට ඔබට බල කෙරෙන්නේ නම් - මෙම අවස්ථාවේදී, සුභ පැතුම්, ඔබ නවීන සේවාදායක මෘදුකාංගයක් නිර්මාණය කරයි. ඉහත ලැයිස්තුගත කර ඇති සියලුම විශිෂ්ට විශේෂාංග ඇත්ත වශයෙන්ම ඔබට තීරණාත්මක වේ. යෙදුම විශ්වාසදායක, ආරක්ෂිත විය යුතු අතර එය කරන්නේ කුමක්දැයි ඔබට දැකීමට හැකි විය යුතුය. සේවා දැල විසඳීමට උපකාර වන මෙම ප්රශ්න වේ.
(හරි, මෙම ප්‍රවේශය සේවාදායක මෘදුකාංග තැනීමේ නවීන ක්‍රමය බව මගේ විශ්වාසය පෙර ඡේදයට රිංගා ඇත. අනෙක් අය ඉහත දක්වා ඇති නිර්වචනයට නොවැටෙන මොනොලිත්, "ප්‍රතික්‍රියාශීලී ක්ෂුද්ර සේවා" සහ වෙනත් දේවල් සංවර්ධනය කිරීමට කැමැත්තක් දක්වයි. මගේ මතයට වඩා වෙනස් වන අතර, අනෙක් අතට, ඒවා "වැරදි" යැයි මම විශ්වාස කරමි - ඕනෑම අවස්ථාවක, සේවා දැල ඔවුන්ට එතරම් ප්රයෝජනවත් නොවේ).
«සම්පූර්ණ තොගය සඳහා නිල ඇඳුම". සේවා දැල මගින් සපයනු ලබන විශේෂාංග තීරනාත්මක නොවේ. ඔවුන් ලියා ඇත්තේ කුමන භාෂාවෙන්ද, කුමන රාමුවකින්ද, කුමන රාමුවකින්ද, ඒවා ලිව්වේ කවුරුන්ද, ඒවා යෙදවූයේ කෙසේද, සහ ඒවායේ සංවර්ධනයේ සහ භාවිතයේ අනෙකුත් සියුම්කම් නොසලකා, යෙදුමක ඇති සියලුම සේවාවන් සඳහා ඒවා අදාළ වේ.
«යෙදුම් කේතය ස්වාධීන". අවසාන වශයෙන්, සේවා දැල සම්පූර්ණ තොගය පුරා ස්ථාවර ක්‍රියාකාරීත්වයක් ලබා දෙනවා පමණක් නොව, එය යෙදුම සංස්කරණය කිරීම අවශ්ය නොවන ආකාරයෙන් සිදු කරයි. වින්‍යාස කිරීම, යාවත්කාලීන කිරීම, ක්රියාත්මක කිරීම, නඩත්තු කිරීම යනාදී කාර්යයන් ඇතුළුව සේවා දැලක ක්‍රියාකාරීත්වයේ මූලික පදනම තනිකරම වේදිකා මට්ටමේ වන අතර එය යෙදුමෙන් ස්වාධීන වේ. සේවා දැලට බලපෑමක් නොකර යෙදුම වෙනස් කළ හැක. අනෙක් අතට, කිසිදු යෙදුම් මැදිහත්වීමකින් තොරව සේවා දැල වෙනස් කළ හැකිය.
කෙටියෙන් කිවහොත්, සේවා දැල අත්‍යවශ්‍ය ක්‍රියාකාරීත්වයක් ලබා දෙනවා පමණක් නොව, එය ගෝලීය, ඒකාකාරී සහ යෙදුමෙන් ස්වාධීන ආකාරයකින් සිදු කරයි. එබැවින්, සේවා දැලක ක්‍රියාකාරීත්වය සේවාවක කේතය තුළ ක්රියාත්මක කළ හැකි අතර (උදාහරණයක් ලෙස, එක් එක් සේවාව සමඟ ඇතුළත් පුස්තකාලයක් ලෙස), මෙම ප්‍රවේශය සම්බන්ධයෙන් එතරම් වටිනා ඒකාකාරිත්වය සහ ස්වාධීනත්වය ලබා නොදේ. සේවා දැලක්.
ඔබ කළ යුත්තේ ප්රොක්සි පොකුරක් එකතු කිරීමයි! මම පොරොන්දු වෙනවා, ඉතා ඉක්මනින් අපි මෙම ප්රොක්සි එකතු කිරීම හා සම්බන්ධ මෙහෙයුම් වියදම් දෙස බලමු. නමුත් පළමුව, අපි නවතා දමා විවිධ දෘෂ්ටිකෝණයෙන් ස්වාධීනත්වය පිළිබඳ මෙම අදහස දෙස බලමු ජනතාව.
සේවා දැල උදව් කරන්නේ කාටද?
තාක්‍ෂණයක් පරිසර පද්ධතියේ වැදගත් අංගයක් බවට පත්වීමට නම්, එය අපහසුතාවයක් වුවද, එය මිනිසුන් විසින් පිළිගත යුතුය. ඉතින් සේවා දැලක් ගැන උනන්දුවක් දක්වන්නේ කවුද? එහි භාවිතයෙන් ප්රතිලාභ ලබන්නේ කවුද?
ඔබ නවීන සේවාදායක මෘදුකාංගයක් සංවර්ධනය කරන්නේ නම්, ඔබේ කණ්ඩායම කණ්ඩායමක් ලෙස දළ වශයෙන් සිතාගත හැකිය සේවා හිමිකරුවන්එක්ව ව්‍යාපාර තර්කනය සංවර්ධනය කර ක්රියාත්මක කරන අය, සහ වේදිකා අයිතිකරුවන්මෙම සේවාවන් ක්රියාත්මක වන අභ්යන්තර වේදිකාවේ සංවර්ධනයට සම්බන්ධ වේ. කුඩා සංවිධානවල, මේ අය එකම පුද්ගලයින් විය හැකි නමුත්, සමාගම වර්ධනය වන විට, මෙම භූමිකාවන් වඩාත් පැහැදිලිව පෙනෙන අතර උප භූමිකාවන්ට පවා බෙදී යයි ... (devops වල වෙනස්වන ස්වභාවය ගැන මෙහි පැවසීමට බොහෝ දේ ඇත, ක්ෂුද්ර සේවා ආදියෙහි ආයතනික බලපෑම).
මෙම දෘෂ්ටි කෝණයෙන්, සේවා දැලෙහි පැහැදිලි ප්‍රතිලාභීන් වේදිකාවේ හිමිකරුවන් වේ. සියල්ලට පසු, වේදිකා කණ්ඩායමේ අවසාන ඉලක්කය වන්නේ සේවා හිමිකරුවන්ට ව්‍යාපාර තර්කනය ක්රියාත්මක කළ හැකි අභ්යන්තර වේදිකාවක් නිර්මාණය කිරීම සහ එහි ක්‍රියාකාරිත්වයේ දරුණු විස්තර වලින් ඔවුන්ට උපරිම ස්වාධීනත්වය සහතික වන ආකාරයෙන් එය කිරීමයි. සේවා දැල මෙම ඉලක්කය සාක්ෂාත් කර ගැනීම සඳහා තීරනාත්මක හැකියාවන් ලබා දෙනවා පමණක් නොව, එය සේවා හිමිකරුවන් මත යැපීමක් නොපෙන්වන ආකාරයෙන් සිදු කරයි.
වඩාත් වක්‍ර ආකාරයකින් වුවද සේවා හිමිකරුවන්ටද ප්රතිලාභ ලැබේ. සේවා හිමිකරුගේ පරමාර්ථය වන්නේ ව්‍යාපාර ක්‍රියාවලියේ තර්කනය ක්‍රියාවට නැංවීමේදී හැකි තරම් ඵලදායි වීම වන අතර, මෙහෙයුම් ගැටළු පිළිබඳව ඔහුට කරදර වීමට ඇති තරමට වඩා හොඳය. ප්‍රතිපත්ති හෝ TLS බලාත්මක කිරීම, පවසන්න, නැවත උත්සාහ කිරීම වෙනුවට, ඔවුන්ට ව්‍යාපාරය කෙරෙහි පමණක් අවධානය යොමු කළ හැකි අතර වේදිකාව ඉතිරිය බලා ගනී යැයි බලාපොරොත්තු වේ. ඔවුන්ට මෙය විශාල වාසියකි.
වේදිකා සහ සේවාවන්හි හිමිකරුවන් අතර එවැනි බෙදීමක සංවිධානාත්මක වටිනාකම අධිතක්සේරු කළ නොහැකිය. මම හිතන්නේ ඇය දායක වෙනවා ප්රධාන සේවා දැලෙහි වටිනාකමට දායකත්වය.
අපි මෙම පාඩම ඉගෙන ගත්තේ මුල් ලින්කර්ඩ් රසිකයෙක් ඔවුන් සේවා දැල තෝරා ගත්තේ මන්දැයි අපට පැවසූ විටය: එය ඔවුන්ට “අවම වශයෙන් කතා කිරීමට” ඉඩ දුන් බැවිනි. මෙන්න විස්තර කිහිපයක්: එක් විශාල සමාගමක පිරිමි ළමයින් ඔවුන්ගේ වේදිකාව Kubernetes වෙත සංක්‍රමණය විය. යෙදුම සංවේදී තොරතුරු සමඟ ක්‍රියා කළ බැවින්, ඔවුන්ට අවශ්ය වූයේ පොකුරු තුළ ඇති සියලුම සන්නිවේදනයන් සංකේතනය කිරීමටය. කෙසේ වෙතත්, සේවා සිය ගණනක් සහ සංවර්ධන කණ්ඩායම් සිය ගණනක් සිටීම නිසා තත්වය සංකීර්ණ විය. සෑම කෙනෙකුම සම්බන්ධ කර ගැනීමට සහ ඔවුන්ගේ සැලසුම්වලට TLS සඳහා සහය ඇතුළත් කිරීමට ඔවුන්ට ඒත්තු ගැන්වීමේ අපේක්ෂාව ඔවුන් කිසිසේත් සතුටු කළේ නැත. Linkerd ස්ථාපනය කිරීමෙන්, ඔවුන් සංක්‍රමණය විය වගකීමයි සංවර්ධකයින්ගේ සිට (එය අනවශ්‍ය කරදරයක් වූ) වේදිකාකරුවන් දක්වා, මෙය ඉහළ මට්ටමේ ප්‍රමුඛතාවයක් විය. වෙනත් වචන වලින් කිවහොත්, ලින්කර්ඩ් ඔවුන් සඳහා විසඳමින් සිටියේ ආයතනික ගැටළුවක් තරම් තාක්ෂණික ගැටළුවක් නොවේ.
කෙටියෙන් කිවහොත්, සේවා දැලක්, ඒ වෙනුවට, තාක්ෂණික විසඳුමක් නොවේ, නමුත් සමාජ-තාක්ෂණික ගැටලු. (ඔයාට ස්තූතියි මෙම පදය හඳුන්වා දීම සඳහා.
සේවා දැල මගේ සියලු ගැටලු විසඳයිද?
ඔව්. මම කිව්වේ, නැහැ!
ඉහත දක්වා ඇති විශේෂාංග කාණ්ඩ තුන දෙස බලන විට - විශ්වසනීයත්වය, ආරක්ෂාව සහ නිරීක්ෂණ හැකියාව - මෙම කිසිදු ගැටළුවකට සේවා දැල සම්පූර්ණ විසඳුමක් නොවන බව පැහැදිලි වේ. Linkerd හට නැවත නැවත ඉල්ලීම් යැවිය හැකි වුවද (ඒවා දුර්වල බව එය දන්නේ නම්), සේවාව අවසානයේ අඩු වී ඇත්නම්, පරිශීලකයා වෙත ආපසු යා යුතු දේ පිළිබඳව තීරණ ගැනීමට එයට හැකියාවක් නැත - එවැනි තීරණ යෙදුම මගින් සිදු කළ යුතුය. Linkerd හට සාර්ථක ඉල්ලීම් පිළිබඳ සංඛ්‍යාලේඛන තබා ගත හැක, නමුත් එයට සේවාව සොයා බැලීමට සහ එහි අභ්යන්තර ප්‍රමිතික ලබා දීමට නොහැකි වේ - යෙදුමක එවැනි මෙවලම් කට්ටලයක් තිබිය යුතුය. ලින්කර්ඩ්ට mTLS සත්කාරකත්වය සැපයීමට හැකියාව ඇති අතර, පූර්ණ ආරක්ෂක විසඳුම් සඳහා තවත් බොහෝ දේ අවශ්ය වේ.
සේවා දැල මගින් පිරිනමනු ලබන මෙම ක්ෂේත්‍රවල විශේෂාංගවල උප කුලකයක් සම්බන්ධ වේ වේදිකා විශේෂාංග. මෙයින් මා අදහස් කරන්නේ පහත සඳහන් කාර්යයන්
- ව්‍යාපාර තර්කයෙන් ස්වාධීනයි. ෆූ සහ බාර් අතර ඇමතුම් හිස්ටෝග්‍රෑම් ගොඩනඟා ඇති ආකාරය සම්පූර්ණයෙන්ම ස්වාධීන වේ ඇයි? ෆූ බාර් කැඳවයි.
- නිවැරදිව ක්රියාත්මක කිරීමට අපහසුය. Linkerd හි, නැවත උත්සාහයන් නැවත උත්සාහ කිරීමේ අයවැය වැනි සියලු ආකාරයේ විසිතුරු දේවල් සමඟ පරාමිතිකරණය කර ඇත. (අයවැය නැවත උත්සාහ කරන්න), එවැනි දේ ක්රියාත්මක කිරීම සඳහා සරල මනසකින් යුත් ප්‍රවේශයක් නිසැකවම ඊනියා "ඉල්ලීම්වල හිම කුණාටුව" මතුවීමට තුඩු දෙනු ඇත. (කුණාටුව නැවත උත්සාහ කරන්න) සහ බෙදා හරින ලද පද්ධති සඳහා විශේෂිත වූ වෙනත් ගැටළු.
- අඛණ්ඩව යොදන විට වඩාත් ඵලදායී වේ. TLS යාන්ත්‍රණය අර්ථවත් වන්නේ සෑම තැනකම යෙදුවහොත් පමණි.
මෙම විශේෂාංග ක්රියාත්මක කර ඇත්තේ ප්රොක්සි ස්ථරයේ (සහ යෙදුම් ස්ථරයේ නොවේ), සේවා දැල ඒවා නිරාවරණය කරයි වේදිකාව, යෙදුම් නොවේ. මේ අනුව, සේවාවන් ලියා ඇත්තේ කුමන භාෂාවෙන්ද, ඔවුන් භාවිතා කරන රාමුව කුමක්ද, ඒවා ලිව්වේ කවුරුන්ද සහ ඇයිද යන්න ගැටළුවක් නොවේ. ප්රොක්සි මෙම සියලු විස්තර වලින් ඔබ්බට ක්‍රියා කරන අතර, වින්‍යාස කිරීම, යාවත්කාලීන කිරීම, ක්රියාත්මක කිරීම, නඩත්තු කිරීම යනාදී කාර්යයන් ඇතුළුව මෙම ක්‍රියාකාරීත්වයේ මූලික පදනම පවතින්නේ වේදිකා මට්ටමේ පමණි.
සේවා දැල් හැකියාවන් පිළිබඳ උදාහරණ
සාරාංශයක් ලෙස, සේවා දැලක් විශ්වසනීයත්වය, නිරීක්ෂණ හැකියාව හෝ ආරක්ෂාව සඳහා සම්පූර්ණ විසඳුමක් නොවේ. මෙම ක්ෂේත්‍රවල විෂය පථය සේවා හිමිකරුවන්, Ops / SRE කණ්ඩායම් සහ අනෙකුත් සමාගම් පාර්ශවකරුවන්ගේ අනිවාර්ය සහභාගීත්වය අදහස් කරයි. සේවා දැල මෙම එක් එක් ප්‍රදේශ සඳහා වේදිකා මට්ටමින් "පෙත්තක්" පමණක් සපයයි.
සේවා දැල දැන් ජනප්‍රිය වී ඇත්තේ ඇයි?
ඔබ දැන් කල්පනා කරනවා ඇති: හරි, සේවා දැල ඉතා හොඳ නම්, වසර දහයකට පෙර අපි මිලියන ගණනක් ප්රොක්සි තොගය මත යෙදවීමට පටන් නොගත්තේ ඇයි?
මෙම ප්රශ්නයට අශෝභන පිළිතුරක් තිබේ: වසර දහයකට පෙර සෑම කෙනෙකුම මොනොලිත් ගොඩනඟා ඇති අතර, කිසිවෙකුට සේවා දැලක් අවශ්ය නොවීය. මෙය සත්‍යයකි, නමුත් මගේ මතය අනුව, මෙම පිළිතුර කාරණය මග හැරේ. මීට වසර දහයකට පෙර පවා, මහා පරිමාණ පද්ධති නිර්මාණය කිරීමට පොරොන්දු වූ ක්‍රමයක් ලෙස ක්ෂුද්ර සේවා සංකල්පය ට්විටර්, ෆේස්බුක්, ගූගල් සහ නෙට්ෆ්ලික්ස් වැනි සමාගම්වල පුළුල් ලෙස සාකච්ඡා කර ක්රියාත්මක විය. සාමාන්ය සංජානනය - අවම වශයෙන් මම සම්බන්ධ වී ඇති කර්මාන්තයේ කොටස්වල - ක්ෂුද්ර සේවා යනු විශාල පද්ධති සෑදීමට "නිවැරදි මාර්ගය" බව, එය ඉතා දුෂ්කර වුවද.
ඇත්ත වශයෙන්ම, මීට වසර දහයකට පෙර ක්ෂුද්ර සේවා සූරාකන සමාගම් තිබුණද, ඔවුන් සේවා දැලක් සෑදීමට හැකි සෑම තැනකම ප්රොක්සි ඇලවූයේ නැත. කෙසේ වෙතත්, ඔබ සමීපව බැලුවහොත්, ඔවුන් සමාන දෙයක් කළා: මෙම සමාගම් බොහොමයක් ජාලකරණය සඳහා විශේෂ අභ්යන්තර පුස්තකාලයක් භාවිතා කිරීම අනිවාර්ය කර ඇත (සමහර විට මේදය සේවාදායක පුස්තකාලය ලෙස හැඳින්වේ, මහත සේවාදායක පුස්තකාලය).
Netflix සතුව Hysterix, Google සතුව Stubby, Twitter හට Finagle පුස්තකාලය තිබුණි. උදාහරණයක් ලෙස, Twitter හි සෑම නව සේවාවක් සඳහාම Finagle අනිවාර්ය කර ඇත. එය සම්බන්ධතා වල සේවාලාභියා සහ සේවාදායකය යන දෙකම හසුරුවන අතර, නැවත නැවත ඉල්ලීම්, සහය දක්වන ඉල්ලීම් මාර්ගගත කිරීම, පැටවුම් තුලනය සහ මැනීම සඳහා ඉඩ ලබා දුන්නේය. සේවාව කුමක් කළත් එය සමස්ත ට්විටර් තොගය පුරාවටම විශ්වාසනීයත්වයේ සහ නිරීක්‍ෂණයේ ස්ථාවර ස්ථරයක් සපයන ලදී. ඇත්ත වශයෙන්ම, එය JVM භාෂා සඳහා පමණක් ක්‍රියා කළ අතර සම්පූර්ණ යෙදුම සඳහා භාවිතා කළ යුතු ක්‍රමලේඛන ආකෘතියක් මත පදනම් විය. කෙසේ වෙතත්, එහි ක්‍රියාකාරිත්වය සේවා දැලෙහි ක්‍රියාකාරිත්වයට සමාන විය. (ඇත්ත වශයෙන්ම, Linkerd හි පළමු අනුවාදය ප්රොක්සි ආකාරයෙන් ඔතා Finagle විය.)
මේ අනුව, වසර දහයකට පෙර ක්ෂුද්ර සේවා පමණක් නොව, අද සේවා දැල විසඳන ගැටළුම විසඳන විශේෂ ප්‍රොටෝ-සේවා-දැල් පුස්තකාල ද තිබුණි. කෙසේ වෙතත්, සේවා දැලක් එවකට නොතිබුණි. ඇය පෙනී සිටීමට පෙර තවත් මාරුවක් තිබිය යුතුය.
පසුගිය වසර 10 තුළ සිදු වූ තවත් වෙනසක් තුළ සැඟවී ඇති ගැඹුරු පිළිතුර ඇත්තේ මෙහිදීය: ක්ෂුද්ර සේවා යෙදවීමේ පිරිවැයේ තියුනු පහත වැටීමක් සිදුවී ඇත. දශකයකට පෙර ක්ෂුද්ර සේවා භාවිතා කළ ඉහත සඳහන් කළ සමාගම් - ට්විටර්, නෙට්ෆ්ලික්ස්, ෆේස්බුක්, ගූගල් - විශාල පරිමාණයේ සහ විශාල සම්පත් ඇති සමාගම් විය. ඔවුන්ට අවශ්‍යතාවය පමණක් නොව, ක්ෂුද්ර සේවා මත පදනම්ව විශාල යෙදුම් තැනීමට, යෙදවීමට සහ ක්රියාත්මක කිරීමට හැකියාව ද තිබුණි. ට්විටර් ඉංජිනේරුවන් මොනොලිතික් එකක සිට ක්ෂුද්ර සේවා ප්‍රවේශයක් දක්වා ගමන් කර ඇති ශක්තිය සහ උත්සාහය පුදුම සහගතය. (අවංකවම, එය ක්රියාත්මක වූවා සේම.) මේ ආකාරයේ යටිතල පහසුකම් උපාමාරු කුඩා සමාගම්වලට එවකට කළ නොහැකි විය.
අපි වර්තමානයට යමු. අද වන විට ක්ෂුද්ර සේවා සහ සංවර්ධකයින්ගේ අනුපාතය 5:1 (හෝ ඊටත් වඩා) වන ආරම්භක පවතී ), තවද, ඔවුන් සමඟ සාර්ථකව කටයුතු කරයි! පුද්ගලයන් 5 දෙනෙකුගෙන් යුත් ආරම්භකයකුට ක්ෂුද්ර සේවා 50 ක් වෙහෙසකින් තොරව ක්රියාත්මක කිරීමට හැකි නම්, යමක් පැහැදිලිවම ඒවා ක්රියාත්මක කිරීමේ පිරිවැය අඩු කළේය.
Monzo හි ක්ෂුද්ර සේවා 1500; සෑම රේඛාවක්ම ගමනාගමනයට ඉඩ සලසන නියමිත ජාල රීතියකි
මෙහෙයුම් ක්ෂුද්ර සේවාවල පිරිවැය නාටකාකාර ලෙස අඩු කිරීම තනි ක්‍රියාවලියක ප්‍රතිඵලයකි: බහාලුම්වල ජනප්‍රියතාවය වර්ධනය වේ и වාදකයින්. සේවා දැලක් මතුවීමට දායක වූයේ කුමක්ද යන ප්රශ්නයට හරියටම මෙය ගැඹුරු පිළිතුරයි. එම තාක්ෂණයම සේවා දැලක් සහ ක්ෂුද්ර සේවා දෙකම ආකර්ශනීය කළේය: කුබර්නෙටස් සහ ඩොකර්.
ඇයි? හොඳයි, ඩොකර් එක විශාල ගැටළුවක් විසඳයි - ඇසුරුම්කරණයේ ගැටලුව. යෙදුමක් සහ එහි (ජාල නොවන) ධාවන කාල පරායත්තතා බහාලුමක ඇසුරුම් කිරීමෙන්, ඩොකර් යෙදුම ඕනෑම තැනක සත්කාරක කර ධාවනය කළ හැකි දිලීර ඒකකයක් බවට පත් කරයි. ඒ අතරම, එය මෙහෙයුම බෙහෙවින් සරල කරයි. බහුභාෂා තොගය: කන්ටේනරයක් ක්රියාත්මක කිරීමේ පරමාණුක ඒකකයක් වන බැවින්, එය යෙදවීම සහ ක්රියාත්මක කිරීමේ අරමුණු සඳහා එය JVM, Node, Go, Python, හෝ Ruby යෙදුමක් වේවා, ඇතුළත ඇති දේ වැදගත් නොවේ. ඔබ එය ක්රියාත්මක කරන්න, එය එයයි.
Kubernetes සෑම දෙයක්ම ඊළඟ මට්ටමට ගෙන යයි. දැන් "ක්රියාත්මක කළ හැකි දේවල්" ගොන්නක් සහ ඒවා ක්රියාත්මක කිරීමට බොහෝ යන්ත්‍ර ඇති බැවින්, ඒවා එකිනෙකට සමාන කළ හැකි මෙවලමක් අවශ්ය වේ. පුළුල් අර්ථයකින්, ඔබ Kubernetes හට බොහෝ බහාලුම් සහ බොහෝ යන්ත්‍ර ලබා දෙන අතර, එය ඒවා එකිනෙකට ගැලපේ (ඇත්ත වශයෙන්ම, මෙය ගතික සහ නිරන්තරයෙන් වෙනස් වන ක්‍රියාවලියකි: නව බහාලුම් පද්ධතිය වටා ගමන් කිරීම, යන්ත්‍ර ආරම්භ කිරීම සහ නැවැත්වීම යනාදිය. කෙසේ වෙතත්, Kubernetes මේ සියල්ල සැලකිල්ලට ගනී ).
Kubernetes පිහිටුවා ගත් පසු, එක් සේවාවක් යෙදවීමට සහ ක්රියාත්මක කිරීමට ගතවන කාලය සේවා දහයක් යෙදවීමට සහ ක්රියාත්මක කිරීමට වැයවන මුදලට වඩා බොහෝ වෙනස් නොවේ (ඇත්ත වශයෙන්ම එය සේවා 100කට ආසන්න වශයෙන් සමාන වේ). බහුභාෂා ක්රියාත්මක කිරීම දිරිමත් කරන ඇසුරුම් යාන්ත්‍රණයක් ලෙස මෙම බහාලුම්වලට එක් කරන්න, සහ ඔබට සේවා දැල ඉතා හොඳින් ගැලපෙන ආකාරයේ පරිසරයක් සඳහා බහු භාෂාවලින් ලියා ඇති ක්ෂුද්ර සේවා ලෙස ක්රියාත්මක කරන ලද නව යෙදුම් ටොන් ගණනක් ඇත.
එබැවින්, සේවා දැලක් පිළිබඳ අදහස දැන් ජනප්‍රිය වී ඇත්තේ මන්ද යන ප්රශ්නයට පිළිතුරට අපි පැමිණෙමු: කුබර්නෙට්ස් සේවා සඳහා සපයන ඒකාකාරිත්වය සේවා දැල මුහුණ දෙන මෙහෙයුම් කාර්යයන් සඳහා කෙලින්ම අදාළ වේ. ඔබ ප්රොක්සි බහාලුම්වල ඇසුරුම් කර, හැකි සෑම තැනකම ඒවා ඇලවීමේ කාර්යය Kubernetes වෙත ලබා දෙන්න, සහ voila! ප්රතිඵලයක් වශයෙන්, ඔබට සේවා දැලක් ලැබෙනු ඇත, Kubernetes එහි යෙදවීමේ සියලු යාන්ත්රික පාලනය කරයි. (අඩුම තරමින් කුරුල්ලෙකුගේ ඇසකින්. ඇත්ත වශයෙන්ම, මෙම ක්‍රියාවලියට බොහෝ සූක්ෂ්මතා ඇත.)
සාරාංශගත කිරීම සඳහා: සේවා දැල දැන් ජනප්‍රිය වීමට හේතුව සහ වසර දහයකට පෙර නොවේ කුබර්නෙට්ස් සහ ඩොකර් සැලකිය යුතු ලෙස වැඩි වූවා පමණක් නොවේ. අවශ්යයි එහි, බහුභාෂා ක්ෂුද්ර සේවා කට්ටලයක් ලෙස යෙදුම් ක්රියාත්මක කිරීම සරල කරන නමුත් සැලකිය යුතු ලෙස අඩු කරයි වියදම් සයිඩ්කාර් ප්රොක්සි උද්‍යාන යෙදවීම සහ නඩත්තු කිරීම සඳහා යාන්ත්‍රණ සැපයීම මගින් එහි ක්‍රියාකාරිත්වය සඳහා.
සේවා දැලක් ගැන මෙතරම් කතා කරන්නේ ඇයි?
වැළැක්වීම: මෙම කොටසේදී, මම සියලු ආකාරයේ උපකල්පන, අනුමාන, ගොතන ලද සහ අභ්යන්තර තොරතුරු වෙත යොමු වෙමි.
"සේවා දැලක්" සෙවීමෙන් ප්‍රතිචක්‍රීකරණය කරන ලද, අඩු කැලරි අන්තර්ගතයන්, අමුතු ව්‍යාපෘති සහ echo chamber එකකට සුදුසු විකෘති කිරීමේ කැලිඩෝස්කෝප් පොකුරක් ලැබෙනු ඇත. ඕනෑම නවීන තාක්‍ෂණයකට මෙය ඇත, නමුත් සේවා දැල සම්බන්ධයෙන්, ගැටළුව විශේෂයෙන් උග්‍ර වේ. ඇයි?
හොඳයි, එය අර්ධ වශයෙන් මගේ වරදකි. මෙවැනි අසංඛ්‍යාත බ්ලොග් සටහන් සහ ලිපි හරහා සෑම අවස්ථාවකදීම Linkerd සහ සේවා දැල් ප්‍රවර්ධනය කිරීමට මම මගේ උපරිමය කර ඇත. ඒත් මම ඒ තරම් බලවත් නැහැ. මෙම ප්රශ්නයට සැබවින්ම පිළිතුරු දීමට නම්, අපි සාමාන්ය තත්වය ගැන ටිකක් කතා කළ යුතුය. එක් ව්‍යාපෘතියක් සඳහන් නොකර ඒ ගැන කතා කළ නොහැක: Google, IBM සහ Lyft විසින් ඒකාබද්ධව සංවර්ධනය කරන ලද විවෘත මූලාශ්‍ර සේවා ජාලයකි.
(එම සමාගම් තුනට බොහෝ වෙනස් භූමිකාවන් ඇත: Lyft ගේ සම්බන්ධය නමට පමණක් සීමා වී ඇති බව පෙනේ; ඔවුන් එන්වෝයි කර්තෘ නමුත් Istio භාවිතා නොකරන හෝ සංවර්ධනයට සම්බන්ධ වී නැත. IBM Istio සංවර්ධනයට සම්බන්ධ වී එය භාවිතා කරයි. Google දැඩි ලෙස Istio සංවර්ධනයට සම්බන්ධ, නමුත් මට කිව හැකි පරිදි, ඇත්ත වශයෙන්ම එය භාවිතා නොකරයි.)
Istio ව්යාපෘතිය කරුණු දෙකක් සඳහා කැපී පෙනේ. පළමුව, එය Google, විශේෂයෙන් එහි ප්‍රවර්ධනය සඳහා යොදවන විශාල අලෙවිකරණ උත්සාහයයි. සේවා දැල් සංකල්පය ගැන දැනට දන්නා බොහෝ අය මුලින්ම ඒ ගැන ඉගෙන ගත්තේ ඉස්ටියෝට ස්තුති වන්නට බව මම තක්සේරු කරමි. දෙවෙනි ලක්ෂණය තමයි ඉස්තියෝට කොච්චර නරක විදියට ලැබුණද කියන එක. මේ කාරණයේදී, මම, පැහැදිලිවම, උනන්දුවක් දක්වන පාර්ශ්වයක්, නමුත් හැකි තරම් වෛෂයිකව සිටීමට උත්සාහ කරමි, මට තවමත් උදව් කළ නොහැක. , ඉතා නිශ්චිත නොවේ (අද්විතීය නොවුනත්: systemd මතකයට එයි, ...) විවෘත මූලාශ්‍ර ව්‍යාපෘතියක් සඳහා.
(ප්‍රායෝගිකව, Istio හට සංකීර්ණත්වය සහ UX සමග පමණක් නොව, කාර්ය සාධනය සම්බන්ධයෙන්ද ගැටළු ඇති බව පෙනේ. උදාහරණයක් ලෙස, තුන්වන පාර්ශ්වයක් විසින් පවත්වන ලද, විශේෂඥයින් විසින් Linkerd දිගටම සාර්ථකව ක්රියාත්මක වූ විට, Istio ගේ වලිගය ප්රමාදය Linkerd ට වඩා 100 ගුණයකින් වැඩි වූ අවස්ථා මෙන්ම සම්පත් හිඟතා සහිත තත්වයන් සොයා ගත් අතර, Istio සම්පූර්ණයෙන්ම ක්‍රියා කිරීම නැවැත්වීය.)
මෙය සිදු වූයේ ඇයිද යන්න පිළිබඳ මගේ න්‍යායන් පසෙක තබා, සේවා දැල වටා ඇති පරිමාණයෙන් බැහැර ප්‍රබෝධය ගූගල්ගේ මැදිහත්වීම නිසා ඇති වූවක් යැයි මම විශ්වාස කරමි. එනම්, පහත සඳහන් සාධක තුනක එකතුවකි:
- Google විසින් Istio හි උමතු ප්‍රවර්ධනය;
- ව්යාපෘතිය කෙරෙහි සුදුසු අකමැත්ත, විවේචනාත්මක ආකල්පය;
- Kubernetes හි මෑත කාලීන ජනප්‍රියත්වය, එහි මතකය තවමත් නැවුම් ය.
මෙම සාධක එක්ව, තාර්කික විනිශ්චය කිරීමේ හැකියාව දුර්වල වන ආකාරයේ විෂ සහිත, නිර්වින්දන පරිසරයක් බවට ඒකාබද්ධ වන අතර, පුදුමාකාර විවිධත්වයක් පමණක් ඉතිරි වේ. .
Linkerd ගේ දෘෂ්ටි කෝණයෙන්, මෙය ... මම එය මිශ්‍ර ආශිර්වාදයක් ලෙස විස්තර කරමි. මම අදහස් කළේ, සේවා දැල ප්රධාන ධාරාවට ඇතුළු වීම විශිෂ්ටයි - 2016 දී Linkerd මුලින්ම පෙනී සිටි අවස්ථාවේ එය එසේ නොවූ අතර ව්යාපෘතිය කෙරෙහි මිනිසුන්ගේ අවධානය ලබා ගැනීම ඇත්තෙන්ම දුෂ්කර විය. දැන් එහෙම ප්‍රශ්නයක් නෑ! නමුත් නරක ආරංචිය නම් අද සේවා දැල් තත්වය කෙතරම් ව්‍යාකූල වී ඇත්ද යත්, සේවා දැල් කාණ්ඩයට සැබවින්ම අයත් වන්නේ කුමන ව්‍යාපෘතිදැයි සොයා ගැනීමට නොහැකි තරම්ය (විශේෂිත භාවිත නඩුවක් සඳහා හොඳම එක කුමක්දැයි සොයා ගැනීමට ඉඩ දෙන්න). මෙය නිසැකවම සෑම කෙනෙකුටම බාධා කරයි (සහ අනිවාර්යයෙන්ම සමහර අවස්ථාවලදී Istio හෝ වෙනත් ව්යාපෘතිය Linkerd වලට වඩා හොඳය, මන්ද දෙවැන්න සියල්ලටම ගැලපෙන විසඳුමක් නොවේ).
ලින්කර්ඩ්ගේ පැත්තෙන්, අපගේ උපාය මාර්ගය වී ඇත්තේ ශබ්දය නොසලකා හැරීම, ප්‍රජාවේ සැබෑ ගැටලු විසඳීම කෙරෙහි අවධානය යොමු කිරීම සහ අත්‍යවශ්‍යයෙන්ම උද්දීපනය මිය යන තෙක් බලා සිටීමයි. අන්තිමේදී මේ ප්‍රහේලිකාව අඩුවෙලා සාමකාමීව වැඩ කරගෙන යන්න පුළුවන්.
එතකන් අපි හැමෝටම ඉවසන්න වෙනවා.
නිහතමානී මෘදුකාංග ඉංජිනේරුවෙකු වන මට සේවා දැල ප්රයෝජනවත් වේවිද?
පහත ප්‍රශ්නාවලිය මෙම ප්රශ්නයට පිළිතුරු දීමට උපකාරී වනු ඇත:
ඔබ ව්‍යාපාර තර්කනය ක්රියාත්මක කිරීම සම්බන්ධයෙන් පමණක් කටයුතු කරනවාද? මෙම අවස්ථාවේදී, සේවා දැල ඔබට ප්රයෝජනවත් නොවනු ඇත. එනම්, ඇත්ත වශයෙන්ම, ඔබ ඒ ගැන උනන්දු විය හැකිය, නමුත් ඉතා මැනවින්, සේවා දැල ඔබේ පරිසරයේ කිසිම දෙයකට සෘජුවම බලපාන්නේ නැත. ඔබට ගෙවන දේ මත දිගටම වැඩ කරන්න.
ඔබ Kubernetes භාවිතා කරන සමාගමක වේදිකාවක් පවත්වාගෙන යනවාද? ඔව්, මෙම අවස්ථාවේදී ඔබට සේවා දැලක් අවශ්ය වේ (ඇත්ත වශයෙන්ම, ඔබ K8s භාවිතා නොකරන්නේ නම් ඒකලිතයක් හෝ කණ්ඩායම් සැකසුම් ක්රියාත්මක කිරීමට පමණි - නමුත් ඔබට K8s අවශ්ය වන්නේ මන්දැයි මම විමසීමට කැමතියි). බොහෝ දුරට, ඔබ විවිධ පුද්ගලයින් විසින් ලියන ලද බොහෝ ක්ෂුද්ර සේවා සහිත තත්වයක සිටිනු ඇත. ඔවුන් සියල්ලන්ම එකිනෙකා සමඟ අන්තර් ක්‍රියා කරන අතර ධාවන කාල පරායත්තතා වල පටලැවිල්ලකට බැඳී ඇති අතර, මේ සියල්ල සමඟ කටයුතු කිරීමට ඔබට ක්‍රමයක් සොයාගත යුතුය. Kubernetes භාවිතය ඔබට "ඔබටම" සේවා දැලක් තෝරා ගැනීමට ඉඩ සලසයි. මෙය සිදු කිරීම සඳහා, ඔවුන්ගේ හැකියාවන් සහ විශේෂාංග පිළිබඳව ඔබව හුරු කරවන්න සහ පවතින ඕනෑම ව්‍යාපෘතියක් ඔබට ගැලපේද යන ප්රශ්නයට පිළිතුරු දෙන්න (Linkerd සමඟ ඔබේ පර්යේෂණ ආරම්භ කිරීමට මම නිර්දේශ කරමි).
ඔබ Kubernetes භාවිතා නොකරන නමුත් microservices භාවිතා කරන සමාගමක් සඳහා වේදිකාවක් පවත්වාගෙන යනවාද? මෙම අවස්ථාවේදී, සේවා දැල ඔබට ප්රයෝජනවත් වනු ඇත, නමුත් එහි භාවිතය සුළු නොවන වනු ඇත. අැත්තවශයෙන්ම ඔබට පුළුවන් අනුකරණය කරන්න ප්රොක්සි සමූහයක් සත්කාරකත්වය මගින් සේවා දැලක්, නමුත් Kubernetes හි වැදගත් වාසියක් වන්නේ හරියටම යෙදවුම් ආකෘතියයි: මෙම ප්රොක්සි අතින් නඩත්තු කිරීම සඳහා වැඩි කාලයක්, වෑයමක් සහ පිරිවැයක් අවශ්ය වේ.
ඔබ මොනොලිත් සමඟ වැඩ කරන සමාගමක වේදිකාව භාරව සිටින්නේද? මෙම අවස්ථාවේදී, ඔබට සමහරවිට සේවා දැලක් අවශ්ය නොවේ. ඔබ හොඳින් නිර්වචනය කර ඇති සහ කලාතුරකින් වෙනස් වන අන්තර්ක්‍රියා රටා ඇති ඒකලිත (හෝ මොනොලිත් කට්ටල පවා) සමඟ වැඩ කරන්නේ නම්, සේවා දැල ඔබට ලබා දීමට ඇත්තේ අල්ප වශයෙනි. එබැවින් ඔබට එය නොසලකා හැර එය නරක සිහිනයක් මෙන් අතුරුදහන් වනු ඇතැයි බලාපොරොත්තු විය හැකිය ...
නිගමනය
බොහෝ විට, සේවා දැල තවමත් “ලෝකයේ වඩාත්ම ප්‍රචලිත තාක්ෂණය” ලෙස හැඳින්විය යුතු නැත - මෙම සැක සහිත ගෞරවය බොහෝ විට බිට්කොයින් හෝ AI ට අයත් වේ. සමහර විට ඇය පළමු පස් දෙනා අතර සිටී. නමුත් ඔබ ඝෝෂාකාරී හා ඝෝෂාකාරී ස්ථර හරහා ගියහොත්, කුබර්නෙට්ස් හි යෙදුම් නිර්මාණය කරන අයට සේවා දැලක් සැබෑ ප්රතිලාභ ගෙන දෙන බව පැහැදිලි වේ.
මම කැමතියි ඔබ Linkerd උත්සාහ කරනවාට - එය Kubernetes පොකුරක ස්ථාපනය කිරීම (හෝ ලැප්ටොප් එකක Minikube පවා) මම කතා කරන දේ ඔබටම දැක ගත හැකිය.
නිති අසන පැණ
- මම සේවා දැල නොසලකා හරින්නේ නම්, එය අතුරුදහන් වේද?
- මම ඔබව කලකිරීමට පත් කළ යුතුයි: සේවා දැල දිගු කාලයක් අප සමඟ ඇත.
— නමුත් මට සේවා දැලක් භාවිතා කිරීමට අවශ්ය නැත!
- හොඳයි, එය අවශ්ය නොවේ! ඔබ අවම වශයෙන් එහි මූලික කරුණු පිළිබඳව ඔබව හුරු කර ගත යුතු දැයි බැලීමට ඉහත මගේ ප්‍රශ්නාවලිය කියවන්න.
— අලුත් සෝස් එකක් එක්ක හොඳ පරණ ESB/middleware එකක් නේද?
- සේවා දැල ක්‍රියාන්විත තර්කය සමඟ ගනුදෙනු කරයි, අර්ථකථන නොවේ. ව්යවසාය සේවා බස් () මෙම වෙන්වීම තබා ගැනීම සේවා දැලට එකම ඉරණම වළක්වා ගැනීමට උපකාරී වේ.
- සේවා දැලක් API ද්වාර වලින් වෙනස් වන්නේ කෙසේද?
මෙම විෂය පිළිබඳ ලිපි මිලියනයක් ඇත. ගූගල් කරන්න.
එන්වොයි යනු සේවා දැලක්ද?
- නැත, එන්වෝයි යනු සේවා දැලක් නොවේ, එය ප්රොක්සි සේවාදායකයකි. එය සේවා දැලක් සංවිධානය කිරීමට භාවිතා කළ හැකිය (සහ තවත් බොහෝ දේ - එය පොදු කාර්ය ප්‍රොක්සියකි). නමුත් එය විසින්ම එය සේවා දැලක් නොවේ.
- ජාල සේවා දැලක් - එය සේවා දැලක්ද?
- නැත. නම තිබියදීත්, මෙය සේවා දැලක් නොවේ (ඔබ අලෙවිකරණයේ ආශ්චර්යයන්ට කැමති වන්නේ කෙසේද?).
- පණිවිඩ පෝලිම මත පදනම්ව මගේ ප්‍රතික්‍රියාශීලී අසමමුහුර්ත පද්ධතියට සේවා දැල උදවු කරයිද?
- නැත, සේවා දැල ඔබට උදව් නොකරනු ඇත.
- මා භාවිතා කළ යුත්තේ කුමන සේවා දැලක්ද?
- , මොලේ නැත.
- ලිපිය නරකයි! / කර්තෘ - සබන් මත!
— කරුණාකර එයට සබැඳිය ඔබේ සියලු මිතුරන් සමඟ බෙදා ගන්න එවිට ඔවුන්ට මෙය ඒත්තු ගැන්විය හැකිය!
පිළිගැනීම්
මාතෘකාවෙන් ඔබට අනුමාන කළ හැකි පරිදි, මෙම ලිපිය ජේ ක්‍රෙප්ස්ගේ අපූරු නිබන්ධනය මගින් ආභාෂය ලබා ඇත.". මීට වසර දහයකට පෙර මට ජේව මුණගැසුණේ Linked In හි සම්මුඛ සාකච්ඡාවක් කරමින් සිටියදී ඔහු එතැන් සිට මට ආශ්වාදයක් විය.
මම "Linkerd සංවර්ධකයෙකු" ලෙස හැඳින්වීමට කැමති වුවත්, යථාර්ථය නම් මම ව්‍යාපෘතියක README.md ගොනුව නඩත්තු කරන්නෙකු වීමයි. අද Linkerd එකේ වැඩ කරනවා , , මිනිසුන්, සහ දායකයින් සහ පරිශීලකයින්ගේ විශ්මයජනක ප්රජාව නොමැතිව මෙම ව්යාපෘතිය කළ නොහැකි වනු ඇත.
අවසාන වශයෙන්, Linkerd හි නිර්මාතෘට විශේෂ ස්තුතිය, (primus inter pares), මීට වසර ගණනාවකට පෙර මා සමඟ, සේවා දැල සමඟ මේ සියලු කලබලයට හිස ඔසවමින් කිමිදුණේය.
පරිවර්තකගෙන් PS
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:
- «»;
- «»;
- «»;
- «»;
- «".
මූලාශ්රය: www.habr.com