ඩෝඩෝ IS ගෘහ නිර්මාණ ශිල්පයේ ඉතිහාසය: මුල් මොනොලිත්

නැතහොත් මොනොලිත් සහිත සෑම අසතුටුදායක සමාගමක්ම තමන්ගේම ආකාරයෙන් අසතුටට පත්වේ.

Dodo IS පද්ධතියේ සංවර්ධනය 2011 දී Dodo Pizza ව්‍යාපාරය මෙන් වහාම ආරම්භ විය. එය පදනම් වූයේ ව්‍යාපාර ක්‍රියාවලීන්ගේ සම්පූර්ණ සහ සම්පූර්ණ ඩිජිටල්කරණය පිළිබඳ අදහස මත ය තමන්ගේ මත, එය 2011 දී පවා බොහෝ ප්‍රශ්න සහ සැකයන් ඇති කළේය. නමුත් දැන් වසර 9 ක් තිස්සේ අපි මෙම මාවත අනුගමනය කරමින් සිටිමු - ඒකලිතයකින් ආරම්භ වූ අපගේම සංවර්ධනය සමඟ.

මෙම ලිපිය “වාස්තු විද්‍යාව නැවත ලියන්නේ සහ එවැනි මහා පරිමාණ සහ දිගු කාලීන වෙනස්කම් කරන්නේ ඇයි?” යන ප්‍රශ්නවලට “පිළිතුරක්” වේ. පෙර ලිපිය වෙත ආපසු "ඩොඩෝ හි ඉතිහාසය ගෘහ නිර්මාණ ශිල්පය: පසුපස කාර්යාලයේ මාර්ගය". මම Dodo IS හි සංවර්ධනය ආරම්භ වූ ආකාරය, මුල් ගෘහ නිර්මාණ ශිල්පය පෙනුණේ කෙසේද, නව මොඩියුල දිස් වූ ආකාරය සහ විශාල පරිමාණයේ වෙනස්කම් සිදු කළ යුතු ගැටළු මොනවාද යන්න ආරම්භ කරමි.

ලිපි මාලාව "Dodo IS යනු කුමක්ද?" ගැන කියයි:

1. Dodo IS හි මුල් ඒකලිත (2011-2015). (ඔයා මෙහෙයි)

2. පසු කාර්යාල මාර්ගය: වෙනම කඳවුරු සහ බස් රථය.

3. සේවාදායක පැති මාර්ගය: පාදම මත මුහුණත (2016-2017). (ප්රගතියේ...)

4. සැබෑ ක්ෂුද්ර සේවා ඉතිහාසය. (2018-2019). (ප්රගතියේ...)

5. මොනොලිත් කැපීම සහ ගෘහ නිර්මාණ ශිල්පය ස්ථායීකරණය කිරීම අවසන් කර ඇත. (ප්රගතියේ...)

ආරම්භක ගෘහ නිර්මාණ ශිල්පය

2011 දී, ඩෝඩෝ අයිඑස් ගෘහ නිර්මාණ ශිල්පය මේ වගේ ය:

ගෘහ නිර්මාණ ශිල්පයේ පළමු මොඩියුලය වන්නේ ඇණවුම් පිළිගැනීමයි. ව්යාපාර ක්රියාවලිය වූයේ:

• සේවාදායකයා pizzeria අමතන්න;

• කළමනාකරු දුරකථනය අතට ගනී;

• දුරකථනයෙන් ඇණවුමක් පිළිගනී;

• ඇණවුම් භාරගැනීමේ අතුරුමුහුණතෙහි සමාන්තරව එය පුරවයි: සේවාදායකයා පිළිබඳ තොරතුරු, ඇණවුම් විස්තර පිළිබඳ දත්ත, බෙදා හැරීමේ ලිපිනය සැලකිල්ලට ගනී. 

තොරතුරු පද්ධතියේ අතුරු මුහුණත මේ වගේ දෙයක් ...

2011 ඔක්තෝබර් සිට පළමු අනුවාදය:

2012 ජනවාරි මාසයේදී තරමක් දියුණු විය

ඩෝඩෝ පීසා තොරතුරු පද්ධතිය බෙදාහැරීමේ පීසා ආපන ශාලාව

පළමු ඇණවුම ලබා ගැනීමේ මොඩියුලය සංවර්ධනය සඳහා සම්පත් සීමිත විය. අපට ඉක්මනින් හා කුඩා කණ්ඩායමක් සමඟ බොහෝ දේ කිරීමට සිදු විය. කුඩා කණ්ඩායමක් යනු සමස්ත අනාගත පද්ධතිය සඳහා අඩිතාලම දැමූ සංවර්ධකයින් දෙදෙනෙකි.

ඔවුන්ගේ පළමු තීරණය තාක්ෂණික තොගයේ ඉරණම තීරණය කළේය:

• ASP.NET MVC, C# භාෂාව මත පසුබිම. සංවර්ධකයින් dotnetchiki විය, මෙම තොගය ඔවුන්ට හුරුපුරුදු හා ප්රසන්න විය.

• Bootstrap සහ JQuery මත ඉදිරිපස: ස්වයං-ලිඛිත මෝස්තර සහ ස්ක්‍රිප්ට් මත පරිශීලක අතුරුමුහුණත්. 

