Эй Хабр!

Коронавирусқа байланысты ағымдағы оқиғаларға байланысты бірқатар интернет қызметтері жүктемені ұлғайта бастады. Мысалы, Ұлыбританияның бір бөлшек сауда желісі өзінің онлайн тапсырыс беру веб-сайтын жай ғана жауып тастады., себебі сыйымдылық жеткіліксіз болды. Күшті жабдықты қосу арқылы серверді жылдамдату әрқашан мүмкін емес, бірақ тұтынушы сұраулары өңделуі керек (немесе олар бәсекелестерге барады).

Бұл мақалада мен жылдам және ақауларға төзімді қызметті құруға көмектесетін танымал тәжірибелерді қысқаша талқылаймын. Дегенмен, ықтимал әзірлеу схемаларының ішінен мен тек қазіргі уақытта қолданылып жатқандарын таңдадым. пайдалану оңайӘрбір элемент үшін сізде дайын кітапханалар бар немесе мәселені бұлттық платформа арқылы шеше аласыз.

Көлденең масштабтау

Бұл ең қарапайым және ең танымал нүкте. Жалпы айтқанда, ең көп тараған екі жүктемені бөлу схемасы көлденең және тік масштабтау болып табылады. Бірінші жағдайда Сіз қызметтерге параллель жұмыс істеуге рұқсат бересіз, осылайша олардың арасында жүктемені бөлесіз. Екінші орында Сіз неғұрлым қуатты серверлерге тапсырыс бересіз немесе кодты оңтайландырасыз.

Мысал ретінде мен дерексіз бұлттық файл қоймасын аламын, яғни OwnCloud, OneDrive және т.б. аналогтары.

Мұндай схеманың типтік диаграммасы төменде берілген, бірақ ол тек жүйенің күрделілігін көрсетеді. Өйткені, біз қандай да бір түрде қызметтерді синхрондауымыз керек. Пайдаланушы файлды планшеттен сақтап, оны телефонда көргісі келсе не болады?

Тәсілдердің айырмашылығы мынада: тік масштабтауда біз түйіндердің сыйымдылығын арттыруға дайынбыз, ал көлденең масштабтауда жүктемені бөлу үшін жаңа түйіндерді қосуға дайынбыз.

CQRS

Пәрменді сұрау жауапкершілігін бөлу Бұл өте маңызды үлгі, өйткені ол әртүрлі клиенттерге әртүрлі қызметтерге қосылуға ғана емес, сонымен қатар бірдей оқиғалар ағындарын алуға мүмкіндік береді. Оның артықшылықтары қарапайым қолданба үшін соншалықты айқын емес, бірақ бос емес қызмет үшін бұл өте маңызды (және қарапайым). Оның мәні кіріс және шығыс деректер ағындары қиылыспауы керек. Яғни, сіз сұрау жіберіп, жауап күте алмайсыз; оның орнына сіз А қызметіне сұрау жібересіз, бірақ В қызметінен жауап аласыз.

Бұл тәсілдің бірінші артықшылығы - ұзақ сұрау кезінде байланыстарды (сөздің кең мағынасында) бұзу мүмкіндігі. Мысалы, азды-көпті стандартты тізбекті алайық:

1. Клиент серверге сұрау жіберді.
2. Сервер ұзақ өңдеуді бастады.
3. Сервер клиентке нәтижемен жауап берді.

2-қадамда қосылым үзілгенін елестетіп көрейік (не желі қайта қосылды немесе пайдаланушы басқа бетке өтіп, қосылымды үзді). Бұл жағдайда серверге пайдаланушыға нақты не өңделгені туралы хабарлайтын жауап жіберу қиынға соғады. CQRS көмегімен реттілік сәл өзгеше болады:

1. Клиент жаңартуларға жазылды.
2. Клиент серверге сұрау жіберді.
3. Сервер «сұраныс қабылданды» деп жауап берді.
4. Сервер «1» нүктесінен арна арқылы нәтижемен жауап берді.

