Эй Хабр!

Коронавируска байланыштуу болуп жаткан окуяларга байланыштуу бир катар интернет кызматтары жүктөмдү ала баштады. Мисалы, Улуу Британиянын соода түйүндөрүнүн бири жөн гана онлайн заказ сайтын токтотту., анткени кубаттуулук жетишсиз болгон. Ал эми жөн гана күчтүү жабдууларды кошуу менен серверди тездетүү дайыма эле мүмкүн боло бербейт, бирок кардарлардын суроо-талаптары иштелип чыгышы керек (же алар атаандаштарга барат).

Бул макалада мен кыскача тез жана катачылыкка чыдамдуу кызматты түзүүгө мүмкүндүк берген популярдуу тажрыйбалар жөнүндө айтып берем. Бирок, мүмкүн болгон иштеп чыгуу схемаларынан мен азыр иштеп жаткандарды гана тандап алдым колдонууга жеңил. Ар бир нерсе үчүн сизде даяр китепканалар бар, же булут платформасын колдонуу менен көйгөйдү чечүү мүмкүнчүлүгү бар.

Горизонталдык масштабдоо

Эң жөнөкөй жана эң белгилүү пункт. Шарттуу түрдө жүктү бөлүштүрүүнүн эң кеңири таралган эки схемасы горизонталдуу жана вертикалдуу масштабдоо болуп саналат. Биринчи учурда сиз кызматтардын параллелдүү иштешине уруксат бересиз, ошону менен жүктү алардын ортосунда бөлүштүрөсүз. экинчи сиз күчтүү серверлерге заказ кылсаңыз же кодду оптималдаштырасыз.

Мисалы, мен абстракттуу булут файлдарын сактайм, башкача айтканда, OwnCloud, OneDrive жана башкалар.

Мындай схеманын стандарттуу сүрөтү төмөндө, бирок ал системанын татаалдыгын гана көрсөтөт. Анткени, биз кандайдыр бир жол менен кызматтарды синхрондоштуруу керек. Колдонуучу файлды планшеттен сактап, анан аны телефондон көргүсү келсе эмне болот?

Мамилелер ортосундагы айырма: вертикалдык масштабда биз түйүндөрдүн күчүн көбөйтүүгө даярбыз, ал эми горизонталдуу масштабда жүктү бөлүштүрүү үчүн жаңы түйүндөрдү кошууга даярбыз.

CQRS

Command Query жоопкерчилигин бөлүү Бул абдан маанилүү үлгү, анткени ал ар кандай кардарларга ар кандай кызматтарга туташуу үчүн гана эмес, ошондой эле бир эле окуя агымдарын алууга мүмкүндүк берет. Анын артыкчылыктары жөнөкөй колдонуу үчүн ачык-айкын эмес, бирок ал бош эмес кызмат үчүн өтө маанилүү (жана жөнөкөй). Анын маңызы: кирүүчү жана чыгуучу маалымат агымдары кесилишкен болбошу керек. Башкача айтканда, сиз суроо-талапты жөнөтүп, жооп күтө албайсыз, анын ордуна сиз А кызматына суроо-талап жөнөтөсүз, бирок Б кызматынан жооп аласыз.

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

1. Кардар серверге суроо-талап жөнөттү.
2. Сервер узакка иштетиле баштады.
3. Сервер кардарга жыйынтык менен жооп берди.

Келгиле, 2-пунктта байланыш үзүлдү (же тармак кайра кошулду, же колдонуучу байланышты үзүп, башка бетке өтүп кетти) деп элестетип көрөлү. Бул учурда, сервер үчүн колдонуучуга так эмне иштетилгени жөнүндө маалымат менен жооп жөнөтүү кыйынга турат. CQRS колдонуу, ырааттуулугу бир аз башкача болот:

1. Кардар жаңыртууларга жазылды.
2. Кардар серверге суроо-талап жөнөттү.
3. Сервер "суроо кабыл алынды" деп жооп берди.
4. Сервер "1" чекиттен канал аркылуу жыйынтык менен жооп берди.