• MySQL දත්ත සමුදාය: බලපත්‍ර ගාස්තු නැත, භාවිතයට පහසුය.

• වින්ඩෝස් සර්වර් හි සේවාදායකයන්, මක්නිසාද යත් .නෙට් විය හැක්කේ වින්ඩෝස් යටතේ පමණි (අපි මොනෝ ගැන සාකච්ඡා නොකරමු).

භෞතිකව, මේ සියල්ල "හොස්ටරයේ කැපවීම" තුළ ප්රකාශ විය. 

Intake Application Architecture ඇණවුම් කරන්න

එවිට සෑම දෙනාම දැනටමත් ක්ෂුද්‍ර සේවා ගැන කතා කරමින් සිටි අතර, SOA වසර 5 ක් විශාල ව්‍යාපෘතිවල භාවිතා කරන ලදී, උදාහරණයක් ලෙස, WCF 2006 දී නිකුත් කරන ලදී. නමුත් පසුව ඔවුන් විශ්වාසදායක සහ ඔප්පු කළ විසඳුමක් තෝරා ගත්හ.

මේ තියෙන්නේ.

Asp.Net MVC යනු Razor වේ, එය පෝරමයකින් හෝ සේවාලාභියෙකුගෙන් ඉල්ලීමක් මත, සේවාදායක විදැහුම්කරණය සමඟින් HTML පිටුවක් ලබා දෙයි. සේවාලාභියා මත, CSS සහ JS ස්ක්‍රිප්ට් දැනටමත් තොරතුරු ප්‍රදර්ශනය කරන අතර, අවශ්‍ය නම්, JQuery හරහා AJAX ඉල්ලීම් සිදු කරයි.

සේවාදායකයේ ඉල්ලීම් අවසන් වන්නේ *පාලක පන්තිවල වන අතර, එහිදී අවසාන HTML පිටුව සැකසීම සහ උත්පාදනය ක්‍රමය තුළ සිදු වේ. පාලකයන් *සේවා ලෙස හඳුන්වන තාර්කික ස්ථරයකට ඉල්ලීම් කරයි. සෑම සේවාවක්ම ව්‍යාපාරයේ යම් පැතිකඩකට අනුරූප විය:

• උදාහරණයක් ලෙස, DepartmentStructureService pizzerias, දෙපාර්තමේන්තු පිළිබඳ තොරතුරු ලබා දුන්නේය. දෙපාර්තමේන්තුවක් යනු තනි බලයලත් හිමිකරුවෙකු විසින් පවත්වාගෙන යනු ලබන පීසීරියා සමූහයකි.

• ReceivingOrdersService විසින් ඇණවුමේ සංයුතිය පිළිගෙන ගණනය කරන ලදී.

• සහ SmsService SMS යැවීමට API සේවාවන් ඇමතීමෙන් SMS යවන ලදී.

සේවා දත්ත ගබඩාවෙන් දත්ත සකසන ලද, ගබඩා කළ ව්‍යාපාරික තර්කනය. සෑම සේවාවකටම සුදුසු නම සහිත * නිධියක් හෝ කිහිපයක් තිබුණි. ඒවා දැනටමත් දත්ත ගබඩාවේ ගබඩා කර ඇති ක්‍රියා පටිපාටි සඳහා විමසුම් සහ සිතියම්කරුවන්ගේ ස්ථරයක් අඩංගු විය. ගබඩා තුළ ව්‍යාපාරික තර්කයක් තිබුණි, විශේෂයෙන් වාර්තා දත්ත නිකුත් කළ ඒවා තුළ. ORM භාවිතා නොකළ අතර, සෑම කෙනෙකුම අතින් ලියන ලද sql මත රඳා පැවතුනි. 

වසම් ආකෘතියේ සහ පොදු උපකාරක පන්තිවල ස්ථරයක් ද විය, උදාහරණයක් ලෙස, ඇණවුම ගබඩා කළ ඇණවුම් පන්තිය. එම ස්ථානයේම, ස්තරය තුළ, තෝරාගත් මුදල් අනුව දර්ශණ පෙළ පරිවර්තනය කිරීම සඳහා උපකාරකයෙක් විය.

මේ සියල්ල එවැනි ආකෘතියකින් නිරූපණය කළ හැකිය:

මාර්ගය ඇණවුම් කරන්න

එවැනි ඇණවුමක් නිර්මාණය කිරීම සඳහා සරල කළ ආරම්භක ක්රමයක් සලකා බලන්න.

මුලදී, වෙබ් අඩවිය ස්ථිතික විය. එහි මිල ගණන් තිබූ අතර ඉහළින් - දුරකථන අංකයක් සහ "ඔබට පීසා අවශ්‍ය නම් - අංකයට අමතා ඇණවුම් කරන්න." ඇණවුම් කිරීම සඳහා, අපි සරල ප්රවාහයක් ක්රියාත්මක කළ යුතුය: 

• සේවාලාභියා මිල ගණන් සහිත ස්ථිතික වෙබ් අඩවියකට ගොස් නිෂ්පාදන තෝරාගෙන වෙබ් අඩවියේ ලැයිස්තුගත කර ඇති අංකයට කතා කරයි.