Көріп отырғаныңыздай, схема сәл күрделірек. Сонымен қатар, интуитивті сұрау-жауап тәсілі мұнда жоқ. Дегенмен, көріп отырғаныңыздай, сұрауды өңдеу кезінде қосылымның үзілуі қатеге әкелмейді. Сонымен қатар, егер пайдаланушы қызметке шын мәнінде бірнеше құрылғыдан қосылған болса (мысалы, ұялы телефон және планшет), жауаптың екі құрылғыға да жіберілуін реттеуге болады.

Бір қызығы, кіріс хабарламаларды өңдеу коды клиенттің өзі әсер еткен екі оқиға үшін де, басқа да оқиғалар үшін, соның ішінде басқа клиенттерден келген оқиғалар үшін бірдей болады (100% емес).

Дегенмен, шын мәнінде, біз бір бағытты ағынды функционалды түрде өңдеуге болатындығынан қосымша артықшылықтар аламыз (RX және ұқсас әдістерді қолдану). Бұл маңызды артықшылық, өйткені қолданбаны тіпті функционалдық тәсілді қолдана отырып, толығымен реактивті етуге болады. Ауқымды бағдарламалар үшін бұл даму мен қолдау ресурстарын айтарлықтай қысқартуы мүмкін.

Бұл тәсілді көлденең масштабтаумен біріктіру сұрауларды бір серверге жіберу және екіншісінен жауап алу мүмкіндігінің қосымша артықшылығын қамтамасыз етеді. Бұл клиентке қалаған қызметті таңдауға мүмкіндік береді, ал негізгі жүйе оқиғаларды дұрыс өңдей алады.

Оқиға көзі

Өздеріңіз білетіндей, бөлінген жүйенің негізгі ерекшеліктерінің бірі ортақ уақыттың немесе ортақ маңызды бөлімнің болмауы болып табылады. Бір процесс үшін синхрондауды (мутекстерді пайдалану арқылы) жүзеге асыра аласыз, сол кодты басқа ешкім орындамайтынына көз жеткізіңіз. Дегенмен, бөлінген жүйе үшін бұл қауіпті, өйткені ол қосымша шығындарды талап етеді және масштабтаудың мақсатын бұзады — барлық құрамдас бөліктер бұрынғысынша күтеді.

Бұл бізді маңызды фактіге әкеледі: жылдам таратылатын жүйені синхрондауға болмайды, өйткені бұл өнімділікті төмендетеді. Екінші жағынан, бізге компоненттер арасында белгілі бір дәрежеде сәйкестік қажет. Және бұл үшін біз әдісті пайдалана аламыз түпкілікті консистенция, онда соңғы жаңартудан кейін белгілі бір уақыт аралығында деректер өзгерісі болмаса («ақырында»), барлық сұраулар соңғы жаңартылған мәнді қайтаратынына кепілдік беріледі.

Классикалық дерекқорлар үшін ол жиі қолданылатынын түсіну маңызды қатаң консистенциясы, мұнда әрбір түйін бірдей ақпаратқа ие (бұл көбінесе транзакция тек екінші сервер жауап бергеннен кейін ғана орнатылған деп есептелсе қол жеткізіледі). Оқшаулану деңгейіне байланысты бұл жерде кейбір релаксациялар бар, бірақ жалпы идея өзгеріссіз қалады - сіз толығымен үйлесімді әлемде өмір сүре аласыз.

Бірақ бастапқы мәселеге оралайық. Жүйенің бір бөлігімен салынуы мүмкін болса түпкілікті консистенция, содан кейін келесі диаграмманы құруға болады.

Бұл тәсілдің маңызды ерекшеліктері:

