Хөөе Хабр!

Коронавирусын улмаас сүүлийн үед болж буй үйл явдлуудын хүрээнд интернетийн хэд хэдэн үйлчилгээ ачаалал ихсэж эхэлсэн. Жишээлбэл, Их Британийн жижиглэн худалдааны сүлжээнүүдийн нэг нь онлайн захиалгын сайтаа зогсоов., учир нь хүчин чадал хүрэлцэхгүй байсан. Илүү хүчирхэг тоног төхөөрөмж нэмж серверийг хурдасгах нь үргэлж боломжгүй байдаг, гэхдээ үйлчлүүлэгчийн хүсэлтийг боловсруулах ёстой (эсвэл тэд өрсөлдөгчид рүү очно).

Энэ нийтлэлд би хурдан бөгөөд алдаатай үйлчилгээг бий болгох боломжийг олгодог түгээмэл туршлагын талаар товч ярих болно. Гэсэн хэдий ч, боломжит хөгжлийн схемүүдээс би зөвхөн одоо байгаа хувилбаруудыг сонгосон хэрэглэхэд хялбар. Зүйл бүрийн хувьд та бэлэн номын сантай эсвэл үүлэн платформ ашиглан асуудлыг шийдэх боломжтой.

Хэвтээ масштаб

Хамгийн энгийн бөгөөд хамгийн алдартай цэг. Уламжлал ёсоор ачааллын хуваарилалтын хамгийн түгээмэл хоёр схем бол хэвтээ ба босоо масштаб юм. Эхний тохиолдолд Та үйлчилгээг зэрэгцүүлэн ажиллуулахыг зөвшөөрч, ингэснээр ачааллыг хооронд нь хуваарилдаг. Хоёрдугаарт Та илүү хүчирхэг сервер захиалах эсвэл кодыг оновчтой болгох.

Жишээлбэл, би хийсвэр үүлэн файлын хадгалах санг, өөрөөр хэлбэл OwnCloud, OneDrive гэх мэт аналогийг авах болно.

Ийм хэлхээний стандарт зургийг доор харуулав, гэхдээ энэ нь зөвхөн системийн нарийн төвөгтэй байдлыг харуулдаг. Эцсийн эцэст бид ямар нэгэн байдлаар үйлчилгээг синхрончлох хэрэгтэй. Хэрэв хэрэглэгч таблетаас файл хадгалаад утсаараа үзэхийг хүсвэл яах вэ?

Аргын хоорондох ялгаа: босоо масштабаар бид зангилааны хүчийг нэмэгдүүлэхэд бэлэн байна, хэвтээ масштабаар бид ачааллыг хуваарилах шинэ зангилаа нэмэхэд бэлэн байна.

CQRS

Command Query Хариуцлагын тусгаарлалт Энэ нь өөр өөр үйлчлүүлэгчдэд өөр өөр үйлчилгээнд холбогдохоос гадна ижил үйл явдлын урсгалыг хүлээн авах боломжийг олгодог тул нэлээд чухал загвар юм. Энгийн хэрэглээний хувьд түүний ашиг тус нь тийм ч тодорхой биш боловч завгүй үйлчилгээний хувьд маш чухал (мөн энгийн) юм. Үүний мөн чанар: ирж буй болон гарч буй мэдээллийн урсгалууд огтлолцох ёсгүй. Өөрөөр хэлбэл, та хүсэлт илгээж, хариу хүлээх боломжгүй, харин А үйлчилгээ рүү хүсэлт илгээх боловч В үйлчилгээнээс хариу хүлээн авна.

Энэ аргын анхны урамшуулал бол урт хүсэлтийг гүйцэтгэх явцад холболтыг (энэ үгийн өргөн утгаараа) таслах чадвар юм. Жишээлбэл, илүү бага стандарт дарааллыг авч үзье:

1. Үйлчлүүлэгч сервер рүү хүсэлт илгээсэн.
2. Сервер удаан хугацаанд боловсруулагдаж эхэлсэн.
3. Сервер нь үйлчлүүлэгчид хариу өгсөн.

2-р цэгт холболт тасарсан (эсвэл сүлжээ дахин холбогдсон эсвэл хэрэглэгч өөр хуудас руу орж холболтыг тасалсан) гэж төсөөлөөд үз дээ. Энэ тохиолдолд сервер нь яг юу боловсруулсан талаарх мэдээллийг хэрэглэгч рүү илгээхэд хэцүү байх болно. CQRS-ийг ашигласнаар дараалал нь арай өөр байх болно:

1. Үйлчлүүлэгч шинэчлэлтүүдэд бүртгүүлсэн.
2. Үйлчлүүлэгч сервер рүү хүсэлт илгээсэн.
3. Сервер "хүсэлтийг хүлээн авлаа" гэж хариулсан.
4. Сервер "1" цэгээс сувгаар дамжуулан үр дүнг хариу өгсөн.

Таны харж байгаагаар схем нь арай илүү төвөгтэй юм. Түүгээр ч барахгүй хүсэлт-хариултын мэдрэмжтэй арга энд алга. Гэсэн хэдий ч, таны харж байгаагаар хүсэлтийг боловсруулах явцад холболт тасарвал алдаа гарахгүй. Түүнээс гадна, хэрэв хэрэглэгч хэд хэдэн төхөөрөмжөөс (жишээлбэл, гар утас, таблетаас) үйлчилгээнд холбогдсон бол хариу нь хоёр төхөөрөмжид ирж байгаа эсэхийг шалгах боломжтой.

Сонирхолтой нь, ирж буй мессежийг боловсруулах код нь үйлчлүүлэгч өөрөө нөлөөлсөн үйл явдал болон бусад үйл явдал, түүний дотор бусад үйлчлүүлэгчдээс ирсэн үйл явдлын хувьд ижил (100% биш) болдог.

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

Хэрэв бид энэ аргыг хэвтээ масштабтай хослуулбал урамшуулал болгон нэг сервер рүү хүсэлт илгээж, нөгөө серверээс хариулт авах боломжтой болно. Тиймээс үйлчлүүлэгч өөрт тохирсон үйлчилгээг сонгох боломжтой бөгөөд доторх систем нь үйл явдлыг зөв боловсруулах боломжтой хэвээр байх болно.

Үйл явдлын эх сурвалж

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

Эндээс бид чухал баримтыг олж авдаг - хурдан тархсан системийг синхрончлох боломжгүй, учир нь бид гүйцэтгэлийг бууруулна. Нөгөөтэйгүүр, бид бүрэлдэхүүн хэсгүүдийн хооронд тодорхой нийцтэй байх шаардлагатай байдаг. Үүний тулд та хандлагыг ашиглаж болно эцсийн тууштай байдал, Хэрэв сүүлийн шинэчлэлтийн дараа ("эцэст нь") тодорхой хугацаанд өгөгдөлд өөрчлөлт ороогүй тохиолдолд бүх асуулга хамгийн сүүлд шинэчлэгдсэн утгыг буцаана гэсэн баталгаатай.

Сонгодог мэдээллийн сангийн хувьд энэ нь ихэвчлэн ашиглагддаг гэдгийг ойлгох нь чухал юм хүчтэй тууштай байдал, зангилаа бүр ижил мэдээлэлтэй байдаг (энэ нь ихэвчлэн хоёр дахь сервер хариу өгсний дараа гүйлгээ хийгдсэн гэж үздэг тохиолдолд хүрдэг). Тусгаарлалтын түвшнээс шалтгаалан зарим тайвшралууд байдаг, гэхдээ ерөнхий санаа нь ижил хэвээр байна - та бүрэн зохицсон ертөнцөд амьдрах боломжтой.

Гэсэн хэдий ч анхны даалгавар руугаа буцъя. Хэрэв системийн нэг хэсэг нь хамт барьж болно эцсийн тууштай байдал, дараа нь бид дараах диаграммыг байгуулж болно.

Энэ аргын чухал шинж чанарууд:

• Ирж буй хүсэлт бүрийг нэг дараалалд байрлуулна.
• Хүсэлтийг боловсруулах явцад үйлчилгээ нь бусад дараалалд даалгавруудыг байрлуулж болно.
• Ирж буй үйл явдал бүр нь тодорхойлогчтой (энэ нь давхардал арилгахад шаардлагатай).
• Дараалал нь үзэл суртлын хувьд "зөвхөн хавсаргах" схемийн дагуу ажилладаг. Та үүнээс элементүүдийг устгах эсвэл дахин цэгцлэх боломжгүй.
• Дараалал нь FIFO схемийн дагуу ажилладаг (таутологийг уучлаарай). Хэрэв та зэрэгцээ гүйцэтгэл хийх шаардлагатай бол нэг үе шатанд объектуудыг өөр дараалалд шилжүүлэх хэрэгтэй.