Көрүнүп тургандай, схема бир аз татаалыраак. Мындан тышкары, интуитивдик суроо-жооп ыкмасы бул жерде жок. Бирок, сиз көрүп тургандай, өтүнүчтү иштеп жатканда байланыш үзүлүшү катага алып келбейт. Андан тышкары, эгер чындыгында колдонуучу кызматка бир нече түзмөктөн (мисалы, уюлдук телефондон жана планшеттен) туташкан болсо, жооп эки түзмөккө тең келгенин текшере аласыз.

Кызыгы, кирүүчү билдирүүлөрдү иштетүү коду кардар өзү таасир эткен окуялар үчүн да, башка окуялар үчүн да, анын ичинде башка кардарлардан келген окуялар үчүн да бирдей болуп калат (100% эмес).

Бирок, чындыгында, бир багыттуу агым функционалдык стилде (RX жана ушул сыяктууларды колдонуу менен) иштетиле тургандыктан, кошумча бонус алабыз. Ал эми бул олуттуу плюс, анткени, чынында, колдонмо толугу менен реактивдүү болушу мүмкүн, ошондой эле функционалдык ыкманы колдонуу менен. майлуу программалар үчүн, бул олуттуу өнүктүрүү жана колдоо ресурстарын үнөмдөй алат.

Эгерде биз бул ыкманы горизонталдык масштабдоо менен айкалыштырсак, анда бонус катары биз бир серверге суроо-талаптарды жөнөтүп, башкасынан жооп алуу мүмкүнчүлүгүнө ээ болобуз. Ошентип, кардар өзүнө ыңгайлуу болгон кызматты тандап алат жана ичиндеги система дагы окуяларды туура иштете алат.

Event Sourcing

Белгилүү болгондой, бөлүштүрүлгөн системанын негизги өзгөчөлүктөрүнүн бири жалпы убакыттын, жалпы критикалык бөлүмдүн жоктугу. Бир процесс үчүн сиз синхрондоштурууну жасай аласыз (ошол эле мутекстерде), анын ичинде бул кодду башка эч ким аткарбай жатканына ишенесиз. Бирок, бул бөлүштүрүлгөн система үчүн кооптуу, анткени ал ашыкча чыгымды талап кылат, ошондой эле масштабдын бардык сулуулугун жок кылат - бардык компоненттер дагы бирөөнү күтүшөт.

Бул жерден биз маанилүү фактыны алабыз - тез бөлүштүрүлгөн системаны синхрондоштуруу мүмкүн эмес, анткени анда биз өндүрүмдүүлүктү азайтабыз. Башка жагынан алганда, биз көп учурда компоненттеринин ортосунда белгилүү бир ырааттуулук керек. Жана бул үчүн сиз менен мамилени колдоно аласыз акыркы ырааттуулук, анда акыркы жаңыртуудан кийин белгилүү бир убакыт аралыгында эч кандай маалымат өзгөрбөсө (“акыры”), бардык сурамдар акыркы жаңыртылган маанини кайтарат деп кепилдик берилет.

Бул классикалык маалымат базалары үчүн абдан көп колдонулат экенин түшүнүү маанилүү күчтүү ырааттуулук, бул жерде ар бир түйүн бирдей маалыматка ээ (бул көбүнчө транзакция экинчи сервер жооп бергенден кийин гана түзүлгөн деп эсептелген учурда жетишилет). Бул жерде обочолонуу деңгээлине байланыштуу кээ бир эс алуулар бар, бирок жалпы идея ошол эле бойдон калууда - сиз толугу менен гармонияланган дүйнөдө жашай аласыз.

Бирок, келгиле, баштапкы тапшырмага кайрылып көрөлү. системасынын бир бөлүгү менен курууга мүмкүн болсо акыркы ырааттуулук, анда биз төмөнкү диаграмманы түзө алабыз.

Бул ыкманын маанилүү өзгөчөлүктөрү:

• Ар бир келген суроо-талап бир кезекке коюлат.
• Суроо-талапты иштеп чыгууда кызмат башка кезектерге тапшырмаларды да коюшу мүмкүн.
• Ар бир келген окуянын идентификатору бар (бул дедупликация үчүн зарыл).
• Кезек идеологиялык жактан «кошумча гана» схемасы боюнча иштейт. Андан элементтерди алып салуу же аларды кайра иретке келтирүү мүмкүн эмес.
• Кезек FIFO схемасы боюнча иштейт (таутология үчүн кечирим сурайм). Эгерде сизге параллелдүү аткаруу керек болсо, анда бир этапта объекттерди ар кандай кезектерге жылдыруу керек.

Эске сала кетейин, биз онлайн файлдарды сактоо маселесин карап жатабыз. Бул учурда, система төмөнкүдөй көрүнөт:

Диаграммадагы кызматтар өзүнчө серверди билдирбеши маанилүү. Ал тургай, процесс бирдей болушу мүмкүн. Дагы бир нерсе маанилүү: идеологиялык жактан бул нерселер горизонталдуу масштабды оңой колдонууга боло тургандай бөлүнгөн.

Ал эми эки колдонуучу үчүн диаграмма мындай болот (ар кандай колдонуучулар үчүн арналган кызматтар ар кандай түстө көрсөтүлгөн):

Мындай айкалыштыруудан бонустар:

• Маалыматты иштетүү кызматтары бөлүнгөн. Кезектер да бөлүнгөн. Эгер системанын өткөрүү жөндөмдүүлүгүн жогорулатуу керек болсо, анда биз жөн гана көбүрөөк серверлерде көбүрөөк кызматтарды ишке киргизишибиз керек.
• Колдонуучудан маалымат алганда, биз маалыматтар толугу менен сакталганга чейин күтпөйбүз. Тескерисинче, жөн эле “макул” деп жооп берип, анан акырындап иштей башташыбыз керек. Ошол эле учурда, кезек чокуларды жылмакай кылат, анткени жаңы объектти кошуу тез арада ишке ашат жана колдонуучу бүт циклден толук өтүүнү күтпөйт.
• Мисал катары, мен окшош файлдарды бириктирүүгө аракет кылган дедупликация кызматын коштум. Эгерде ал 1% учурларда узак убакыт бою иштесе, кардар аны байкабай калат (жогоруну караңыз), бул чоң плюс, анткени бизден XNUMX% ылдамдык жана ишенимдүүлүк талап кылынбайт.

Бирок, кемчиликтер дароо эле көрүнүп турат:

• Биздин система өзүнүн катуу ырааттуулугун жоготту. Бул, мисалы, сиз ар кандай кызматтарга жазылсаңыз, анда теориялык жактан башка абалды ала аласыз (анткени кызматтардын биринде ички кезектен билдирүү алууга убакыт жок болушу мүмкүн) дегенди билдирет. Дагы бир натыйжасы катары, система азыр жалпы убакыт жок. Башкача айтканда, бардык окуяларды жөн эле келүү убактысы боюнча иреттөө мүмкүн эмес, анткени серверлердин ортосундагы сааттар синхрондуу болбошу мүмкүн (андан тышкары, эки серверде бир эле убакыт утопия).
• Эми эч кандай окуяларды жөн эле артка жылдырууга болбойт (база менен жасалышы мүмкүн). Анын ордуна, сиз жаңы окуя кошуу керек - компенсация окуясы, бул акыркы абалды талап кылынган абалга өзгөртөт. Окшош аймактан мисал катары: тарыхты кайра жазбастан (айрым учурларда бул жаман), сиз gitтеги милдеттенмени артка кайтара албайсыз, бирок сиз атайын жасай аласыз. артка кайтаруу, бул жөн гана эски абалын кайтарат. Бирок, жаңылыштык да, артка кайтаруу да тарыхта кала берет.
• Маалымат схемасы чыгаруудан чыгарууга чейин өзгөрүшү мүмкүн, бирок эски окуялар мындан ары жаңы стандартка жаңыртыла албайт (анткени окуяларды принцип боюнча өзгөртүү мүмкүн эмес).