• Әрбір кіріс сұрау бір кезекке қойылады.
• Сұрауды өңдеу кезінде қызмет тапсырмаларды басқа кезектерге қоюы мүмкін.
• Әрбір кіріс оқиғаның идентификаторы болады (ол қайталану үшін қажет).
• Кезек «тек қосу» принципі бойынша жұмыс істейді. Элементтерді жою немесе ретін өзгерту мүмкін емес.
• Кезек FIFO (бірінші келген, бірінші шыққан) принципі бойынша жұмыс істейді. Параллельді орындау қажет болса, нысандарды бір кезеңде әртүрлі кезектерге жылжыту керек.

Біз онлайн файлдарды сақтау мүмкіндігін қарастырып жатқанымызды еске сала кетейін. Бұл жағдайда жүйе келесідей болады:

Диаграммадағы қызметтер міндетті түрде бөлек серверлерді көрсетпейтінін ескеру маңызды. Олар тіпті бірдей процесті бөлісуі мүмкін. Ең бастысы, бұл заттардың көлденең масштабтау оңай жүзеге асырылуы үшін идеологиялық түрде бөлінгені.

Ал екі пайдаланушы үшін диаграмма келесідей болады (әртүрлі пайдаланушыларға арналған қызметтер әртүрлі түстермен белгіленген):

Мұндай комбинацияның бонустары:

• Ақпаратты өңдеу қызметтері бөлінген. Кезектер де бөлінген. Жүйенің өткізу қабілетін арттыру қажет болса, бізге көбірек серверлерде көбірек қызметтерді іске қосу керек.
• Пайдаланушыдан ақпаратты алған кезде деректердің толық сақталуын күтудің қажеті жоқ. Оның орнына біз жай ғана «OK» деп жауап береміз, содан кейін біртіндеп өңдеуді бастаймыз. Кезек сонымен қатар шыңдарды тегістейді, өйткені жаңа нысанды қосу тез орындалады және пайдаланушыға бүкіл цикл аяқталуын күтудің қажеті жоқ.
• Мысал ретінде мен бірдей файлдарды біріктіруге әрекеттенетін қайталау қызметін қостым. 1% жағдайда аяқтау үшін көп уақыт қажет болса, клиент әрең байқайды (жоғарыдан қараңыз), бұл үлкен плюс, өйткені біз енді 100% жылдамдық пен сенімділікті қажет етпейміз.

Дегенмен, кемшіліктер бірден көрінеді:

• Біздің жүйеде енді қатаң жүйелілік жоқ. Бұл, мысалы, әртүрлі қызметтерге жазылсаңыз, теориялық тұрғыдан әртүрлі күйлерді алуға болатынын білдіреді (себебі қызметтердің бірінде ішкі кезектен хабарландыру алуға уақыт болмауы мүмкін). Тағы бір салдары - жүйеде жалпы уақыт жоқ. Бұл, мысалы, келу уақыты бойынша барлық оқиғаларды сұрыптау мүмкін емес дегенді білдіреді, себебі серверлер арасындағы сағаттар синхрондалмаған болуы мүмкін (шын мәнінде, екі серверде бірдей уақыттың болуы утопия).
• Енді ешбір оқиғаны жай ғана кері қайтару мүмкін емес (деректер базасы сияқты). Оның орнына жаңа оқиға қосылуы керек— өтемақы оқиғасы, ол соңғы күйді қажетті күйге өзгертеді. Ұқсас аймақтың мысалы ретінде: тарихты қайта жазбай (кейбір жағдайларда бұл нашар), сіз Git-те міндеттемені кері қайтара алмайсыз, бірақ сіз арнайы жасай аласыз. кері қайтару міндеттемесі, бұл негізінен ескі күйді қайтарады. Дегенмен, қате міндеттеме де, кері қайтару да тарихта сақталады.
• Деректер схемасы шығарылымнан шығарылымға дейін өзгеруі мүмкін, бірақ ескі оқиғалар енді жаңа стандартқа жаңартылмайды (өйткені оқиғаларды негізінен өзгерту мүмкін емес).

