Же монолит менен ар бир бактысыз компания өз жолу менен бактысыз.
Dodo IS системасын өнүктүрүү Dodo Pizza бизнеси сыяктуу дароо башталган - 2011-жылы. Бул бизнес процесстерин толук жана толук санариптештирүү идеясына негизделген жана 2011-жылы да көптөгөн суроолорду жана шектенүүлөрдү жараткан. Бирок 9 жылдан бери биз бул жолду — монолиттен башталган өзүбүздүн өнүгүүбүз менен бара жатабыз.
Бул макала “Эмне үчүн архитектураны кайра жазып, мынчалык масштабдуу жана узак мөөнөттүү өзгөртүүлөрдү киргизүү керек?” деген суроолорго “жооп” болуп саналат. мурунку макалага . Мен Dodo ISтин өнүгүшү кантип башталганын, баштапкы архитектурасы кандай болгондугун, жаңы модулдар кантип пайда болгонун жана кандай көйгөйлөрдөн улам масштабдуу өзгөртүүлөрдү киргизүү керектигинен баштайм.
Макалалар сериясы "Додо IS деген эмне?" жөнүндө айтып берет:
-
Додо ИСте алгачкы монолит (2011-2015). (Сен бул жерде)
-
.
-
Кардар бөлүгүнүн жолу: базанын үстүндөгү фасад (2016-2017). (Прогрессте...)
-
Чыныгы микросервистердин тарыхы. (2018-2019). (Прогрессте...)
-
Монолитти кесүү жана архитектураны турукташтыруу аяктады. (Прогрессте...)
Алгачкы архитектура
2011-жылы, Dodo IS архитектурасы төмөнкүдөй болгон:
Архитектурадагы биринчи модул - заказды кабыл алуу. Бизнес процесси мындай болгон:
-
кардар пиццерияны чакырат;
-
Менеджер телефонду алат;
-
телефон аркылуу заказдарды кабыл алат;
-
Ошол эле учурда, аны заказды кабыл алуу интерфейсинде толтурат: кардар жөнүндө маалымат, заказдын деталдары боюнча маалыматтар жана жеткирүү дареги эске алынат.
Маалыматтык системанын интерфейси ушундай көрүндү...
2011-жылдын октябрындагы биринчи версия:
Биринчи заказды кабыл алуу модулун иштеп чыгуу үчүн ресурстар чектелген. Чакан команда менен тез, көп иштерди жасоо керек болчу. Чакан команда бүтүндөй келечектеги системанын пайдубалын түзгөн 2 иштеп чыгуучудан турат.
Алардын биринчи чечими технологиялык стектин келечектеги тагдырын аныктады:
-
ASP.NET MVC, C# тилиндеги Backend. Иштеп чыгуучулар чекиттер болгон; бул стек аларга тааныш жана жагымдуу болчу.
-
Bootstrap жана JQuery боюнча Frontend: колдонуучунун интерфейстери ыңгайлаштырылган стилдерге жана скрипттерге негизделген.
-
MySQL маалымат базасы: лицензиялык чыгымдар жок, колдонууга оңой.
-
Windows сервериндеги серверлер, анткени .NET анда Windows'до гана болушу мүмкүн (биз Monoну талкуулабайбыз).
Физикалык жактан алганда, мунун баары "хостердин столунда" айтылган.
Заказды кабыл алуу арызынын архитектурасы
Ошол учурда бардыгы микросервистер жөнүндө айтып жатышкан жана SOA 5 жылдай ири долбоорлордо колдонулуп келген, мисалы, WCF 2006-жылы чыккан. Бирок андан кийин алар ишенимдүү жана далилденген чечимди тандап алышты.
Бул жерде.
Asp.Net MVC бул Razor, ал формадан же кардардан суроо-талап боюнча серверде рендеринг менен HTML барагын чыгарат. Кардардын CSS жана JS скрипттери мурунтан эле маалыматты көрсөтүп турат жана зарыл болсо, JQuery аркылуу AJAX сурамдарын аткарат.
Сервердеги суроо-талаптар *Controller класстарына кирет, мында метод акыркы HTML барагын иштеп чыгат жана түзөт. Контроллерлор * Кызматтар деп аталган логикалык катмарга суроо-талаптарды жасашат. Кызматтардын ар бири бизнестин айрым аспектилерине туура келген:
-
Мисалы, DepartmentStructureService пиццериялар жана бөлүмдөр боюнча маалымат берди. Бөлүм – бул бир франчайзи башкарган пиццериялардын тобу.
-
ReceivingOrdersService заказдын мазмунун кабыл алып, эсептеп чыкты.
-
Ал эми SmsService SMS жөнөтүү үчүн API кызматтарын чакыруу менен SMS жөнөттү.
Кызматтар маалымат базасынан маалыматтарды иштетип, бизнес логикасын сакташат. Ар бир кызматтын тиешелүү аталышы бар бир же бир нече *Репозиторийлери болгон. Алар мурунтан эле маалымат базасында сакталган процедураларга суроо-талаптарды жана картачылардын катмарын камтыган. Репозиторийлерде бизнес логикасы болгон, айрыкча алардын көбү отчеттук маалыматтарды чыгарган. ORM колдонулган эмес, баары кол менен жазылган SQLге таянышкан.
Ошондой эле домен моделинин катмары жана жалпы жардамчы класстар бар болчу, мисалы, тартипти сактаган Order классы. Ал жерде, катмарда тандалган валютага ылайык дисплей текстин өзгөртүү үчүн жардамчы бар болчу.
Мунун баары бул модель менен көрсөтүлүшү мүмкүн:
Заказ кылуу жолу
Мындай тартипти түзүүнүн жөнөкөйлөштүрүлгөн баштапкы жолун карап көрөлү.
Башында сайт статикалык болгон. Анын баалары, жогору жагында телефон номери жана “Эгер пицца кааласаңыз, номерге чалып заказ кылыңыз” деген жазуу бар. Заказ берүү үчүн, биз жөнөкөй агымын ишке ашыруу керек:
-
Кардар баалары менен статикалык веб-сайтка кирип, өнүмдөрдү тандап, веб-сайтта көрсөтүлгөн номерге чалат.
-
Кардар буйрутмага кошкусу келген товарлардын атын атайт.
-
Анын дарегин жана атын берет.
-
Оператор заказды кабыл алат.
-
Буйрутма кабыл алынган буйруктар интерфейсинде көрсөтүлөт.
Мунун баары меню дисплейден башталат. Кирген оператор колдонуучу бир эле учурда бир гана заказды кабыл алат. Демек, арабанын долбоору өз сессиясында сакталышы мүмкүн (колдонуучунун сеансы эстутумда сакталат). Товарларды жана кардар маалыматын камтыган Cart объекти бар.
Кардар товардын атын атайт, оператор чыкылдатат + продукттун жанында жана суроо-талап серверге жөнөтүлөт. Товар тууралуу маалымат базадан чыгарылып, товар тууралуу маалымат арабага кошулат.
пикир. Ооба, бул жерде сиз продуктуну маалымат базасынан чыгарбашыңыз керек, бирок аны алдыңкы четинен өткөрүп бериңиз. Бирок түшүнүктүү болуш үчүн мен так жолду базадан көрсөттүм.
Андан кийин, кардардын дарегин жана атын киргизиңиз.
"Заказ түзүү" дегенди басканда:
-
Сурамды OrderController.SaveOrder()ге жөнөтөбүз.
-
Арбаны сессиядан алабыз, керектүү санда продукциялар бар.
-
Биз Картты кардар жөнүндө маалымат менен толуктайбыз жана аны ReceivingOrderService классынын AddOrder ыкмасына өткөрүп беребиз, ал жерде ал маалымат базасына сакталат.
-
Маалымат базасында буйрутма, заказдын мазмуну, кардар жазылган таблицалар бар жана алардын баары биригип турат.
-
Заказ дисплей интерфейси барып, эң акыркы буйрутмаларды чыгарып, аларды көрсөтөт.
Жаңы модулдар
Заказды алуу маанилүү жана зарыл болгон. Сатууга буйрутмаңыз жок болсо, пицца бизнесин жүргүзө албайсыз. Ошентип, система функционалдык мүмкүнчүлүккө ээ боло баштады - болжол менен 2012-жылдан 2015-жылга чейин. Бул убакыттын ичинде системанын көптөгөн түрдүү блоктору пайда болду, мен аларды чакырам модулдар, кызмат же продукт түшүнүгүнө каршы.
Модуль - бул кандайдыр бир жалпы бизнес максаттары менен бириктирилген функциялардын жыйындысы. Мындан тышкары, алар физикалык жактан бир эле тиркемеде жайгашкан.
Модулдарды системалык блок деп атоого болот. Мисалы, бул отчеттуулук модулу, администратор интерфейси, , авторизация. Булардын бардыгы ар кандай колдонуучу интерфейстери, айрымдарынын визуалдык стилдери да ар түрдүү. Анын үстүнө, баары бир тиркеме, бир иштеп жаткан процесстин ичинде.
Техникалык жактан, модулдар аймак катары иштелип чыккан (бул идея ал тургай калган ). Фронт, моделдер, ошондой эле өздөрүнүн контроллер класстары үчүн өзүнчө файлдар бар болчу. Натыйжада, система ушундай...
...буга:
Кээ бир модулдар өзүнчө сайттар (аткалуучу долбоор) тарабынан ишке ашырылат, ал толугу менен өзүнчө функционалдуулукка жана жарым-жартылай өзүнчө, көбүрөөк багытталган өнүгүүгө байланыштуу. Бул:
-
сайт - dodopizza.ru сайты.
-
экспорттоо: 1C үчүн Dodo ISтен отчетторду жүктөп алуу.
-
өз - кызматкердин жеке эсеби. Ал өзүнчө иштелип чыккан жана өзүнүн кирүү чекити жана өзүнчө дизайны бар.
-
fs — статикалык хостинг үчүн долбоор. Кийинчерээк биз андан алыстап, бардык статикалык мазмунду Akamai CDNге көчүрдүк.
Калган блоктор BackOffice тиркемесинде жайгашкан.
Аттардын түшүндүрмөсү:
-
Кассир - ресторандын кассасы.
-
ShiftManager - "Shift Manager" ролу үчүн интерфейстер: пиццерия сатуу боюнча оперативдүү статистика, өнүмдөрдү токтотуу тизмесине коюу, тартипти өзгөртүү мүмкүнчүлүгү.
-
OfficeManager - "Пиццерия менеджери" жана "Франчайзи" ролдору үчүн интерфейстер. Бул жерден сиз пиццерияны уюштуруу, анын бонустук акциялары, кызматкерлерди кабыл алуу жана алар менен иштөө жана отчетторду таба аласыз.
-
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-жылы болгон ).
Системанын ар кандай бөлүктөрү туруктуулуктун ар кандай көрсөткүчтөрүн талап кылган, бирок системанын күчтүү байланышынан улам биз муну камсыздай алган жокпуз. Администратор панелинде жаңы функцияны иштеп чыгууда ката сайтта буйрутманы кабыл алууга алып келиши мүмкүн, анткени код жалпы жана көп жолу колдонулуучу, маалымат базасы жана маалыматтар да бирдей.
Мындай монолиттүү-модулдук архитектуранын алкагында бул каталарды жана көйгөйлөрдү болтурбоо мүмкүн болмок: милдеттерди бөлүштүрүү, кодду да, маалымат базасын да рефакторлоо, катмарларды бири-биринен так бөлүп, сапатка күн сайын мониторинг жүргүзүү. Бирок тандалган архитектуралык чечимдер жана системанын функционалдуулугун тез кеңейтүүгө көңүл буруу туруктуулук маселелеринде көйгөйлөргө алып келди.
Power of Mind блогу ресторандарга кассалык аппараттарды кантип койгон
Эгерде пиццерия тармагынын өсүшү (жана жүктөө) ошол эле темп менен уланса, анда бир аздан кийин тамчылар система калыбына келбей тургандай болот. Төмөнкү окуя 2015-жылга карата биз туш боло баштаган көйгөйлөрдү жакшы көрсөтүп турат.
блогунда ""Бүткүл тармак боюнча жыл ичинде киреше маалыматтарын көрсөткөн виджет бар болчу. Виджет бул дайындарды камсыз кылган коомдук Dodo API'ге кирди. Бул статистика азыр жеткиликтүү . Виджет ар бир бетте көрсөтүлүп, ар бир 20 секунд сайын таймерден суроо-талаптарды жасап турган. Сураныч api.dodopizza.ru сайтына кирип, сурады:
-
тармактагы пиццериялардын саны;
-
жылдын башынан бери тармактын жалпы кирешеси;
-
бүгүнкү киреше.
Кирешенин статистикасы боюнча суроо-талап түз эле маалымат базасына келип, буйруктар боюнча маалыматтарды сурай баштады, маалыматтарды түздөн-түз ыкчам чогултуп, сумманы чыгара баштады.
Ресторандардагы кассалар ошол эле заказдардын таблицасына кирип, бүгүнкү күнгө кабыл алынган заказдардын тизмесин жүктөшүп, ага жаңы заказдар кошулду. Кассалык аппараттар ар бир 5 секунд сайын же баракча жаңыланганда өз талаптарын коюшчу.
Диаграмма мындай көрүндү:
Күздүн бир күнү Федор Овчинников өзүнүн блогуна узун жана популярдуу макала жазган. Блогго көп адамдар келип, баарын кунт коюп окуй башташты. Келген адамдардын ар бири макаланы окуп жатканда, киреше виджети туура иштеп, ар бир 20 секунд сайын API сурады.
API тармактагы бардык пиццериялар үчүн жыл башынан бери бардык буйрутмалардын суммасын эсептөө үчүн сакталган процедураны чакырды. Агрегация абдан популярдуу болгон заказдар таблицасына негизделген. Ошол кездеги бардык ачылган ресторандардын бардык кассалары ага барат. Кассалар иштебей, заказдар кабыл алынган эмес. Алар ошондой эле сайттан кабыл алынган эмес, трекерде көрүнгөн эмес жана нөөмөт жетекчиси аларды өз интерфейсинде көрө алган эмес.
Бул жалгыз окуя эмес. 2015-жылдын күзүндө, ар жума күнү системага жүктөө өтө маанилүү болгон. Бир нече жолу биз коомдук API'ни өчүрдүк, ал тургай бир жолу эч нерсе жардам бербегендиктен сайтты өчүрүүгө туура келди. Ал тургай, оор жүктөмдөрдүн астында өчүрүү тартиби менен кызматтардын тизмеси бар болчу.
Ушул убактан баштап, жүктөр менен жана системаны турукташтыруу үчүн күрөшүбүз башталат (2015-жылдын күзүнөн 2018-жылдын күзүнө чейин). Мына ошондо болду"" Андан тышкары, кээде каталар да болгон, алардын айрымдары өтө сезимтал болгон, бирок туруксуздуктун жалпы мезгили азыр бүттү деп эсептесе болот.
Бизнестин тез өсүшү
Эмне үчүн аны "дароо жакшы кылып" жасоого болбойт? Жөн гана төмөнкү графиктерди караңыз.
Ошондой эле 2014-2015-жылдары Румынияда ачылышы болуп, АКШда ачылышы даярдалып жаткан.
Чынжыр абдан тез өсүп, жаңы өлкөлөр ачылды, пиццериялардын жаңы форматтары пайда болду, мисалы, фуд-кортто пиццерия ачылды. Мунун баары өзгөчө Dodo IS функцияларын кеңейтүүгө олуттуу көңүл бурууну талап кылды. Бул функциялардын бардыгы болбосо, ашканада байкоо салбастан, системадагы продуктыларды жана жоготууларды эсепке алуусуз, фуд-корт залында буйрутмалардын жеткирилишин көрсөтпөстөн, биз азыр “туура” архитектура жана “туура” архитектура жөнүндө сөз кылып жатканыбыз күмөн. ” өнүктүрүүгө болгон мамиле.
Архитектураны өз убагында кайра карап чыгууга жана техникалык көйгөйлөргө жалпы көңүл бурууга дагы бир тоскоолдук 2014-жылдагы кризис болду. Мындай нерселер командалардын өсүү мүмкүнчүлүктөрүнө зыян келтирет, айрыкча Dodo Pizza сыяктуу жаш бизнес үчүн.
Жардам берген тез чечимдер
Көйгөйлөрдү чечүү керек. Шарттуу түрдө, чечимдер 2 топко бөлүүгө болот:
-
Өрттү өчүрүп, бизге коопсуздуктун бир аз чегин берип, өзгөртүүгө убакытты сатып алган тез адамдар.
-
Системалык жана, демек, узак. Бир катар модулдарды реинжинирингдөө, монолиттүү архитектураны өзүнчө кызматтарга бөлүү (алардын көбү микро эмес, макросервистер жана бул жөнүндө дагы көп нерселер бар. ).
Ыкчам өзгөрүүлөрдүн кургак тизмеси:
Масштабды кеңейтүү
Албетте, жүк менен күрөшүү үчүн жасалган биринчи нерсе - сервердин күчүн жогорулатуу. Бул башкы маалымат базасы жана веб-серверлер үчүн жасалган. Тилекке каршы, бул белгилүү бир чекке чейин гана мүмкүн, андан тышкары ал өтө кымбат болуп калат.
2014-жылдан бери биз Azure-ге көчүп келдик; биз дагы бул тема жөнүндө макалада жазганбыз "" Бирок сервердин бир катар жогорулашынан кийин базанын баасы чекке жетти.
Окуу үчүн маалымат базасынын репликалары
Биз базанын эки көчүрмөсүн жасадык:
ReadReplica каталог суроо үчүн. Ал шаар, көчө, пиццерия, продуктулар (акырын өзгөртүлгөн домен) сыяктуу каталогдорду окуу үчүн жана кичине кечигүүгө жол берилген интерфейстерде колдонулат. Бул репликалардын 2си бар болчу, биз алардын жеткиликтүүлүгүн мастер сыяктуу эле камсыз кылдык.
Отчеттук суроо-талаптар үчүн ReadReplica. Бул базанын жеткиликтүүлүгү төмөн болгон, бирок бардык отчеттор ага кеткен. Алар чоң маалыматтарды кайра эсептөө үчүн оор суроо-талаптар болушу мүмкүн, бирок алар негизги маалымат базасына жана оперативдүү интерфейстерге таасир этпейт.
Коддогу кэштер
Коддун эч бир жеринде кэштер болгон эмес (дегеле). Бул жүктөлгөн маалымат базасына дайыма эле зарыл эмес, кошумча суроо-талаптарга алып келди. Башында кэштер эстутумда да, тышкы кэш кызматында да болгон, ал Redis болчу. Баары убакыт жараксыз болгон, орнотуулар коддо көрсөтүлгөн.
Backend үчүн бир нече серверлер
Колдонмонун арткы бөлүгү да жогорулатылган жүктөргө туруштук берүү үчүн масштабдалышы керек болчу. Бир IIS серверинен кластер түзүү керек болчу. Биз көчтүк RedisCache эстутумунан, бул тегерек робин менен жөнөкөй жүк балансынын артында бир нече серверлерди түзүүгө мүмкүндүк берди. Башында, ошол эле Redis кэштер үчүн колдонулган, андан кийин алар бир нечеге бөлүнгөн.
Натыйжада архитектура татаалдашып кеткен...
...бирок кээ бир чыңалуу жеңилдеди.
Андан кийин жүктөлгөн компоненттерди кайра жасоо керек болчу, муну биз кабыл алганбыз. Бул тууралуу кийинки бөлүмдө сөз кылабыз.
Source: www.habr.com