Бид онлайн файл хадгалах асуудлыг авч үзэж байгааг сануулъя. Энэ тохиолдолд систем нь иймэрхүү харагдах болно.

Диаграм дээрх үйлчилгээ нь тусдаа сервер гэсэн үг биш байх нь чухал юм. Тэр ч байтугай үйл явц нь ижил байж болно. Өөр нэг чухал зүйл бол үзэл суртлын хувьд эдгээр зүйлүүд нь хэвтээ масштабыг хялбархан ашиглах боломжтой байдлаар тусгаарлагдсан байдаг.

Хоёр хэрэглэгчийн хувьд диаграмм нь иймэрхүү харагдах болно (өөр өөр хэрэглэгчдэд зориулсан үйлчилгээг өөр өөр өнгөөр ​​​​заав).

Ийм хослолын урамшуулал:

• Мэдээлэл боловсруулах үйлчилгээ нь тусдаа байдаг. Дараалал нь бас тусгаарлагдсан. Хэрэв бид системийн дамжуулах чадварыг нэмэгдүүлэх шаардлагатай бол илүү олон сервер дээр илүү олон үйлчилгээг эхлүүлэх хэрэгтэй.
• Бид хэрэглэгчээс мэдээлэл хүлээн авахдаа өгөгдөл бүрэн хадгалагдах хүртэл хүлээх шаардлагагүй болно. Харин ч бид зүгээр л “за” гэж хариулж, дараа нь аажмаар ажиллаж эхлэх хэрэгтэй. Үүний зэрэгцээ, дараалал нь оргил цэгүүдийг жигд болгодог, учир нь шинэ объект нэмэх нь хурдан явагддаг бөгөөд хэрэглэгч бүхэл бүтэн мөчлөгийг бүрэн өнгөрөхийг хүлээх шаардлагагүй болно.
• Жишээлбэл, би ижил файлуудыг нэгтгэхийг оролддог давхардал арилгах үйлчилгээг нэмсэн. Хэрэв энэ нь тохиолдлын 1% -д удаан хугацаагаар ажилладаг бол үйлчлүүлэгч үүнийг бараг анзаарахгүй (дээрхийг харна уу), энэ нь биднээс XNUMX% хурдтай, найдвартай байх шаардлагагүй болсон тул том давуу тал юм.

Гэсэн хэдий ч сул талууд нь шууд харагдах болно:

• Манай систем хатуу тууштай байдлаа алдсан. Энэ нь, жишээлбэл, хэрэв та өөр үйлчилгээнд бүртгүүлсэн бол онолын хувьд та өөр төлөвийг авах боломжтой гэсэн үг юм (учир нь аль нэг үйлчилгээ нь дотоод дарааллаас мэдэгдэл хүлээн авах цаг байхгүй байж магадгүй). Өөр нэг үр дагавар нь системд нийтлэг цаг байхгүй болсон. Жишээлбэл, серверүүдийн хоорондох цаг нь синхрон биш байж болох тул бүх үйл явдлыг зүгээр л ирсэн цагт нь ангилах боломжгүй (түүнээс гадна хоёр сервер дээр ижил цаг нь утопи юм).
• Одоо ямар ч үйл явдлыг зүгээр л буцаах боломжгүй (мэдээллийн сантай адил). Үүний оронд та шинэ үйл явдал нэмэх хэрэгтэй - нөхөн төлбөрийн үйл явдал, энэ нь сүүлчийн төлөвийг шаардлагатай болгож өөрчлөх болно. Үүнтэй төстэй газраас жишээ авбал: түүхийг дахин бичихгүйгээр (зарим тохиолдолд энэ нь муу байдаг) та git дээр хийсэн амлалтаа буцаах боломжгүй, гэхдээ та тусгай зүйл хийж болно. буцаах үүрэг, энэ нь үндсэндээ хуучин төлөвийг буцаана. Гэсэн хэдий ч алдаатай үйлдэл болон буцаалт хоёулаа түүхэнд үлдэх болно.
• Өгөгдлийн схем нь хувилбараас гарах хүртэл өөрчлөгдөж болох ч хуучин үйл явдлуудыг шинэ стандарт руу шинэчлэх боломжгүй болно (үйл явдлыг зарчмын хувьд өөрчлөх боломжгүй).