Көріп отырғаныңыздай, Event Sourcing CQRS-пен жақсы жұмыс істейді. Сонымен қатар, деректер ағындарын бөлмей, тиімді және ыңғайлы кезектері бар жүйені енгізу өте қиын, өйткені ол кезектердің оң әсерін жоққа шығаратын синхрондау нүктелерін қосуды қажет етеді. Екі тәсілді бір уақытта пайдалану бағдарлама кодына аздаған түзетулерді талап етеді. Біздің жағдайда файлды серверге жіберген кезде жауап тек «OK» қайтарады, бұл жай ғана «файл қосу операциясы сақталды» дегенді білдіреді. Техникалық тұрғыдан бұл деректер басқа құрылғыларда әлдеқашан қолжетімді дегенді білдірмейді (мысалы, көшірмелерді жою қызметі индексті қайта құруы мүмкін). Дегенмен, біраз уақыттан кейін клиент «X файлы сақталды» деген хабарлама алады.

Болғандықтан:

• Файлдарды жіберу күйлерінің саны артып келеді: классикалық «жіберілген файлдың» орнына біз енді екеуін көреміз: «сервер кезегіне қосылған файл» және «сақтауға сақталған файл». Соңғысы басқа құрылғылар енді файлды қабылдауды бастай алатынын білдіреді (кезектер әртүрлі жылдамдықта жұмыс істейді деген ескертумен).
• Жіберу ақпараты қазір әртүрлі арналар арқылы келетіндіктен, біз файлдарды өңдеу күйін алу үшін шешімдерді әзірлеуіміз керек. Нәтижесінде, классикалық сұрау-жауап әдісінен айырмашылығы, клиентті файл өңделіп жатқанда қайта іске қосуға болады, бірақ өңдеу күйі дұрыс болып қалады. Сонымен қатар, бұл функция негізінен қораптан тыс жұмыс істейді. Нәтижесінде біз қазір сәтсіздіктерге шыдамды боламыз.

Sharding

Жоғарыда сипатталғандай, оқиға көзі бар жүйелерде қатаң сәйкестік жоқ. Бұл бірнеше сақтау құрылғыларын олардың арасында синхрондаусыз пайдалана алатынымызды білдіреді. Тапсырмамызға келе отырып, біз:

• Файлдарды түрі бойынша бөліңіз. Мысалы, суреттерді/бейнелерді дешифрлеуге және тиімдірек пішімді таңдауға болады.
• Ел бойынша бөлек шоттарды. Көптеген заңдар мұны талап етуі мүмкін, бірақ бұл архитектура бұл мүмкіндікті автоматты түрде қамтамасыз етеді.

Деректерді бір жадтан екіншісіне тасымалдағыңыз келсе, стандартты құралдар орындамайды. Өкінішке орай, бұл жағдайда кезекті тоқтатып, тасымалдауды орындап, оны қайта бастау керек. Жалпы, деректерді «ұшу кезінде» тасымалдай алмайсыз. Дегенмен, егер оқиға кезегі толығымен сақталса және сізде алдыңғы сақтау күйлерінің суреттері болса, оқиғаларды келесідей қайталауға болады:

• Оқиғалар көзінде әрбір оқиғаның өз идентификаторы болады (дұрысы кемімейтін). Бұл жадқа өрісті — соңғы өңделген элементтің идентификаторын қоса алатынымызды білдіреді.
• Біз барлық оқиғаларды бірнеше тәуелсіз сақтау орындарында өңдеуге болатындай етіп кезекті көшіреміз (біріншісі - қазіргі уақытта деректерді сақтайтын, екіншісі - жаңа, бірақ қазір бос). Екінші кезек, әрине, қазір өңделмейді.
• Біз екінші кезекті бастаймыз (яғни оқиғаларды қайталай бастаймыз).
• Жаңа кезек салыстырмалы түрде бос болғаннан кейін (яғни, элементті қосу мен оны шығарып алу арасындағы орташа уақыт айырмашылығы қолайлы), оқырмандар жаңа жадқа ауыса алады.