Көрүнүп тургандай, Event Sourcing CQRS менен жакшы иштейт. Андан тышкары, эффективдүү жана ыңгайлуу кезектер менен системаны ишке ашыруу, бирок маалымат агымдарын бөлбөстөн, өзүнчө эле кыйын, анткени кезектердин бүтүндөй оң таасирин нейтралдаштырган синхрондоштуруу пункттарын кошууга туура келет. Бир эле учурда эки ыкманы колдонуу менен, программанын кодун бир аз тууралоо керек. Биздин учурда, файлды серверге жөнөтүүдө "макул" гана жооп келет, бул "файлды кошуу операциясы сакталды" дегенди гана билдирет. Формалдуу түрдө бул маалыматтар башка түзмөктөрдө жеткиликтүү дегенди билдирбейт (мисалы, дедупликация кызматы индексти кайра түзө алат). Бирок, бир нече убакыт өткөндөн кийин, кардар "X файлы сакталды" стилинде эскертме алат.

Натыйжада:

• Файлды жөнөтүү статустарынын саны көбөйүүдө: классикалык "файл жөнөтүлгөн" дегендин ордуна экөөнү алабыз: "файл сервердеги кезекке кошулду" жана "файл сактагычта сакталды." Акыркысы башка түзмөктөр файлды кабыл ала башташы мүмкүн дегенди билдирет (кезектер ар кандай ылдамдыкта иштешине ылайыкталган).
• Тапшыруу маалыматы азыр ар кандай каналдар аркылуу келип жаткандыктан, биз файлды иштетүү статусун алуу үчүн чечимдерди табышыбыз керек. Мунун кесепети: классикалык суроо-жооптон айырмаланып, кардар файлды иштеп жатканда кайра иштетилиши мүмкүн, бирок бул иштетүүнүн абалы туура болот. Мындан тышкары, бул нерсе, негизинен, кутудан тышкары иштейт. Натыйжада: биз азыр катачылыктарга көбүрөөк чыдайбыз.

КХЛ

Жогоруда айтылгандай, окуя булактарын системалары катуу ырааттуулук жок. Бул биз алардын ортосунда эч кандай синхрондоштуруусуз бир нече сактагычтарды колдоно алабыз дегенди билдирет. Биздин көйгөйгө жакындап, биз:

• Файлдарды түрү боюнча бөлүңүз. Мисалы, сүрөттөрдү/видеолорду чечмелеп, эффективдүү форматын тандаса болот.
• Өлкө боюнча өзүнчө эсептер. Көптөгөн мыйзамдарга ылайык, бул талап кылынышы мүмкүн, бирок бул архитектуралык схема автоматтык түрдө мындай мүмкүнчүлүктү берет

Эгер сиз маалыматты бир сактагычтан экинчисине өткөргүңүз келсе, анда стандарттык каражаттар мындан ары жетишсиз. Тилекке каршы, бул учурда кезекти токтотуп, миграцияны жасап, анан башташ керек. Жалпы учурда, маалыматтарды "учуп баратканда" өткөрүп берүү мүмкүн эмес, бирок, окуя кезеги толугу менен сакталса жана сизде мурунку сактоо абалынын сүрөттөрү болсо, анда биз окуяларды төмөнкүдөй кайталай алабыз:

• Окуя булагында ар бир окуянын өзүнүн идентификатору болот (идеалында, азайбайт). Бул сактагычка талааны кошо алабыз дегенди билдирет - акыркы иштетилген элементтин идентификатору.
• Биз кезекти кайталайбыз, ошондуктан бардык окуялар бир нече көзкарандысыз сактагычтар үчүн иштетилет (биринчиси, маалыматтар буга чейин сакталган, ал эми экинчиси жаңы, бирок дагы эле бош). Экинчи кезек, албетте, азырынча иштелбей жатат.
• Биз экинчи кезекти ишке киргизебиз (б.а. окуяларды кайталай баштайбыз).
• Жаңы кезек салыштырмалуу бош болгондо (башкача айтканда, элементти кошуу менен аны алуунун ортосундагы орточо убакыт айырмасы алгылыктуу), сиз окурмандарды жаңы сактагычка которуштурууну баштасаңыз болот.

