Մոնոլիտ ընդդեմ միկրոծառայությունների

01Երեք ձև՝ մոնոլիտ, մոդուլային մոնոլիտ, միկրոծառայություններ

Պատկերացրու ռեստորան։ Մոնոլիտը մեկ խոհանոց է, որտեղ ցանկացած խոհարար կարող է ցանկացած դարակից վերցնել ցանկացած բաղադրիչ՝ սկզբում արագ է, հետո՝ քաոս։ Մոդուլային մոնոլիտը նույն խոհանոցն է՝ բաժանված կայանների (գրիլ, հրուշակեղեն, աղցաններ), որոնցից յուրաքանչյուրն ունի իր դարակները և վաճառասեղան, որտեղ պատվերները փոխանցվում են։ Միկրոծառայությունները առանձին ռեստորաններ են, որոնք միմյանց պատվերներ են ուղարկում առաքիչով․ յուրաքանչյուրը կարող է անկախ բացվել, փակվել կամ վերանորոգվել, բայց ամեն փոխանցում հիմա ժամանակ է խլում և կարող է կորչել։ Ծրագրային լեզվով՝ մոնոլիտը մեկ կոդաբազա է, պրոցեսի մեկ տեսակ և սովորաբար մեկ տվյալների բազա։ Մոդուլային մոնոլիտը պահում է մեկ դեպլոյվող միավոր, բայց կոդը բաժանում է հանրային ինտերֆեյսներով մոդուլների, և յուրաքանչյուր մոդուլ տիրապետում է իր աղյուսակներին։ Միկրոծառայությունները անկախ դեպլոյվող պրոցեսներ են, յուրաքանչյուրն իր տվյալների պահոցով, որոնք հաղորդակցվում են HTTP-ով, gRPC-ով կամ հաղորդագրություններով։

• Մոնոլիտ՝ ամենապարզն է կառուցելու, թեստավորելու, դեպլոյելու և դեբագելու համար. ռիսկը «big ball of mud»-ն է՝ ցեխի մեծ գունդ։
• Մոդուլային մոնոլիտ՝ մեկ դեպլոյ, պարտադրված սահմաններ, պրոցեսի ներսում կանչեր, մեկ տրանզակցիա, երբ պետք է։
• Միկրոծառայություններ՝ անկախ դեպլոյներ և մասշտաբավորում ըստ ծառայության. գինը բաշխված համակարգերի բարդությունն է։

02Միկրոծառայությունների իրական գինը

Միկրոծառայությունները բարդությունը կոդից տեղափոխում են ցանց։ Ֆունկցիայի կանչը, որը երբեք չէր ձախողվում, դառնում է հարցում, որը կարող է timeout տալ, երկու անգամ հասնել կամ հաջողվել՝ առանց որ դու դրա մասին իմանաս։ Տվյալների բազայի մեկ տրանզակցիան դառնում է բաշխված workflow, որին պետք են saga-ներ, outbox-ներ և իդեմպոտենտություն։ Տվյալների սեփականությունը դառնում է խիստ․ orders ծառայությունը չի կարող կարդալ customers աղյուսակը, ուստի պետք են API-ներ, իրադարձություններ կամ լոկալ պատճեններ, և այդ պատճենները կարող են հնացած լինել։ Դեբագինգին պետք են distributed tracing, իրար կապված լոգեր և ամեն ծառայության համար դաշբորդներ, այլապես մեկ դանդաղ checkout-ը դառնում է դետեկտիվ պատմություն։ Դեպլոյին պետք են CI pipeline-ներ, տարբերակավորված պայմանագրեր, service discovery և սովորաբար օրկեստրատոր։ Յուրաքանչյուր ծառայության պետք են նաև իր մոնիթորինգը, ալերտները, գաղտնիքները և թարմացումները։ Սրանցից ոչինչ անհնար չէ, բայց սա մշտական հարկ է, որը վճարում ես ամեն շաբաթ։

• Բաշխված տրանզակցիաներ՝ ծառայությունների միջև ընդհանուր ACID տրանզակցիա չկա։
• Ցանցային ձախողումներ՝ timeout-ներ, կրկնակի փորձեր, մասնակի ձախողումներ, կասկադային խափանումներ։
• Տվյալների սեփականություն՝ ծառայությունների միջև join-ներ չկան. կրկնօրինակված, eventually consistent տվյալներ։
• Observability և ծախս՝ tracing, ավելի շատ ենթակառուցվածք, on-call-ի ավելի մեծ մակերես։

03Սահմանների գտնելը bounded context-ների օգնությամբ