• පාරිභෝගිකයා තමන්ට ඇණවුමට එක් කිරීමට අවශ්‍ය නිෂ්පාදන නම් කරයි.

• ඔහුගේ ලිපිනය සහ නම ලබා දෙයි.

• ක්රියාකරු ඇණවුම පිළිගනී.

• ඇණවුම පිළිගත් ඇණවුම් අතුරුමුහුණතෙහි දර්ශනය වේ.

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

පාරිභෝගිකයා නිෂ්පාදනය නම් කරයි, ක්රියාකරු ක්ලික් කරයි + නිෂ්පාදනයට යාබදව, සහ ඉල්ලීමක් සේවාදායකය වෙත යවනු ලැබේ. නිෂ්පාදිතය පිළිබඳ තොරතුරු දත්ත ගබඩාවෙන් පිටතට ඇද දමනු ලබන අතර භාණ්ඩය පිළිබඳ තොරතුරු කරත්තයට එකතු කරනු ලැබේ.

අදහස් දැක්වීම්. ඔව්, මෙහිදී ඔබට දත්ත සමුදායෙන් නිෂ්පාදිතය ඇද ගත නොහැක, නමුත් එය ඉදිරිපස සිට මාරු කරන්න. නමුත් පැහැදිලිකම සඳහා, මම දත්ත සමුදායෙන් මාර්ගය හරියටම පෙන්වමි. 

ඊළඟට, සේවාදායකයාගේ ලිපිනය සහ නම ඇතුළත් කරන්න. 

ඔබ "ඇණවුම සාදන්න" ක්ලික් කළ විට:

• ඉල්ලීම OrderController.SaveOrder() වෙත යවනු ලැබේ.

• අපි සැසියෙන් Cart ලබා ගනිමු, අපට අවශ්ය ප්රමාණයේ නිෂ්පාදන තිබේ.

• අපි කරත්තය සේවාදායකයා පිළිබඳ තොරතුරු සමඟ අතිරේකව සපයන අතර එය දත්ත ගබඩාවට සුරකින ලද ReceivingOrderService පන්තියේ AddOrder ක්‍රමයට යවන්නෙමු. 

• දත්ත ගබඩාවේ ඇණවුම, ඇණවුමේ සංයුතිය, සේවාදායකයා සමඟ වගු ඇති අතර ඒවා සියල්ලම සම්බන්ධ වේ.

• ඇණවුම් සංදර්ශක අතුරුමුහුණත ගොස් නවතම ඇණවුම් පිටතට ගෙන ඒවා ප්‍රදර්ශනය කරයි.

නව මොඩියුල

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

මොඩියුලයක් යනු කිසියම් පොදු ව්‍යාපාරික ඉලක්කයක් මගින් ඒකාබද්ධ වූ කාර්යයන් සමූහයකි. ඒ අතරම, ඔවුන් භෞතිකව එකම යෙදුමේ ඇත.

මොඩියුල පද්ධති බ්ලොක් ලෙස හැඳින්විය හැක. උදාහරණයක් ලෙස, මෙය වාර්තාකරණ මොඩියුලයක්, පරිපාලක අතුරුමුහුණත්, කුස්සියේ ආහාර ට්රැකර්, අවසරය. මේ සියල්ල විවිධ පරිශීලක අතුරුමුහුණත්, සමහරක් විවිධ දෘශ්‍ය ශෛලීන් ඇත. ඒ අතරම, සෑම දෙයක්ම එක් යෙදුමක, එක් ධාවන ක්රියාවලියක රාමුව තුළ පවතී. 

තාක්ෂණික වශයෙන්, මොඩියුල නිර්මාණය කර ඇත්තේ ප්‍රදේශයක් ලෙසය (එවැනි අදහසක් පවා පැවතුනි asp.net core) ඉදිරිපස, ආකෘති, මෙන්ම ඔවුන්ගේම පාලක පන්ති සඳහා වෙනම ගොනු විය. එහි ප්රතිඵලයක් වශයෙන්, පද්ධතිය මෙයින් පරිවර්තනය විය ...

...මෙයට:

සමහර මොඩියුල සම්පූර්ණයෙන්ම වෙනම ක්‍රියාකාරීත්වයක් හේතුවෙන් සහ අර්ධ වශයෙන් තරමක් වෙන් වූ, වැඩි අවධානයක් යොමු කළ සංවර්ධනයක් හේතුවෙන්, වෙනම අඩවි (ක්‍රියාත්මක කළ හැකි ව්‍යාපෘතිය) මගින් ක්‍රියාත්මක වේ. මෙය:

• අඩවිය - පළමු අනුවාදය වෙබ් අඩවිය dodopizza.ru.

• අපනයන: 1C සඳහා Dodo IS වෙතින් වාර්තා උඩුගත කිරීම. 

• පුද්ගලික - සේවකයාගේ පුද්ගලික ගිණුම. එය වෙනමම සංවර්ධනය කරන ලද අතර එහි ඇතුල් වීමේ ස්ථානය සහ වෙනම සැලසුමක් ඇත.

• fs - ස්ථිතික සත්කාරක ව්‍යාපෘතියක්. පසුව අපි එයින් ඉවත් වූ අතර, සියලු ස්ථිතික Akamai CDN වෙත ගෙන ගියෙමු. 