Таны харж байгаагаар Event Sourcing нь CQRS-тэй сайн ажилладаг. Түүгээр ч барахгүй үр ашигтай, тохиромжтой дараалал бүхий системийг хэрэгжүүлэх нь өгөгдлийн урсгалыг салгахгүй байх нь өөрөө хэцүү байдаг, учир нь та дарааллын эерэг нөлөөг бүхэлд нь саармагжуулах синхрончлолын цэгүүдийг нэмэх шаардлагатай болно. Хоёр аргыг нэгэн зэрэг ашигласнаар програмын кодыг бага зэрэг тохируулах шаардлагатай. Манай тохиолдолд сервер рүү файл илгээх үед зөвхөн "ok" гэсэн хариу ирдэг бөгөөд энэ нь зөвхөн "файл нэмэх үйлдлийг хадгалсан" гэсэн үг юм. Албан ёсоор, энэ нь өгөгдөл нь бусад төхөөрөмж дээр аль хэдийн бэлэн болсон гэсэн үг биш юм (жишээлбэл, хуулбарлах үйлчилгээ нь индексийг дахин бүтээх боломжтой). Гэсэн хэдий ч хэсэг хугацааны дараа үйлчлүүлэгч "X файлыг хадгаллаа" гэсэн мэдэгдэл хүлээн авах болно.

Үр дүнд нь:

• Файл илгээх статусын тоо нэмэгдэж байна: "файл илгээсэн" гэсэн сонгодог хувилбарын оронд "файл серверийн дараалалд нэмэгдсэн" ба "файл нь хадгалах санд хадгалагдсан" гэсэн хоёрыг авдаг. Сүүлийнх нь бусад төхөөрөмжүүд аль хэдийн файлыг хүлээн авч эхлэх боломжтой гэсэн үг юм (дараалал өөр өөр хурдтай ажилладаг тул тохируулсан).
• Илгээх мэдээлэл одоо өөр өөр сувгаар ирдэг тул бид файлын боловсруулалтын статусыг хүлээн авах шийдлүүдийг гаргах шаардлагатай байна. Үүний үр дүнд: сонгодог хүсэлт-хариултаас ялгаатай нь файлыг боловсруулах явцад үйлчлүүлэгчийг дахин эхлүүлж болох боловч энэ боловсруулалтын статус өөрөө зөв байх болно. Түүнээс гадна, энэ зүйл нь үндсэндээ хайрцагнаас гарч ажилладаг. Үүний үр дүнд бид одоо бүтэлгүйтэлд илүү тэсвэртэй болсон.

Цайруулах

Дээр дурдсанчлан, үйл явдлын эх сурвалжийн системд хатуу тууштай байдаггүй. Энэ нь бид хэд хэдэн санг хооронд нь синхрончлолгүйгээр ашиглах боломжтой гэсэн үг юм. Асуудалд ойртоход бид дараахь зүйлийг хийж чадна.

• Файлуудыг төрлөөр нь салга. Жишээлбэл, зураг/видео кодыг тайлж, илүү үр дүнтэй форматыг сонгох боломжтой.
• Дансуудыг улсаар тусад нь. Олон хуулиас шалтгаалан энэ нь шаардлагатай байж болох ч энэхүү архитектурын схем нь ийм боломжийг автоматаар олгодог

Хэрэв та өгөгдлийг нэг сангаас нөгөөд шилжүүлэхийг хүсч байвал стандарт арга хэрэгсэл хангалтгүй болно. Харамсалтай нь, энэ тохиолдолд та дарааллыг зогсоож, шилжилт хөдөлгөөнийг хийж, дараа нь эхлүүлэх хэрэгтэй. Ерөнхий тохиолдолд өгөгдлийг "шууд" дамжуулах боломжгүй, гэхдээ хэрэв үйл явдлын дараалал бүрэн хадгалагдсан бөгөөд танд өмнөх хадгалалтын төлөвийн агшин зураг байгаа бол бид үйл явдлуудыг дараах байдлаар дахин тоглуулах боломжтой.

