Эсвэл цултай аз жаргалгүй компани бүр өөр өөрийнхөөрөө аз жаргалгүй байдаг.
Dodo IS системийг хөгжүүлэх ажил 2011 онд Dodo Pizza бизнес шиг шууд эхэлсэн. Энэ нь бизнесийн үйл явцыг бүрэн, бүрэн дижитал болгох санаан дээр үндэслэсэн юм , тэр үед ч гэсэн 2011 онд олон асуулт, эргэлзээ төрүүлж байсан. Харин бид 9 жил энэ замаар явж байна - цул хөгжлөөр эхэлсэн.
Энэхүү нийтлэл нь “Яагаад архитектурыг дахин бичиж, ийм өргөн цар хүрээтэй, урт хугацааны өөрчлөлтийг хийх ёстой вэ?” гэсэн асуултын "хариулт" юм. өмнөх нийтлэл рүү буцах . Би Dodo IS-ийн хөгжил хэрхэн эхэлсэн, анхны архитектур хэрхэн харагдаж байсан, шинэ модулиуд хэрхэн гарч ирсэн, ямар асуудлуудаас болж томоохон хэмжээний өөрчлөлт хийх шаардлагатай болсон талаар ярих болно.
Цуврал нийтлэл "Додо IS гэж юу вэ?" тухай өгүүлдэг:
-
Додо IS дахь эртний цул (2011-2015). (чи энд байна)
-
.
-
Үйлчлүүлэгчийн хажуугийн зам: суурийн дээгүүр фасад (2016-2017). (Явж байна...)
-
Бодит микро үйлчилгээний түүх. (2018-2019). (Явж байна...)
-
Цул хөрөөдөж, архитектурыг тогтворжуулах ажил дууссан. (Явж байна...)
Анхны архитектур
2011 онд Dodo IS архитектур дараах байдалтай байв.
Архитектурын эхний модуль бол захиалга хүлээн авах явдал юм. Бизнесийн үйл явц нь:
-
үйлчлүүлэгч пиццаны газар руу залгадаг;
-
менежер утсаа авдаг;
-
утсаар захиалга хүлээн авдаг;
-
захиалга хүлээн авах интерфейстэй зэрэгцэн бөглөнө: энэ нь үйлчлүүлэгчийн талаарх мэдээлэл, захиалгын дэлгэрэнгүй мэдээлэл, хүргэх хаягийг харгалзан үздэг.
Мэдээллийн системийн интерфейс иймэрхүү харагдаж байв ...
2011 оны XNUMX-р сарын анхны хувилбар:
Эхний захиалга авах модулийг боловсруулах нөөц хязгаарлагдмал байсан. Бид маш их зүйлийг хурдан, цомхон багтай хийх ёстой байсан. Жижиг баг бол ирээдүйн бүх системийн суурийг тавьсан 2 хөгжүүлэгч юм.
Тэдний анхны шийдвэр нь технологийн стекийн хувь заяаг тодорхойлсон.
-
ASP.NET MVC, C# хэл дээрх backend. Хөгжүүлэгчид нь dotnetchiki байсан бөгөөд энэ стек нь тэдэнд танил, тааламжтай байсан.
-
Bootstrap болон JQuery дээрх Frontend: өөрөө бичсэн загвар болон скрипт дээрх хэрэглэгчийн интерфейс.
-
MySQL мэдээллийн сан: лицензийн зардалгүй, хэрэглэхэд хялбар.
-
Windows Server дээрх серверүүд, учир нь .NET нь зөвхөн Windows дээр байж болох юм (бид Mono-г хэлэлцэхгүй).
Бие махбодийн хувьд энэ бүгдийг "хотын эзэнд зориулсан ёслол" дээр илэрхийлсэн.
Захиалга авах програмын архитектур
Дараа нь хүн бүр микро үйлчилгээний талаар аль хэдийн ярьж байсан бөгөөд SOA том төслүүдэд 5 жилийн турш ашиглагдаж байсан, жишээлбэл, WCF 2006 онд гарсан. Гэвч дараа нь тэд найдвартай, батлагдсан шийдлийг сонгосон.
Энэ байна.
Asp.Net MVC нь маягт эсвэл үйлчлүүлэгчийн хүсэлтээр HTML хуудсыг серверийн дүрслэлээр гаргадаг Razor юм. Үйлчлүүлэгч дээр CSS болон JS скриптүүд аль хэдийн мэдээллийг харуулдаг бөгөөд шаардлагатай бол JQuery-ээр дамжуулан AJAX хүсэлтийг гүйцэтгэдэг.
Сервер дээрх хүсэлтүүд нь *Controller ангиудад дуусдаг бөгөөд эцсийн HTML хуудсыг боловсруулах, үүсгэх нь тухайн аргад явагддаг. Хянагч нар *Үйлчилгээ гэж нэрлэгддэг логикийн давхаргад хүсэлт гаргадаг. Үйлчилгээ бүр нь бизнесийн зарим талтай нийцэж байв:
-
Жишээлбэл, DepartmentStructureService нь пицца, хэлтсийн талаар мэдээлэл өгсөн. Хэлтэс гэдэг нь нэг франчайз хүлээн авагчийн удирддаг пиццеруудын бүлэг юм.
-
ReceivingOrdersService нь захиалгын бүрэлдэхүүнийг хүлээн авч тооцоолсон.
-
SmsService нь SMS илгээхийн тулд API үйлчилгээг дуудаж SMS илгээсэн.
Үйлчилгээнүүд нь мэдээллийн сангаас өгөгдлийг боловсруулж, бизнесийн логикийг хадгалдаг. Үйлчилгээ бүр нь тохирох нэртэй нэг буюу хэд хэдэн *Repositories-тэй байсан. Тэд өгөгдлийн санд хадгалагдсан процедурын асуулга болон зураглагчдын давхарга аль хэдийн агуулж байсан. Хадгалах газруудад бизнесийн логик байсан, ялангуяа тайлангийн мэдээлэл гаргадаг хүмүүст маш их байдаг. ORM ашиглаагүй, хүн бүр гараар бичсэн sql-д найдаж байсан.
Домэйн загварын давхарга болон нийтлэг туслах ангиуд, тухайлбал захиалгыг хадгалдаг Order анги байсан. Яг ижил газар, давхаргад дэлгэцийн текстийг сонгосон мөнгөн тэмдэгтийн дагуу хөрвүүлэх туслах байсан.
Энэ бүгдийг ийм загвараар төлөөлж болно.
Захиалгын арга
Ийм захиалга үүсгэх хялбаршуулсан анхны аргыг авч үзье.
Эхэндээ сайт нь хөдөлгөөнгүй байсан. Үүн дээр үнэ, дээр нь утасны дугаар, "Хэрэв та пицца авахыг хүсвэл дугаар руу залгаад захиалаарай" гэсэн бичээстэй байв. Захиалга өгөхийн тулд бид энгийн урсгалыг хэрэгжүүлэх хэрэгтэй:
-
Үйлчлүүлэгч үнэ бүхий статик сайтад зочилж, бүтээгдэхүүнээ сонгож, сайт дээр жагсаасан дугаар руу залгана.
-
Хэрэглэгч захиалгад нэмэхийг хүссэн бүтээгдэхүүнээ нэрлэнэ.
-
Түүний хаяг, нэрийг өгдөг.
-
Оператор захиалгыг хүлээн авна.
-
Захиалга нь хүлээн зөвшөөрөгдсөн захиалгын интерфейс дээр харагдана.
Энэ бүхэн цэсийг харуулахаас эхэлдэг. Нэвтэрсэн хэрэглэгчийн оператор нэг удаад зөвхөн нэг захиалгыг хүлээн авдаг. Тиймээс, ноорог тэрэг нь түүний сессэд (хэрэглэгчийн сесс санах ойд хадгалагддаг) хадгалагдаж болно. Бүтээгдэхүүн болон хэрэглэгчийн мэдээллийг агуулсан Cart объект байдаг.
Үйлчлүүлэгч бүтээгдэхүүнээ нэрлэж, оператор дээр дарна + бүтээгдэхүүний хажууд байгаа бөгөөд сервер рүү хүсэлт илгээгдэнэ. Мэдээллийн сангаас тухайн бүтээгдэхүүний талаарх мэдээллийг татан авч сагсанд оруулдаг.
тайлбар. Тийм ээ, энд та өгөгдлийн сангаас бүтээгдэхүүнийг татаж авах боломжгүй, харин урд талаас нь шилжүүлээрэй. Гэхдээ тодорхой болгохын тулд би мэдээллийн сангаас яг замыг зааж өгсөн.
Дараа нь үйлчлүүлэгчийн хаяг, нэрийг оруулна уу.
"Захиалга үүсгэх" дээр дарахад:
-
Хүсэлтийг OrderController.SaveOrder() руу илгээсэн.
-
Бид сессээс Cart авдаг, хэрэгцээтэй тоо хэмжээгээр бүтээгдэхүүнүүд байдаг.
-
Бид Сагсыг үйлчлүүлэгчийн талаарх мэдээллээр нэмж, ReceivingOrderService ангийн AddOrder арга руу дамжуулж мэдээллийн санд хадгалдаг.
-
Мэдээллийн санд захиалга, захиалгын бүтэц, үйлчлүүлэгч гэсэн хүснэгтүүд байдаг бөгөөд тэдгээр нь бүгд холбогдсон байдаг.
-
Захиалгын дэлгэцийн интерфэйс нь хамгийн сүүлийн үеийн захиалгыг гаргаж, харуулна.
Шинэ модулиуд
Захиалга авах нь чухал бөгөөд шаардлагатай байсан. Хэрэв танд зарах захиалга байхгүй бол пиццаны бизнес хийж чадахгүй. Тиймээс систем нь функциональ байдлыг олж авч эхэлсэн - ойролцоогоор 2012-2015 он хүртэл. Энэ хугацаанд системийн олон янзын блокууд гарч ирсэн бөгөөд би үүнийг дуудах болно модулиуд, үйлчилгээ, бүтээгдэхүүн гэсэн ойлголтоос ялгаатай.
Модуль гэдэг нь бизнесийн нийтлэг зорилгод нийцсэн функцүүдийн багц юм. Үүний зэрэгцээ тэд бие махбодийн хувьд нэг хэрэглээнд байдаг.
Модулуудыг системийн блок гэж нэрлэж болно. Жишээлбэл, энэ нь тайлагнах модуль, админ интерфейс, , зөвшөөрөл. Эдгээр нь бүгд өөр өөр хэрэглэгчийн интерфэйсүүд бөгөөд зарим нь бүр өөр харагдах загвартай байдаг. Үүний зэрэгцээ бүх зүйл нэг програм, нэг ажиллаж байгаа процессын хүрээнд байдаг.
Техникийн хувьд модулиудыг бүс болгон зохион бүтээсэн (ийм санаа нь ч хэвээр үлдсэн ). Фронт хэсэг, загварууд, мөн өөрсдийн хянагч ангиудын хувьд тусдаа файлууд байсан. Үүний үр дүнд систем үүнээс өөрчлөгдсөн ...
... үүнд:
Зарим модулиуд нь тусдаа сайтуудаар (гүйцэтгэх боломжтой төсөл) хэрэгждэг бөгөөд энэ нь бүрэн тусдаа функциональ, хэсэгчлэн тусдаа, илүү төвлөрсөн хөгжүүлэлтийн улмаас хийгддэг. Энэ:
-
Сайтын - dodopizza.ru сайт.
-
Экспорт: 1С-д зориулсан Dodo IS-ээс тайланг байршуулж байна.
-
Хувийн - ажилтны хувийн данс. Үүнийг тусад нь боловсруулсан бөгөөд өөрийн нэвтрэх цэг, тусдаа дизайнтай.
-
fs — статикийг байршуулах төсөл. Хожим нь бид үүнээс холдож, бүх статикуудыг Акамаи CDN рүү шилжүүлэв.
Үлдсэн блокууд нь BackOffice программд байсан.
Нэрийн тайлбар:
-
Кассчин - Рестораны кассчин.
-
ShiftManager - "Shift Manager" үүрэг гүйцэтгэх интерфейсүүд: пиццаны борлуулалтын үйл ажиллагааны статистик, бүтээгдэхүүнийг зогсоох жагсаалтад оруулах, дарааллыг өөрчлөх чадвар.
-
OfficeManager - "Pizzeria Manager" болон "Франчайз"-ын үүрэгт зориулсан интерфейс. Энд пиццаны газар байгуулах, урамшууллын урамшуулал, ажилчдыг хүлээн авах, хамтран ажиллах функц, тайлангуудыг цуглуулав.
-
PublicScreens - пиццаны газар өлгөөтэй зурагт болон таблетуудад зориулсан интерфейс. Телевизүүд нь цэс, сурталчилгааны мэдээлэл, хүргэлтийн үед захиалгын статусыг харуулдаг.
Тэд нийтлэг үйлчилгээний давхарга, нийтлэг Dodo.Core домэйн ангиллын блок, нийтлэг суурь ашигласан. Заримдаа тэд бие бие рүүгээ шилжих шилжилтийг удирдаж чаддаг. Dodopizza.ru эсвэл personal.dodopizza.ru гэх мэт бие даасан сайтуудыг оруулаад ерөнхий үйлчилгээнд очсон.
Шинэ модулиуд гарч ирэхэд бид мэдээллийн санд аль хэдийн үүсгэсэн үйлчилгээний код, хадгалагдсан процедур, хүснэгтүүдийг дахин ашиглахыг хичээсэн.
Системд хийсэн модулиудын цар хүрээг илүү сайн ойлгохын тулд 2012 оны хөгжлийн төлөвлөгөө бүхий диаграммыг энд оруулав.
2015 он гэхэд бүх зүйл газрын зураг дээр байсан бөгөөд үүнээс ч илүүг үйлдвэрлэсэн.
-
Захиалга хүлээн авах нь Холбоо барих төвийн тусдаа блок болж, захиалгыг оператор хүлээн авдаг.
-
Пиццаны газруудад цэс, мэдээлэл бүхий олон нийтийн дэлгэц өлгөөтэй байв.
-
Гал тогооны өрөөнд шинэ захиалга ирэхэд автоматаар "Шинэ пицца" дуут мессежийг тоглуулахаас гадна шуудан зөөгчийн нэхэмжлэхийг хэвлэх модуль байдаг. Энэ нь гал тогооны өрөөний үйл явцыг ихээхэн хялбарчилж, ажилчдыг олон тооны энгийн үйлдлүүдэд сатааруулахгүй байх боломжийг олгодог.
-
Хүргэлтийн хэсэг нь тусдаа Хүргэлтийн Шалгалт болж, захиалга нь өмнө нь ээлж авч байсан шуудан зөөгчдөө олгогддог байв. Цалингийн тооцоонд түүний ажлын цагийг харгалзан үзсэн.
Үүний зэрэгцээ 2012-2015 онуудад 10 гаруй хөгжүүлэгч гарч ирж, 35 пицца нээн, системийг Румынд байрлуулж, АНУ-д худалдааны цэгүүдийг нээхэд бэлтгэсэн. Хөгжүүлэгчид бүх ажлыг хийхээ больсон, харин багуудад хуваагдсан. тус бүр нь системийн өөрийн гэсэн хэсэгт мэргэшсэн.
Асуудал
Архитектурын улмаас (гэхдээ зөвхөн биш).
Суурь дахь эмх замбараагүй байдал
Нэг суурь нь тохиромжтой. Харилцааны мэдээллийн санд суурилуулсан хэрэгслүүдийн зардлаар тууштай байдлыг бий болгож чадна. Түүнтэй ажиллах нь танил бөгөөд тохиромжтой, ялангуяа хүснэгт цөөн, өгөгдөл багатай бол.
Гэвч 4 жилийн турш хөгжүүлэлтийн явцад мэдээллийн сан нь 600 орчим хүснэгт, 1500 хадгалагдсан процедуртай болсон бөгөөд тэдгээрийн ихэнх нь логиктой байв. Харамсалтай нь, хадгалсан процедур нь MySQL-тэй ажиллахад тийм ч их давуу тал өгдөггүй. Тэдгээр нь үндсэн дээр хадгалагдаагүй бөгөөд тэдгээрт логикийг хадгалах нь хөгжүүлэлт болон дибаг хийхэд хүндрэл учруулдаг. Кодыг дахин ашиглах нь бас хэцүү байдаг.
Олон хүснэгтэд тохирох индекс байхгүй байсан, хаа нэгтээ, эсрэгээрээ, олон тооны индексүүд байсан бөгөөд энэ нь оруулахад хүндрэл учруулсан. 20 орчим хүснэгтийг өөрчлөх шаардлагатай байсан - захиалга үүсгэх гүйлгээ нь ойролцоогоор 3-5 секунд болно.
Хүснэгт дэх өгөгдөл нь үргэлж хамгийн тохиромжтой хэлбэрээр байдаггүй. Хаа нэгтээ хэвийн бус болгох шаардлагатай байсан. Тогтмол хүлээн авдаг өгөгдлийн нэг хэсэг нь XML бүтэц хэлбэрээр баганад байсан бөгөөд энэ нь гүйцэтгэлийн хугацааг нэмэгдүүлж, асуулгыг уртасгаж, боловсруулалтыг төвөгтэй болгосон.
Үүнтэй ижил хүснэгтүүдийг маш ихээр үйлдвэрлэсэн нэг төрлийн бус хүсэлтүүд. Дээр дурдсан хүснэгт шиг алдартай хүснэгтүүд ялангуяа зовж шаналж байв. захиалга эсвэл хүснэгтүүд Пиццаны газар. Эдгээрийг гал тогооны өрөөний үйл ажиллагааны интерфэйс, аналитикийг харуулахад ашигласан. Өөр сайт тэдэнтэй холбоо барьсан (), ямар ч үед гэнэт маш олон хүсэлт ирж болно.
Өгөгдлийг нэгтгээгүй ба суурийг ашиглан олон тооны тооцоолол хийсэн. Энэ нь шаардлагагүй тооцоо, нэмэлт ачааллыг бий болгосон.
Ихэнхдээ код нь үүнийг хийх боломжгүй үед мэдээллийн сан руу очдог. Хаа нэгтээ их хэмжээний ажиллагаа хангалтгүй байсан тул найдвартай байдлыг хурдасгах, нэмэгдүүлэхийн тулд кодоор дамжуулан нэг хүсэлтийг хэд хэдэн болгон тараах шаардлагатай байв.
Код дахь нэгдмэл байдал, бүдүүлэг байдал
Бизнесийнхээ хэсгийг хариуцах ёстой байсан модулиуд үүнийг шударгаар хийсэнгүй. Тэдний заримынх нь үүргийн давхардалтай байсан. Жишээлбэл, өөрийн хотод сүлжээний маркетингийн үйл ажиллагааг хариуцдаг орон нутгийн маркетер "Админ" интерфейс (урамшуулал үүсгэх) болон "Оффис менежер" интерфейсийг (сурталчилгааны бизнест үзүүлэх нөлөөг харах) хоёуланг нь ашиглах шаардлагатай байв. Мэдээжийн хэрэг, хоёр модуль дотор урамшууллын урамшуулалтай ижил үйлчилгээг ашигладаг байсан.
Үйлчилгээнүүд (нэг цул том төслийн доторх ангиуд) өгөгдлөө баяжуулахын тулд бие биенээ дуудаж болно.
Өгөгдөл хадгалдаг загвар ангиудын тусламжтайгаар, кодын ажил өөрөөр хийгдсэн. Хаа нэгтээ шаардлагатай талбаруудыг зааж өгөх боломжтой бүтээгчид байсан. Үүнийг хаа нэгтээ нийтийн өмчөөр дамжуулан хийсэн. Мэдээжийн хэрэг, мэдээллийн сангаас өгөгдөл авах, өөрчлөх нь олон янз байсан.
Логик нь хянагч эсвэл үйлчилгээний ангиудад байсан.
Эдгээр нь өчүүхэн асуудал мэт боловч хөгжлийг ихээхэн удаашруулж, чанарыг бууруулж, тогтворгүй байдал, алдаа гаргахад хүргэсэн.
Том бүтээн байгуулалтын нарийн төвөгтэй байдал
Хөгжлийн бэрхшээлүүд өөрөө бий болсон. Системийн өөр өөр блокуудыг хийх шаардлагатай байсан бөгөөд зэрэгцээ. Бүрэлдэхүүн хэсэг бүрийн хэрэгцээг нэг код болгон тохируулах нь улам бүр хэцүү болсон. Бүх бүрэлдэхүүн хэсгүүдийг нэгэн зэрэг хүлээн зөвшөөрч, баярлуулах нь амаргүй байсан. Үүн дээр технологийн хязгаарлалтууд, ялангуяа суурь болон урд талын хязгаарлалтууд нэмэгдсэн. jQuery-г орхиж, өндөр түвшний фреймворкууд, ялангуяа үйлчлүүлэгчийн үйлчилгээ (вэб сайт) руу шилжих шаардлагатай байв.
Системийн зарим хэсэгт үүнд илүү тохиромжтой мэдээллийн санг ашиглаж болно.. Жишээлбэл, дараа нь бид захиалгын сагс хадгалахын тулд Redis-аас CosmosDB руу шилжих тохиолдол гарсан.
Өөрсдийн салбарт ажиллаж буй багууд болон хөгжүүлэгчид өөрсдийн үйлчилгээг хөгжүүлэх болон нэвтрүүлэх тал дээр илүү бие даасан байдлыг хүсч байгаа нь тодорхой. Зөрчилдөөнийг нэгтгэх, асуудлыг арилгах. Хэрэв 5 хөгжүүлэгчийн хувьд энэ асуудал ач холбогдолгүй бол 10, тэр ч байтугай төлөвлөсөн өсөлтийн хувьд бүх зүйл илүү ноцтой болно. Цаашид мобайл програмыг хөгжүүлэх ёстой байсан (энэ нь 2017 онд эхэлсэн бөгөөд 2018 онд ).
Системийн өөр өөр хэсгүүд нь янз бүрийн түвшний тогтвортой байдлыг шаарддаг, гэхдээ системийн хүчтэй холболтын улмаас бид үүнийг хангаж чадаагүй. Админ самбарт шинэ функцийг боловсруулахад алдаа гарсан нь сайт дээрх захиалгыг хүлээн авахад гарсан байж магадгүй юм, учир нь код нь нийтлэг бөгөөд дахин ашиглах боломжтой, мэдээллийн сан, өгөгдөл нь мөн адил юм.
Ийм цул-модульчлагдсан архитектурын хүрээнд эдгээр алдаа, бэрхшээлээс зайлсхийх боломжтой байх: хариуцлагыг хуваарилах, код болон мэдээллийн санг хоёуланг нь өөрчлөх, давхаргыг бие биенээсээ тодорхой тусгаарлах, чанарыг өдөр бүр хянах. Гэхдээ сонгосон архитектурын шийдэл, системийн үйл ажиллагааг хурдацтай өргөжүүлэхэд анхаарлаа төвлөрүүлэх нь тогтвортой байдлын асуудалд хүргэсэн.
"Оюуны хүч" блог рестораны кассын машиныг хэрхэн байрлуулсан тухай
Хэрэв пиццаны сүлжээний өсөлт (мөн ачаалал) ижил хурдаар үргэлжилсэн бол хэсэг хугацааны дараа уналт нь систем өсөхгүй байх болно. 2015 он гэхэд бидний тулгарч эхэлсэн асуудлуудыг сайн харуулсан, энд ийм түүх байна.
Блогт "” нь нийт сүлжээний жилийн орлогын мэдээллийг харуулсан виджет байв. Энэхүү виджет нь энэ өгөгдлийг өгдөг Dodo public API-д хандсан. Энэ статистикийг одоогоор үзэх боломжтой . Энэхүү виджетийг хуудас бүр дээр харуулсан бөгөөд 20 секунд тутамд таймер дээр хүсэлт тавьдаг. Хүсэлт api.dodopizza.ru хаягаар орж, дараах хүсэлтийг тавьсан:
-
сүлжээнд байгаа пиццаны тоо;
-
оны эхнээс хойшхи сүлжээний нийт орлого;
-
өнөөдрийн орлого.
Орлогын статистик мэдээлэл авах хүсэлт шууд мэдээллийн сан руу орж, захиалгын мэдээллийг авах хүсэлт, мэдээллийг нэгтгэж, дүнг гаргаж эхэлсэн.
Ресторануудын кассууд захиалгын ижил хүснэгтэд очиж, өнөөдрийн хүлээн авсан захиалгын жагсаалтыг буулгаж, түүнд шинэ захиалга нэмэгдэв. Кассын машинууд хүсэлтээ 5 секунд тутамд эсвэл хуудасны шинэчлэлт дээр гаргадаг.
Диаграм нь иймэрхүү харагдаж байв.
Нэг намар Федор Овчинников блогтоо урт, алдартай нийтлэл бичжээ. Олон хүмүүс блог руу орж, бүх зүйлийг анхааралтай уншиж эхлэв. Ирсэн хүмүүс тус бүр нийтлэлийг уншиж байх хооронд орлогын виджет зөв ажиллаж, API-г 20 секунд тутамд хүссэн.
API нь сүлжээний бүх пиццаны оны эхнээс хойшхи бүх захиалгын нийлбэрийг тооцоолохын тулд хадгалсан процедур гэж нэрлэдэг. Агрегатыг захиалгын хүснэгтэд үндэслэн хийсэн бөгөөд энэ нь маш алдартай. Тэр үеийн бүх нээлттэй рестораны бүх кассууд түүн дээр очдог. Бэлэн мөнгөний ширээ хариу өгөхөө больсон, захиалга хүлээж аваагүй. Тэд мөн сайтаас хүлээн аваагүй, трекер дээр гарч ирээгүй, ээлжийн менежер тэдгээрийг интерфэйс дээрээ харж чадаагүй.
Энэ бол цорын ганц түүх биш юм. 2015 оны намар гэхэд долоо хоног бүрийн баасан гаригт системийн ачаалал маш чухал байсан. Хэд хэдэн удаа бид олон нийтийн API-г унтрааж, нэг удаа юу ч тус болоогүй тул сайтыг унтраах шаардлагатай болсон. Ачаалал ихтэй үед унтрах захиалгатай үйлчилгээний жагсаалт хүртэл байсан.
Одооноос эхлэн бидний ачаалал, системийг тогтворжуулахын төлөөх тэмцэл (2015 оны намраас 2018 оны намар хүртэл) эхэлж байна. Тэгээд л ийм зүйл болсон"". Цаашилбал, заримдаа бүтэлгүйтэлүүд тохиолддог, зарим нь маш мэдрэмтгий байсан ч тогтворгүй байдлын ерөнхий үеийг одоо өнгөрсөн гэж үзэж болно.
Бизнесийн хурдацтай өсөлт
Яагаад тэр дор нь хийж болдоггүй юм бэ? Дараах графикуудыг харвал зүгээр.
Мөн 2014-2015 онд Румынд нээлтээ хийж, АНУ-д нээлтээ хийхээр бэлтгэж байсан.
Сүлжээ маш хурдан хөгжиж, шинэ улс орнууд нээгдэж, пиццаны шинэ хэлбэрүүд гарч ирэв, жишээлбэл, хоолны газар пиццаны газар нээгдэв. Энэ бүхэн Dodo IS функцийг өргөжүүлэхэд онцгой анхаарал хандуулах шаардлагатай байв. Эдгээр бүх функцгүйгээр, гал тогооны өрөөнд хяналт тавих, систем дэх бүтээгдэхүүн, алдагдлыг бүртгэх, хоолны танхимд тушаал гаргасныг харуулахгүйгээр бид "зөв" архитектур, "зөв" хандлагын талаар ярихгүй байх болно. одоо хөгжил.
Архитектурыг цаг тухайд нь шинэчлэх, техникийн асуудалд анхаарлаа хандуулах өөр нэг бэрхшээл бол 2014 оны хямрал байв. Иймэрхүү зүйл нь багуудын өсөлт хөгжилтөд, ялангуяа Додо Пицца шиг залуу бизнест хүнд цохилт болдог.
Тусалсан хурдан шийдлүүд
Асуудлыг шийдвэрлэх шаардлагатай. Уламжлал ёсоор шийдлүүдийг 2 бүлэгт хувааж болно.
-
Галыг унтрааж, аюулгүй байдлын бага зэрэг өгч, солих цагийг бидэнд олгодог хурдан хүмүүс.
-
Системчилсэн, тиймээс урт. Хэд хэдэн модулиудын дахин инженерчлэл, цул архитектурыг тусдаа үйлчилгээнд хуваах (ихэнх нь микро биш, харин макро үйлчилгээ байдаг бөгөөд үүнд ямар нэгэн зүйл бий. ).
Түргэн өөрчлөлтүүдийн хуурай жагсаалт дараах байдалтай байна.
Үндсэн мастерын хэмжээг нэмэгдүүлэх
Мэдээжийн хэрэг, ачааллыг даван туулахын тулд хамгийн түрүүнд хийх зүйл бол серверийн хүчин чадлыг нэмэгдүүлэх явдал юм. Үүнийг мастер мэдээллийн сан болон вэб серверт зориулж хийсэн. Харамсалтай нь энэ нь зөвхөн тодорхой хязгаар хүртэл боломжтой бөгөөд дараа нь хэтэрхий үнэтэй болно.
2014 оноос хойш бид Azure руу нүүсэн бөгөөд бид мөн энэ сэдвийн талаар тухайн үед нийтлэлдээ бичсэн.". Гэвч суурийн серверийг хэд хэдэн удаа нэмэгдүүлсний дараа тэд зардлын эсрэг гарч ирэв.
Уншихад зориулсан үндсэн хуулбарууд
Суурийн хувьд хоёр хуулбарыг хийсэн:
Хуулбарыг уншина уу лавлагааны хүсэлтийн хувьд. Энэ нь лавлах, төрөл, хот, гудамж, пиццаны газар, бүтээгдэхүүн (аажмаар өөрчлөгдсөн домэйн) болон бага зэрэг саатал хүлээн авах боломжтой интерфейсүүдэд уншихад ашиглагддаг. Эдгээр хуулбаруудын 2 нь байсан бөгөөд бид мастеруудын нэгэн адил бэлэн байдлыг баталгаажуулсан.
Тайлангийн хүсэлтийн хуулбарыг уншина уу. Энэ мэдээллийн сангийн хүртээмж бага байсан ч бүх тайлангууд түүн рүү очсон. Тэдэнд асар их өгөгдлийг дахин тооцоолох хүсэлт гаргахыг зөвшөөр, гэхдээ тэдгээр нь үндсэн мэдээллийн сан болон үйл ажиллагааны интерфейст нөлөөлөхгүй.
Код дахь кэш
Кодын хаана ч кэш байхгүй байсан (ерөнхийдөө). Энэ нь ачаалагдсан мэдээллийн санд үргэлж шаардлагатай биш нэмэлт хүсэлт гаргахад хүргэсэн. Кэшүүд нь эхлээд санах ойд болон гадаад кэш үйлчилгээнд байсан бөгөөд энэ нь Redis юм. Бүх зүйл цаг хугацааны явцад хүчингүй болсон, тохиргоог кодонд зааж өгсөн.
Олон тооны арын серверүүд
Өсөн нэмэгдэж буй ажлын ачааллыг зохицуулахын тулд програмын арын хэсгийг бас масштаблах шаардлагатай болсон. Нэг iis-серверээс кластер хийх шаардлагатай байсан. Бид дахин хуваарь гаргасан санах ойноос RedisCache руу шилжүүлсэн нь энгийн ачаалал тэнцвэржүүлэгчийн ард хэд хэдэн сервер хийх боломжтой болсон. Эхлээд ижил Redis-ийг кэштэй адил ашиглаж байсан бөгөөд дараа нь хэд хэдэн хэсэгт хуваагдсан.
Үүний үр дүнд архитектур нь илүү төвөгтэй болсон ...
… гэхдээ зарим хурцадмал байдал арилсан.
Дараа нь бидний хийсэн ачаалагдсан бүрэлдэхүүн хэсгүүдийг дахин хийх шаардлагатай болсон. Энэ талаар бид дараагийн хэсэгт ярих болно.
Эх сурвалж: www.habr.com