මෙම ලිපියෙන්, මම වැඩ කරන ව්යාපෘතිය විශාල ඒකලිතයක සිට ක්ෂුද්ර සේවා කට්ටලයක් බවට පරිවර්තනය වූ ආකාරය ගැන කතා කරමි.
මෙම ව්යාපෘතිය සිය ඉතිහාසය ආරම්භ කළේ බොහෝ කලකට පෙර, එනම් 2000 වර්ෂයේ මුල් භාගයේදීය. පළමු අනුවාද ලියා ඇත්තේ විෂුවල් බේසික් 6 හි ය. කාලයත් සමඟම, IDE සිට අනාගතයේදී මෙම භාෂාවේ සංවර්ධනය සඳහා සහය දැක්වීම දුෂ්කර බව පැහැදිලි විය. සහ භාෂාවම දුර්වල ලෙස වර්ධනය වී ඇත. 2000 ගණන්වල අවසානයේ, වඩාත් පොරොන්දු වූ C# වෙත මාරු වීමට තීරණය විය. නව අනුවාදය පැරණි එක සංශෝධනයට සමාන්තරව ලියා ඇත, ක්‍රමයෙන් වැඩි වැඩියෙන් කේතය .NET හි ලියා ඇත. C# හි පසුපෙළ මුලින් සේවා ගෘහ නිර්මාණ ශිල්පයක් කෙරෙහි අවධානය යොමු කරන ලදී, නමුත් සංවර්ධනය අතරතුර, තර්කනය සහිත පොදු පුස්තකාල භාවිතා කරන ලද අතර, සේවා තනි ක්‍රියාවලියක් තුළ දියත් කරන ලදී. එහි ප්‍රතිඵලය වූයේ අපි "සේවා මොනොලිත්" ලෙස හැඳින්වූ යෙදුමකි.
මෙම සංයෝජනයේ ඇති වාසි කිහිපයෙන් එකක් වූයේ බාහිර API හරහා එකිනෙකා ඇමතීමට සේවාවන්ට ඇති හැකියාවයි. වඩාත් නිවැරදි සේවාවක් වෙත මාරුවීම සඳහා පැහැදිලි පූර්වාවශ්යතාවයන් සහ අනාගතයේ දී ක්ෂුද්ර සේවා ගෘහ නිර්මාණ ශිල්පය විය.
අපි 2015 දී පමණ දිරාපත්වීම පිළිබඳ අපගේ වැඩ කටයුතු ආරම්භ කළෙමු. අපි තවම පරමාදර්ශී තත්වයකට පැමිණ නැත - මොනොලිත් ලෙස හැඳින්විය නොහැකි විශාල ව්‍යාපෘතියක කොටස් තවමත් ඇත, නමුත් ඒවා ක්ෂුද්ර සේවා මෙන් ද නොපෙනේ. කෙසේ වෙතත්, ප්රගතිය සැලකිය යුතු ය.
මම ඒ ගැන ලිපියෙන් කතා කරන්නම්.
අන්තර්ගතය
පවතින විසඳුමේ ගෘහ නිර්මාණ ශිල්පය සහ ගැටළු
මුලදී, ගෘහ නිර්මාණ ශිල්පය පෙනුනේ මේ ආකාරයට ය: UI යනු වෙනම යෙදුමකි, ඒකලිතික කොටස විෂුවල් බේසික් 6 හි ලියා ඇත, .NET යෙදුම තරමක් විශාල දත්ත ගබඩාවක් සමඟ ක්රියා කරන අදාළ සේවා සමූහයකි.
පෙර විසඳුමේ අවාසි
අසාර්ථක වීමේ තනි ලක්ෂ්‍යය
අපට අසාර්ථක වීමේ එක් කරුණක් තිබුණි: .NET යෙදුම තනි ක්‍රියාවලියක ධාවනය විය. කිසියම් මොඩියුලයක් අසමත් වුවහොත්, සම්පූර්ණ යෙදුම අසාර්ථක වූ අතර නැවත ආරම්භ කිරීමට සිදු විය. අපි විවිධ පරිශීලකයින් සඳහා ක්‍රියාවලි විශාල සංඛ්‍යාවක් ස්වයංක්‍රීය කරන බැවින්, ඔවුන්ගෙන් එකක් අසාර්ථක වීම නිසා, සෑම කෙනෙකුටම යම් කාලයක් වැඩ කිරීමට නොහැකි විය. මෘදුකාංග දෝෂයක් ඇති වූ විට, උපස්ථය පවා උදව් කළේ නැත.
වැඩිදියුණු කිරීම් පෝලිම
මෙම අඩුපාඩුව තරමක් සංවිධානාත්මක ය. අපගේ යෙදුමට බොහෝ ගනුදෙනුකරුවන් සිටින අතර, ඔවුන් සියල්ලන්ටම හැකි ඉක්මනින් එය වැඩිදියුණු කිරීමට අවශ්ය වේ. මීට පෙර, මෙය සමාන්තරව කළ නොහැකි වූ අතර, සියලුම ගනුදෙනුකරුවන් පේළියේ සිටගෙන සිටියහ. මෙම ක්‍රියාවලිය ව්‍යාපාර සඳහා ඍණාත්මක වූයේ ඔවුන්ගේ කාර්යය වටිනා බව ඔප්පු කිරීමට ඔවුන්ට සිදු වූ බැවිනි. තවද සංවර්ධන කණ්ඩායම මෙම පෝලිම සංවිධානය කිරීමට කාලය ගත කළේය. මෙය බොහෝ කාලයක් හා වෑයමක් දැරූ අතර, අවසානයේ නිෂ්පාදිතය ඔවුන් කැමති තරම් ඉක්මනින් වෙනස් කළ නොහැක.
සම්පත් උපප්‍රශස්ත භාවිතය
තනි ක්‍රියාවලියක සේවා සත්කාරකත්වය සපයන විට, අපි සෑම විටම සේවාදායකයෙන් සේවාදායකයට වින්‍යාසය සම්පූර්ණයෙන්ම පිටපත් කළෙමු. සම්පත් නාස්ති නොකිරීමට සහ අපගේ යෙදවීමේ යෝජනා ක්‍රමයට වඩා නම්‍යශීලී පාලනයක් ලබා ගැනීමට අපට අවශ්ය වූයේ වැඩිපුරම පටවා ඇති සේවාවන් වෙන වෙනම තැබීමටයි.
නවීන තාක්ෂණයන් ක්රියාත්මක කිරීමට අපහසුය
සියලුම සංවර්ධකයින්ට හුරුපුරුදු ගැටළුවක්: ව්යාපෘතියට නවීන තාක්ෂණයන් හඳුන්වා දීමට ආශාවක් ඇත, නමුත් අවස්ථාවක් නොමැත. විශාල මොනොලිතික් විසඳුමක් සමඟ, වර්තමාන පුස්තකාලයේ ඕනෑම යාවත්කාලීන කිරීමක්, නව එකක් වෙත මාරුවීම ගැන සඳහන් නොකර, තරමක් සුළු නොවන කාර්යයක් බවට පත්වේ. මෙය නාස්ති වූ ස්නායු වලට වඩා වැඩි බෝනස් ගෙන එන බව කණ්ඩායම් නායකයාට ඔප්පු කිරීමට බොහෝ කාලයක් ගත වේ.
වෙනස්කම් නිකුත් කිරීමේ අපහසුතාව
මෙය බරපතලම ගැටලුව විය - අපි සෑම මාස දෙකකට වරක් නිකුතු නිකුත් කරමින් සිටියෙමු.
සංවර්ධකයින්ගේ පරීක්ෂණ සහ උත්සාහයන් නොතකා, සෑම නිකුතුවක්ම බැංකුවට සැබෑ ව්‍යසනයක් බවට පත් විය. සතිය ආරම්භයේදී එහි සමහර ක්‍රියාකාරීත්වය ක්රියා නොකරන බව ව්‍යාපාරය තේරුම් ගෙන ඇත. සතියක බරපතල සිදුවීම් ඔවුන් බලා සිටින බව සංවර්ධකයින් තේරුම් ගත්හ.
තත්වය වෙනස් කිරීමට සෑම කෙනෙකුටම ආශාවක් තිබුණි.
ක්ෂුද්ර සේවා වෙතින් අපේක්ෂාවන්
සූදානම් වන විට සංරචක නිකුත් කිරීම. විසඳුම දිරාපත් කිරීම සහ විවිධ ක්රියාවලීන් වෙන් කිරීම මගින් සූදානම් වන විට සංරචක බෙදා හැරීම.
කුඩා නිෂ්පාදන කණ්ඩායම්. පැරණි monolith මත වැඩ කරන විශාල කණ්ඩායමක් කළමනාකරණය කිරීමට අපහසු වූ නිසා මෙය වැදගත් වේ. එවැනි කණ්ඩායමකට දැඩි ක්රියාවලියකට අනුව වැඩ කිරීමට බල කෙරුණු නමුත් ඔවුන්ට අවශ්ය වූයේ වඩා නිර්මාණශීලිත්වය සහ ස්වාධීනත්වයයි. කුඩා කණ්ඩායම්වලට පමණක් මෙය දැරිය හැකි විය.
වෙනම ක්රියාවලීන්හි සේවා හුදකලා කිරීම. ඉතා මැනවින්, මට එය බහාලුම්වල හුදකලා කිරීමට අවශ්ය විය, නමුත් .NET Framework හි ලියා ඇති සේවාවන් විශාල සංඛ්‍යාවක් ක්රියාත්මක වන්නේ වින්ඩෝස් මත පමණි. .NET Core මත පදනම් වූ සේවාවන් දැන් දිස් වේ, නමුත් තවමත් ඒවායින් කිහිපයක් තිබේ.
යෙදවීමේ නම්‍යතාවය. අපි කැමති සේවා අපට අවශ්ය ආකාරයට ඒකාබද්ධ කිරීමට මිස කේතය බල කරන ආකාරයට නොවේ.
නව තාක්ෂණයන් භාවිතය. මෙය ඕනෑම ක්‍රමලේඛකයෙකුට සිත්ගන්නා සුළුය.
සංක්‍රාන්ති ගැටළු
ඇත්ත වශයෙන්ම, මොනොලිත් එකක් ක්ෂුද්ර සේවාවලට කැඩීම පහසු නම්, ඒ ගැන සම්මන්ත්‍රණවල කතා කිරීමට සහ ලිපි ලිවීමට අවශ්ය නොවනු ඇත. මෙම ක්‍රියාවලියේ බොහෝ අන්තරායන් ඇත; අපට බාධා කළ ප්රධාන ඒවා මම විස්තර කරමි.
පළමු ගැටළුව බොහෝ ඒකලිත සඳහා සාමාන්‍ය: ව්‍යාපාර තර්කනයේ සමෝධානය. අපි ඒකලිතයක් ලියන විට, අනවශ්‍ය කේතයක් නොලියවීම සඳහා අපගේ පන්ති නැවත භාවිතා කිරීමට අවශ්ය වේ. ක්ෂුද්ර සේවා වෙත යන විට, මෙය ගැටළුවක් බවට පත්වේ: සියලුම කේතය තරමක් තදින් සම්බන්ධ වී ඇති අතර සේවාවන් වෙන් කිරීම දුෂ්කර ය.
වැඩ ආරම්භ කරන විට, ගබඩාවේ ව්‍යාපෘති 500 කට වඩා සහ කේත රේඛා 700 කට වඩා තිබුණි. මෙය තරමක් විශාල තීරණයක් සහ දෙවන ගැටළුව. එය සරලව ගෙන එය ක්ෂුද්ර සේවාවලට බෙදීමට නොහැකි විය.
තුන්වන ගැටලුව - අවශ්ය යටිතල පහසුකම් නොමැතිකම. ඇත්ත වශයෙන්ම, අපි මූලාශ්ර කේතය සර්වර් වෙත අතින් පිටපත් කරමින් සිටියෙමු.
මොනොලිත් සිට ක්ෂුද්ර සේවා වෙත මාරු කරන්නේ කෙසේද
ක්ෂුද්ර සේවා සැපයීම
පළමුව, ක්ෂුද්ර සේවා වෙන් කිරීම පුනරාවර්තන ක්‍රියාවලියක් බව අපි වහාම තීරණය කළෙමු. අපට සැමවිටම අවශ්ය වූයේ ව්යාපාරික ගැටලු සමාන්තරව වර්ධනය කිරීමයි. අපි මෙය තාක්ෂණික වශයෙන් ක්රියාත්මක කරන්නේ කෙසේද යන්න දැනටමත් අපගේ ගැටලුවකි. එබැවින්, අපි පුනරාවර්තන ක්රියාවලියකට සූදානම් විය. ඔබට විශාල යෙදුමක් තිබේ නම් සහ එය නැවත ලිවීමට මුලින් සූදානම් නැතිනම් එය වෙනත් ආකාරයකින් ක්රියා නොකරනු ඇත.
ක්ෂුද්ර සේවා හුදකලා කිරීමට අප භාවිතා කරන ක්‍රම මොනවාද?
පළමු ක්රමය — පවතින මොඩියුල සේවා ලෙස ගෙන යන්න. මේ සම්බන්ධයෙන්, අපි වාසනාවන්ත විය: දැනටමත් WCF ප්රොටෝකෝලය භාවිතයෙන් වැඩ කරන ලද ලියාපදිංචි සේවාවන් තිබේ. ඔවුන් වෙනම රැස්වීම්වලට වෙන් කරන ලදී. අපි ඒවා වෙන වෙනම පෝට් කර, එක් එක් ගොඩනැගීමට කුඩා දියත් කිරීමක් එකතු කළෙමු. එය ලියා ඇත්තේ අපූරු Topshelf පුස්තකාලය භාවිතයෙන් වන අතර එමඟින් යෙදුම සේවාවක් ලෙස සහ කොන්සෝලයක් ලෙස ක්රියාත්මක කිරීමට ඔබට ඉඩ සලසයි. විසඳුමේ අමතර ව්‍යාපෘති අවශ්ය නොවන බැවින් මෙය නිදොස්කරණය සඳහා පහසු වේ.
ඔවුන් පොදු එකලස් කිරීම් සහ පොදු දත්ත සමුදායක් සමඟ වැඩ කළ බැවින් සේවා ව්යාපාරික තර්කයට අනුව සම්බන්ධ විය. ඒවායේ පිරිසිදු ස්වරූපයෙන් ඒවා ක්ෂුද්ර සේවා ලෙස හැඳින්විය නොහැක. කෙසේ වෙතත්, අපට මෙම සේවාවන් වෙන වෙනම, විවිධ ක්‍රියාවලීන්ගෙන් සැපයිය හැකිය. මෙය පමණක් එකිනෙකාට ඔවුන්ගේ බලපෑම අඩු කිරීමට හැකි වූ අතර, සමාන්තර සංවර්ධනය හා අසාර්ථකත්වයේ තනි ලක්ෂ්යයක් සමඟ ගැටළුව අඩු කරයි.
ධාරකය සමඟ එකලස් කිරීම වැඩසටහන් පන්තියේ එක් කේතයක් පමණි. අපි Topshelf සමඟ වැඩ සහායක පන්තියක සඟවා තැබුවෙමු.
namespace RBA.Services.Accounts.Host
{
internal class Program
{
private static void Main(string[] args)
{
HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");
}
}
}
ක්ෂුද්ර සේවා වෙන් කිරීමේ දෙවන ක්රමය නම්: නව ගැටළු විසඳීම සඳහා ඒවා නිර්මාණය කරන්න. ඒ සමඟම මොනොලිත් වර්ධනය නොවන්නේ නම්, මෙය දැනටමත් විශිෂ්ටයි, එයින් අදහස් කරන්නේ අපි නිවැරදි දිශාවට ගමන් කරන බවයි. නව ගැටළු විසඳීම සඳහා, අපි වෙනම සේවාවන් නිර්මාණය කිරීමට උත්සාහ කළෙමු. එවැනි අවස්ථාවක් තිබුනේ නම්, අපි ඔවුන්ගේම දත්ත ආකෘතියක්, වෙනම දත්ත ගබඩාවක් සම්පූර්ණයෙන්ම කළමනාකරණය කරන තවත් "කැනොනිකල්" සේවාවන් නිර්මාණය කළෙමු.
අපි, බොහෝ දෙනෙක් මෙන්, සත්‍යාපනය සහ බලය පැවරීමේ සේවාවන් සමඟ ආරම්භ කළෙමු. ඔවුන් මේ සඳහා පරිපූර්ණයි. ඔවුන් ස්වාධීන, නීතියක් ලෙස, ඔවුන් වෙනම දත්ත ආකෘතියක් ඇත. ඔවුන්ම මොනොලිත් සමඟ අන්තර් ක්රියා නොකරයි, සමහර ගැටළු විසඳීමට එය ඔවුන් වෙත හැරේ. මෙම සේවාවන් භාවිතා කරමින්, ඔබට නව ගෘහ නිර්මාණ ශිල්පයකට මාරුවීම ආරම්භ කළ හැකිය, ඒවා මත යටිතල පහසුකම් දෝශ නිරාකරණය කිරීම, ජාල පුස්තකාල සම්බන්ධ ප්රවේශයන් කිහිපයක් උත්සාහ කරන්න. සත්‍යාපන සේවාවක් තැනීමට නොහැකි වූ කණ්ඩායම් කිසිවක් අපගේ සංවිධානයේ නොමැත.
ක්ෂුද්ර සේවා වෙන් කිරීම සඳහා තුන්වන ක්රමයඅපි පාවිච්චි කරන එක අපිට ටිකක් විශේෂිතයි. මෙය UI ස්ථරයෙන් ව්යාපාරික තර්කනය ඉවත් කිරීමයි. අපගේ ප්රධාන UI යෙදුම ඩෙස්ක්ටොප් වේ; එය, පසුපෙළ මෙන්, C# වලින් ලියා ඇත. සංවර්ධකයින් වරින් වර වැරදි සිදු කර ඇති අතර පසු අන්තයේ පැවතිය යුතු සහ නැවත භාවිතා කළ යුතු තර්කයේ කොටස් UI වෙත මාරු කරන ලදී.
ඔබ UI කොටසේ කේතයෙන් සැබෑ උදාහරණයක් දෙස බැලුවහොත්, මෙම විසඳුමේ බොහෝමයක් UI පෝරමය ගොඩනැගීමට පමණක් නොව අනෙකුත් ක්රියාවලීන් සඳහා ප්‍රයෝජනවත් වන සැබෑ ව්යාපාරික තර්කනය අඩංගු බව ඔබට පෙනෙනු ඇත.
සැබෑ UI තර්කය ඇත්තේ අවසාන පේළි දෙකේ පමණි. අපි එය නැවත භාවිතා කිරීමට හැකි වන පරිදි එය සේවාදායකයට මාරු කළෙමු, එමඟින් UI අඩු කර නිවැරදි ගෘහ නිර්මාණ ශිල්පය සාක්ෂාත් කර ගන්නෙමු.
ක්ෂුද්ර සේවා හුදකලා කිරීමට සිව්වන සහ වැදගත්ම ක්රමය, එය මොනොලිත් අඩු කිරීමට හැකි වන පරිදි, සැකසීම සමඟ පවතින සේවාවන් ඉවත් කිරීමයි. අප දැනට පවතින මොඩියුල ඉවත් කරන විට, ප්‍රති result ලය සැමවිටම සංවර්ධකයින්ගේ රුචිකත්වයට නොපැමිණෙන අතර, ක්‍රියාකාරීත්වය නිර්මාණය කළ දා සිට ව්‍යාපාර ක්‍රියාවලිය යල් පැන ගොස් තිබිය හැක. ප්‍රතිනිර්මාණය කිරීමත් සමඟ, ව්‍යාපාර අවශ්‍යතා නිරන්තරයෙන් වෙනස් වන නිසා අපට නව ව්‍යාපාර ක්රියාවලියකට සහාය විය හැක. අපට මූලාශ්ර කේතය වැඩිදියුණු කිරීමට, දන්නා දෝෂ ඉවත් කිරීමට සහ වඩා හොඳ දත්ත ආකෘතියක් නිර්මාණය කිරීමට හැකිය. ප්‍රතිලාභ රැසක් ලැබෙනවා.
සැකසුම් වලින් සේවා වෙන් කිරීම සීමා කළ සන්දර්භය පිළිබඳ සංකල්පයට වෙන් කළ නොහැකි ලෙස සම්බන්ධ වේ. මෙය Domain Driven Design හි සංකල්පයකි. එහි තේරුම තනි භාෂාවක සියලුම නියමයන් අනන්‍ය ලෙස අර්ථ දක්වා ඇති වසම් ආකෘතියේ කොටසකි. උදාහරණයක් ලෙස රක්ෂණ සහ බිල්පත් වල සන්දර්භය දෙස බලමු. අපට මොනොලිතික් යෙදුමක් ඇති අතර, අපි රක්ෂණයේ ගිණුම සමඟ වැඩ කළ යුතුය. සංවර්ධකයා වෙනත් එකලස් කිරීමක පවතින ගිණුම් පන්තියක් සොයා ගනු ඇතැයි අපි බලාපොරොත්තු වෙමු, එය රක්ෂණ පන්තියෙන් යොමු කරයි, සහ අපට ක්‍රියාකාරී කේතය ලැබෙනු ඇත. DRY මූලධර්මයට ගරු කරනු ඇත, පවතින කේතය භාවිතා කිරීමෙන් කාර්යය වේගයෙන් සිදු කරනු ඇත.
ප්රතිඵලයක් වශයෙන්, ගිණුම් සහ රක්ෂණයේ සන්දර්භය සම්බන්ධ වී ඇති බව පෙනී යයි. නව අවශ්‍යතා මතුවන විට, මෙම සම්බන්ධ කිරීම දැනටමත් සංකීර්ණ ව්යාපාරික තර්කනයේ සංකීර්ණත්වය වැඩි කරමින් සංවර්ධනයට බාධාවක් වනු ඇත. මෙම ගැටළුව විසඳීම සඳහා, ඔබ කේතයේ සන්දර්භය අතර මායිම් සොයා ගැනීමට සහ ඒවායේ උල්ලංඝනයන් ඉවත් කිරීමට අවශ්ය වේ. උදාහරණයක් ලෙස, රක්ෂණ සන්දර්භය තුළ, අංක 20 මහ බැංකු ගිණුම් අංකයක් සහ ගිණුම විවෘත කළ දිනය ප්‍රමාණවත් විය හැකිය.
මෙම සීමා සහිත සන්දර්භයන් එකිනෙකින් වෙන් කිරීමට සහ මොනොලිතික් විසඳුමකින් ක්ෂුද්ර සේවා වෙන් කිරීමේ ක්‍රියාවලිය ආරම්භ කිරීමට, අපි යෙදුම තුළ බාහිර API නිර්මාණය කිරීම වැනි ප්‍රවේශයක් භාවිතා කළෙමු. කිසියම් මොඩියුලයක් ක්‍රියාවලිය තුළ කෙසේ හෝ වෙනස් කරන ලද ක්ෂුද්ර සේවාවක් බවට පත් විය යුතු බව අපි දැන සිටියේ නම්, අපි වහාම බාහිර ඇමතුම් හරහා වෙනත් සීමිත සන්දර්භයකට අයත් තර්කයට ඇමතුම් ලබා ගත්තෙමු. උදාහරණයක් ලෙස, REST හෝ WCF හරහා.
බෙදා හරින ලද ගනුදෙනු අවශ්ය වන කේතය අපි මග නොහරින බව අපි තරයේ තීරණය කළෙමු. අපගේ නඩුවේදී, මෙම රීතිය අනුගමනය කිරීම තරමක් පහසු විය. දැඩි බෙදා හරින ලද ගනුදෙනු ඇත්ත වශයෙන්ම අවශ්ය වන අවස්ථා අප තවමත් මුහුණ දී නොමැත - මොඩියුල අතර අවසාන අනුකූලතාවය තරමක් ප්‍රමාණවත් වේ.
අපි නිශ්චිත උදාහරණයක් බලමු. අපට වාද්‍ය වෘන්දයක සංකල්පය ඇත - "යෙදුම" යන ආයතනය සකසන නල මාර්ගයකි. ඔහු ගනුදෙනුකරුවෙකු, ගිණුමක් සහ බැංකු කාඩ්පතක් නිර්මාණය කරයි. සේවාලාභියා සහ ගිණුම සාර්ථකව නිර්මාණය කර ඇත්නම්, නමුත් කාඩ්පත් නිර්මාණය අසාර්ථක වුවහොත්, යෙදුම "සාර්ථක" තත්ත්වයට නොයන අතර "කාඩ්පත නිර්මාණය නොකළ" තත්ත්වයෙහි පවතී. අනාගතයේදී, පසුබිම් ක්‍රියාකාරකම් එය ලබාගෙන එය අවසන් කරනු ඇත. මෙම ක්රමය කලක සිට අනනුකූල තත්වයක පැවතුනද අපි සාමාන්‍යයෙන් මෙයින් සෑහීමකට පත් වෙමු.
දත්තවල කොටසක් අඛණ්ඩව සුරැකීමට අවශ්ය වූ විට තත්වයක් ඇති වුවහොත්, එය එක් ක්‍රියාවලියක් තුළ සැකසීම සඳහා අපි බොහෝ විට සේවාව ඒකාබද්ධ කිරීමට යමු.
ක්ෂුද්ර සේවාවක් වෙන් කිරීම පිළිබඳ උදාහරණයක් බලමු. ඔබ එය සාපේක්ෂව ආරක්ෂිතව නිෂ්පාදනයට ගෙන එන්නේ කෙසේද? මෙම උදාහරණයේ දී, අපට පද්ධතියේ වෙනම කොටසක් ඇත - වැටුප් ගෙවීම් සේවා මොඩියුලයක්, අපි ක්ෂුද්ර සේවා කිරීමට කැමති කේත කොටස් වලින් එකකි.
පළමුවෙන්ම, අපි කේතය නැවත ලිවීමෙන් මයික්‍රො සර්විස් එකක් සාදන්නෙමු. අපි සතුටු නොවූ සමහර පැති අපි වැඩිදියුණු කරමින් සිටිමු. අපි පාරිභෝගිකයාගෙන් නව ව්යාපාරික අවශ්‍යතා ක්රියාත්මක කරන්නෙමු. අපි UI සහ පසුපෙළ අතර සම්බන්ධතාවයට API Gateway එකක් එක් කරන්නෙමු, එය ඇමතුම් යොමු කිරීම සපයනු ඇත.
ඊළඟට, අපි මෙම වින්‍යාසය ක්රියාත්මක කිරීමට මුදා හරිමු, නමුත් නියමු තත්වයක. අපගේ බොහෝ පරිශීලකයින් තවමත් පැරණි ව්‍යාපාර ක්‍රියාවලි සමඟ වැඩ කරයි. නව පරිශීලකයින් සඳහා, අපි තවදුරටත් මෙම ක්‍රියාවලිය අඩංගු නොවන මොනොලිතික් යෙදුමේ නව අනුවාදයක් සංවර්ධනය කරමින් සිටිමු. අත්‍යවශ්‍යයෙන්ම, අපට ගුවන් නියමුවෙකු ලෙස වැඩ කරන මොනොලිත් සහ ක්ෂුද්ර සේවාවක එකතුවක් තිබේ.
සාර්ථක නියමුවෙකු සමඟ, නව වින්‍යාසය සැබවින්ම ක්රියා කළ හැකි බව අපි තේරුම් ගනිමු, අපට සමීකරණයෙන් පැරණි මොනොලිත් ඉවත් කර පැරණි විසඳුම වෙනුවට නව වින්‍යාසය තැබිය හැකිය.
සමස්තයක් වශයෙන්, අපි ඒකලිතයක ප්‍රභව කේතය බෙදීම සඳහා දැනට පවතින සියලුම ක්‍රම පාහේ භාවිතා කරමු. ඒවා සියල්ලම අපට යෙදුමේ කොටස්වල ප්‍රමාණය අඩු කිරීමට සහ ඒවා නව පුස්තකාලවලට පරිවර්තනය කිරීමට ඉඩ සලසයි, එය වඩා හොඳ ප්‍රභව කේතයක් බවට පත් කරයි.
දත්ත සමුදාය සමඟ වැඩ කිරීම
දත්ත සමුදාය ප්‍රභව කේතයට වඩා නරක ලෙස බෙදිය හැකිය, මන්ද එහි වර්තමාන ක්රමය පමණක් නොව සමුච්චිත ඓතිහාසික දත්ත ද අඩංගු වේ.
අපගේ දත්ත සමුදාය, අනෙකුත් බොහෝ අය මෙන්, තවත් වැදගත් අඩුපාඩුවක් තිබුණි - එහි විශාලත්වය. මෙම දත්ත සමුදාය නිර්මාණය කර ඇත්තේ මොනොලිත් එකක සංකීර්ණ ව්යාපාරික තර්කයට අනුව වන අතර විවිධ මායිම් සන්දර්භවල වගු අතර සමුච්චිත සම්බන්ධතා.
අපගේ නඩුවේදී, සියලු කරදර (විශාල දත්ත සමුදාය, බොහෝ සම්බන්ධතා, සමහර විට වගු අතර නොපැහැදිලි මායිම්) ඉහළට, බොහෝ විශාල ව්‍යාපෘතිවල ඇති වන ගැටළුවක් පැන නගී: හවුල් දත්ත සමුදා අච්චුව භාවිතා කිරීම. දත්ත වගු වලින් දර්ශනය හරහා, අනුකරණය හරහා ලබාගෙන, මෙම අනුකරණය අවශ්ය වෙනත් පද්ධති වෙත යවන ලදී. එහි ප්රතිඵලයක් ලෙස, සක්‍රියව භාවිත කර ඇති බැවින්, අපට වගු වෙනම ක්‍රමලේඛයකට ගෙන යාමට නොහැකි විය.
කේතයේ සීමිත සන්දර්භවලට එකම බෙදීම අපට වෙන්වීමට උපකාරී වේ. එය සාමාන්‍යයෙන් අපි දත්ත සමුදා මට්ටමින් දත්ත බිඳ දමන්නේ කෙසේද යන්න පිළිබඳ හොඳ අදහසක් ලබා දෙයි. එක් සීමා සහිත සන්දර්භයකට අයත් වන වගු සහ තවත් එකකට අයත් වන වගු අපි තේරුම් ගනිමු.
අපි දත්ත සමුදාය කොටස් කිරීමේ ගෝලීය ක්‍රම දෙකක් භාවිතා කළෙමු: පවතින වගු කොටස් කිරීම සහ සැකසුම් සමඟ කොටස් කිරීම.
දත්ත ව්‍යුහය හොඳ නම්, ව්යාපාරික අවශ්‍යතා සපුරාලන්නේ නම් සහ සියලු දෙනාම ඒ ගැන සතුටු වන්නේ නම්, පවතින වගු වෙන් කිරීම භාවිතා කිරීමට හොඳ ක්‍රමයකි. මෙම අවස්ථාවේදී, අපට දැනට පවතින වගු වෙනම සැලැස්මකට වෙන් කළ හැකිය.
ව්‍යාපාර ආකෘතිය විශාල වශයෙන් වෙනස් වී ඇති විට සැකසුම් සහිත දෙපාර්තමේන්තුවක් අවශ්ය වන අතර වගු තවදුරටත් අපව කිසිසේත් තෘප්තිමත් නොකරනු ඇත.
පවතින වගු බෙදීම. අප වෙන් කරන්නේ කුමක්ද යන්න තීරණය කළ යුතුය. මෙම දැනුම නොමැතිව, කිසිවක් ක්රියා නොකරනු ඇති අතර, මෙහිදී කේතය තුළ සීමා වූ සන්දර්භයන් වෙන් කිරීම අපට උපකාර වනු ඇත. රීතියක් ලෙස, මූලාශ්ර කේතයේ සන්දර්භයවල මායිම් තේරුම් ගත හැකි නම්, දෙපාර්තමේන්තුව සඳහා ලැයිස්තුවේ ඇතුළත් කළ යුතු වගු මොනවාද යන්න පැහැදිලි වේ.
අපි හිතමු මොනොලිත් මොඩියුල දෙකක් එක දත්ත ගබඩාවක් සමඟ අන්තර්ක්‍රියා කරන විසඳුමක් තියෙනවා කියලා. වෙන් කරන ලද වගු වල කොටස සමඟ එක් මොඩියුලයක් පමණක් අන්තර්ක්‍රියා කරන බවට අපි සහතික විය යුතු අතර අනෙක API හරහා එය සමඟ අන්තර් ක්රියා කිරීමට පටන් ගනී. ආරම්භ කිරීම සඳහා, API හරහා පටිගත කිරීම පමණක් සිදු කිරීම ප්රමාණවත්ය. ක්ෂුද්ර සේවාවල ස්වාධීනත්වය ගැන කතා කිරීමට අපට මෙය අවශ්ය කොන්දේසියකි. කියවීමේ සම්බන්ධතා විශාල ගැටලුවක් නොමැති තාක් කල් පැවතිය හැකිය.
මීලඟ පියවර නම්, අපට වෙන් කරන ලද වගු සමඟ ක්රියා කරන කේත කොටස, සැකසීම සමඟ හෝ රහිතව, වෙනම ක්ෂුද්ර සේවාවකට වෙන් කර එය වෙනම ක්‍රියාවලියක්, බහාලුමක් තුළ ක්රියාත්මක කළ හැකිය. මෙය මොනොලිත් දත්ත ගබඩාවට සහ එයට සෘජුව සම්බන්ධ නොවන වගු වලට සම්බන්ධයක් සහිත වෙනම සේවාවක් වනු ඇත. ඒකලිතය තවමත් වෙන් කළ හැකි කොටස සමඟ කියවීම සඳහා අන්තර්ක්‍රියා කරයි.
පසුව අපි මෙම සම්බන්ධතාවය ඉවත් කරන්නෙමු, එනම්, වෙන් කරන ලද වගු වලින් මොනොලිතික් යෙදුමකින් දත්ත කියවීම ද API වෙත මාරු කරනු ලැබේ.
ඊළඟට, අපි සාමාන්‍ය දත්ත සමුදායෙන් නව ක්ෂුද්ර සේවා පමණක් ක්රියා කරන වගු තෝරා ගනිමු. අපට වගු වෙනම ස්කීමා එකකට හෝ වෙනම භෞතික දත්ත ගබඩාවකට ගෙන යා හැක. මයික්‍රොසර්විස් සහ මොනොලිත් දත්ත ගබඩාව අතර කියවීමේ සම්බන්ධතාවයක් තවමත් පවතී, නමුත් කරදර වීමට කිසිවක් නැත, මෙම වින්‍යාසය තුළ එය සෑහෙන කාලයක් ජීවත් විය හැකිය.
අවසාන පියවර වන්නේ සියලු සම්බන්ධතා සම්පූර්ණයෙන්ම ඉවත් කිරීමයි. මෙම අවස්ථාවේදී, අපට ප්රධාන දත්ත සමුදායෙන් දත්ත සංක්‍රමණය කිරීමට අවශ්ය විය හැකිය. සමහර විට අපට දත්ත සමුදා කිහිපයක බාහිර පද්ධති වලින් අනුකරණය කරන ලද සමහර දත්ත හෝ නාමාවලි නැවත භාවිතා කිරීමට අවශ්ය වේ. මෙය අපට වරින් වර සිදු වේ.
සැකසුම් දෙපාර්තමේන්තුව. මෙම ක්රමය පළමු එකට බෙහෙවින් සමාන ය, ප්‍රතිලෝම අනුපිළිවෙලින් පමණි. අපි වහාම API හරහා මොනොලිත් සමඟ අන්තර්ක්‍රියා කරන නව දත්ත සමුදායක් සහ නව ක්ෂුද්ර සේවාවක් වෙන් කරමු. නමුත් ඒ සමඟම, අනාගතයේදී අපට මකා දැමීමට අවශ්ය දත්ත සමුදා වගු කට්ටලයක් ඉතිරිව පවතී. අපට එය තවදුරටත් අවශ්ය නැත; අපි එය නව මාදිලියේ ප්‍රතිස්ථාපනය කළෙමු.
මෙම යෝජනා ක්රමය ක්රියාත්මක වීමට නම්, අපට සංක්‍රාන්ති කාලයක් අවශ්ය වනු ඇත.
එවිට හැකි ප්රවේශයන් දෙකක් තිබේ.
පළමුවෙනි: අපි සියලු දත්ත නව සහ පැරණි දත්ත සමුදායන්හි අනුපිටපත් කරමු. මෙම අවස්ථාවේදී, අපට දත්ත අතිරික්තයක් ඇති අතර සමමුහුර්ත කිරීමේ ගැටළු මතු විය හැක. නමුත් අපට වෙනස් ගනුදෙනුකරුවන් දෙදෙනෙකු ගත හැකිය. එකක් නව අනුවාදය සමඟ වැඩ කරනු ඇත, අනෙක පැරණි එක සමඟ.
දෙවනුව: අපි සමහර ව්යාපාරික නිර්ණායක අනුව දත්ත බෙදන්නෙමු. උදාහරණයක් ලෙස, පැරණි දත්ත ගබඩාවේ ගබඩා කර ඇති පද්ධතියේ නිෂ්පාදන 5 ක් අපට තිබුණි. අපි නව දත්ත ගබඩාවක නව ව්යාපාරික කාර්යය තුළ හයවැනි එක තබමු. නමුත් අපට මෙම දත්ත සමමුහුර්ත කර සේවාදායකයාට ලබා ගත යුත්තේ කොතැනින්ද සහ කුමක් දැයි පෙන්වන API ද්වාරයක් අවශ්ය වේ.
ප්රවේශයන් දෙකම ක්රියාත්මක වේ, තත්වය අනුව තෝරා ගන්න.
සෑම දෙයක්ම ක්රියාත්මක වන බව අපට සහතික වූ පසු, පැරණි දත්ත සමුදා ව්යුහයන් සමඟ ක්රියා කරන මොනොලිත් කොටස අක්‍රිය කළ හැකිය.
අවසාන පියවර වන්නේ පැරණි දත්ත ව්යුහයන් ඉවත් කිරීමයි.
සාරාංශගත කිරීම සඳහා, අපට දත්ත සමුදාය සමඟ ගැටළු ඇති බව අපට පැවසිය හැකිය: මූලාශ්ර කේතය හා සසඳන විට එය සමඟ වැඩ කිරීමට අපහසු වේ, එය බෙදා ගැනීමට වඩා අපහසු වේ, නමුත් එය කළ හැකි සහ කළ යුතු ය. මෙය තරමක් ආරක්ෂිතව කිරීමට අපට ඉඩ සලසන ක්‍රම කිහිපයක් අපි සොයාගෙන ඇත, නමුත් මූලාශ්ර කේතයට වඩා දත්ත සමඟ වැරදි කිරීම තවමත් පහසුය.
මූල කේතය සමඟ වැඩ කිරීම
අපි මොනොලිතික් ව්යාපෘතිය විශ්ලේෂණය කිරීමට පටන් ගත් විට ප්‍රභව කේත රූප සටහන දිස් වූයේ මෙයයි.
එය දළ වශයෙන් ස්ථර තුනකට බෙදිය හැකිය. මෙය දියත් කරන ලද මොඩියුල, ප්ලගීන, සේවා සහ තනි ක්‍රියාකාරකම්වල ස්ථරයකි. ඇත්ත වශයෙන්ම, මේවා මොනොලිතික් විසඳුමක් තුළ ඇතුල් වීමේ ස්ථාන විය. ඒවා සියල්ලම පොදු ස්ථරයකින් තදින් මුද්‍රා තබා ඇත. එහි සේවා බෙදාගත් ව්යාපාරික තර්කයක් සහ සම්බන්ධතා රාශියක් තිබුණි. එක් එක් සේවාව සහ ප්ලගිනය ඒවායේ ප්‍රමාණය සහ සංවර්ධකයින්ගේ හෘදය සාක්ෂිය මත පදනම්ව, පොදු එකලස් කිරීම් 10ක් හෝ ඊට වැඩි ගණනක් භාවිතා කරයි.
වෙන වෙනම භාවිතා කළ හැකි යටිතල පහසුකම් පුස්තකාල තිබීම අපට වාසනාවකි.
සමහර පොදු වස්තූන් ඇත්ත වශයෙන්ම මෙම ස්ථරයට අයත් නොවන නමුත් යටිතල පහසුකම් පුස්තකාල වූ විට සමහර විට තත්වයක් ඇති විය. මෙය නැවත නම් කිරීමෙන් විසඳා ඇත.
ලොකුම සැලකිල්ල වූයේ සීමා සහිත සන්දර්භයන්ය. එක් පොදු සභාවක සන්දර්භ 3-4 ක් මිශ්‍ර කර එකම ව්යාපාරික කාර්යයන් තුළ එකිනෙක භාවිතා කිරීම සිදු විය. මෙය බෙදිය හැක්කේ කොතැනින්ද සහ කුමන සීමාවන් ඔස්සේද යන්න සහ මෙම බෙදීම මූලාශ්ර කේත එකලස්කිරීම්වලට සිතියම්ගත කිරීමෙන් මීළඟට කුමක් කළ යුතුද යන්න තේරුම් ගැනීමට අවශ්ය විය.
කේත බෙදීමේ ක්‍රියාවලිය සඳහා අපි නීති කිහිපයක් සකස් කර ඇත.
පළමුවෙනි: අපට තවදුරටත් සේවා, ක්‍රියාකාරකම් සහ ප්ලගීන අතර ව්යාපාරික තර්කනය බෙදා ගැනීමට අවශ්ය නැත. අපට අවශ්ය වූයේ ක්ෂුද්ර සේවා තුළ ව්‍යාපාර තර්කනය ස්වාධීන කිරීමට ය. අනෙක් අතට, ක්ෂුද්ර සේවා සම්පූර්ණයෙන්ම ස්වාධීනව පවතින සේවාවන් ලෙස පරමාදර්ශී ලෙස සැලකේ. මෙම ප්‍රවේශය තරමක් අපතේ යන බව මම විශ්වාස කරන අතර එය සාක්ෂාත් කර ගැනීම දුෂ්කර ය, මන්ද, උදාහරණයක් ලෙස, C# හි සේවාවන් ඕනෑම අවස්ථාවක සම්මත පුස්තකාලයකින් සම්බන්ධ වනු ඇත. අපගේ පද්ධතිය C# වලින් ලියා ඇත; අපි තවම වෙනත් තාක්ෂණයන් භාවිතා කර නැත. එබැවින්, පොදු තාක්ෂණික එකලස් කිරීම් භාවිතා කිරීමට අපට හැකි බව අපි තීරණය කළා. ප්රධාන දෙය නම් ඒවායේ ව්යාපාරික තර්කයේ කිසිදු කොටස් අඩංගු නොවීමයි. ඔබ භාවිතා කරන ORM එක මත ඔබට පහසු ආවරණයක් තිබේ නම්, එය සේවාවෙන් සේවාවට පිටපත් කිරීම ඉතා මිල අධික වේ.
අපගේ කණ්ඩායම වසම මත පදනම් වූ මෝස්තරයේ රසිකයෙක්, එබැවින් ලූනු ගෘහ නිර්මාණ ශිල්පය අපට ඉතා සුදුසු විය. අපගේ සේවාවන්හි පදනම වන්නේ දත්ත ප්‍රවේශ ස්තරය නොව, ව්යාපාරික තර්කය පමණක් අඩංගු වන සහ යටිතල පහසුකම් සමඟ කිසිදු සම්බන්ධයක් නොමැති වසම් තර්කනය සහිත එකලස් කිරීමකි. ඒ අතරම, රාමු සම්බන්ධ ගැටළු විසඳීම සඳහා අපට ස්වාධීනව වසම් එකලස් කිරීම වෙනස් කළ හැකිය.
මෙම අදියරේදී අපි අපගේ පළමු බරපතල ගැටලුවට මුහුණ දුන්නෙමු. සේවාවට එක් වසම් එකලස් කිරීමකට යොමු වීමට සිදු විය, අපට තර්කය ස්වාධීන කිරීමට අවශ්ය විය, සහ DRY මූලධර්මය අපට මෙහි විශාල බාධාවක් විය. සංවර්ධකයින්ට අනුපිටපත් වැළැක්වීම සඳහා අසල්වැසි එකලස්කිරීම් වලින් පන්ති නැවත භාවිතා කිරීමට අවශ්ය වූ අතර එහි ප්රතිඵලයක් ලෙස වසම් නැවත එකට සම්බන්ධ වීමට පටන් ගත්තේය. අපි ප්‍රතිඵල විශ්ලේෂණය කර සමහර විට ගැටලුව ඇත්තේ ප්‍රභව කේත ගබඩා උපාංගයේ ප්‍රදේශය තුළ බව තීරණය කළෙමු. සියලුම ප්‍රභව කේත අඩංගු විශාල ගබඩාවක් අප සතුව තිබුණි. සමස්ත ව්යාපෘතිය සඳහා විසඳුම දේශීය යන්ත්රයක් මත එකලස් කිරීම ඉතා අපහසු විය. එමනිසා, ව්‍යාපෘතියේ කොටස් සඳහා වෙනම කුඩා විසඳුම් නිර්මාණය කරන ලද අතර, ඒවාට පොදු හෝ වසම් එකලස් කිරීම් එකතු කිරීම සහ ඒවා නැවත භාවිතා කිරීම කිසිවෙකු තහනම් කළේ නැත. අපට මෙය කිරීමට ඉඩ නොදුන් එකම මෙවලම කේත සමාලෝචනයයි. නමුත් සමහර අවස්ථාවලදී එයද අසාර්ථක විය.
ඊට පස්සේ අපි වෙනම ගබඩා සහිත ආකෘතියකට යන්න පටන් ගත්තා. ව්‍යාපාර තර්කනය තවදුරටත් සේවාවෙන් සේවාවට ගලා නොයයි, වසම් සැබවින්ම ස්වාධීන වී ඇත. සීමා සහිත සන්දර්භයන් වඩාත් පැහැදිලිව සහාය දක්වයි. අපි යටිතල පහසුකම් පුස්තකාල නැවත භාවිතා කරන්නේ කෙසේද? අපි ඒවා වෙනම ගබඩාවකට වෙන් කර, පසුව ඒවා නුගෙට් පැකේජවලට තැබුවෙමු, එය අපි කෘතිම කර්මාන්තශාලාවට තැබුවෙමු. ඕනෑම වෙනසක් සමඟ, එකලස් කිරීම සහ ප්‍රකාශනය ස්වයංක්රීයව සිදු වේ.
අපගේ සේවාවන් අභ්‍යන්තර යටිතල පහසුකම් පැකේජ බාහිර ඒවා ලෙසම යොමු කිරීමට පටන් ගත්තේය. අපි නුගෙට් වෙතින් බාහිර පුස්තකාල බාගත කරමු. අපි මෙම පැකේජ තැබූ Artifactory සමඟ වැඩ කිරීමට, අපි පැකේජ කළමනාකරුවන් දෙදෙනෙකු භාවිතා කළෙමු. කුඩා ගබඩාවල අපි නුගෙට් ද භාවිතා කළෙමු. බහුවිධ සේවා සහිත ගබඩාවලදී, අපි මොඩියුල අතර වැඩි අනුවාද අනුකූලතාවයක් සපයන පැකට් භාවිතා කළෙමු.
මේ අනුව, මූල කේතය මත වැඩ කිරීමෙන්, ගෘහ නිර්මාණ ශිල්පය තරමක් වෙනස් කිරීමෙන් සහ ගබඩා වෙන් කිරීමෙන්, අපි අපගේ සේවාවන් වඩාත් ස්වාධීන කරමු.
යටිතල පහසුකම් ගැටළු
ක්ෂුද්ර සේවා වෙත යාමේ බොහෝ අවාසි යටිතල පහසුකම් සම්බන්ධ වේ. ඔබට ස්වයංක්‍රීය යෙදවීම අවශ්ය වනු ඇත, යටිතල පහසුකම් ක්රියාත්මක කිරීමට ඔබට නව පුස්තකාල අවශ්ය වනු ඇත.
පරිසරය තුළ අතින් ස්ථාපනය කිරීම
මුලදී, අපි පරිසරය සඳහා විසඳුම අතින් ස්ථාපනය කළෙමු. මෙම ක්‍රියාවලිය ස්වයංක්‍රීය කිරීම සඳහා, අපි CI/CD නල මාර්ගයක් නිර්මාණය කළෙමු. ව්යාපාරික ක්‍රියාවලීන්ගේ දෘෂ්ටි කෝණයෙන් අඛණ්ඩව යෙදවීම තවමත් අපට පිළිගත නොහැකි බැවින් අපි අඛණ්ඩ බෙදා හැරීමේ ක්‍රියාවලිය තෝරා ගත්තෙමු. එබැවින්, මෙහෙයුම සඳහා යැවීම බොත්තමක් භාවිතයෙන් සිදු කරනු ලබන අතර, පරීක්ෂා කිරීම සඳහා - ස්වයංක්රීයව.
අපි මූල කේත ගබඩා කිරීම සඳහා Atlassian, Bitbucket සහ ගොඩනැගීම සඳහා Bamboo භාවිතා කරමු. අපි Cake එකේ build scripts ලියන්න කැමතියි මොකද C# වගේම තමයි. සූදානම් කළ පැකේජ කෘතිම කර්මාන්ත ශාලාවට පැමිණෙන අතර ඇන්සිබල් ස්වයංක්රීයව පරීක්ෂණ සේවාදායකයන් වෙත පැමිණෙන අතර ඉන් පසුව ඒවා වහාම පරීක්ෂා කළ හැකිය.
වෙනම ලොග් කිරීම
එක් කාලයකදී, monolith හි එක් අදහසක් වූයේ හවුල් ලොග් කිරීම සැපයීමයි. තැටිවල ඇති තනි ලඝු-සටහන් සමඟ කළ යුතු දේ ද අපට තේරුම් ගැනීමට අවශ්ය විය. අපගේ ලොග් පෙළ ගොනු වලට ලියා ඇත. අපි සම්මත ELK තොගයක් භාවිතා කිරීමට තීරණය කළෙමු. අපි සෘජුවම සපයන්නන් හරහා ELK වෙත ලිව්වේ නැත, නමුත් අපි මෙම ලොග පසුව විග්‍රහ කළ හැකි වන පරිදි, සේවා නාමය එකතු කරමින්, පෙළ ලොග වෙනස් කර ඒවායේ හෝඩුවාව හැඳුනුම්පත හඳුනාගැනීමක් ලෙස ලිවීමට තීරණය කළෙමු.
Filebeat භාවිතයෙන්, අපට අපගේ ලොග් සේවාදායකයන්ගෙන් එකතු කර, පසුව ඒවා පරිවර්තනය කිරීමට, UI තුළ විමසුම් ගොඩනඟා ගැනීමට Kibana භාවිතා කිරීමට සහ සේවා අතර ඇමතුම ගිය ආකාරය බැලීමට අපට අවස්ථාව ලැබේ. Trace ID එක මේකට ගොඩක් උදවු වෙනවා.
අදාළ සේවාවන් පරීක්ෂා කිරීම සහ නිදොස් කිරීම
මුලදී, සංවර්ධනය වෙමින් පවතින සේවාවන් දෝශ නිරාකරණය කරන්නේ කෙසේදැයි අපට සම්පූර්ණයෙන් අවබෝධ නොවීය. මොනොලිත් සමඟ සෑම දෙයක්ම සරලයි; අපි එය දේශීය යන්ත්රයක් මත ධාවනය කළා. මුලදී ඔවුන් ක්ෂුද්ර සේවා සමඟද එසේ කිරීමට උත්සාහ කළ නමුත් සමහර විට එක් ක්ෂුද්ර සේවාවක් සම්පූර්ණයෙන්ම දියත් කිරීමට ඔබට තවත් කිහිපයක් දියත් කිරීමට අවශ්ය වන අතර මෙය අපහසු වේ. අපට දෝශ නිරාකරණය කිරීමට අවශ්ය සේවාව හෝ සේවාවන් පමණක් දේශීය යන්ත්‍රයෙන් තබන ආකෘතියකට යා යුතු බව අපට වැටහුණි. ප්‍රොඩ් සමඟ වින්‍යාසයට ගැළපෙන සේවාදායකයන්ගෙන් ඉතිරි සේවාවන් භාවිත කෙරේ. දෝශ නිරාකරණය කිරීමෙන් පසු, පරීක්ෂා කිරීමේදී, එක් එක් කාර්යය සඳහා, වෙනස් කරන ලද සේවාවන් පමණක් පරීක්ෂණ සේවාදායකයට නිකුත් කරනු ලැබේ. මේ අනුව, විසඳුම අනාගතයේදී නිෂ්පාදනයේ දිස්වන ආකාරයෙන් පරීක්ෂා කරනු ලැබේ.
සේවාවල නිෂ්පාදන අනුවාදයන් පමණක් ධාවනය කරන සේවාදායකයන් ඇත. මෙම සේවාදායකයන් සිදුවීම් වලදී, යෙදවීමට පෙර බෙදා හැරීම පරීක්ෂා කිරීමට සහ අභ්‍යන්තර පුහුණුව සඳහා අවශ්ය වේ.
අපි ජනප්‍රිය Specflow පුස්තකාලය භාවිතයෙන් ස්වයංක්‍රීය පරීක්ෂණ ක්‍රියාවලියක් එකතු කර ඇත. Ansible වෙතින් යෙදවූ වහාම NUnit භාවිතයෙන් පරීක්ෂණ ස්වයංක්රීයව ක්රියාත්මක වේ. කාර්ය ආවරණය සම්පූර්ණයෙන්ම ස්වයංක්‍රීය නම්, අතින් පරීක්ෂා කිරීම අවශ්ය නොවේ. සමහර විට අතිරේක අතින් පරීක්ෂණ තවමත් අවශ්ය වුවද. නිශ්චිත ගැටළුවක් සඳහා කුමන පරීක්ෂණ ක්රියාත්මක කළ යුතුද යන්න තීරණය කිරීමට අපි ජිරා හි ටැග් භාවිතා කරමු.
මීට අමතරව, බර පරීක්ෂා කිරීමේ අවශ්‍යතාවය වැඩි වී ඇත; මීට පෙර එය සිදු කරන ලද්දේ දුර්ලභ අවස්ථාවන්හිදී පමණි. අපි පරීක්ෂණ ක්රියාත්මක කිරීමට JMeter, ඒවා ගබඩා කිරීමට InfluxDB සහ ක්‍රියාවලි ප්‍රස්ථාර තැනීමට Grafana භාවිතා කරමු.
අප අත්කරගෙන ඇත්තේ කුමක්ද?
පළමුව, අපි "මුදා හැරීම" යන සංකල්පය ඉවත් කළෙමු. ව්යාපාරික ක්රියාවලීන් තාවකාලිකව කඩාකප්පල් කරමින්, නිෂ්පාදන පරිසරයක මෙම දැවැන්තය යෙදවූ විට මාස දෙකක බිහිසුණු නිකුතු ඉවත් වී ඇත. දැන් අපි සාමාන්‍යයෙන් සෑම දින 1,5 කට වරක් සේවා යොදවන්නෙමු, ඒවා අනුමත කිරීමෙන් පසු ක්රියාත්මක වන බැවින් ඒවා කාණ්ඩගත කරන්නෙමු.
අපගේ පද්ධතියේ මාරාන්තික අසාර්ථකත්වයන් නොමැත. අපි දෝෂයක් සහිත ක්ෂුද්ර සේවාවක් නිකුත් කළහොත්, ඒ හා සම්බන්ධ ක්‍රියාකාරීත්වය බිඳ වැටෙනු ඇති අතර අනෙකුත් සියලුම ක්‍රියාකාරීත්වයට බලපාන්නේ නැත. මෙය පරිශීලක අත්දැකීම බෙහෙවින් වැඩි දියුණු කරයි.
අපට යෙදවීමේ රටාව පාලනය කළ හැකිය. ඔබට අවශ්ය නම්, ඉතිරි විසඳුමෙන් වෙන් වෙන්ව සේවා කණ්ඩායම් තෝරාගත හැක.
මීට අමතරව, අපි වැඩිදියුණු කිරීම් විශාල පෝලිමක් සමඟ ගැටළුව සැලකිය යුතු ලෙස අඩු කර ඇත. අපට දැන් සමහර සේවා සමඟ ස්වාධීනව වැඩ කරන වෙනම නිෂ්පාදන කණ්ඩායම් ඇත. Scrum ක්‍රියාවලිය දැනටමත් මෙහි හොඳින් ගැලපේ. නිශ්චිත කණ්ඩායමකට කාර්යයන් පවරන වෙනම නිෂ්පාදන හිමිකරුවෙකු සිටිය හැක.
සාරාංශය
- සංකීර්ණ පද්ධති දිරාපත් කිරීම සඳහා ක්ෂුද්ර සේවා හොඳින් ගැලපේ. ක්‍රියාවලියේදී, අපගේ පද්ධතියේ ඇති දේ, එහි ඇති සීමිත සන්දර්භ මොනවාද, ඒවායේ මායිම් කොතැනද යන්න අපි තේරුම් ගැනීමට පටන් ගනිමු. මොඩියුල අතර වැඩිදියුණු කිරීම් නිවැරදිව බෙදා හැරීමට සහ කේත ව්‍යාකූලත්වය වැලැක්වීමට මෙය ඔබට ඉඩ සලසයි.
- ක්ෂුද්ර සේවා ආයතනික ප්‍රතිලාභ ලබා දෙයි. ඒවා බොහෝ විට කතා කරන්නේ ගෘහ නිර්මාණ ශිල්පය ලෙස පමණි, නමුත් ඕනෑම ගෘහ නිර්මාණ ශිල්පයක් අවශ්ය වන්නේ ව්යාපාරික අවශ්‍යතා විසඳීමට මිස තනිවම නොවේ. එමනිසා, Scrum දැන් ඉතා ජනප්‍රිය බැවින් කුඩා කණ්ඩායම්වල ගැටළු විසඳීම සඳහා ක්ෂුද්ර සේවා හොඳින් ගැලපෙන බව අපට පැවසිය හැකිය.
- වෙන්වීම පුනරාවර්තන ක්රියාවලියකි. ඔබට යෙදුමක් ගෙන එය ක්ෂුද්ර සේවාවලට බෙදිය නොහැක. ප්‍රති result ලය වූ නිෂ්පාදනය ක්‍රියාකාරී විය නොහැක. ක්ෂුද්ර සේවා කැප කිරීමේදී, පවතින උරුමය නැවත ලිවීම ප්‍රයෝජනවත් වේ, එනම්, එය අප කැමති කේතයක් බවට පත් කර ක්‍රියාකාරීත්වය සහ වේගය අනුව ව්යාපාරික අවශ්‍යතා වඩාත් හොඳින් සපුරාලයි.
කුඩා අවවාදයක්: ක්ෂුද්ර සේවා වෙත යාමේ පිරිවැය බෙහෙවින් සැලකිය යුතු ය. යටිතල පහසුකම් ප්‍රශ්නය තනියම විසඳන්න සෑහෙන කාලයක් ගියා. එබැවින් ඔබට විශේෂිත පරිමාණයක් අවශ්ය නොවන කුඩා යෙදුමක් තිබේ නම්, ඔබේ කණ්ඩායමේ අවධානය සහ කාලය සඳහා තරඟ කරන ගනුදෙනුකරුවන් විශාල සංඛ්‍යාවක් නොමැති නම්, අද ඔබට අවශ්ය ක්ෂුද්ර සේවා නොවිය හැකිය. එය තරමක් මිල අධිකයි. ඔබ ක්ෂුද්ර සේවා සමඟ ක්‍රියාවලිය ආරම්භ කරන්නේ නම්, ඔබ මොනොලිත් එකක් සංවර්ධනය කිරීමත් සමඟ එකම ව්යාපෘතිය ආරම්භ කරනවාට වඩා පිරිවැය මුලින් වැඩි වනු ඇත.
PS වඩාත් සංවේදී කතාවක් (සහ ඔබට පෞද්ගලිකව මෙන්) - අනුව .
වාර්තාවේ සම්පූර්ණ පිටපත මෙන්න.
මූලාශ්රය: www.habr.com