Көріп отырғаныңыздай, біздің жүйеде қатаң жүйелілік ешқашан болған емес және әлі де жоқ. Оқиғалардың бірдей ретпен өңделуіне кепілдік беретін түпкілікті тұрақтылық бар (әртүрлі кідірістермен болуы мүмкін). Осының артықшылығын пайдалана отырып, біз жүйені тоқтатпай әлемнің басқа жағына салыстырмалы түрде оңай деректерді тасымалдай аламыз.

Осылайша, онлайн файлдарды сақтау үлгісін жалғастыра отырып, бұл архитектура бізге бірқатар бонустар береді:

• Біз нысандарды пайдаланушыларға жақындатып, динамикалық түрде жылжыта аламыз, осылайша қызмет көрсету сапасын жақсарта аламыз.
• Біз кейбір деректерді компаниялар ішінде сақтай аламыз. Мысалы, кәсіпорын пайдаланушылары көбінесе деректердің басқарылатын деректер орталықтарында сақталуын талап етеді (деректер ағып кетуін болдырмау үшін). Sharding арқылы біз мұны оңай қолдай аламыз. Тұтынушыда үйлесімді бұлт болса, бұл тапсырма одан әрі жеңілдетіледі (мысалы, Azure өзін-өзі басқарады).
• Ең бастысы, біз мұны істеудің қажеті жоқ. Ақыр соңында, барлық тіркелгілер үшін бір сақтау орны өте жақсы болар еді (тезірек бастау үшін). Және бұл жүйенің басты ерекшелігі, ол кеңейтілетін болса да, бастапқыда өте қарапайым. Миллион бөлек тәуелсіз кезектерді өңдейтін кодты бірден жазудың қажеті жоқ, т.б. Қажет болса, біз мұны кейінірек жасай аламыз.

Статикалық мазмұнды хостинг

Бұл нүкте толығымен анық көрінуі мүмкін, бірақ ол әлі де аз немесе аз стандартты, жоғары жүктемелі қолданба үшін өте маңызды. Оның мәні қарапайым: барлық статикалық мазмұн қолданба орналасқан серверден емес, осы тапсырмаға арнайы бөлінген арнайы серверлерден беріледі. Нәтижесінде бұл әрекеттер жылдамырақ орындалады (мысалы, Nginx Java серверіне қарағанда файлдарға жылдамырақ және арзанырақ қызмет көрсетеді). Сонымен қатар, CDN архитектурасы бар (Мазмұнды жеткізу желісі) файлдарды соңғы пайдаланушыларға жақынырақ орналастыруға мүмкіндік береді, бұл қызметті пайдаланудың қарапайымдылығына оң әсер етеді.

Статикалық мазмұнның ең қарапайым және стандартты мысалы - веб-сайтқа арналған сценарийлер мен кескіндер жинағы. Бұл қарапайым — олар алдын ала белгілі, содан кейін мұрағат CDN серверлеріне жүктеледі, ол жерден ол соңғы пайдаланушыларға қызмет етеді.

Дегенмен, іс жүзінде статикалық мазмұн үшін ламбда архитектурасына біршама ұқсас тәсілді қолдануға болады. Пайдаланушыларға файлдарды тарату керек болатын тапсырмамызға (онлайн файлдарды сақтау) оралайық. Ең қарапайым қарапайым шешім - әрбір пайдаланушы сұрауы үшін барлық қажетті тексерулерді (авторизация және т.б.) орындайтын, содан кейін файлды біздің қоймадан тікелей жүктеп алатын қызметті жасау. Бұл тәсілдің негізгі кемшілігі статикалық мазмұнға (және белгілі бір нұсқасы бар файл негізінен статикалық мазмұн болып табылады) іскери логиканы қамтитын сол сервер арқылы қызмет етеді. Оның орнына біз келесі схеманы пайдалана аламыз:

