Uweza wa kuweka kila huduma kwa kujitegemea ndio nchi yote, kwa hiyo kila huduma inahitaji pipeline yake mwenyewe ya CI/CD pamoja na mkakati wa kutoleza hatari ndogo — kawaida canary au blue-green — ili kusambaza kwa usalama mara nyingi sana kwa siku.
Kila huduma inaunda, inajaribu, na kuweka kwa cadence yake mwenyewe. Mabadiliko ya huduma moja hayatumiki kamwe release kamili ya mfumo.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Mkakati | Jinsi | Faida | Ubaya |
|---|---|---|---|
| Rolling | Badilisha matukio kwa polepole | Rahisi, chaguo-msingi | Matolotisho yenye mchanganyiko kwa muda mfupi |
| Blue-green | Mazingira mawili, badilisha trafiki | Kurudi nyuma mara moja | Miundombinu 2x |
| Canary | Tuma asilimia ndogo kwa toleo jipya | Huddudu blast radius | Inahitaji metrics nzuri |
v1 ████████████████ 95% ← watch error rate / latency
v2 █ 5% ← promote if healthy, roll back if not
└─ automated check on SLOs decides promote vs abort
[ Blue v1 ] ◀─ live ──┐
[ Green v2 ] ◀─ idle ├─ flip router ─▶ Green is live; Blue is instant rollback
Bila schemas zinazosambamba na nyuma, canary/blue-green huvunja kwa sababu matolotisho mawili yanakimbia wakati mmoja. Daima andika mabadiliko kuwa sawa kwa matolotisho.
Wuwekaji wenye mara kwa mara wenye hatari ndogo ndio kinachofanya microservices kuwa na thamani ya utata — kutoleza polepole na hatari kungekamatia faida ya kujitegemea.
Canary na blue-green huongeza khiriji la blast radius ya kuweka kwa uovu na kutoa kurudi nyuma karibu mara moja, kumgeuza uwekaji kutoka tukio linalosumbufu kuwa kazi ya kawaida, iliyoweza, na ya kila siku.