Strangler fig usulida yangi tizim eskisining yonida quriladi va funksiyalar birin-ketin unga oʻtkaziladi. Eski va yangi tizim oldida oraliq qatlam turadi, u soʻrovni kerakli tizimga yuboradi. Eng qiyin masala maʼlumot: har bir turdagi maʼlumot uchun har lahzada bitta ega boʻlishi kerak. Usul bepul emas, vaqtinchalik ulanishlar va uzoq muddat talab qiladi, kichik tizimlar uchun esa ortiqcha.
2001 yilda Martin Fowler Avstraliyaning Kvinslend oʻrmonlarida sayohat qilib, boʻgʻuvchi anjirlarni koʻrdi. Bu oʻsimlik urugʻi daraxtning shoxiga tushadi, mezbon daraxtdan oziq olib oʻsadi va vaqt oʻtib oʻz tanasini qurib oladi. Mezbon daraxt baʼzan nobud boʻladi, anjir esa uning shaklini saqlab qoladi. Fowler bu jarayonni hamkasblari eski dasturiy tizimlarni almashtirish usuliga oʻxshatdi va undan mashhur nom chiqdi.
Gʻoya: yangi tizim eskisini sekin oʻrab oladi
Fowler tavsiya qilgan yoʻl oddiy koʻrinadi: eski tizimni butunlay almashtirish oʻrniga, yangi imkoniyatlar uning yonida quriladi va tizim xatti-harakati qismlab yangi kodga oʻtkaziladi. Yoder va Merson uni shunday taʼriflaydi: yangi tizim eskisining chetida asta-sekin oʻsadi va bir necha yil davomida kuchayib, eskisini siqib chiqaradi.
Atamaning sanasi manbalarda har xil. Yoder va Merson Fowler uni 2004 yilda taklif qilgan, deb yozadi. Fowlerning oʻz sahifasida esa 2024 yil 22 avgust sanasi turibdi, boshqa sana koʻrsatilmagan. Ikkala maʼlumotni birga aytish toʻgʻri: gʻoya ancha oldin tarqalgan boʻlishi, sahifa esa keyin yangilanishi mumkin. Sahifadagi izohga koʻra, dastlabki yozuv «Strangler Application» deb nomlangan, keyin muallif nomni «Strangler Fig Application» ga almashtirgan, chunki oʻsimlik asosini yaqqolroq koʻrsatmoqchi boʻlgan.
Nega birdan almashtirish xavfli
Fowler katta tizimni butunlay almashtirishning bir necha zaif tomonini koʻrsatadi. Bunday ish uzoq davom etadi va shu vaqt ichida foydalanuvchilar yangi imkoniyatlarni kutib turolmaydi. Eski tizimning amaldagi xatti-harakatini toʻliq yozib chiqish qiyin, uning ayrim qismlari esa aslida kerak ham emas, ularni qayta qurish behuda mehnat. Bundan tashqari, eski tizim qotib qolgan va moʻrt boʻlib qoladi.
Qismlab almashtirishning asosiy daʼvosi shu: xavf kichrayadi va foyda erta keladi. Fowlerning oʻz soʻzlari bilan, bosqichma-bosqich yondashuvning kamaygan xavfi va erta foydasi uning xarajatlaridan ustun turadi. Bu daʼvo har bir korxonaga mos kelishi shart emas, quyida chegaralar koʻriladi.
Qanday ishlaydi: kirish nuqtasi va ketma-ket oʻtish
Microsoftning Azure meʼmorchilik markazi usulni toʻrt bosqichda tasvirlaydi. Birinchi bosqichda mijoz va eski tizim orasiga oraliq qatlam, yaʼni fasad yoki proksi qoʻyiladi. Fasad kelgan soʻrovlarni qabul qilib, ularni yo eski, yo yangi tizimga yuboradi, boshida deyarli hammasi eskisiga ketadi. Ikkinchi bosqichda funksiyalar birin-ketin yangi tizimga oʻtadi va fasad tobora koʻproq soʻrovni yangisiga yoʻnaltiradi. Uchinchi bosqichda eski tizimga hech narsa bogʻliq qolmaydi va u oʻchiriladi, oxirgi bosqichda esa fasad ham olib tashlanadi va mijoz yangi tizim bilan toʻgʻridan-toʻgʻri ishlay boshlaydi.
Foydalanuvchi bu vaqtda nimani sezadi? Hech narsani. Hujjatga koʻra, mijozlar bir xil interfeysdan foydalanishda davom etadi va koʻchish boshlanganini bilmaydi. Amazon Web Services qoʻllanmasi ham shu jarayonni uch soʻz bilan beradi: oʻzgartirish, birga yashash, yoʻq qilish. «Birga yashash» bosqichida eski tizim orqaga qaytish imkoniyati sifatida saqlanadi, tashqi soʻrovlar esa proksi orqali yangisiga yoʻnaltiriladi.
Yoʻnaltirishni asta-sekin oshirish
Fasad soʻrovlarni bir zumda emas, bosqichma-bosqich yangi tizimga oʻtkazishi mumkin. Google muhandislari qisman va vaqt bilan cheklangan joriy etishni kanareyka deb ataydi. Ular bir misol keltiradi: soʻrovlarning besh foizi yangi qismga tushib, unda yigirma foiz xato boʻlsa, umumiy xato ulushiga taxminan bir foiz qoʻshiladi. Xato ulushi tizimga tushgan yuk bilan toʻgʻri proporsional oʻsadi.
Shu qoidani yuqoridagi mantiqqa tatbiq etamiz. Quyidagi hisob gipotetik, xato ulushi yigirma foiz deb olingan va oldindan maʼlum emas.
| Hafta | Yangi tizimga yoʻnaltirilgan ulush | Umumiy xatoga qoʻshimcha | Qaror |
|---|---|---|---|
| 1 | 5% | 5% x 20% = 1% | Xatolarni yigʻish, tuzatish |
| 2 | 20% | 20% x 20% = 4% | Xato kamaymasa, ulushni oshirmaslik |
| 3 | 50% | 50% x 20% = 10% | Faqat xato ulushi pasaygandan keyin |
| 4 | 100% | 100% x 20% = 20% | Faqat xato ulushi nolga yaqin boʻlganda |
Jadval oddiy fikrni koʻrsatadi: ulushni oshirish xatoni ham oshiradi, shuning uchun oshirishdan oldin xato ulushi kamayganini koʻrish kerak. Google qoʻllanmasi yana bir amaliy qoidani eslatadi: kanareyka natijasi nazorat guruhi bilan solishtiriladi va ular keskin farq qilsa, qismni toʻxtatish yoki qaytarish kerak. Fasadli tizimda qaytarish ulushni pasaytirish bilan teng.
Eng qiyin qism: maʼlumot kimniki
Kod koʻchirish nisbatan oson, maʼlumot koʻchirish esa qiyin. Microsoft hujjatidagi misol buni yaxshi koʻrsatadi. Eski tizimda hamma sohaga xizmat qiladigan bitta katta baza bor, yangi xizmat esa avval shu bazadan oʻqiydi va unga yozadi. Keyin yangi xizmat uchun alohida baza ochiladi, eski maʼlumot unga bir marta toʻliq yuklanadi, soʻng oʻzgarishlar doimiy ravishda nusxalanadi. Bu bosqichda ikki baza orasidagi moslik tekshiriladi. Moslik tasdiqlangandan keyingina yangi baza asosiy manbaga aylanadi.
Hujjat orqaga qaytish haqida muhim ogohlantirish beradi: eski jadvallar va sinxronlash hali oʻchirilmagan paytda qaytish mumkin. Ular olib tashlangandan keyin qaytish katta mehnat va xavf talab qiladi, shuning uchun eski obyektlarni oʻchirish har bir soha uchun ongli va oxirgi qadam boʻlishi kerak.
Yoder va Merson ham shu muammoni eslatadi. Yangi xizmat eski bazaga toʻgʻridan-toʻgʻri murojaat qilsa, bu ortiqcha bogʻlanish yaratadi va u vaqtinchalik boʻlishi lozim. Maʼlumotni ikki joyda nusxalash esa loyihani murakkablashtiradi, doimiy kuzatuv talab qiladi va bir tomon eskirgan maʼlumotni koʻrib qolishi mumkin. Demak maʼlumot uchun har bir lahzada bitta ega boʻlishi kerak: qaysi tizim qaysi sohaning asosiy manbai ekani oldindan yozib qoʻyiladi.
Bu usul bepul emas
Fowler oʻzi ham bu usulning qiyin tomonini yashirmaydi. Eski va yangi tizim birga ishlashi uchun vaqtinchalik meʼmorchilik qurish kerak, u keyin tashlab yuboriladi, odamlar esa buning zarurligiga koʻpincha qarshilik qiladi. Yana bir shart: eski tizimni boʻlish mumkin boʻlgan «chok» joylari boʻlishi kerak, yaxshi qurilgan tizimda ular allaqachon mavjud, boshqasida esa avval ularni yaratish lozim.
Microsoft bir nechta aniq xavfni sanaydi. Fasad oʻzi yagona nosozlik nuqtasi yoki sekinlik sababi boʻlib qolishi mumkin. Ikki tizim bir-biridan xabar olishi kerak, shuning uchun ularning orasiga tarjimon qatlam qoʻyiladi, bu qatlam esa yangi tizimning tuzilishini eski tizim odatlaridan himoya qiladi. Fasadni oxirida olib tashlash ham mumkin, baʼzan esa eski mijozlar uchun moslashtiruvchi sifatida qoldiriladi.
Tashkiliy tomon ham bor. Fowler ishni toʻrt faoliyatga ajratadi va ularning tartibi qatʼiy emasligini aytadi. Bular: kerakli natijani tushunish, muammoni kichik boʻlaklarga ajratish, boʻlaklarni muvaffaqiyatli yetkazish va tashkilotni bu ishni doimiy bajarishga moslashtirish. Oxirgisi muhim: tashkilot oʻzgarmasa, yangi tizim ham vaqt oʻtib eskisiga oʻxshab qoladi.
Qachon bu usul mos kelmaydi
Microsoft hujjati usul mos kelmasligi mumkin boʻlgan toʻrt holatni sanaydi.
- Eski tizimga boradigan soʻrovlarni ushlab boʻlmaydi.
- Eski tizimning manba kodiga yoki oʻzgartirish mumkin boʻlgan boshqa ulanish nuqtasiga, masalan bazaga, kirib boʻlmaydi.
- Tizim kichik va uni butunlay almashtirish oson.
- Eski yechimni tezda toʻliq oʻchirish kerak.
AWS qoʻllanmasi ham kichik va oddiy tizimlar uchun usulni mos emas deb hisoblaydi va har bir qayta yozilgan qism uchun alohida qaytish rejasini talab qiladi. Yana bir cheklov vaqt bilan bogʻliq: qismlab almashtirish uzoq davom etishi mumkin, Yoder va Merson uni bir necha yilga choʻzilishi mumkin deb yozadi.
Biznes tizimiga koʻchirsak
Strangler gʻoyasi dasturchilar uchun yaratilgan, lekin uning mantigʻi korxonaning ish tizimiga ham mos tushadi. Bu tahririyat fikri. Gipotetik misol: korxona bitta eski dasturda sotuv, ombor va buxgalteriyani yuritadi. Yangi tizim bu uchala sohani birdan emas, ketma-ket oladi.
| Bosqich | Yangi tizim | Eski tizim | Maʼlumot egasi |
|---|---|---|---|
| 1. Tayyorgarlik | Hali ishlamaydi | Hamma ish shu yerda | Eski tizim |
| 2. Ombor | Ombor harakati va qoldiq | Sotuv va hisob | Ombor uchun yangi, qolgan hammasi uchun eski |
| 3. Sotuv | Ombor va sotuv | Faqat buxgalteriya | Buxgalteriya uchun eski |
| 4. Hisob | Hamma soha | Faqat arxiv | Yangi tizim |
| 5. Yopish | Hamma soha | Oʻchiriladi | Yangi tizim |
Jadvalning oxirgi ustuni eng muhimi. Har bosqichda har bir maʼlumot turi uchun bitta ega bor: ombor qoldigʻi ikkinchi bosqichdan yangi tizimga tegishli, qarz hisobi esa hali eskisida qoladi. Agar ikki tizim bir vaqtda bir xil maʼlumotni oʻzgartirsa, ular tez orada bir-biriga zid raqamlar koʻrsatadi va qaysi biri toʻgʻri ekanini hech kim bilmaydi. Shu sababli oʻtish aniq sanaga bogʻlanadi: shu kundan boshlab qoldiq faqat yangi tizimda oʻzgaradi.
Bunday ketma-ketlik uchun vaqtinchalik ulanishlar kerak: masalan, ombor qoldigʻi yangi tizimdan eskisiga kuniga bir marta uzatiladi. Microsoftning joriy etish qoʻllanmasi bosqichli joriy etishning shu kamchiligini ochiq aytadi: yangi va eski tizimlarni ulash uchun vaqtinchalik interfeyslar kerak boʻladi, maʼlumot koʻchirish esa bosqichlarga boʻlinib, ancha murakkablashadi. Yana bir xavf: bosqichlar choʻzilsa, xodimlar oʻzgarishdan charchaydi va jamoa tezligini yoʻqotadi.
Amalda nima qilish mumkin
Quyidagi qadamlar manbalardan chiqarilgan tahririyat xulosasi, tayyor protokol emas.
- Avval nima uchun almashtirayotganingizni va qanday natija kutayotganingizni yozing.
- Eski tizimni mustaqil qismlarga boʻling va ularni qaysi tartibda oʻtkazishni belgilang.
- Har bir qism uchun maʼlumot egasini va orqaga qaytish rejasini oldindan yozing.
- Vaqtinchalik ulanishlarni alohida loyiha deb hisoblang va ular uchun vaqt ajrating.
- Qismni yopishdan oldin yangi va eski maʼlumotni solishtiring, eski obyektni faqat shundan keyin oʻchiring.
Qismlab almashtirish tez usul emas. Uning yutugʻi shundaki, har qadamdan keyin korxona ishlayveradi va xatoning oqibati bitta qism bilan cheklanadi.
Qismlab almashtirish tezlikni emas, boshqariluvchanlikni beradi: har qadamdan keyin korxona ishlayveradi va xato kichik doirada qoladi. Buning uchun maʼlumot egasi, orqaga qaytish rejasi va vaqtinchalik ulanishlar oldindan oʻylangan boʻlishi kerak. Oʻzingizdan soʻrang: tizimning qaysi qismini ertaga ham ajratib olish mumkin?
Asosiy atamalar
- Strangler fig
- Boʻgʻuvchi anjir: daraxtni oʻrab olib, uning oʻrnini egallaydigan oʻsimlik. Dasturda esa eski tizimni yangisi bilan asta-sekin almashtirish usuli.
- Eski tizim
- Hozir ishlab turgan, lekin almashtirilishi kerak boʻlgan dastur. Odatda yillar davomida oʻzgartirilib, murakkablashib qolgan.
- Fasad
- Eski va yangi tizim oldidagi oraliq qatlam. U soʻrovlarni qabul qilib, qaysi tizimga yuborishni hal qiladi.
- Orqaga qaytish rejasi
- Yangi qism ishlamay qolsa, ishni eski usulga qaytarish tartibi. U oldindan yoziladi.
- Vaqtinchalik interfeys
- Eski va yangi tizimni vaqtincha bogʻlaydigan ulanish. Koʻchirish tugagach tashlab yuboriladi.
- Maʼlumot egasi
- Maʼlum maʼlumot turi uchun asosiy manba hisoblangan tizim. Har lahzada bitta boʻlishi kerak.
- Monolit
- Hamma funksiyasi bir butun boʻlib qurilgan katta dastur. Uni qismlarga ajratish qiyin boʻladi.
- Tarjimon qatlam
- Ikki tizim orasida soʻrovlarni tarjima qiladigan qism. U yangi tizimni eski tizim odatlaridan himoya qiladi.
- Chok
- Tizimni qismlarga ajratish mumkin boʻlgan joy. Yaxshi qurilgan tizimda bunday joylar oldindan boʻladi.
- Sinxronlash
- Ikki joydagi maʼlumotni bir xil holatda saqlash. Unda bir tomon vaqtincha eskirgan maʼlumotni koʻrishi mumkin.
Manbalar
Maqola quyidagi manbalarga tayanadi:
- Martin Fowler. Strangler Fig Application. martinfowler.com, sahifa sanasi 2024-yil 22-avgust; 1-izoh: asl sarlavha «Strangler Application». Muallifning shaxsiy bilim bazasi (bliki). https://www.martinfowler.com/bliki/StranglerFigApplication.html (koʻrilgan: 20-oktabr, 2026)
- J. W. Yoder, P. Merson. Strangler Patterns. 27th Conference on Pattern Languages of Programs (PLoP 2020), Hillside Group, 25 bet. https://hillside.net/plop/2020/papers/yoder.pdf (koʻrilgan: 20-oktabr, 2026)
- Microsoft Learn. Strangler Fig pattern. Azure Architecture Center (ms.date 2026-05-29). Bulut platformasi sotuvchisining qoʻllanmasi. https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig (koʻrilgan: 20-oktabr, 2026)
- Amazon Web Services. Strangler fig pattern. AWS Prescriptive Guidance, Decomposing monoliths into microservices. https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html (koʻrilgan: 20-oktabr, 2026)
- Microsoft Learn. Plan your solution deployment and release, boʻlim «Phased rollout». Dynamics 365 Implementation Guide (ms.date 2023-04-27). https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/implementation-strategy-define-strategy-deployment-release (koʻrilgan: 20-oktabr, 2026)
- Google. Canarying Releases. The Site Reliability Workbook, sre.google: kanareyka taʼrifi, kanareyka va nazorat guruhini solishtirish, xato ulushiga taʼsir misoli. https://sre.google/workbook/canarying-releases/ (koʻrilgan: 20-oktabr, 2026)