Ցանկացած բաժանման ամենադժվար մասը որոշելն է, թե որտեղից կտրել։ Domain-Driven Design-ը տալիս է գործնական գործիք՝ bounded context, բիզնեսի մի տիրույթ, որտեղ բառերն ունեն մեկ ճշգրիտ իմաստ։ «Ապրանքը» կատալոգում նշանակում է նկարագրություն լուսանկարներով, պահեստում՝ պաշար պահեստում, բիլինգում՝ գնի տող։ Յուրաքանչյուր կոնտեքստ ստանում է իր մոդելը և իր մոդուլը։ Լավ սահմաններն ունեն բարձր cohesion ներսում (այն, ինչ փոխվում է միասին, ապրում է միասին) և ցածր coupling դրսում (նեղ, կայուն ինտերֆեյս)։ Օգտակար թեստ․ կարո՞ղ է թիմը մեկ շաբաթ փոխել այս մոդուլը՝ ոչ մեկի հետ չհամաձայնեցնելով։ Եթե ոչ, սահմանը սխալ է։ Կտրիր ըստ բիզնես կարողության (պատվերներ, վճարումներ, լոյալություն), երբեք՝ ըստ տեխնիկական շերտի («database service» կամ «validation service»), որը միայն ստեղծում է շատախոս, փխրուն կախվածություններ։

1// eslint.config.mjs: modules may import each other only through a public index
2export default [
3  {
4    files: ["src/modules/**/*.ts"],
5    rules: {
6      "no-restricted-imports": ["error", {
7        patterns: [{
8          group: ["@/modules/*/internal/*", "@/modules/*/db/*"],
9          message: "Use the other module's public index.ts, not its internals.",
10        }],
11      }],
12    },
13  },
14];

04Մոդուլային մոնոլիտ, որը մնում է մոդուլային

Սահմանները, որոնք ապրում են միայն դիագրամում, մի քանի ամսում քայքայվում են։ Պարտադրիր դրանք կոդում։ Յուրաքանչյուր մոդուլի տուր թղթապանակ՝ հանրային մուտքի կետով (ծառայություններ, DTO-ներ, իրադարձություններ), իսկ մնացած ամեն ինչ պահիր ներքին։ Թող յուրաքանչյուր մոդուլ տիրապետի իր աղյուսակներին, և արգելիր մյուս մոդուլներին դրանց ուղղակի հարցումներ անել․ միջմոդուլային կարդալը գնում է տեր մոդուլի ծառայության միջոցով։ Կողմնակի էֆեկտների համար օգտագործիր պրոցեսի ներսի դոմեյն իրադարձություններ («պատվերը վճարված է»-ն գործարկում է լոյալության միավորներ), որպեսզի մոդուլները միմյանց երկար շղթաներով չկանչեն։ Ավելացրու lint կանոններ կամ ճարտարապետական թեստեր, որոնք կոտրում են build-ը արգելված import-ների դեպքում։ Մոդուլային համակարգ ունեցող ֆրեյմվորքերում, ինչպես NestJS-ը, export արա միայն այն, ինչ մյուս մոդուլները կարող են օգտագործել։ Արդյունքը․ երբ մի մոդուլ իսկապես պետք է առանձին մասշտաբավորվի կամ դեպլոյվի, դու արդեն ունես նրա ինտերֆեյսը, տվյալները և իրադարձությունները, և առանձնացումը դառնում է շաբաթների նախագիծ, ոչ թե վերագրում։

05Միգրացիա strangler fig պատերնով

Երբ գոյություն ունեցող մոնոլիտը պետք է բաժանել, երբեք մի փորձիր «big bang» վերագրում․ այն ամիսներով սառեցնում է նոր ֆիչերները և սովորաբար ձախողվում է։ Օգտագործիր strangler fig պատերնը, որն անվանվել է մի բույսի պատվին, որը դանդաղ աճում է ծառի շուրջը։ Մոնոլիտի առջև դիր routing շերտ (reverse proxy կամ API gateway)։ Ընտրիր մեկ լավ սահմանազատված կարողություն, կառուցիր այն որպես նոր ծառայություն և միայն նրա endpoint-ները ուղղիր այնտեղ, մինչ մնացած ամեն ինչ դեռ գնում է մոնոլիտ։ Անցման ընթացքում տվյալները համաժամեցրու իրադարձություններով կամ change data capture-ով, հետո տվյալների սեփականությունը փոխանցիր նոր ծառայությանը։ Կրկնիր՝ մեկ կարողություն ամեն անգամ, և յուրաքանչյուր քայլից հետո ջնջիր հին կոդը։ Ամեն քայլ փոքր է, հետադարձելի և թողարկելի, ուստի բիզնեսը շարունակում է առաջ գնալ, մինչ ճարտարապետությունը փոխվում է տակից։