Көрүнүп тургандай, биздин системада катуу ырааттуулук болгон эмес жана азыр да жок. Болгону акыркы ырааттуулук бар, башкача айтканда, окуялар бир тартипте (бирок, балким, ар кандай кечигүү менен) иштетилет деген кепилдик бар. Жана муну колдонуу менен, биз дүйнөнүн башка тарабына системаны токтотпостон, маалыматтарды салыштырмалуу оңой өткөрө алабыз.

Ошентип, файлдарды онлайн сактоо боюнча мисалыбызды улантуу менен, мындай архитектура бизге бир катар бонустарды берет:

• Биз объекттерди колдонуучуларга динамикалык жол менен жакындата алабыз. Ушундай жол менен сиз кызматтын сапатын жакшырта аласыз.
• Биз кээ бир маалыматтарды компаниялардын ичинде сактай алабыз. Мисалы, Enterprise колдонуучулары көбүнчө өз маалыматтарын көзөмөлдөнүүчү маалымат борборлорунда сакталышын талап кылышат (маалыматтардын агып кетишин болтурбоо үчүн). Sharding аркылуу биз муну оңой эле колдой алабыз. Ал эми кардарда туура келген булут бар болсо, тапшырма дагы жеңил болот (мисалы, Azure өзүн өзү уюштурду).
• Эң негизгиси, биз муну кылбашыбыз керек. Баарынан мурда, биз бардык аккаунттар үчүн бир сактагычка абдан ыраазы болмокпуз (тез арада иштей баштоо үчүн). Ал эми бул системанын негизги өзгөчөлүгү, ал кеңейтилсе да, баштапкы этапта абдан жөнөкөй. Сиз миллиондогон өзүнчө көз карандысыз кезектер менен иштеген кодду дароо жазуунун кажети жок, ж.б. Зарыл болсо, бул келечекте жасалышы мүмкүн.

Статикалык мазмун хостинги

Бул пункт абдан ачык сезилиши мүмкүн, бирок ал дагы эле аздыр-көптүр стандарттуу жүктөлгөн колдонмо үчүн зарыл. Анын маңызы жөнөкөй: бардык статикалык мазмун тиркеме жайгашкан серверден эмес, атайын ушул тапшырмага арналган атайын серверлерден бөлүштүрүлөт. Натыйжада, бул операциялар тезирээк аткарылат (шарттуу nginx файлдарды Java серверине караганда тезирээк жана арзаныраак тейлейт). Plus CDN архитектурасы (Мазмун жеткирүү тармагы) биздин файлдарды акыркы колдонуучуларга жакыныраак жайгаштырууга мүмкүндүк берет, бул сервис менен иштөөнүн ыңгайлуулугуна оң таасирин тийгизет.

Статикалык мазмундун эң жөнөкөй жана стандарттуу мисалы бул веб-сайт үчүн скрипттердин жана сүрөттөрдүн жыйындысы. Алар менен баары жөнөкөй - алар алдын ала белгилүү, андан кийин архив CDN серверлерине жүктөлөт, ал жерден алар акыркы колдонуучуларга таратылат.