• Сервер жүктеп алу URL мекенжайын береді. Ол file_id + key пішімінде болуы мүмкін, мұнда кілт келесі 24 сағат ішінде ресурсқа рұқсат беретін шағын цифрлық қолтаңба болып табылады.
• Файлды тарату келесі опциялармен қарапайым nginx арқылы өңделеді:
  • Мазмұнды кэштеу. Бұл қызметті бөлек серверде орналастыруға болатындықтан, біз жақында жүктелген барлық файлдарды дискіде сақтау арқылы болашақты тексеруді қамтамасыз еттік.
  • Қосылымды жасау кезінде кілтті тексеру
• Қосымша: ағындық мазмұнды өңдеу. Мысалы, қызметтегі барлық файлдарды қысатын болсақ, оларды тікелей осы модульде ашуға болады. Нәтижесінде IO операциялары тиесілі жерде орындалады. Java архиваторы қажетсіз жадты оңай бөледі, бірақ қызметті кәдімгі Rust/C++ жүйесінде бизнес логикасы арқылы қайта жазу да тиімсіз болуы мүмкін. Біздің жағдайда біз әртүрлі процестерді (немесе тіпті қызметтерді) пайдаланамыз, бұл бизнес логикасын және IO операцияларын тиімді ажырата алатынымызды білдіреді.

Бұл схема статикалық мазмұнға қызмет көрсетуге мүлдем ұқсамайды (өйткені біз бүкіл статикалық пакетті бір жерде жүктеп салмаймыз), бірақ шын мәнінде бұл тәсіл өзгермейтін деректерге дәл қызмет етеді. Сонымен қатар, бұл схеманы мазмұн жай ғана статикалық емес, өзгермейтін және алынбайтын блоктар жиынтығы ретінде көрсетуге болатын басқа жағдайларға жалпылауға болады (бірақ оларды қосуға болады).

Міне, тағы бір мысал (бекіту үшін): егер сіз Jenkins немесе TeamCity бағдарламаларымен жұмыс істеген болсаңыз, екі шешім де Java тілінде жазылғанын білесіз. Екеуі де құрастыру оркестрін және мазмұнды басқаруды басқаратын Java процестері. Атап айтқанда, олардың екеуінде де «серверден файлды/қалтаны тасымалдау» сияқты тапсырмалар бар. Мысалдар артефакт жеткізуді, бастапқы кодты тасымалдауды (агент кодты репозиторийден тікелей жүктеп алмағанда, бірақ сервер оны ол үшін жасайды) және журналға кіруді қамтиды. Бұл тапсырмалардың барлығында әртүрлі IO жүктемелері бар. Бұл күрделі бизнес логикасына жауап беретін сервер үлкен деректер ағындарын өзі арқылы тиімді түрде итермелей алуы керек дегенді білдіреді. Ең қызығы, бұл операцияны дәл сол схеманы пайдаланып Nginx-ке беруге болады (деректер кілтін сұрауға қосуды қоспағанда).

Алайда, егер біз жүйемізге оралсақ, біз ұқсас схеманы аламыз:

Көріп отырғаныңыздай, жүйе түбегейлі күрделене түсті. Бұл енді файлдарды жергілікті түрде сақтайтын шағын процесс емес. Ол енді күрделі қолдауды, API нұсқасын басқаруды және т.б. қажет етеді. Сондықтан, барлық диаграммалар сызылғаннан кейін, ауқымдылықтың инвестициялауға тұрарлық екенін мұқият бағалаған дұрыс. Дегенмен, жүйені кеңейту мүмкіндігін алғыңыз келсе (оның ішінде пайдаланушылардың одан да көп санын өңдеу үшін), сізге осындай шешімдерге жүгінуге тура келеді. Дегенмен, нәтижесінде жүйенің архитектурасы жоғары жүктемеге дайындалады (іс жүзінде әрбір құрамдас көлденең масштабтау үшін клондауға болады). Жүйені өшірмей-ақ жаңартуға болады (кейбір операциялар жай ғана баяуырақ болады).