ඉතිරි කොටස් BackOffice යෙදුමේ විය. 

නම පැහැදිලි කිරීම:

• මුදල් අයකැමි - ආපනශාලා අයකැමි.

• ShiftManager - "Shift Manager" භූමිකාව සඳහා අතුරුමුහුණත්: pizzeria විකුණුම් පිළිබඳ මෙහෙයුම් සංඛ්යා ලේඛන, නැවතුම් ලැයිස්තුවේ නිෂ්පාදන තැබීමේ හැකියාව, අනුපිළිවෙල වෙනස් කරන්න.

• OfficeManager - "Pizzeria Manager" සහ "Franchisee" භූමිකාවන් සඳහා අතුරු මුහුණත්. පීසීරියා පිහිටුවීම, එහි ප්‍රසාද ප්‍රවර්ධන, සේවකයින් ලබා ගැනීම සහ වැඩ කිරීම, වාර්තා සඳහා එකතු කරන ලද කාර්යයන් මෙන්න.

• PublicScreens - පීසීරියා වල එල්ලෙන රූපවාහිනී සහ ටැබ්ලට් සඳහා අතුරුමුහුණත්. රූපවාහිනී මෙනු, වෙළඳ ප්‍රචාරණ තොරතුරු, බෙදා හැරීමේදී ඇණවුම් තත්ත්වය පෙන්වයි. 

ඔවුන් පොදු සේවා ස්ථරයක්, පොදු Dodo.Core වසම් පන්ති වාරණයක් සහ පොදු පදනමක් භාවිතා කළහ. සමහර විට ඔවුන් තවමත් එකිනෙකා වෙත සංක්රමණය දිගේ ගමන් කළ හැකිය. dodopizza.ru හෝ personal.dodopizza.ru වැනි තනි අඩවි ඇතුළුව, සාමාන්‍ය සේවා වෙත ගියේය.

නව මොඩියුල දර්ශනය වූ විට, අපි දැනටමත් නිර්මාණය කර ඇති සේවා කේතය, ගබඩා කර ඇති ක්‍රියා පටිපාටි සහ දත්ත ගබඩාවේ වගු උපරිම ලෙස නැවත භාවිතා කිරීමට උත්සාහ කළෙමු. 

පද්ධතියේ සාදන ලද මොඩියුලවල පරිමාණය පිළිබඳ වඩා හොඳ අවබෝධයක් සඳහා, සංවර්ධන සැලසුම් සහිත 2012 සිට රූප සටහනක් මෙන්න:

2015 වන විට, සියල්ල සිතියමෙහි තිබූ අතර ඊටත් වඩා නිෂ්පාදනය විය.

• ඇණවුම පිළිගැනීම සම්බන්ධතා මධ්‍යස්ථානයේ වෙනම කොටසකට වර්ධනය වී ඇත, එහිදී ඇණවුම ක්‍රියාකරු විසින් පිළිගනු ලැබේ.

• මෙනු සහ තොරතුරු සහිත පොදු තිර පීසාරියාවල එල්ලා තිබුණි.

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

• බෙදාහැරීමේ ඒකකය වෙනම බෙදාහැරීමේ චෙක්අවුට් එකක් බවට පත් වූ අතර, එහිදී කලින් මාරුව ලබා ගත් කුරියර් වෙත ඇණවුම නිකුත් කරන ලදී. වැටුප් ගණනය කිරීම සඳහා ඔහුගේ වැඩ කරන කාලය සැලකිල්ලට ගන්නා ලදී. 

සමාන්තරව, 2012 සිට 2015 දක්වා, සංවර්ධකයින් 10 කට වඩා පෙනී සිටි අතර, පීසීරියා 35 ක් විවෘත කර, පද්ධතිය රුමේනියාවට යොදවා එක්සත් ජනපදයේ අලෙවිසැල් විවෘත කිරීමට සූදානම් විය. සංවර්ධකයින් තවදුරටත් සියලු කාර්යයන් සමඟ කටයුතු නොකළ නමුත් කණ්ඩායම් වලට බෙදා ඇත. එක් එක් පද්ධතියේ තමන්ගේම කොටසෙහි විශේෂිත වේ. 

ගැටළු

ගෘහ නිර්මාණ ශිල්පය නිසා ඇතුළුව (නමුත් පමණක් නොවේ).

පදනමේ අවුල්

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

නමුත් වසර 4 ක සංවර්ධන කාලය තුළ, දත්ත සමුදායේ වගු 600 ක්, ගබඩා කර ඇති ක්‍රියා පටිපාටි 1500 ක් පමණ ඇති අතර, ඒවායින් බොහොමයක් තර්කානුකූලව ද ඇත. අහෝ, MySQL සමඟ වැඩ කිරීමේදී ගබඩා කර ඇති ක්‍රියා පටිපාටි වැඩි වාසියක් ගෙන එන්නේ නැත. ඒවා පදනම මගින් හැඹිලිගත නොකෙරෙන අතර, ඒවායේ තර්කනය ගබඩා කිරීම සංවර්ධනය සහ දෝෂහරණය කිරීම සංකීර්ණ කරයි. කේතය නැවත භාවිතා කිරීම ද අපහසු වේ.