• Event Source-д үйл явдал бүр өөрийн гэсэн тодорхойлогчтой байдаг (хамгийн тохиромжтой нь буурахгүй). Энэ нь бид хадгалах санд талбар нэмж болно гэсэн үг - хамгийн сүүлд боловсруулсан элементийн id.
• Бид дарааллыг давхардуулж, бүх үйл явдлыг хэд хэдэн бие даасан хадгалах сангуудад боловсруулах боломжтой (эхнийх нь өгөгдөл аль хэдийн хадгалагдсан, хоёр дахь нь шинэ боловч хоосон хэвээр байгаа). Хоёр дахь дараалал нь мэдээжийн хэрэг хараахан боловсруулагдаагүй байна.
• Бид хоёр дахь дарааллыг эхлүүлдэг (өөрөөр хэлбэл бид үйл явдлуудыг дахин тоглуулж эхэлдэг).
• Шинэ дараалал харьцангуй хоосон байх үед (өөрөөр хэлбэл элемент нэмэх, сэргээх хоорондох дундаж хугацааны зөрүү нь зөвшөөрөгдөх боломжтой) бол уншигчдыг шинэ санах ой руу шилжүүлж эхлэх боломжтой.

Таны харж байгаагаар манай системд хатуу тууштай байдал байгаагүй, одоо ч байхгүй байна. Зөвхөн эцсийн тууштай байдал, өөрөөр хэлбэл үйл явдлуудыг ижил дарааллаар (гэхдээ өөр өөр сааталтайгаар) боловсруулах баталгаа байдаг. Үүнийг ашигласнаар бид системийг дэлхийн нөгөө тал руу зогсоохгүйгээр харьцангуй хялбар өгөгдөл дамжуулах боломжтой.

Тиймээс, файлын онлайн хадгалалтын талаархи жишээг үргэлжлүүлбэл, ийм архитектур нь бидэнд хэд хэдэн урамшуулал өгдөг.

• Бид объектуудыг динамик байдлаар хэрэглэгчдэд ойртуулж чадна. Ингэснээр та үйлчилгээний чанарыг сайжруулж чадна.
• Бид зарим өгөгдлийг компаниудад хадгалах боломжтой. Жишээлбэл, Enterprise хэрэглэгчид өөрсдийн өгөгдлийг хяналттай мэдээллийн төвд хадгалахыг шаарддаг (өгөгдлийн алдагдлаас зайлсхийхийн тулд). Sharding-ээр дамжуулан бид үүнийг хялбархан дэмжиж чадна. Хэрэв үйлчлүүлэгч тохирох үүлтэй бол ажил нь илүү хялбар болно (жишээлбэл, Azure өөрөө зохион байгуулсан).
• Хамгийн гол нь бид үүнийг хийх шаардлагагүй юм. Эцсийн эцэст, бид бүх бүртгэлд зориулсан нэг санах ойтой байх болно (хурдан ажиллаж эхлэхийн тулд). Энэ системийн гол онцлог нь хэдийгээр өргөтгөх боломжтой боловч эхний шатанд энэ нь маш энгийн байдаг. Та сая тусдаа бие даасан дараалал гэх мэт кодыг шууд бичих шаардлагагүй. Шаардлагатай бол үүнийг ирээдүйд хийж болно.

Статик контент байршуулах

Энэ цэг нь нэлээд ойлгомжтой мэт санагдаж болох ч стандарт ачаалагдсан програмын хувьд шаардлагатай хэвээр байна. Үүний мөн чанар нь энгийн: бүх статик агуулгыг програмын байрладаг серверээс биш, харин энэ даалгаварт тусгайлан зориулсан тусгай контентоос түгээдэг. Үүний үр дүнд эдгээр үйлдлүүд илүү хурдан хийгддэг (нөхцөлт nginx нь Java серверээс илүү хурдан бөгөөд бага өртөгтэй файлуудад үйлчилдэг). Дээрээс нь CDN архитектур (Агуулгын Хүргэлтийн Сүлжээ) нь бидэнд файлуудаа эцсийн хэрэглэгчдэд ойртуулах боломжийг олгодог бөгөөд энэ нь үйлчилгээтэй ажиллахад тав тухтай байдалд эерэгээр нөлөөлдөг.

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

Гэсэн хэдий ч бодит байдал дээр статик агуулгын хувьд та lambda архитектуртай төстэй аргыг ашиглаж болно. Хэрэглэгчдэд файл түгээх шаардлагатай ажилдаа (онлайн файл хадгалах) буцаж орцгооё. Хамгийн энгийн шийдэл бол хэрэглэгчийн хүсэлт болгонд шаардлагатай бүх шалгалтыг (зөвшөөрөл гэх мэт) хийж, дараа нь манай сангаас файлыг шууд татаж авдаг үйлчилгээг бий болгох явдал юм. Энэ аргын гол сул тал нь статик контент (мөн тодорхой хувилбартай файл нь үнэндээ статик контент) нь бизнесийн логикийг агуулсан ижил серверээр тархдаг явдал юм. Үүний оронд та дараах диаграммыг хийж болно.

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