Бастапқыда айтқанымдай, қазіргі уақытта бірқатар онлайн-қызметтердің жүктемесі артып отыр. Ал олардың кейбіреулері дұрыс жұмысын тоқтатты. Негізінде, жүйелер бизнес ақша табуы керек сәтте істен шықты. Осылайша, жеткізуді кешіктірудің орнына, тұтынушыларға «жеткізуіңізді алдағы бірнеше айға жоспарлаңыз» деген ұсыныстың орнына, жүйе жай ғана «бәсекелестерге барыңыз» деді. Бұл, шын мәнінде, төмен өнімділіктің бағасы: жоғалтулар пайда ең жоғары болған кезде пайда болады.

қорытынды

Бұл тәсілдердің барлығы біраз уақыттан бері болды. Мысалы, VK кескіндерге қызмет көрсету үшін статикалық мазмұнды хостинг идеясын бұрыннан пайдаланып келеді. Көптеген онлайн ойындар ойыншыларды аймақ бойынша бөлу немесе ойын орындарын бөлу үшін (әлемнің өзі біртұтас болса) sharding пайдаланады. Оқиға көзі электрондық поштада белсенді қолданылады. Деректерді үздіксіз қабылдайтын сауда қолданбаларының көпшілігі шын мәнінде кіріс деректерді сүзу үшін CQRS тәсіліне негізделген. Ал көлденең масштабтау көптеген қызметтерде бұрыннан қолданылған.

Дегенмен, ең бастысы, осы үлгілердің барлығын заманауи қолданбаларда қолдану өте оңай болды (әрине, егер олар сәйкес болса). Бұлттық есептеулер әртүрлі деректер орталықтарында бөлек бөлінген серверлерге тапсырыс беруден әлдеқайда оңай болатын қораптан тыс бөлу және көлденең масштабтауды ұсынады. CQRS, тек RX сияқты кітапханалардың дамуының арқасында ғана оңайырақ болды. Он жыл бұрын бірнеше веб-сайттар бұған қолдау көрсете алар еді. Оқиға көзін алу дайын Apache Kafka контейнерлерінің арқасында орнату өте оңай. Он жыл бұрын бұл жаңашыл болар еді; қазір үйреншікті жағдайға айналды. Сол сияқты, Static Content Hosting көмегімен пайдаланушыға ыңғайлы технологиялар (оның ішінде егжей-тегжейлі құжаттама және үлкен жауап беру дерекқоры) бұл тәсілді бұрынғыдан да қарапайым етті.

Нәтижесінде, біршама күрделі архитектуралық үлгілерді жүзеге асыру қазір әлдеқайда оңай болды, яғни оларды ертерек қарастырған жөн. Он жылдық қолданба жоғары енгізу және операциялық шығындарға байланысты жоғарыдағы шешімдердің бірінен бас тартуы мүмкін болса да, жаңа қолданба немесе мүмкін рефакторинг енді архитектуралық жағынан кеңейтілетін (өнімділік тұрғысынан) және жаңа клиент сұрауларына дайын (мысалы, жеке деректерді оқшаулау үшін) қызмет жасай алады.

Ең бастысы: егер сізде қарапайым қолданба болса, бұл тәсілдерді қолданбаңыз. Иә, олар әдемі және қызықты, бірақ 100 адамдық ең жоғары трафикі бар сайт үшін классикалық монолит жиі жеткілікті болуы мүмкін (кем дегенде сыртында; ішкі жағынан, барлығын модульдерге бөлуге болады және т.б.).

Ақпарат көзі: www.habr.com