Эй Хабр!

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

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

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

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

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

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

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

CQRS

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

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

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

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

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

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

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

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

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

Оқиға көзі

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

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

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

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

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

• Әрбір кіріс сұрау бір кезекке қойылады.
• Сұрауды өңдеу кезінде қызмет тапсырмаларды басқа кезектерге қоюы мүмкін.
• Әрбір кіріс оқиғаның идентификаторы болады (ол дедупликация үшін қажет).
• Кезек идеологиялық тұрғыдан «тек қосу» схемасы бойынша жұмыс істейді. Одан элементтерді жою немесе оларды қайта реттеу мүмкін емес.
• Кезек ФИФО схемасы бойынша жұмыс істейді (таутология үшін кешірім сұраймыз). Егер параллельді орындау қажет болса, онда бір кезеңде объектілерді әртүрлі кезектерге жылжыту керек.

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

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

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

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

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

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

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

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

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

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

Sharding

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

қорытынды

Бұл тәсілдердің барлығы бұрын белгілі болған. Дәл сол ВК суреттерді көрсету үшін Static Content Hosting идеясын бұрыннан пайдаланып келеді. Көптеген онлайн ойындар ойыншыларды аймақтарға бөлу немесе ойын орындарын (егер әлемнің өзі бір болса) бөлу үшін Sharding схемасын пайдаланады. Оқиға көзін алу әдісі электрондық поштада белсенді қолданылады. Деректер үнемі қабылданатын сауда қолданбаларының көпшілігі шын мәнінде алынған деректерді сүзгілеу мүмкіндігіне ие болу үшін CQRS тәсіліне негізделген. Көлденең масштабтау көптеген қызметтерде ұзақ уақыт бойы қолданылған.

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

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

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

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