• Սկսիր այնպիսի կարողությունից, որն ունի տվյալների հստակ սեփականություն և քիչ մուտքային կախվածություններ։
• Գործարկիր հին և նոր ուղիները զուգահեռ և համեմատիր արդյունքները՝ նախքան տրաֆիկը փոխելը։
• Չափիր․ եթե նոր ծառայությունը չի հեշտացնում դեպլոյը կամ մասշտաբավորումը, կանգ առ։

06Ընտրություն՝ թիմի չափ, դոմեյն և մասշտաբավորման կարիքներ

Կոնվեյի օրենքն ասում է, որ համակարգերը կրկնում են դրանք կառուցող թիմերի հաղորդակցության կառուցվածքը։ Մեկ կամ երկու փոքր թիմ միկրոծառայություններից գրեթե ոչինչ չի շահում, որովհետև նրանք առանց այդ էլ հեշտ են համաձայնեցնում, մինչդեռ վճարում են ամբողջ օպերացիոն գինը։ Միկրոծառայությունները սկսում են իրենց արդարացնել, երբ մի քանի ինքնավար թիմեր միմյանց արգելափակում են ընդհանուր թողարկման վրա, երբ համակարգի մասերն ունեն շատ տարբեր մասշտաբավորման կամ հուսալիության կարիքներ (վիդեո էնկոդեր ընդդեմ ադմին պանելի), կամ երբ compliance-ը պահանջում է կոշտ մեկուսացում։ Միայն տրաֆիկը հազվադեպ է պատճառ․ լավ կառուցված մոնոլիտը load balancer-ի հետևում հորիզոնական մասշտաբավորվում է մինչև շատ մեծ բեռներ։ Ընկերությունների մեծ մասի համար խելամիտ լռելյայն ընտրությունն է՝ սկսել մոդուլային մոնոլիտից, ներդրում անել սահմանների, թեստերի և observability-ի մեջ, և ծառայություն առանձնացնել միայն այն ժամանակ, երբ կոնկրետ, չափված ցավը դա արդարացնում է։

07Coupling, որը չես տեսնում․ ժամանակային, տվյալների և դեպլոյի

Import-ի կանոնները բռնում են կոդի coupling-ը, բայց երեք ավելի «լուռ» տեսակ են որոշում՝ բաժանումը կաշխատի՞, թե՞ ոչ։ Ժամանակային coupling․ A ծառայությունը կարող է ավարտել իր հարցումը միայն այն ժամանակ, երբ B-ն աշխատում է, որովհետև այն սինխրոն կանչում է B-ին։ Այդ դեպքում availability-ն բազմապատկվում է․ երեք ծառայություն՝ յուրաքանչյուրը 99.9 տոկոս, շղթայով միացված, ամբողջ հոսքի համար տալիս են մոտ 99.7 տոկոս։ Տվյալների coupling․ երկու մոդուլ կարդում կամ գրում են նույն աղյուսակները, այնպես որ մեկի սխեմայի փոփոխությունը կոտրում է մյուսին՝ առանց նրանց միջև որևէ import-ի։ Դեպլոյի coupling․ փոփոխությունը պահանջում է համաձայնեցված թողարկումներ, որովհետև պայմանագիրը փոխվել է ոչ backward-compatible ձևով։ Չափիր սրանք մինչև բաժանելը։ Նայիր, թե որ աղյուսակներին է դիպչում յուրաքանչյուր մոդուլ, tracing-ից ստացված կանչերի գրաֆին և թե որ թղթապանակներն են փոխվում նույն commit-ներում մի քանի ամսվա ընթացքում (change coupling՝ Git-ի պատմությունից)։ Մոդուլները, որոնք անընդհատ փոխվում են միասին, պատկանում են միասին՝ ինչ էլ որ ասի դիագրամը։

• Շղթայի availability․ բազմապատկիր յուրաքանչյուր սինխրոն քայլի SLO-ները։
• Ընդհանուր աղյուսակները սահմանի խախտում են՝ նույնիսկ մաքուր import-ների դեպքում։
• Git-ում միասին փոփոխվող ֆայլերի վերլուծությունը էժան ձևով ցույց է տալիս իրական coupling-ը։

08Ծառայությունների միջև պայմանագրեր․ տարբերակավորում և consumer-driven թեստեր