බොහෝ වගු වල සුදුසු දර්ශක නොතිබුණි, කොහේ හරි, ඊට පටහැනිව, දර්ශක ගොඩක් තිබුනා, එය ඇතුල් කිරීමට අපහසු විය. වගු 20 ක් පමණ වෙනස් කිරීමට අවශ්ය විය - ඇණවුමක් සෑදීමේ ගනුදෙනුව තත්පර 3-5 ක් පමණ ගත විය හැකිය. 

වගු වල දත්ත සෑම විටම වඩාත්ම සුදුසු ආකාරයෙන් නොතිබුණි. කොහේ හරි denormalization කිරීමට අවශ්ය විය. නිතිපතා ලැබෙන දත්ත වලින් කොටසක් XML ව්‍යුහයක ස්වරූපයෙන් තීරුවක විය, මෙය ක්‍රියාත්මක කිරීමේ කාලය වැඩි කර, විමසුම් දිගු කර සංවර්ධනය සංකීර්ණ කළේය.

එකම වගු සඳහා ඉතා නිෂ්පාදනය කරන ලදී විෂම ඉල්ලීම්. ඉහත සඳහන් කළ වගුව මෙන් ජනප්‍රිය වගු විශේෂයෙන් දුක් විඳිති. නියෝග හෝ මේස පීසා සාප්පුව. කුස්සියේ, විශ්ලේෂණවල මෙහෙයුම් අතුරුමුහුණත් ප්රදර්ශනය කිරීමට ඒවා භාවිතා කරන ලදී. වෙනත් වෙබ් අඩවියක් ඔවුන් හා සම්බන්ධ විය (dodopizza.ru), ඕනෑම අවස්ථාවක හදිසියේ ඉල්ලීම් ගොඩක් පැමිණිය හැකි තැන. 

දත්ත එකතු කර නැත සහ බොහෝ ගණනය කිරීම් පාදම භාවිතා කරමින් පියාසර කරන ලදී. මෙය අනවශ්‍ය ගණනය කිරීම් සහ අමතර බරක් නිර්මාණය කළේය. 

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

කේතයේ ඒකාබද්ධතාවය සහ අපැහැදිලි වීම

ඔවුන්ගේ ව්‍යාපාරයේ කොටසකට වගකිව යුතු මොඩියුල එය අවංකව කළේ නැත. ඔවුන්ගෙන් සමහරක් භූමිකාවන් සඳහා කාර්යයන් අනුපිටපත් කර ඇත. නිදසුනක් වශයෙන්, තම නගරයේ ජාලයේ අලෙවිකරණ ක්‍රියාකාරකම් සඳහා වගකිව යුතු දේශීය අලෙවිකරුවෙකුට "පරිපාලක" අතුරුමුහුණත (ප්‍රවර්ධනයන් නිර්මාණය කිරීමට) සහ "කාර්යාල කළමනාකරු" අතුරුමුහුණත (ව්‍යාපාරයට උසස්වීම්වල බලපෑම බැලීමට) භාවිතා කිරීමට සිදු විය. ඇත්ත වශයෙන්ම, මොඩියුල දෙකම ඇතුළත ප්‍රසාද ප්‍රවර්ධන සමඟ වැඩ කළ එකම සේවාව භාවිතා කරන ලදී.

සේවා (එක් මොනොලිතික් විශාල ව්‍යාපෘතියක් තුළ ඇති පන්ති) ඔවුන්ගේ දත්ත පොහොසත් කිරීමට එකිනෙකා ඇමතීමට හැකිය.

දත්ත ගබඩා කරන ආදර්ශ පන්ති සමඟ, කේතයේ වැඩ වෙනස් ආකාරයකින් සිදු කරන ලදී. අවශ්‍ය ක්ෂේත්‍ර සඳහන් කිරීමට හැකි වන පරිදි ඉදිකිරීම්කරුවන් කොහේ හරි තිබුණි. කොතැනක හෝ පොදු දේපල හරහා මෙය සිදු කරන ලදී. ඇත්ත වශයෙන්ම, දත්ත සමුදායෙන් දත්ත ලබා ගැනීම සහ පරිවර්තනය කිරීම විවිධාකාර විය. 

තාර්කික වූයේ පාලකයන්ගේ හෝ සේවා පන්තිවල ය. 

මේවා සුළු ගැටළු බව පෙනේ, නමුත් ඒවා බොහෝ සෙයින් සංවර්ධනය මන්දගාමී වූ අතර ගුණාත්මක භාවය අඩු කර, අස්ථාවරත්වය සහ දෝෂ ඇති කරයි. 

විශාල සංවර්ධනයක සංකීර්ණත්වය

සංවර්ධනය තුළම දුෂ්කරතා ඇති විය. පද්ධතියේ විවිධ කොටස් සෑදීමට අවශ්ය වූ අතර, සමාන්තරව. එක් එක් සංරචකයේ අවශ්‍යතා තනි කේතයකට සවි කිරීම වඩ වඩාත් දුෂ්කර විය. සියලුම සංරචක එකවර එකඟ කර සතුටු කිරීම පහසු නොවීය. විශේෂයෙන්ම පාදම සහ ඉදිරිපස සම්බන්ධයෙන් තාක්‍ෂණයේ සීමාවන් මෙයට එකතු විය. විශේෂයෙන්ම සේවාදායක සේවා (වෙබ් අඩවිය) සම්බන්ධයෙන් ඉහළ මට්ටමේ රාමු වෙත jQuery අත්හැරීම අවශ්‍ය විය.

