Monolith-оос Microservices рүү

О.Дэлгэрмаа

Багш

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

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

1. Monolith: "Нэг цул" байхын давуу тал

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

Монолит гэдэг нь бүх үйлдэл, бүх код нэг дороо, нэг цул байхыг хэлнэ. Хэрэв та "Пицца хүргэлт"-ийн апп хийж байгаа бол захиалга авах, төлбөр тооцоо, хүргэлтийн мэдээлэл бүгд нэг том программ дотор байна гэсэн үг. Бүх код нэг саванд (repository) байдаг учраас хөгжүүлэгч бүх зүйлийг нэг дороос харах боломжтой. Функцууд хоорондоо санах ойн түвшинд шууд харьцдаг тул сүлжээний хоцрогдол (latency) огт байхгүй. Алдаа хаана гарсныг мөшгөхөд нэг log файл харахад л хангалттай.

Энэ архитектур нь компьютерын шинжлэх ухааны эхэн үеэс ашиглагдаж ирсэн бөгөөд өнөөдөр ч олон том системүүд Монолит хэвээр ажилладаг

Гэвч төсөл томрох тусам энэ "цул" бүтэц "Giant Spaghetti" болон хувирдаг — учрыг нь олоход бэрх, нэгийг нь засахаар нөгөө талд нь алдаа гардаг эмзэг систем болж хувирна.

2. Microservices: Хувааж, захирах архитектур

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

Scalability буюу өргөтгөхийн хувьд системийн зөвхөн ачаалал ихтэй хэсгийг л томруулах хэрэгтэй бөгөөд жишээлбэл, төлбөрийн сервис ачаалал авч байвал зөвхөн тэр серверийн хүчин чадлыг нэмнэ. Fault isolation-н ачаар нэг сервис унахад систем бүхэлдээ зогсохгүй "Төлбөрийн сервис" ажиллахгүй байлаа ч хэрэглэгч бараагаа үзсээр байх боломжтой.

3. Яагаад "Хар дарсан зүүд" болдог вэ?

Олон компани "Google, Netflix ашиглаж байгаа юм чинь бид ч бас ашиглах ёстой" гэсэн хандлагаар ойртож, дараах бэрхшээлүүдэд унадаг.

Нэгдүгээрт, complexity overhead. Нэг байсан зүйлийг 20 хувааснаар та 20 дахин их зүйлийг хянах хэрэгтэй болно. Түүнд сүлжээний тохиргоо, API-уудын харилцан хамаарал гээд ажил асар их нэмэгдэнэ.
Хоёрдугаарт, distributed monolith. Энэ бол хамгийн аюултай хувилбар. Сервисүүдээ хуваасан боловч тэдгээр нь хоорондоо хэт хамааралтай (tightly coupled) болчихвол та "хамгийн муу Монолит"-ыг бүтээж байна гэсэн үг. Нэгийг нь deploy хийхэд бүгдийг нь зэрэг асаах хэрэгтэй болдог.
Гуравдугаарт, өгөгдлийн нэгдмэл байдал. Монолит дээр нэг transaction-оор шийддэг байсан асуудал Microservices дээр асар хүнд болно. Хоёр өөр датабэйс дээрх өгөгдлийг хэрхэн нэгэн зэрэг, алдаагүй шинэчлэх вэ гэдэг нь цоо шинэ нарийн төвөгтэй асуудал болж гарч ирнэ.

4. Хэзээ Microservices рүү шилжих вэ?

Инженер хүний хувьд хамгийн чухал зүйл бол trade-off-оо мэдэх явдал — юуг золиослоод юуг авч байгаагаа ойлгох.

Шилжихээсээ өмнө системийнхээ хамаарлыг UML (Component, Sequence diagram) ашиглан маш нарийн зурах хэрэгтэй. Цаасан дээр сервисүүдээ тусгаарлаж чадахгүй бол кодон дээр бүр ч чадахгүй. Мөн хэрэв танайд CI/CD, автоматжуулсан тест, мониторинг байхгүй бол Microservices бол жинхэнэ хар дарсан зүүд байх болно. Багийн хэмжээний хувьд 10-аас цөөн хүнтэй бол Монолиттойгоо явах нь хамаагүй үр ашигтай.

Дүгнэлт

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