ඔබ ඔබේ මොනොලිත් ක්ෂුද්ර සේවා බවට ප්‍රතිනිර්මාණය කිරීමට මාස ගණනාවක් ගත කර ඇති අතර, අවසානයේ ස්විචය පෙරළීමට සියලු දෙනා එකතු වී ඇත. ඔබ පළමු වෙබ් පිටුවට යන්න... කිසිවක් සිදු නොවේ. ඔබ එය නැවත පූරණය කරන්න - නැවතත් හොඳ කිසිවක් නැත, වෙබ් අඩවිය ඉතා මන්දගාමී වන අතර එය මිනිත්තු කිහිපයක් සඳහා ප්‍රතිචාර නොදක්වයි. සිදුවුයේ කුමක් ද?
ඔහුගේ කතාවේදී, ජිමී බොගාර්ඩ් සැබෑ ජීවිතයේ ක්ෂුද්ර සේවා ව්‍යසනයක් පිළිබඳ “පශ්චාත් මරණ පරීක්ෂණයක්” පවත්වනු ඇත. ඔහු විසින් සොයා ගන්නා ලද ආකෘති නිර්මාණය, සංවර්ධනය සහ නිෂ්පාදන ගැටළු සහ ඔහුගේ කණ්ඩායම නව බෙදා හරින ලද ඒකලිතය සෙමෙන් සනීපාරක්ෂාව පිළිබඳ අවසාන පින්තූරය බවට පරිවර්තනය කළ ආකාරය පෙන්වයි. සැලසුම් දෝෂ සම්පූර්ණයෙන්ම වැළැක්විය නොහැකි වුවද, අවසාන නිෂ්පාදනය විශ්වාසදායක බෙදාහැරීමේ පද්ධතියක් බවට පත් කිරීම සහතික කිරීම සඳහා සැලසුම් ක්‍රියාවලියේ මුල් අවධියේදී ඔබට අවම වශයෙන් ගැටළු හඳුනාගත හැකිය.
හැමෝටම ආයුබෝවන්, මම ජිමී, අද ඔයාලට අහන්න යන්නේ ක්ෂුද්ර සේවා තැනීමේදී මෙගා ආපදා වළක්වා ගන්නේ කෙසේද කියායි. මේ මම වසර එකහමාරක් පමණ සේවය කළ ආයතනයක ඔවුන්ගේ නැව අයිස් කුට්ටියක ගැටීම වැලැක්වීම සඳහා වූ කතාවයි. මෙම කතාව නිවැරදිව පැවසීමට, අපට අතීතයට ගොස් මෙම සමාගම ආරම්භ වූ ස්ථානය සහ එහි තොරතුරු තාක්ෂණ යටිතල පහසුකම් කාලයත් සමඟ වර්ධනය වී ඇති ආකාරය ගැන කතා කළ යුතුය. මේ ව්‍යසනයේ ඉන්න අහිංසකයන්ගේ නම් ආරක්ෂා කරන්න මම මේ ආයතනයේ නම බෙල් කොම්පියුටර්ස් කියලා වෙනස් කළා. 90 ගණන්වල මැද භාගයේදී එවැනි සමාගම්වල තොරතුරු තාක්ෂණ යටිතල පහසුකම් පෙනුණේ කෙසේද යන්න ඊළඟ ස්ලයිඩයෙන් පෙන්වයි. මෙය පරිගණක දෘඩාංග ගබඩාවක් ක්රියාත්මක කිරීම සඳහා විශාල විශ්වීය දෝෂ-ඉවසන HP Tandem Mainframe සේවාදායකයක සාමාන්‍ය ගෘහ නිර්මාණ ශිල්පයකි.
සියලුම ඇණවුම්, විකුණුම්, ප්‍රතිලාභ, නිෂ්පාදන නාමාවලි සහ පාරිභෝගික පදනම කළමනාකරණය කිරීමට ඔවුන්ට පද්ධතියක් ගොඩනැගීමට අවශ්‍ය වූ අතර, එම නිසා ඔවුන් එකල වඩාත් පොදු ප්‍රධාන රාමු විසඳුම තෝරා ගත්හ. මෙම යෝධ පද්ධතිය තුළ සමාගම පිළිබඳ සෑම තොරතුරක්ම, හැකි සෑම දෙයක්ම අඩංගු වූ අතර සෑම ගනුදෙනුවක්ම මෙම ප්‍රධාන රාමුව හරහා සිදු කරන ලදී. ඔවුන් තම බිත්තර සියල්ල එක කූඩයක තබා එය සාමාන්‍ය දෙයක් යැයි සිතූහ. මෙහි ඇතුළත් නොවන එකම දෙය වන්නේ තැපැල් ඇණවුම් නාමාවලි සහ දුරකථනයෙන් ඇණවුම් කිරීමයි.
කාලයාගේ ඇවෑමෙන්, පද්ධතිය විශාල හා විශාල වූ අතර විශාල කසළ ප්‍රමාණයක් එහි එකතු විය. එසේම, COBOL යනු ලෝකයේ වඩාත්ම ප්‍රකාශිත භාෂාව නොවේ, එබැවින් පද්ධතිය විශාල, මොනොලිතික් කුණු කෑල්ලක් බවට පත් විය. 2000 වන විට, බොහෝ සමාගම්වල වෙබ් අඩවි ඇති බව ඔවුන් දුටු අතර, ඔවුන් විසින් ඔවුන්ගේ සියලුම ව්‍යාපාර සම්පූර්ණයෙන්ම කරගෙන ගිය අතර, ඔවුන්ගේ පළමු වාණිජ ඩොට්-කොම් වෙබ් අඩවිය ගොඩනැගීමට තීරණය කළහ.
ආරම්භක සැලසුම ඉතා ලස්සන පෙනුමක් ඇති අතර ඉහළ මට්ටමේ වෙබ් අඩවියක් වන bell.com සහ තනි යෙදුම් සඳහා උප ඩොමේන් ගණනාවකින් සමන්විත විය: catalog.bell.com, accounts.bell.com, orders.bell.com, නිෂ්පාදන සෙවීම් search.bell. com. සෑම උප ඩොමේනයක්ම ASP.Net 1.0 රාමුව සහ තමන්ගේම දත්ත සමුදායන් භාවිතා කළ අතර, ඔවුන් සියල්ලෝම පද්ධති පසුබිමට කතා කළහ. කෙසේ වෙතත්, සියලුම ඇනවුම් එකම දැවැන්ත ප්‍රධාන රාමුවක් තුළ අඛණ්ඩව ක්රියාත්මක කර ක්රියාත්මක කරන ලද අතර, එහි සියලු කුණු ඉතිරිව ඇත, නමුත් ඉදිරිපස කෙළවර තනි යෙදුම් සහ වෙනම දත්ත සමුදායන් සහිත වෙනම වෙබ් අඩවි විය.
එබැවින් පද්ධතියේ සැලසුම පිළිවෙලට හා තාර්කික ලෙස පෙනුනද, සැබෑ පද්ධතිය ඊළඟ විනිවිදකයේ පෙන්වා ඇත.
සියලුම මූලද්‍රව්‍ය එකිනෙකාට ඇමතුම් ආමන්ත්‍රණය කරන ලදී, API වෙත ප්රවේශ විය, තෙවැනි පාර්ශ්ව dlls, සහ ඒ හා සමාන ය. අනුවාද පාලන පද්ධති වෙනත් කෙනෙකුගේ කේතය උදුරා ගැනීම, එය ව්‍යාපෘතිය තුළට තල්ලු කිරීම, පසුව සියල්ල කැඩී යාම බොහෝ විට සිදු විය. MS SQL Server 2005 ලින්ක් සර්වර් සංකල්පය භාවිතා කළ අතර, මම ස්ලයිඩයේ ඊතල නොපෙන්වූවත්, දත්ත සමුදා කිහිපයකින් ලබාගත් දත්ත මත පදනම්ව වගු සෑදීමේ වරදක් නොමැති නිසා, එක් එක් දත්ත සමුදායන් ද එකිනෙකා සමඟ කතා කළහ.
ඔවුන්ට දැන් පද්ධතියේ විවිධ තාර්කික ප්‍රදේශ අතර යම් වෙන්වීමක් ඇති බැවින්, මෙය බෙදා හරින ලද කුණු කසළ බවට පත් විය, විශාලතම කසළ කැබැල්ල තවමත් ප්‍රධාන රාමු පසුබිමේ ඉතිරිව ඇත.
හාස්‍යජනක කරුණ නම් මෙම Mainframe එක Bell Computers හි තරඟකරුවන් විසින් ගොඩනගා ඇති අතර තවමත් ඔවුන්ගේ තාක්ෂණික උපදේශකයින් විසින් නඩත්තු කරනු ලැබීමයි. එහි යෙදුම්වල අසතුටුදායක කාර්ය සාධනය ගැන ඒත්තු ගැන්වූ සමාගම ඒවා ඉවත් කර පද්ධතිය නැවත සැලසුම් කිරීමට තීරණය කළේය.
දැනට පවතින යෙදුම වසර 15ක් තිස්සේ නිෂ්පාදනය කර ඇත, එය ASP.Net මත පදනම් වූ යෙදුම් සඳහා වාර්තාවකි. සේවාව ලොව පුරා ඇණවුම් පිළිගත් අතර, මෙම තනි යෙදුමෙන් වාර්ෂික ආදායම ඩොලර් බිලියනයකට ළඟා විය. ලාභයෙන් සැලකිය යුතු කොටසක් bell.com වෙබ් අඩවිය මගින් ජනනය විය. කළු සිකුරාදා දිනවල, වෙබ් අඩවිය හරහා ලබා දුන් ඇණවුම් සංඛ්‍යාව මිලියන ගණනකට ළඟා විය. කෙසේ වෙතත්, පවතින ගෘහ නිර්මාණ ශිල්පය කිසිදු සංවර්ධනයකට ඉඩ දුන්නේ නැත, මන්ද පද්ධති මූලද්‍රව්‍යවල දෘඩ අන්තර් සම්බන්ධතා ප්‍රායෝගිකව සේවාවට කිසිදු වෙනසක් කිරීමට ඉඩ නොදෙන බැවිනි.
බරපතලම ප්‍රශ්නය වූයේ මෙවැනි වෙළෙඳ ක්‍රමයක් ගෝලීය සමාගම්වල බහුලව දක්නට ලැබුණද, එක් රටකින් ඇණවුමක් ලබාදී, එය තවත් රටකට ගෙවීමට සහ තුන්වැන්නකට යැවීමට නොහැකිවීමයි. පවතින වෙබ් අඩවියේ මෙවැනි දේකට ඉඩ නොදුන් නිසා දුරකථනයෙන් මෙම ඇනවුම් බාරගෙන ලබා දීමට ඔවුන්ට සිදු විය. මෙය ගෘහ නිර්මාණ ශිල්පය වෙනස් කිරීම, විශේෂයෙන් ක්ෂුද්ර සේවා වෙත මාරුවීම පිළිබඳව සමාගම වැඩි වැඩියෙන් සිතීමට හේතු විය.
ඔවුන් එවැනිම ගැටලුවක් විසඳා ඇත්තේ කෙසේදැයි බැලීමට වෙනත් සමාගම් දෙස බැලීමෙන් ඔවුන් බුද්ධිමත් දෙය කළහ. මෙම විසඳුම්වලින් එකක් වූයේ API සහ බාහිර දත්ත ගබඩාවක් හරහා සම්බන්ධ වූ ක්ෂුද්ර සේවා වලින් සමන්විත Netflix සේවා ගෘහ නිර්මාණ ශිල්පයයි.
බෙල් කම්පියුටර්ස් කළමනාකාරිත්වය යම් මූලික මූලධර්මවලට අනුකූලව එවැනි ගෘහ නිර්මාණ ශිල්පයක් ගොඩනැගීමට තීරණය කළේය. පළමුව, ඔවුන් හවුල් දත්ත සමුදා ප්‍රවේශයක් භාවිතා කරමින් දත්ත අනුපිටපත් ඉවත් කරන ලදී. දත්ත යවා නැත; ඊට පටහැනිව, එය අවශ්‍ය සෑම කෙනෙකුටම මධ්‍යගත ප්‍රභවයක් වෙත යාමට සිදු විය. මෙයින් පසු හුදකලා වීම සහ ස්වාධීනත්වය - සෑම සේවාවක්ම අනෙක් අයගෙන් ස්වාධීන විය. ඔවුන් සෑම දෙයක් සඳහාම Web API භාවිතා කිරීමට තීරණය කළා - ඔබට දත්ත ලබා ගැනීමට හෝ වෙනත් පද්ධතියකට වෙනස්කම් කිරීමට අවශ්‍ය නම්, ඒ සියල්ල Web API හරහා සිදු කරන ලදී. අවසාන විශාල දෙය නම් තරඟකරුවන්ගේ දෘඩාංග මත පදනම් වූ "බෙල්" ප්‍රධාන රාමුවට ප්‍රතිවිරුද්ධව "බෙල් ඔන් බෙල්" නම් නව ප්‍රධාන රාමුවකි.
ඉතින්, මාස 18 ක් පුරා, ඔවුන් මෙම මූලික මූලධර්ම වටා පද්ධතිය ගොඩනඟා එය පූර්ව නිෂ්පාදනයට ගෙන ආවා. සති අන්තයෙන් පසු නැවත වැඩට ගිය පසු, සංවර්ධකයින් එකතු වී නව පද්ධතිය සම්බන්ධ කර ඇති සියලුම සේවාදායකයන් සක්‍රීය කළහ. මාස 18ක වැඩ, සිය ගණනක් සංවර්ධකයින්, නවීනතම බෙල් දෘඩාංග - සහ ධනාත්මක ප්‍රතිඵලයක් නැත! මෙය බොහෝ දෙනෙකුගේ කලකිරීමට හේතු වී ඇත්තේ ඔවුන් මෙම පද්ධතිය ඔවුන්ගේ ලැප්ටොප් පරිගණකවල බොහෝ වාරයක් ධාවනය කර ඇති අතර සියල්ල හොඳින් සිදු වූ බැවිනි.
මෙම ගැටලුව විසඳීම සඳහා ඔවුන්ගේ සියලු මුදල් විසි කිරීමට ඔවුන් දක්ෂ විය. ඔවුන් ස්විච සහිත නවීනතම සේවාදායක රාක්ක ස්ථාපනය කර, ගිගාබිට් ඔප්ටිකල් ෆයිබර් භාවිතා කර, උමතු RAM ප්‍රමාණයක් සහිත බලවත්ම සේවාදායක දෘඩාංග, ඒ සියල්ල සම්බන්ධ කර, වින්‍යාස කර ඇත - සහ නැවතත්, කිසිවක් නැත! ඊට පස්සේ හේතුව කල් ඉකුත්වීම් වෙන්න ඇති කියලා සැක කරන්න පටන් ගත්තා, ඒ නිසා ඔවුන් සියලුම වෙබ් සැකසුම්, සියලුම API සැකසුම් තුළට ගොස් සම්පූර්ණ කාල සීමාව වින්‍යාසය උපරිම අගයන්ට යාවත්කාලීන කළ අතර, ඔවුන්ට කළ හැක්කේ යමක් සිදු වන තෙක් වාඩි වී බලා සිටීමයි. අඩවියට. අන්තිමට වෙබ් සයිට් එක ලෝඩ් වෙනකම් විනාඩි 9 හමාරක් බලාගෙන හිටියා.
ඉන් පසු වත්මන් තත්ත්වය පිළිබඳව ගැඹුරු විග්‍රහයක් අවශ්‍ය බව ඔවුන්ට අවබෝධ වූ අතර ඔවුන් අපට ආරාධනා කළා. අප සොයාගත් පළමු දෙය නම්, සංවර්ධනයේ මාස 18 තුළ එකම “ක්ෂුද්ර” එකක්වත් නිර්මාණය නොවූ බවයි - සියල්ල විශාල විය. මෙයින් පසු, අපි ව්‍යසනයට හේතුව තේරුම් ගැනීම සඳහා "මොළයේ කුණාටුවක්" හා සමාන පශ්චාත් මරණ පරීක්ෂණයක් ලිවීමට පටන් ගත්තෙමු, එය "පසුතැවිලි" හෝ "ශෝක ප්‍රතිගාමී" ලෙසද හැඳින්වේ, "දොස් කුණාටුවක්" ලෙසද හැඳින්වේ.
අපට හෝඩුවාවන් කිහිපයක් තිබුනා, ඉන් එකක් API ඇමතුම කරන අවස්ථාවේ සම්පූර්ණ මාර්ග තදබදයයි. ඔබ මොනොලිතික් සේවා ගෘහනිර්මාණ ශිල්පයක් භාවිතා කරන විට, අසාර්ථක වීමට හේතු විය හැකි සෑම දෙයක්ම වාර්තා කරන තනි තොග හෝඩුවාවක් ඔබ සතුව ඇති නිසා හරියටම වැරදුනේ කුමක්ද යන්න ඔබට වහාම තේරුම් ගත හැකිය. සේවා සමූහයක් එකවර එකම API වෙත ප්රවේශ වන අවස්ථාවක, WireShark වැනි අතිරේක ජාල අධීක්ෂණ මෙවලම් භාවිතා කිරීම හැර හෝඩුවාවක් හඹා යාමට ක්‍රමයක් නොමැත, එයට ස්තූතිවන්ත වන්නට ඔබට තනි ඉල්ලීමක් පරීක්ෂා කර එය ක්රියාත්මක කිරීමේදී සිදුවූයේ කුමක්දැයි සොයා බැලිය හැකිය. එබැවින් අපි එක් වෙබ් පිටුවක් ගෙන සති 2කට ආසන්න කාලයක් ප්‍රහේලිකාවේ කොටස් එකට දමා, එයට විවිධ ඇමතුම් ලබා දෙමින් සහ ඒ සෑම එකක් සඳහාම හේතු වූ දේ විශ්ලේෂණය කළෙමු.
මේ පින්තූරය දෙස බලන්න. එක් බාහිර ඉල්ලීමක් ආපසු පැමිණෙන බොහෝ අභ්‍යන්තර ඇමතුම් කිරීමට සේවාව පොළඹවන බව පෙන්වයි. අවශ්‍ය තොරතුරු ලබා ගැනීම සඳහා වෙනත් තැනකට හැරවිය නොහැකි බැවින්, මෙම ඉල්ලීම ස්වාධීනව සේවය කිරීමට හැකි වන පරිදි සෑම අභ්‍යන්තර ඇමතුමක්ම අතිරේක hops කරන බව පෙනේ. බාහිර ඉල්ලීම මගින් වෙනත් අමතර සේවාවන් අමතන අමතර සේවාවන් සහ යනාදී ලෙස දැන්වීම් අනන්තය දක්වා ඇති බැවින්, මෙම පින්තූරය අර්ථ විරහිත ඇමතුම් කැස්සක් සේ පෙනේ.
මෙම රූප සටහනේ ඇති කොළ පැහැයෙන් දැක්වෙන්නේ සේවා එකිනෙක අමතන අර්ධ වෘත්තාකාරයකි - සේවාව A ඇමතුම් සේවාව B, සේවාව B සේවාව C අමතන්න, සහ එය නැවත A සේවාව අමතයි. එහි ප්‍රතිඵලයක් වශයෙන්, අපට “බෙදාහැරුණු අවහිරයක්” ලැබේ. තනි ඉල්ලීමක් ජාල API ඇමතුම් දහසක් නිර්මාණය කරන ලද අතර, පද්ධතියට ගොඩනඟන ලද දෝෂ ඉවසීම සහ ලූප ආරක්ෂණය නොමැති බැවින්, මෙම API ඇමතුම් වලින් එකක් හෝ අසාර්ථක වුවහොත් ඉල්ලීම අසාර්ථක වනු ඇත.
අපි ගණිතය ටිකක් කළා. සෑම API ඇමතුමකටම 150 ms ට නොවැඩි SLA සහ 99,9% ක්රියාත්මක කාලය තිබුණි. එක් ඉල්ලීමක් විවිධ ඇමතුම් 200 ක් ඇති කර ඇති අතර, හොඳම අවස්ථාවෙහිදී, පිටුව 200 x 150 ms = තත්පර 30 කින් පෙන්විය හැක. ස්වාභාවිකවම, මෙය හොඳ නැත. 99,9% ක්‍රියාකාරී කාලය 200 න් ගුණ කිරීමෙන් අපට 0% ලබා ගත හැකි විය. මෙම ගෘහ නිර්මාණ ශිල්පය ආරම්භයේ සිටම අසාර්ථක වීමට හේතු වූ බව පෙනේ.
මාස 18 ක වැඩ කිරීමෙන් පසු මෙම ගැටලුව හඳුනා ගැනීමට ඔවුන් අසමත් වූයේ කෙසේදැයි අපි සංවර්ධකයින්ගෙන් විමසුවෙමු. ඔවුන් විසින් ධාවනය කරන ලද කේතය සඳහා ඔවුන් SLA පමණක් ගණන් කළ බව පෙනී ගියේය, නමුත් ඔවුන්ගේ සේවාව වෙනත් සේවාවක් ඇමතුවහොත්, ඔවුන් ඔවුන්ගේ SLA හි එම කාලය ගණන් නොකළේය. එක් ක්‍රියාවලියක් තුළ දියත් කරන ලද සෑම දෙයක්ම 150 ms අගයට අනුගත විය, නමුත් වෙනත් සේවා ක්‍රියාවලීන් වෙත ප්රවේශ වීම මුළු ප්‍රමාදය බොහෝ වාරයක් වැඩි කළේය. ඉගෙන ගත් පළමු පාඩම වූයේ: "ඔබේ SLA පාලනය ඔබ ද, නැතහොත් SLA ඔබ පාලනය කරන්නේ ද?" අපගේ නඩුවේදී, එය දෙවැන්න විය.
මීළඟට අප සොයා ගත් කරුණ නම් පීටර් ඩීච් සහ ජේම්ස් ගොස්ලින් විසින් සකස් කරන ලද බෙදා හරින ලද පරිගණක වැරදි සංකල්ප පිළිබඳ සංකල්පය ඔවුන් දැන සිටි නමුත් ඔවුන් එහි පළමු කොටස නොසලකා හැරීමයි. එහි සඳහන් වන්නේ "ජාලය විශ්වාසදායකයි", "ශුන්‍ය ප්‍රමාදය" සහ "අසීමිත ප්‍රතිදානය" යන ප්රකාශ වැරදි වැටහීම් බවයි. අනෙකුත් වැරදි වැටහීම්වලට "ජාලය ආරක්ෂිතයි", "ස්ථල විද්‍යාව කිසි විටෙකත් වෙනස් නොවේ", "සෑම විටම සිටින්නේ එක් පරිපාලකයෙක් පමණි", "දත්ත හුවමාරු කිරීමේ පිරිවැය ශුන්‍ය වේ" සහ "ජාලය සමජාතීය" යන ප්රකාශ ඇතුළත් වේ.
දේශීය යන්ත්‍ර මත ඔවුන්ගේ සේවාව පරීක්ෂා කළ නිසාත් කිසි විටෙක බාහිර සේවාවන් සමඟ සම්බන්ධ නොවීමත් නිසා ඔවුන් වැරදීමක් කර ඇත. දේශීයව සංවර්ධනය කරන විට සහ දේශීය හැඹිලියක් භාවිතා කරන විට, ඔවුන් කිසි විටෙකත් ජාල හොප් හමු නොවීය. මාස 18 ක සංවර්ධන කාලය තුළ, බාහිර සේවාවන්ට බලපෑම් ඇති වුවහොත් කුමක් සිදුවේදැයි ඔවුන් කිසි විටෙකත් කල්පනා කර නැත.
ඔබ කලින් පින්තූරයේ සේවා සීමාවන් දෙස බැලුවහොත්, ඒවා සියල්ලම වැරදි බව ඔබට පෙනෙනු ඇත. සේවා සීමාවන් නිර්වචනය කරන්නේ කෙසේද යන්න පිළිබඳව උපදෙස් දෙන මූලාශ්‍ර ඕනෑ තරම් ඇති අතර, මීළඟ විනිවිදකයේ Microsoft වැනි බොහෝ ඒවා වැරදියි.
මෙම පින්තූරය "Microservices ගොඩනඟන්නේ කෙසේද" යන මාතෘකාව මත MS බ්ලොග් අඩවියෙන්. මෙය සරල වෙබ් යෙදුමක්, ව්‍යාපාර තාර්කික බ්ලොක් එකක් සහ දත්ත සමුදායක් පෙන්වයි. ඉල්ලීම කෙලින්ම පැමිණේ, වෙබ් සඳහා එක් සේවාදායකයක්, ව්‍යාපාරය සඳහා එක් සේවාදායකයක් සහ දත්ත සමුදාය සඳහා එකක් තිබේ. ට්‍රැෆික් වැඩි කළොත් පින්තූරය ටිකක් වෙනස් වේවි.
වෙබ් සර්වර් දෙකක් අතර ගමනාගමනය බෙදා හැරීමට ලෝඩ් බැලන්සර් එකක්, වෙබ් සේවාව සහ ව්‍යාපාර තර්කනය අතර ඇති හැඹිලියක් සහ ව්‍යාපාර තර්කනය සහ දත්ත සමුදාය අතර තවත් හැඹිලියක් මෙහි පැමිණේ. මෙය හරියටම 2000 ගණන්වල මැද භාගයේදී එහි බර සමතුලිත කිරීම සහ නිල්/කොළ යෙදවුම් යෙදුම සඳහා භාවිතා කරන ලද ගෘහ නිර්මාණ ශිල්පයයි. මෙම යෝජනා ක්රමය මොනොලිතික් ව්‍යුහයක් සඳහා අදහස් කළ බැවින් යම් කාලයක් දක්වා සෑම දෙයක්ම හොඳින් ක්රියාත්මක විය.
පහත පින්තූරයේ දැක්වෙන්නේ MS විසින් මොනොලිත් එකක සිට ක්ෂුද්ර සේවා වෙත මාරු වීම නිර්දේශ කරන ආකාරයයි - එක් එක් ප්‍රධාන සේවා වෙන වෙනම ක්ෂුද්ර සේවාවලට බෙදීම. මෙම යෝජනා ක්රමය ක්රියාත්මක කිරීමේදී බෙල්ට වැරදීමක් සිදු විය.
ඔවුන් ඔවුන්ගේ සියලුම සේවාවන් විවිධ ස්ථරවලට බෙදා ඇති අතර, ඒ සෑම එකක්ම බොහෝ තනි සේවාවන්ගෙන් සමන්විත විය. උදාහරණයක් ලෙස, වෙබ් සේවාවට අන්තර්ගත විදැහුම්කරණය සහ සත්‍යාපනය සඳහා ක්ෂුද්ර සේවා ඇතුළත් විය, ව්‍යාපාරික තාර්කික සේවාව ඇණවුම් සහ ගිණුම් තොරතුරු සැකසීම සඳහා ක්ෂුද්ර සේවා වලින් සමන්විත විය, දත්ත සමුදාය විශේෂිත දත්ත සහිත ක්ෂුද්ර සේවා සමූහයකට බෙදා ඇත. වෙබ්, ව්‍යාපාර තර්කනය සහ දත්ත සමුදාය යන දෙකම රාජ්‍ය රහිත සේවා විය.
කෙසේ වෙතත්, මෙම පින්තූරය සමාගමේ තොරතුරු තාක්ෂණ පොකුරෙන් පිටත කිසිදු ව්‍යාපාරික ඒකක සිතියම්ගත නොකළ නිසා සම්පූර්ණයෙන්ම වැරදියි. මෙම යෝජනා ක්රමය බාහිර ලෝකය සමඟ කිසිදු සම්බන්ධයක් සැලකිල්ලට ගෙන නැත, එබැවින් තෙවන පාර්ශවීය ව්‍යාපාර විශ්ලේෂණ ලබා ගන්නේ කෙසේද යන්න පැහැදිලි නැත. ඒ සඳහා වැඩි මුදලක් ලබා ගැනීම සඳහා හැකි තරම් පුද්ගලයින් කළමනාකරණය කිරීමට උත්සාහ කළ තනි සේවකයින්ගේ වෘත්තීන් දියුණු කිරීම සඳහා සරලව නිර්මාණය කරන ලද සේවාවන් කිහිපයක් ද ඔවුන් සතුව ඇති බව මම සටහන් කරමි.
ක්ෂුද්ර සේවා වෙත යාම ඔවුන්ගේ අභ්‍යන්තර N-ස්ථර භෞතික ස්ථර යටිතල ව්‍යුහය ගෙන එය මත ඩොකර් ඇලවීම තරම් පහසු බව ඔවුහු විශ්වාස කළහ. සාම්ප්‍රදායික N-ස්ථර ගෘහ නිර්මාණ ශිල්පය කෙබඳුදැයි බලමු.
එය මට්ටම් 4 කින් සමන්විත වේ: UI පරිශීලක අතුරුමුහුණත් මට්ටම, ව්‍යාපාර තාර්කික මට්ටම, දත්ත ප්රවේශ මට්ටම සහ දත්ත සමුදාය. වඩාත් ප්‍රගතිශීලී වන්නේ DDD (Domain-Driven Design) හෝ මෘදුකාංග-නැඹුරු ගෘහ නිර්මාණ ශිල්පයයි, මෙහි මධ්‍යම මට්ටම් දෙක වසම් වස්තූන් සහ ගබඩාවක් වේ.
මෙම ගෘහ නිර්මාණ ශිල්පයේ විවිධ වෙනස්කම්, විවිධ වගකීම් ක්ෂේත්‍ර දෙස බැලීමට මම උත්සාහ කළෙමි. සාමාන්‍ය N-ස්ථර යෙදුමක, ව්‍යුහය සිරස් අතට ඉහළ සිට පහළට විනිවිද යන විවිධ වෙනස්වීම් ක්ෂේත්‍ර වර්ගීකරණය කර ඇත. මේවා නාමාවලිය, තනි පරිගණකවල සිදු කරන ලද වින්‍යාස සැකසුම් සහ මගේ කණ්ඩායම විසින් හසුරුවන ලද Checkout චෙක්පත් වේ.
මෙම යෝජනා ක්‍රමයේ විශේෂත්වය නම්, මෙම වෙනස්වීම් ක්ෂේත්‍රවල මායිම් ව්‍යාපාර තාර්කික මට්ටමට පමණක් නොව, දත්ත සමුදාය දක්වාද බලපාන බවයි.
සේවාවක් යන්නෙන් අදහස් කරන්නේ කුමක්දැයි බලමු. සේවා නිර්වචනයක ලාක්ෂණික ගුණාංග 6 ක් ඇත - එය මෘදුකාංගයකි:
- නිශ්චිත සංවිධානයක් විසින් නිර්මාණය කර භාවිතා කිරීම;
- පද්ධතිය තුළ යම් ආකාරයක තොරතුරු අන්තර්ගතය, සැකසීම සහ/හෝ සැපයීම සඳහා වගකිව යුතුය;
- නිශ්චිත මෙහෙයුම් අවශ්‍යතා සපුරාලීම සඳහා ස්වාධීනව ගොඩනගා, යෙදවීමට සහ ධාවනය කළ හැකිය;
- පාරිභෝගිකයින් සහ වෙනත් සේවාවන් සමඟ සන්නිවේදනය කිරීම, ගිවිසුම් හෝ ගිවිසුම් සහතික මත පදනම්ව තොරතුරු සැපයීම;
- අනවසරයෙන් ප්රවේශ වීමෙන් ආරක්ෂා වන අතර, එහි තොරතුරු අහිමි වීමෙන් ආරක්ෂා කරයි;
- තොරතුරු හානිවලට තුඩු නොදෙන ආකාරයෙන් අසාර්ථකත්වයන් හසුරුවයි.
මෙම සියලු ගුණාංග "ස්වයං පාලනය" යන එක් වචනයකින් ප්රකාශ කළ හැකිය. සේවාවන් එකිනෙකින් ස්වාධීනව ක්රියාත්මක වේ, යම් සීමාවන් තෘප්තිමත් කරයි, සහ මිනිසුන්ට අවශ්‍ය තොරතුරු ලබා ගත හැකි පදනම මත කොන්ත්‍රාත්තු නිර්වචනය කරයි. මම නිශ්චිත තාක්ෂණයන් ගැන සඳහන් කළේ නැත, ඒවායේ භාවිතය ස්වයං-විශිෂ්ට වේ.
දැන් අපි microservices අර්ථ දැක්වීම දෙස බලමු:
- ක්ෂුද්ර සේවාවක් ප්‍රමාණයෙන් කුඩා වන අතර එක් විශේෂිත ගැටළුවක් විසඳීමට නිර්මාණය කර ඇත;
- ක්ෂුද්ර සේවා ස්වයංක්‍රීයයි;
- ක්ෂුද්ර සේවා ගෘහ නිර්මාණ ශිල්පයක් නිර්මාණය කිරීමේදී, නගර සැලසුම් රූපකය භාවිතා වේ. මෙය සෑම් නිව්මන්ගේ බිල්ඩින් ක්ෂුද්ර සේවා යන පොතේ නිර්වචනයයි.
සීමා සහිත සන්දර්භයේ නිර්වචනය Eric Evans ගේ Domain-Driven Design පොතෙන් ලබාගෙන ඇත. මෙය පරිමාමිතික වාස්තුවිද්‍යාත්මක ආකෘති සමඟ ක්‍රියා කරන, විවිධ සීමා සහිත සන්දර්භවලට බෙදා ඒවා අතර අන්තර්ක්‍රියා පැහැදිලිව නිර්වචනය කරන ගෘහ නිර්මාණ සැලසුම් මධ්‍යස්ථානයක් වන DDD හි මූලික රටාවකි.
සරලව කිවහොත්, සීමා සහිත සන්දර්භයක් යනු කිසියම් මොඩියුලයක් භාවිතා කළ හැකි විෂය පථයයි. මෙම සන්දර්භය තුළ තාර්කිකව ඒකාබද්ධ ආකෘතියක් දැකිය හැකිය, උදාහරණයක් ලෙස, ඔබේ ව්‍යාපාර වසම තුළ. ඔබ ඇණවුම් වලට සම්බන්ධ පුද්ගලයින්ගෙන් “සේවාදායකයා කවුද” යැයි ඇසුවහොත්, ඔබට එක් අර්ථ දැක්වීමක් ලැබෙනු ඇත, ඔබ විකුණුම්වල යෙදී සිටින අයගෙන් ඇසුවහොත්, ඔබට තවත් අර්ථ දැක්වීමක් ලැබෙනු ඇත, සහ රංගන ශිල්පීන් ඔබට තුන්වන අර්ථ දැක්වීමක් ලබා දෙනු ඇත.
එබැවින්, සීමා සහිත සන්දර්භය පවසන්නේ අපගේ සේවාවන්හි පාරිභෝගිකයෙකු යනු කුමක්ද යන්න පිළිබඳ පැහැදිලි නිර්වචනයක් ලබා දිය නොහැකි නම්, මෙම යෙදුමේ අර්ථය ගැන කතා කළ හැකි සීමාවන් නිර්වචනය කර, මෙම විවිධ නිර්වචන අතර සංක්‍රාන්ති ලක්ෂ්‍ය නිර්වචනය කරමු. එනම්, අපි ඇණවුම් කිරීමේ දෘෂ්ටි කෝණයෙන් සේවාදායකයෙකු ගැන කතා කරන්නේ නම්, මෙයින් අදහස් කරන්නේ මෙය සහ එයයි, සහ විකුණුම් දෘෂ්ටි කෝණයෙන් නම්, මෙයින් අදහස් කරන්නේ මෙය සහ එයයි.
ක්ෂුද්ර සේවාවක මීළඟ නිර්වචනය වන්නේ ඕනෑම ආකාරයක අභ්‍යන්තර මෙහෙයුම් ආවරණය කිරීම, වැඩ ක්‍රියාවලියේ සංරචක පරිසරයට "කාන්දු වීම" වැළැක්වීමයි. මීළඟට පැමිණෙන්නේ “බාහිර අන්තර්ක්‍රියා හෝ බාහිර සන්නිවේදනයන් සඳහා පැහැදිලි කොන්ත්‍රාත්තු නිර්වචනය” වන අතර එය SLAs වෙතින් ආපසු එන කොන්ත්‍රාත්තු පිළිබඳ අදහස මගින් නිරූපණය කෙරේ. අවසාන නිර්වචනය යනු සෛලයක හෝ සෛලයක රූපකයයි, එයින් අදහස් කරන්නේ ක්ෂුද්ර සේවාවක් තුළ මෙහෙයුම් සමූහයක් සම්පූර්ණයෙන් ආවරණය කිරීම සහ බාහිර ලෝකය සමඟ සන්නිවේදනය සඳහා ප්‍රතිග්‍රාහක එහි තිබීමයි.
ඉතින් අපි බෙල් කම්පියුටර්ස් එකේ කට්ටියට කිව්වා, “ඔබට එය කිරීමට මුදල් නොමැති නිසා අපට ඔබ ඇති කළ අවුල් සහගත කිසිවක් නිවැරදි කළ නොහැක, නමුත් අපි ඒ සියල්ල සෑදීමට එක් සේවාවක් පමණක් සකස් කරමු. හැඟීම." මෙම අවස්ථාවේදී, අපි අපගේ එකම සේවාව මිනිත්තු 9 හමාරකට වඩා වේගයෙන් ඉල්ලීම්වලට ප්‍රතිචාර දක්වන පරිදි අපි සවි කළ ආකාරය ඔබට පැවසීමෙන් ආරම්භ කරමි.
22:30 විනාඩි
ඉතා ඉක්මනින් ඉදිරියට...
පොඩි ඇඩ්වර්ටයිසින් එකක්
අප සමඟ රැඳී සිටීම ගැන ඔබට ස්තුතියි. ඔබ අපේ ලිපි වලට කැමතිද? වඩාත් රසවත් අන්තර්ගතය බැලීමට අවශ්‍යද? ඇණවුමක් කිරීමෙන් හෝ මිතුරන්ට නිර්දේශ කිරීමෙන් අපට සහාය වන්න, , ඔබ වෙනුවෙන් අප විසින් නිර්මාණය කරන ලද ප්රවේශ මට්ටමේ සේවාදායකයන්ගේ අද්විතීය ප්‍රතිසමයක්: (RAID1 සහ RAID10, cores 24 දක්වා සහ 40GB DDR4 දක්වා ඇත).
Dell R730xd ඇම්ස්ටර්ඩෑම් හි Equinix Tier IV දත්ත මධ්‍යස්ථානයේ 2 ගුණයක් ලාභදායීද? මෙතන විතරයි නෙදර්ලන්තයේ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 සිට! ගැන කියවන්න
මූලාශ්රය: www.habr.com