පද්ධතියේ සමහර කොටස් වලදී, මේ සඳහා වඩාත් සුදුසු දත්ත සමුදායන් භාවිතා කළ හැකිය.. උදාහරණයක් ලෙස, පසුව අපට ඇණවුම් කූඩයක් ගබඩා කිරීම සඳහා Redis සිට CosmosDB වෙත මාරු වීමේ අවස්ථාව තිබුණි. 

ඔවුන්ගේ ක්ෂේත්‍රයට සම්බන්ධ කණ්ඩායම් සහ සංවර්ධකයින්ට පැහැදිලිවම ඔවුන්ගේ සේවාවන් සඳහා වැඩි ස්වයං පාලනයක් අවශ්‍ය විය, සංවර්ධනය සහ ප්‍රවාහය යන දෙඅංශයෙන්ම. ගැටුම් ඒකාබද්ධ කරන්න, ගැටළු නිදහස් කරන්න. සංවර්ධකයින් 5 දෙනෙකු සඳහා මෙම ගැටළුව නොවැදගත් නම්, 10 දෙනෙකු සමඟ, සහ ඊටත් වඩා සැලසුම් කළ වර්ධනය සමඟ, සියල්ල වඩාත් බරපතල වනු ඇත. ඉදිරියෙන් ජංගම යෙදුමක් සංවර්ධනය කිරීමට සිදු විය (එය 2017 දී ආරම්භ වූ අතර 2018 දී එය විය. විශාල වැටීම). 

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

එවැනි මොනොලිතික්-මොඩියුලර් ගෘහ නිර්මාණ ශිල්පයක රාමුව තුළ මෙම වැරදි සහ ගැටළු වළක්වා ගැනීමට බොහෝ විට හැකි වනු ඇත: වගකීම් බෙදීමක් කරන්න, කේතය සහ දත්ත සමුදාය යන දෙකම නැවත සකස් කරන්න, පැහැදිලිව එකිනෙකාගෙන් ස්ථර වෙන් කරන්න, සෑම දිනකම ගුණාත්මකභාවය නිරීක්ෂණය කරන්න. නමුත් තෝරාගත් වාස්තුවිද්‍යාත්මක විසඳුම් සහ පද්ධතියේ ක්‍රියාකාරීත්වයේ වේගවත් ව්‍යාප්තිය කෙරෙහි අවධානය යොමු කිරීම ස්ථාවරත්වය සම්බන්ධයෙන් ගැටළු ඇති කළේය.

මනසේ බලය බ්ලොග් අඩවිය අවන්හල්වල මුදල් ලේඛන තැබූ ආකාරය

පීසීරියා ජාලයේ වර්ධනය (සහ පැටවීම) එකම වේගයකින් දිගටම පැවතුනේ නම්, ටික වේලාවකට පසු පද්ධතිය ඉහළ නොයන ලෙස වැටීම් සිදුවනු ඇත. 2015 වන විට අපට මුහුණ දීමට පටන් ගත් ගැටළු හොඳින් නිරූපණය කරයි, මෙන්න එවැනි කතාවක්. 

බ්ලොග් එකේ"මනසේ බලය” යනු සමස්ත ජාලයේ වර්ෂය සඳහා ආදායම් පිළිබඳ දත්ත පෙන්වන විජට් එකකි. විජට් මෙම දත්ත සපයන Dodo public API වෙත ප්‍රවේශ විය. මෙම සංඛ්‍යාලේඛනය දැනට ලබා ගත හැකිය http://dodopizzastory.com/. විජට් සෑම පිටුවකම පෙන්වන අතර සෑම තත්පර 20කට වරක් ටයිමරයක ඉල්ලීම් කළේය. ඉල්ලීම api.dodopizza.ru වෙත ගොස් ඉල්ලා සිටියේ:

• ජාලයේ පීසීරියා සංඛ්යාව;

• වර්ෂය ආරම්භයේ සිට මුළු ජාල ආදායම;

• අද සඳහා ආදායම.

ආදායම පිළිබඳ සංඛ්‍යාලේඛන ඉල්ලීම කෙලින්ම දත්ත ගබඩාවට ගොස් ඇණවුම් පිළිබඳ දත්ත ඉල්ලා සිටීම, පියාසර කිරීම පිළිබඳ දත්ත එකතු කිරීම සහ මුදල ලබා දීම ආරම්භ විය. 

ආපනශාලා වල මුදල් මේස එකම ඇණවුම් මේසය වෙත ගොස්, අද සඳහා ලැබුණු ඇණවුම් ලැයිස්තුවක් බාගෙන, එයට නව ඇණවුම් එකතු විය. මුදල් රෙජිස්ටර් සෑම තත්පර 5කට වරක් හෝ පිටු නැවුම් කිරීමකින් තම ඉල්ලීම් කළේය.