Энэ схем нь статик контентыг түгээхтэй тийм ч төстэй биш (бид статик багцыг бүхэлд нь хаа нэгтээ байршуулдаггүй) гэхдээ бодит байдал дээр энэ арга нь хувиршгүй өгөгдлийг түгээхтэй холбоотой юм. Түүнээс гадна, энэ схемийг агуулга нь зүгээр л статик биш, харин өөрчлөгддөггүй, устгагдахгүй блокуудын багц хэлбэрээр төлөөлж болох бусад тохиолдлуудад ерөнхийд нь авч үзэх боломжтой (хэдийгээр тэдгээрийг нэмж болно).

Өөр нэг жишээ болгон (бэхжүүлэх зорилгоор): хэрэв та Jenkins/TeamCity-тэй ажиллаж байсан бол хоёр шийдэл нь Java хэл дээр бичигдсэн гэдгийг та мэднэ. Эдгээр нь хоёулаа бүтээх зохион байгуулалт, агуулгын менежментийг хоёуланг нь зохицуулдаг Java процесс юм. Ялангуяа тэд хоёулаа "серверээс файл / хавтас шилжүүлэх" гэх мэт даалгавартай. Жишээ нь: олдворуудыг гаргах, эх кодыг шилжүүлэх (агент кодыг репозитороос шууд татаж авахгүй, харин сервер түүнд зориулж хийдэг), бүртгэлд хандах. Эдгээр бүх ажлууд нь IO ачааллаар ялгаатай байдаг. Өөрөөр хэлбэл, бизнесийн нарийн төвөгтэй логикийг хариуцдаг сервер нэгэн зэрэг их хэмжээний мэдээллийн урсгалыг үр дүнтэйгээр дамжуулж чаддаг байх ёстой. Хамгийн сонирхолтой нь ийм үйлдлийг яг ижил схемийн дагуу ижил nginx-д шилжүүлж болно (өгөгдлийн түлхүүрийг хүсэлтэд нэмэхээс бусад тохиолдолд).

Гэсэн хэдий ч, хэрэв бид системдээ буцаж ирвэл бид ижил төстэй диаграммыг авах болно.

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

Би эхэндээ хэлсэнчлэн одоо хэд хэдэн интернетийн үйлчилгээ ачаалал ихсэж эхэлсэн. Тэдний зарим нь зүгээр л зөв ажиллахаа больсон. Үнэн хэрэгтээ, бизнес мөнгө олох ёстой байсан тэр мөчид системүүд бүтэлгүйтсэн. Өөрөөр хэлбэл, хүргэлтийг хойшлуулахын оронд "ирэх саруудад хүргэлтээ төлөвлө" гэж санал болгохын оронд систем нь "өрсөлдөгчид рүүгээ яв" гэсэн үг юм. Үнэн хэрэгтээ энэ бол бага бүтээмжийн үнэ юм: ашиг хамгийн их байх үед алдагдал яг таарна.

дүгнэлт

Эдгээр бүх аргууд нь өмнө нь мэдэгдэж байсан. Ижил VK нь зургийг харуулахын тулд статик контент байршуулах санааг удаан хугацаанд ашиглаж ирсэн. Олон тооны онлайн тоглоомууд нь Sharding схемийг ашиглан тоглогчдыг бүс болгон хуваах эсвэл тоглоомын байршлыг (хэрэв дэлхий өөрөө нэг бол) хуваахад ашигладаг. Үйл явдлын эх сурвалжийн аргыг имэйлд идэвхтэй ашигладаг. Мэдээлэл байнга хүлээн авдаг ихэнх арилжааны програмууд нь хүлээн авсан өгөгдлийг шүүх боломжтой байхын тулд CQRS арга дээр суурилдаг. За, хэвтээ масштабыг олон үйлчилгээнд нэлээд удаан ашиглаж ирсэн.

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

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

Хамгийн гол нь: Хэрэв танд энгийн програм байгаа бол эдгээр аргыг бүү ашигла. Тийм ээ, тэд үзэсгэлэнтэй, сонирхолтой байдаг, гэхдээ 100 хүний ​​хамгийн их зочилсон сайтын хувьд та сонгодог цул (наад зах нь гадна талаасаа, доторх бүх зүйлийг модулиудад хувааж болно гэх мэт) ихэвчлэн авч болно.

Эх сурвалж: www.habr.com