Бирок, чындыгында, статикалык мазмун үчүн, сиз ламбда архитектурасына окшош ыкманы колдоно аласыз. Келгиле, биздин тапшырмабызга (онлайн файл сактагыч) кайрылып көрөлү, анда биз файлдарды колдонуучуларга таратышыбыз керек. Эң жөнөкөй чечим - бул ар бир колдонуучунун суроо-талабы үчүн бардык зарыл текшерүүлөрдү (авторизация ж. Бул ыкманын негизги кемчилиги статикалык мазмун (жана белгилүү бир версиясы бар файл, чындыгында, статикалык мазмун) бизнес логикасын камтыган сервер тарабынан бөлүштүрүлөт. Анын ордуна, сиз төмөнкү диаграмманы түзө аласыз:

• Сервер жүктөө URL дарегин берет. Бул file_id + ачкыч формасында болушу мүмкүн, бул жерде ачкыч кийинки XNUMX саатка ресурска кирүү укугун берген мини-санариптик кол тамга.
• Файл төмөнкү параметрлер менен жөнөкөй nginx тарабынан таратылат:
  • Мазмунду кэштөө. Бул кызмат өзүнчө серверде жайгаштырылышы мүмкүн болгондуктан, биз дискте бардык акыркы жүктөлгөн файлдарды сактоо мүмкүнчүлүгү менен келечекке резерв калтырдык.
  • Байланышты түзүү учурунда ачкычты текшерүү
• Кошумча: агымдык мазмунду иштетүү. Мисалы, эгерде биз кызматтагы бардык файлдарды кыссак, анда биз бул модулда түздөн-түз разрядды ача алабыз. Натыйжада: IO операциялары тиешелүү жерде жасалат. Java'дагы архиватор көп кошумча эстутумду оңой бөлөт, бирок бизнес логикасы менен кызматты Rust/C++ шартына кайра жазуу да натыйжасыз болушу мүмкүн. Биздин учурда, ар кандай процесстер (же кызмат көрсөтүүлөр) колдонулат, ошондуктан биз бизнес логикасын жана IO операцияларын натыйжалуу бөлүп алабыз.

Бул схема статикалык мазмунду таратууга анча окшош эмес (анткени биз бүтүндөй статикалык пакетти бир жерге жүктөбөйбүз), бирок чындыгында бул ыкма так өзгөрүлгүс маалыматтарды таратууга байланыштуу. Мындан тышкары, бул схеманы мазмун жөн эле статикалык эмес, өзгөрүлгүс жана жок кылынбаган блоктордун жыйындысы катары көрсөтүүгө болот (аларды кошууга болот) башка учурларда жалпылаштырууга болот.

Дагы бир мисал (күчөтүү үчүн): эгер сиз Jenkins/TeamCity менен иштеген болсоңуз, анда эки чечим тең Java тилинде жазылганын билесиз. Экөө тең түзүүчү оркестрди жана мазмунду башкарууну тейлеген Java процесси. Атап айтканда, экөөнүн тең "серверден файлды/папканы өткөрүп берүү" сыяктуу тапшырмалары бар. Мисал катары: артефакттарды чыгаруу, баштапкы кодду өткөрүп берүү (агент кодду репозиторийден түз жүктөп албаса, бирок сервер аны ал үчүн кылат), журналдарга кирүү. Бул милдеттердин баары IO жүгү менен айырмаланат. Башкача айтканда, татаал бизнес логикасы үчүн жооптуу сервер ошол эле учурда чоң маалыматтардын агымын өзү аркылуу эффективдүү түртө алышы керек экен. Эң кызыгы, мындай операцияны ошол эле схема боюнча бир эле nginxке өткөрүп берсе болот (маалымат ачкычы сурамга кошулушу керек).

Бирок, биз системабызга кайтып келсек, биз окшош диаграмманы алабыз:

Көрүнүп тургандай, система түп-тамырынан бери татаал болуп калды. Эми бул файлдарды локалдык түрдө сактаган мини-процесс эмес. Эми эң жөнөкөй колдоо эмес, API версиясын башкаруу ж.б.у.с. Ошондуктан, бардык схемалар чийилгенден кийин, кеңейүү баасына татыктуубу, майда-чүйдөсүнө чейин баалоо жакшы. Бирок, эгер сиз системаны кеңейтүүнү кааласаңыз (анын ичинде колдонуучулардын дагы көп саны менен иштөө үчүн), анда ушул сыяктуу чечимдерге барууга туура келет. Бирок, натыйжада, система архитектуралык жактан жогорулатылган жүктөмгө даяр (дээрлик ар бир компонентти горизонталдуу масштабдоо үчүн клондосо болот). Системаны токтотпостон жаңыртууга болот (жөн гана кээ бир операциялар бир аз жайлатат).

Мен башында айткандай, азыр бир катар интернет кызматтары жогорулатылган жүктү ала баштады. Ал эми алардын айрымдары жөн эле туура иштебей башташты. Чынында, системалар бизнес акча табышы керек болгон учурда иштебей калган. Башкача айтканда, кийинкиге калтырылган жеткирүүнүн ордуна, кардарларга "келки айларга жеткирүүңүздү пландаштырыңыз" дегендин ордуна, система жөн гана "атаандаштарыңызга барыңыз" деп айтты. Чынында, бул төмөн өндүрүмдүүлүктүн баасы: жоготуулар так пайда эң көп болгондо пайда болот.

жыйынтыктоо

Бул ыкмалардын баары мурда белгилүү болгон. Ошол эле VK сүрөттөрдү көрсөтүү үчүн Static Content Hosting идеясын көптөн бери колдонуп келет. Көптөгөн онлайн оюндар оюнчуларды аймактарга бөлүү же оюн жайгашкан жерлерди бөлүү үчүн Sharding схемасын колдонушат (эгерде дүйнөнүн өзү бир болсо). Event Sourcing ыкмасы электрондук почтада активдүү колдонулат. Маалыматтар тынымсыз алынып турган көпчүлүк соода тиркемелери чындыгында алынган маалыматтарды чыпкалоо үчүн CQRS ыкмасына негизделген. Ооба, горизонталдык масштабдоо көптөгөн кызматтарда көптөн бери колдонулуп келет.

Бирок, эң негизгиси, бул моделдердин баары заманбап колдонмолордо колдонуу үчүн абдан жеңил болуп калды (алар, албетте, ылайыктуу болсо). Булуттар Sharding жана горизонталдуу масштабды дароо сунуштайт, бул ар кандай маалымат борборлорунда ар кандай арналган серверлерге заказ кылуудан алда канча жеңил. CQRS, RX сыяктуу китепканалардын өнүгүшүнөн улам бир топ жеңил болуп калды. Болжол менен 10 жыл мурун, сейрек веб-сайт муну колдоого алмак. Apache Kafka менен даяр контейнерлердин аркасында Event Sourcing да укмуштуудай оңой орнотуу. 10 жыл мурун бул жаңылык болмок, азыр кадимки көрүнүш. Static Content Hosting менен да ушундай: ыңгайлуураак технологиялардын аркасында (анын ичинде деталдуу документтер жана жооптордун чоң базасы бар), бул ыкма дагы жөнөкөй болуп калды.

Натыйжада, бир катар татаал архитектуралык үлгүлөрдү ишке ашыруу азыр алда канча жөнөкөй болуп калды, демек, аны алдын ала жакшыраак карап чыгуу керек. Эгерде он жылдык тиркемеде жогорудагы чечимдердин бири ишке ашыруунун жана эксплуатациялоонун кымбаттыгынан улам четке кагылган болсо, азыр жаңы тиркемеде же рефакторингден кийин сиз архитектуралык жактан да кеңейе турган кызматты түзө аласыз ( аткаруу боюнча) жана кардарлардын жаңы суроо-талаптарына даяр (мисалы, жеке маалыматтарды локалдаштыруу үчүн).

Эң негизгиси: жөнөкөй колдонмоңуз болсо, бул ыкмаларды колдонбоңуз. Ооба, алар кооз жана кызыктуу, бирок 100 адамдан турган эң жогорку иш сапары менен сайт үчүн, сиз көп учурда классикалык монолит менен ала аласыз (жок дегенде сыртынан, ичиндеги бардыгын модулдарга бөлсө болот, ж.б.).

Source: www.habr.com