රූප සටහන මෙසේ දිස් විය:

එක් වැටීමකදී, Fyodor Ovchinnikov ඔහුගේ බ්ලොග් අඩවියේ දිගු හා ජනප්රිය ලිපියක් ලිවීය. ගොඩක් අය බ්ලොග් එකට ඇවිත් හැමදේම හොඳට කියවන්න පටන් ගත්තා. ආපු එක එක්කෙනා ලිපිය කියවද්දි ආදායම් විජට් එක හරියට වැඩ කරලා තත්පර 20කට සැරයක් API එක ඉල්ලුවා.

API විසින් දම්වැලෙහි ඇති සියලුම pizzeria සඳහා වසරේ ආරම්භයේ සිට සියලුම ඇණවුම්වල එකතුව ගණනය කිරීමට ගබඩා කර ඇති ක්‍රියා පටිපාටියක් ලෙස හැඳින්වේ. එකතු කිරීම ඉතා ජනප්‍රිය ඇණවුම් වගුව මත පදනම් විය. එකල විවෘතව ඇති සියලුම අවන්හල්වල සියලුම මුදල් මේස එයට යයි. මුදල් මේස ප්‍රතිචාර දැක්වීම නැවැත්වීය, ඇණවුම් භාර නොගන්නා ලදී. ඒවා ද වෙබ් අඩවියෙන් පිළිගත්තේ නැත, ට්රැකර් එකේ පෙනී සිටියේ නැත, මාරු කළමණාකරුට ඔහුගේ අතුරු මුහුණතේ ඒවා දැකීමට නොහැකි විය. 

මෙය එකම කතාව නොවේ. 2015 වැටීම වන විට, සෑම සිකුරාදා දිනකම පද්ධතියේ බර ඉතා වැදගත් විය. අපි කිහිප වතාවක්ම පොදු API අක්‍රිය කළ අතර, වරක්, කිසිවක් උදව් නොකළ නිසා, අපට වෙබ් අඩවිය අක්‍රිය කිරීමට පවා සිදු විය. අධික බරක් යටතේ වසා දැමීමේ නියෝගයක් සහිත සේවා ලැයිස්තුවක් පවා විය.

මෙතැන් සිට, බර පැටවීම සහ පද්ධතිය ස්ථාවර කිරීම සඳහා වන අපගේ අරගලය ආරම්භ වේ (2015 සරත් සෘතුවේ සිට 2018 සරත් සෘතුවේ දක්වා). එතකොට තමයි ඒක වුනේ"මහා වැටීම". තවද, සමහර විට අසාර්ථකවීම් ද සිදු විය, සමහර ඒවා ඉතා සංවේදී විය, නමුත් අස්ථාවරත්වයේ සාමාන්‍ය කාල පරිච්ඡේදය දැන් සම්මත වී ඇති බව සැලකිය හැකිය.

වේගවත් ව්‍යාපාර වර්ධනයක්

එය වහාම කළ නොහැකි වූයේ ඇයි? පහත ප්‍රස්ථාර දෙස බලන්න.

එසේම 2014-2015 දී රුමේනියාවේ විවෘත කිරීමක් සිදු වූ අතර ඇමරිකා එක්සත් ජනපදයේ විවෘත කිරීමක් සූදානම් වෙමින් පවතී.

ජාලය ඉතා ඉක්මණින් වර්ධනය විය, නව රටවල් විවෘත විය, පීසීරියා වල නව ආකෘති දර්ශනය විය, උදාහරණයක් ලෙස, ආහාර මළුවෙහි පීසීරියා විවෘත කරන ලදී. මේ සියල්ල Dodo IS ක්‍රියාකාරකම්වල ව්‍යාප්තිය කෙරෙහි විශේෂයෙන් සැලකිය යුතු අවධානයක් අවශ්‍ය විය. මෙම සියලු කාර්යයන් නොමැතිව, මුළුතැන්ගෙයෙහි ලුහුබැඳීමකින් තොරව, පද්ධතියේ නිෂ්පාදන සහ පාඩු ගණනය කිරීමකින් තොරව, ආහාර උසාවි ශාලාවේ නියෝගයක් නිකුත් කිරීම ප්‍රදර්ශනය කිරීමෙන්, අපි “නිවැරදි” ගෘහ නිර්මාණ ශිල්පය සහ “නිවැරදි” ප්‍රවේශය ගැන කතා කරන්නේ නැත. දැන් සංවර්ධනය.

ගෘහ නිර්මාණ ශිල්පය කාලානුරූපව සංශෝධනය කිරීමට සහ සාමාන්යයෙන් තාක්ෂණික ගැටළු කෙරෙහි අවධානය යොමු කිරීමට තවත් බාධාවක් වූයේ 2014 අර්බුදයයි. විශේෂයෙන්ම ඩෝඩෝ පීසා වැනි තරුණ ව්‍යාපාරයක් සඳහා කණ්ඩායම්වලට වර්ධනය වීමට ඇති අවස්ථාවන්ට මෙවැනි දේවල් දැඩි ලෙස බලපෑවේය.

උදව් කළ ඉක්මන් විසඳුම්