Երբ սահմանը դառնում է ցանցային սահման, նրա ինտերֆեյսը հրապարակված պայմանագիր է, և անկախ դեպլոյը կախված է դրա կայունությունից։ Հետևիր tolerant reader կանոնին․ consumer-ները անտեսում են իրենց անծանոթ դաշտերը, իսկ producer-ները միայն ավելացնում են ոչ պարտադիր դաշտեր։ Կոտրող փոփոխություններն անցնում են expand and contract ճանապարհով․ ավելացրու նոր դաշտը կամ endpoint-ը, միգրացրու consumer-ներին, հետո հեռացրու հինը, երբ դրա օգտագործումը իջնի զրոյի։ Consumer-driven contract թեստերը (օրինակ՝ Pact գործիքով) թույլ են տալիս յուրաքանչյուր consumer-ի գրանցել այն հարցումներն ու պատասխանի դաշտերը, որոնց վրա հենվում է․ provider-ի CI-ը վերարտադրում է այդ սպասումները և ձախողվում մինչև կոտրող փոփոխության թողարկումը՝ առանց ամբողջ համակարգը բարձրացնելու։ Սա փոխարինում է դանդաղ և անկայուն end-to-end միջավայրերին՝ որպես անվտանգության հիմնական ցանց։ Իրադարձությունները տարբերակավորիր նույն ձևով և յուրաքանչյուր API-ի համար պահիր գրավոր նշված տեր, որպեսզի հարցերն ունենան հասցե։

09Առանձնացման մեխանիկան․ branch by abstraction և anti-corruption layer

Մոնոլիտի ներսում branch by abstraction-ը մոդուլը պատրաստում է առանձնացման՝ առանց երկարակյաց branch-ի։ Ներմուծիր ինտերֆեյս այդ կարողության համար, բոլոր կանչողներին անցկացրու դրա միջով, հետո ավելացրու երկրորդ իրականացում, որը կանչում է նոր ծառայությունը և միացվում է feature flag-ով՝ ըստ tenant-ի կամ տոկոսի։ Առաջ գնա աստիճանաբար և in-process իրականացումը պահիր որպես fallback, մինչև հեռավորը չապացուցի իրեն։ Եթե նոր ծառայությունն ունի ավելի մաքուր մոդել, քան legacy կոդը, նրանց միջև դիր anti-corruption layer՝ թարգմանիչ, որը հին հասկացությունները քարտեզագրում է նորերին, որպեսզի legacy անվանումներն ու տարօրինակությունները չթափանցեն նոր դիզայն։ Տվյալները տեղափոխվում են փուլերով․ նոր ծառայությունը նախ կարդում է ռեպլիկացված պատճենը, հետո դառնում է գրողը, իսկ մոնոլիտը կարդում է նրանից, և վերջում հին աղյուսակները ջնջվում են։

1// Branch by abstraction: callers depend on the interface, not the location
2export interface PricingPort {
3  quote(cartId: string): Promise<Quote>;
4}
5 
6export function pricingFor(tenantId: string, deps: Deps): PricingPort {
7  return deps.flags.isOn("pricing-service", tenantId)
8    ? new RemotePricing(deps.http)      // new service, behind timeouts and retries
9    : new InProcessPricing(deps.db);    // existing module, kept as fallback
10}

10Թիմերի տոպոլոգիա և inverse Conway manoeuvre

Եթե համակարգերը արտացոլում են թիմերի հաղորդակցությունը, կարող ես կազմակերպությունը նախագծել այնպես, որ ստանաս քո ուզած ճարտարապետությունը․ սա inverse Conway manoeuvre-ն է։ Յուրաքանչյուր stream-aligned թիմի տուր մեկ կամ մի քանի bounded context-ի ամբողջական սեփականություն՝ ներառյալ տվյալները, դեպլոյները և on-call-ը։ Պլատֆորմային թիմը տրամադրում է «հարթ ճանապարհներ» (CI ձևանմուշներ, observability, ծառայությունների scaffolding), որպեսզի ամեն նոր ծառայություն դրանք նորից չհորինի։ Հետևիր ճանաչողական բեռին․ թիմը, որին պատկանում է ավելի շատ ծառայություն, քան այն կարող է հասկանալ, բոլորի վրա էլ «անկյուններ կկտրի»։ Կոպիտ ստուգում է դեպլոյվող միավորների և ինժեներների հարաբերակցությունը․ երբ այն անցնում է մեկը, օպերացիոն աշխատանքը սկսում է գերիշխել ֆիչերի վրա։ Սահմանները վերագծիր, երբ թիմերի կառուցվածքը փոխվում է, որովհետև երեք թիմի պատկանող ծառայությունը դառնում է համակարգման խցան, իսկ անտեր ծառայությունը կամաց փտում է։