ගැටලුවලට විසඳුම් අවශ්‍යයි. සාම්ප්‍රදායිකව, විසඳුම් කණ්ඩායම් 2 කට බෙදිය හැකිය:

• ගින්න නිවා දමා කුඩා ආරක්ෂාවක් ලබා දෙන සහ අපට වෙනස් කිරීමට කාලය මිල දී ගන්නා වේගවත් ඒවා.

• පද්ධතිමය සහ, එබැවින්, දිගු. මොඩියුල ගණනාවක් ප්‍රතිනිර්මාණය කිරීම, මොනොලිතික් ගෘහ නිර්මාණ ශිල්පයක් වෙනම සේවා වලට බෙදීම (ඒවායින් බොහොමයක් ක්ෂුද්‍ර, නමුත් සාර්ව සේවා නොවේ, ඒ ගැන යමක් තිබේ. Andrey Morevskiy ගේ වාර්තාව). 

ඉක්මන් වෙනස්කම් වල වියළි ලැයිස්තුව පහත පරිදි වේ:

මූලික මාස්ටර් පරිමාණය කරන්න

ඇත්ත වශයෙන්ම, බඩු සමඟ කටයුතු කිරීමට සිදු කරන පළමු දෙය නම් සේවාදායකයේ ධාරිතාව වැඩි කිරීමයි. මෙය ප්‍රධාන දත්ත සමුදාය සඳහා සහ වෙබ් සේවාදායකයන් සඳහා සිදු කරන ලදී. අහෝ, මෙය කළ හැක්කේ යම් සීමාවක් දක්වා පමණි, එවිට එය මිල අධික වේ.

2014 සිට, අපි Azure වෙත පදිංචියට ගියෙමු, අපි මෙම මාතෘකාව ගැන එවකට ලිපියේ ලිව්වෙමු.Microsoft Azure Cloud භාවිතයෙන් Dodo Pizza Pizza ලබා දෙන ආකාරය". නමුත් පදනම සඳහා සේවාදායකයේ වැඩි කිරීම් මාලාවකින් පසුව, ඔවුන් පිරිවැයට එරෙහිව පැමිණියහ. 

කියවීම සඳහා මූලික අනුරූ

පදනම සඳහා අනුරූ දෙකක් සාදන ලදී:

ReadReplica යොමු ඉල්ලීම් සඳහා. එය නාමාවලි, වර්ගය, නගරය, වීදිය, පීසාරියා, නිෂ්පාදන (සෙමෙන් වෙනස් වූ වසම) සහ කුඩා ප්‍රමාදයක් පිළිගත හැකි අතුරු මුහුණත් කියවීමට භාවිතා කරයි. මෙම අනුරූවලින් 2ක් තිබුනා, අපි ස්වාමිවරුන් මෙන් ම ඒවායේ ඇති බව සහතික කළෙමු.

වාර්තා ඉල්ලීම් සඳහා ReadReplica. මෙම දත්ත සමුදාය ලබා ගැනීමේ හැකියාව අඩුයි, නමුත් සියලුම වාර්තා එයට ගියේය. විශාල දත්ත නැවත ගණනය කිරීම් සඳහා ඔවුන්ට දැඩි ඉල්ලීම් කිරීමට ඉඩ දෙන්න, නමුත් ඒවා ප්‍රධාන දත්ත ගබඩාවට සහ මෙහෙයුම් අතුරුමුහුණත්වලට බලපාන්නේ නැත. 

කේතය තුළ හැඹිලි

කේතයේ කොතැනකවත් හැඹිලි නොමැත (සියල්ලම). මෙය පූරණය කරන ලද දත්ත සමුදායට අමතර, සෑම විටම අවශ්‍ය නොවන ඉල්ලීම් වලට හේතු විය. හැඹිලි මුලින්ම මතකයේ සහ බාහිර හැඹිලි සේවාවක, එනම් Redis විය. කාලය අනුව සෑම දෙයක්ම අවලංගු විය, සැකසුම් කේතයේ දක්වා ඇත.

බහු පසුබිම් සේවාදායකයන්

වැඩි වූ වැඩ බර හැසිරවීමට යෙදුමේ පසුතලය ද පරිමාණය කිරීමට අවශ්‍ය විය. එක් iis-server එකකින් පොකුරක් සෑදීමට අවශ්ය විය. අපි නැවත කාලසටහන් කර ඇත යෙදුම් සැසිය මතකයේ සිට RedisCache දක්වා, රවුන්ඩ් රොබින් සහිත සරල පැටවුම් සමතුලිතයක් පිටුපස සේවාදායකයන් කිහිපයක් සෑදීමට හැකි විය. මුලදී, හැඹිලි සඳහා එකම රෙඩිස් භාවිතා කරන ලදී, පසුව එය කිහිපයකට බෙදා ඇත. 

එහි ප්රතිඵලයක් වශයෙන්, ගෘහ නිර්මාණ ශිල්පය වඩාත් සංකීර්ණ වී ඇත ...

නමුත් යම් ආතතියක් ඉවත් විය.

ඉන්පසු අප විසින් භාර ගන්නා ලද පටවන ලද සංරචක නැවත සිදු කිරීම අවශ්‍ය විය. අපි මේ ගැන ඊළඟ කොටසින් කතා කරමු.

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