Ներածություն Ի՞նչ է «պայմանագիրը» ծառայության փոխազդեցության համատեքստում: Ծառայությունների փոխազդեցության մոդուլների համատեքստում առաջանում է անխուսափելի հարցը. է իրականացվում հաղորդակցությունը: ՏՏ արտադրանքներում «պայմանագիրը» ներկայացնում է պաշտոնական պատկերացում, են հոսում համակարգերի միջև և են դրանք փոխանցվում: Սա ներառում է տվյալների ձևաչափը (JSON, Protobuf և այլն), կառուցվածքային տարրեր (դաշտեր, տվյալների տեսակներ), կապի արձանագրություն (REST, gRPC, հաղորդագրությունների հերթեր) և այլ բնութագրեր: Ի՞նչ կանոններով թե ինչ տվյալներ ինչպես Պայմանագիրը ապահովում է բացություն (բոլորը գիտեն, թե ինչ է ստացվել և ուղարկվել), կանխատեսելիություն (մենք կարող ենք թարմացնել պայմանագիրը և պահպանել տարբերակները) և հուսալիություն (մեր համակարգը չի ձախողվի, եթե մենք լավ կառավարվող փոփոխություններ կատարենք): Ինչու են մարդիկ հակված տվյալների բազայում աղյուսակ ընտրել որպես «պայմանագիր»: Գործնականում, թեև բոլորը խոսում են միկրոծառայությունների, «պայմանագրերի» և API-ների մասին, մենք հաճախ տեսնում ենք, որ մարդիկ որդեգրում են այն մոտեցումը. Երբ ամեն ինչ միշտ պահվել է մեկ DB համակարգում մեկ ընկերության ներսում, ինչո՞ւ նորից հորինել անիվը: Պատմական կամ կազմակերպչական սովորություն. մենք կգրենք, դուք կկարդաք առանց թույլտվության կանոններ սահմանելու և API-ի առանձնահատկությունները նախագծելու: «Արագ ուղղման» մտածելակերպը. Տասնյակ կամ նույնիսկ հարյուրավոր գիգաբայթ տվյալների հետ աշխատելիս ընդհանուր աղյուսակում ուղղակի փոխանցումն ավելի պարզ, արագ և խնայող է թվում, բայց գործնականում այն ստեղծում է մասշտաբայնության և կատարողականի խնդիրներ, ինչպես նաև տվյալների սեփականության հետ կապված խնդիրներ: «Մեծ տվյալներ» փաստարկ. Հետևաբար, թեև տվյալների փոխանակման համար ընդհանուր աղյուսակի օգտագործումը կարող է արդյունավետ և օպտիմիզացված թվալ արագ արդյունքների համար, այն երկարաժամկետ հեռանկարում առաջացնում է տարբեր տեխնիկական և կազմակերպչական մարտահրավերներ: Այնուամենայնիվ, երբ թիմերը ընտրում են ընդհանուր աղյուսակներ տվյալների փոխանակման համար, նրանք կարող են բախվել բազմաթիվ խնդիրների իրականացման ընթացքում: Ինչու՞ «Տվյալների բազայում աղյուսակը» պայմանագիր չէ (և ինչու է այն հակաօրինաչափություն): Հստակ սահմանված ինտերֆեյսի բացակայություն Երբ ծառայությունները հաղորդակցվում են REST/gRPC/GraphQL-ի միջոցով, դրանք ունեն պաշտոնական սահմանում՝ OpenAPI (Swagger), պրոտոբուֆ սխեմաներ կամ GraphQL սխեմաներ: Սրանք մանրամասնորեն սահմանում են, թե որ ռեսուրսները (վերջնական կետերը) են հասանելի, որ դաշտերը սպասվում են, դրանց տեսակները և հարցում/պատասխանի ձևաչափերը: Երբ «ընդհանուր աղյուսակը» գործում է որպես պայմանագիր, չկա պաշտոնական նկարագրություն. չկա պայմանագրի պաշտոնական նկարագրություն. հասանելի է միայն աղյուսակի սխեման (DDL), և նույնիսկ դա լավ փաստագրված չէ: Աղյուսակի կառուցվածքի ցանկացած աննշան փոփոխություն (օրինակ՝ սյունակի ավելացում կամ ջնջում, տվյալների տեսակների փոփոխություն) կարող է ազդել այլ թիմերի վրա, որոնք կարդում կամ գրում են այս աղյուսակից: Տարբերակման և էվոլյուցիայի խնդիրներ API-ի տարբերակավորումը սովորական պրակտիկա է. մենք կարող ենք ունենալ v1, v2 և այլն, և մենք կարող ենք պահպանել հետընթաց համատեղելիությունը, այնուհետև աստիճանաբար հաճախորդներին տեղափոխել ավելի նոր տարբերակներ: Տվյալների բազայի աղյուսակների համար մենք ունենք միայն DDL գործողություններ (օրինակ՝ ), որոնք սերտորեն կապված են որոշակի DB շարժիչի հետ և պահանջում են միգրացիաների մանրակրկիտ մշակում: ALTER TABLE Չկա կենտրոնացված համակարգ, որը կարող է ծանուցումներ ուղարկել սպառողներին սխեմայի փոփոխությունների մասին, որոնք պահանջում են թարմացնել իրենց հարցումները: Արդյունքում կարող են տեղի ունենալ . ինչ-որ մեկը կարող է չաթում տեղադրել «Վաղը մենք X սյունակը կփոխենք Y-ի», բայց երաշխիք չկա, որ բոլորը ժամանակին պատրաստ կլինեն: «սեղանի տակ» գործարքներ Չկա հստակ սեփականություն Երբ կա հստակ սահմանված API, ակնհայտ է, թե ում է պատկանում այն՝ ծառայությունը, որը ծառայում է որպես API հրատարակիչ: Երբ մի քանի թիմեր օգտագործում են տվյալների բազայի միևնույն աղյուսակը, շփոթություն է առաջանում, թե ով կարող է որոշել կառուցվածքը և որ դաշտերը պահել և ինչպես մեկնաբանել դրանք: Արդյունքում, աղյուսակը կարող է դառնալ «ոչ մեկի սեփականությունը», և յուրաքանչյուր փոփոխություն դառնում է որոնում. «Մենք պետք է ստուգենք մյուս թիմը, եթե նրանք օգտագործում են հին սյունակը»: Անվտանգության և մուտքի վերահսկման խնդիրներ Դժվար է հետևել, թե ով կարող է կարդալ և գրել սեղանի վրա, եթե շատ թիմեր մուտք ունեն DB: Հնարավորություն կա, որ չարտոնված ծառայությունները կարող են մուտք գործել տվյալներ, թեև դրանք նախատեսված չեն նրանց համար: Ավելի հեշտ է կառավարել նման խնդիրները API-ով. Դուք կարող եք վերահսկել մուտքի իրավունքները (ով կարող է զանգահարել, թե որ մեթոդներին), օգտագործել նույնականացում և թույլտվություն և վերահսկել, թե ով ինչ է զանգահարել: Սեղանի դեպքում դա շատ ավելի բարդ է: Կախվածությունը ներքին կառուցվածքից Տվյալների ցանկացած ներքին փոփոխություն (ինդեքսների վերակազմավորում, աղյուսակի բաժանում, DB-ի փոփոխություն) դառնում է գլոբալ խնդիր: Եթե աղյուսակը գործում է որպես հանրային ինտերֆեյս, սեփականատերը չի կարող ներքին փոփոխություններ կատարել՝ առանց վտանգի ենթարկելու բոլոր արտաքին ընթերցողներին և գրողներին: Ցավի կետերը և տիպիկ խնդիրները գործնականում Համակարգող փոփոխություններ Սա ամենացավալին կողմն է. կարելի է մեկ այլ թիմին տեղեկացնել, որ հաջորդ օրը սխեման փոխվելու է: ինչպե՞ս սեփականատերը հինին զուգահեռ ստեղծում է նոր աղյուսակ՝ թարմացված սխեմայով: Հին տարբերակը հասանելի է մնում ներկայիս սպառողներին, և սեփականատերը նրանց հաղորդագրություն է ուղարկում, որտեղ ասվում է. «Նոր կառուցվածքը հասանելի է. ստուգեք փաստաթղթերը և ժամկետները: Խնդրում ենք տեղափոխել, քանի դեռ երկու տարբերակներն էլ կան»։ Աղյուսակի տարբերակի թարմացման հաջողված սցենար. Այնուամենայնիվ, OLAP-ի սցենարում կամ տվյալների մեծ ծավալով, երկու զուգահեռ աղյուսակների պահպանումը աննշան խնդիր չէ: Դուք նաև պետք է որոշեք, թե ինչպես տեղափոխել տվյալները հին սխեմայից նոր: Սա երբեմն կարող է պահանջել պլանավորված պարապուրդ կամ շատ բարդ ենթակառուցվածք: Այս գործընթացն անպայման ենթադրում է և՛ ռիսկ, և՛ լրացուցիչ աշխատանք: Տվյալների ամբողջականության խնդիրներ Երբ մի քանի թիմեր օգտագործում են ընդհանուր աղյուսակը կարևոր տվյալներ ընտրելու և թարմացնելու համար, այն հեշտությամբ կարող է դառնալ «ռազմի դաշտ»: Արդյունքն այն է, որ բիզնեսի տրամաբանությունն ավարտվում է ցրված տարբեր ծառայություններում, և տվյալների ամբողջականության կենտրոնացված վերահսկողություն չկա: Շատ դժվար է դառնում իմանալ, թե ինչու է որոշակի դաշտը պահվում որոշակի ձևով, ով կարող է թարմացնել այն և ինչ է տեղի ունենում, եթե այն դատարկ մնա: Վրիպազերծման և մոնիտորինգի մարտահրավերներ Օրինակ, ենթադրենք, որ աղյուսակը կոտրվում է. ասենք, վատ տվյալներ կան կամ ինչ-որ մեկը կողպել է որոշ կարևոր տողեր: Խնդրի աղբյուրը բացահայտելու համար հաճախ կարող է պահանջվել DB մուտք ունեցող յուրաքանչյուր թիմից խնդրել՝ որոշելու, թե որ հարցումն է առաջացրել խնդիրը: Դա հաճախ ակնհայտ չէ. սա նշանակում է, որ մի թիմի հարցումը կարող է արգելափակել տվյալների բազան, մինչդեռ մյուս թիմի հարցումն առաջացնում է նկատելի սխալ: Մեկ հանգույցի ձախողումը բոլորին քաշում է ներքեւ: Համօգտագործվող տվյալների բազան ձախողման մեկ կետ է: Եթե այն իջնի, ապա դրա հետ շատ ծառայություններ կիջնեն։ Երբ տվյալների բազան աշխատանքի հետ կապված խնդիրներ ունի մեկ ծառայության ծանր հարցումների պատճառով, բոլոր ծառայությունները խնդիրներ են ունենում: Հստակ API-ներով և տվյալների սեփականություն ունեցող մոդելում յուրաքանչյուր թիմ տիրապետում է իր ծառայության հասանելիությանը և կատարողականին, ուստի մի բաղադրիչի ձախողումը չի տարածվում մյուսների վրա: Միայն կարդալու համար առանձին կրկնօրինակ տրամադրելը խնդիրը չի լուծում: Ընդհանուր փոխզիջումը հետևյալն է. «Մենք ձեզ կտրամադրենք միայն կարդալու կրկնօրինակ, որպեսզի կարողանաք հարցումներ կատարել՝ առանց մեր հիմնական տվյալների բազայի վրա ազդելու»: Սկզբում դա կարող է լուծել ծանրաբեռնվածության որոշ խնդիրներ, բայց. Տարբերակման խնդիրները մնում են: Հիմնական խնդիրն այն է, որ երբ հիմնական աղյուսակի կառուցվածքը փոխվում է, կրկնօրինակի կառուցվածքը նույնպես փոխվում է, պարզապես որոշ ուշացումով: Կրկնօրինակման հետաձգումը կարող է հանգեցնել տվյալների վիճակների անկանխատեսելի լինելուն, հատկապես մեծ տվյալների հավաքածուների դեպքում: Սեփականության իրավունքը դեռևս պարզ չէ. ո՞վ է սահմանում ձևաչափը, կառուցվածքը և օգտագործման կանոնները: Կրկնօրինակը դեռևս ուրիշի տվյալների բազայի «մի կտոր» է: Ինչպես ճիշտ ձևավորել ծառայության փոխազդեցությունը (առաջին պայմանագիրը) Պայմանագրի հստակ սահմանում. Դիզայնի ժամանակակից պրակտիկան (օրինակ՝ «API First» կամ «Contract First») սկսվում է ինտերֆեյսի պաշտոնական սահմանմամբ: Օգտագործվում են OpenAPI/Swagger, protobuf կամ GraphQL սխեմաներ: Այսպիսով, և՛ մարդիկ, և՛ մեքենաները գիտեն, թե որ վերջնակետերն են հասանելի, որ դաշտերն են պահանջվում և ինչ տվյալների տեսակներ են օգտագործվում: Ծառայություն որպես տվյալների սեփականատեր Միկրոծառայությունների (կամ նույնիսկ մոդուլային) ճարտարապետության մեջ ենթադրվում է, որ յուրաքանչյուր ծառայություն ամբողջությամբ տիրապետում է իր տվյալներին: Այն սահմանում է կառուցվածքը, պահեստավորումը և բիզնես տրամաբանությունը և ապահովում է API՝ այդ API-ի բոլոր արտաքին մուտքի համար: Ոչ ոք չի կարող դիպչել «ուրիշի» տվյալների բազային. միայն պաշտոնական վերջնական կետերը կամ իրադարձությունները: Սա հեշտացնում է կյանքը, երբ փոփոխությունները հարցականի տակ են, և միշտ պարզ է, թե ով է մեղավոր: Իրականացման օրինակներ REST/HTTP. Ծառայությունը հրապարակում է վերջնակետեր, ինչպիսիք են , , և այլն, և հաճախորդները հարցումներ են կատարում տվյալների հստակ սահմանված սխեմայով (DTO): GET /items POST /items gRPC / երկուական արձանագրություններ. gRPC/protobuf-ում ծառայությունը և հաղորդագրությունները պաշտոնապես սահմանվում են .proto ֆայլերում, և փոփոխությունները պարզապես կատարվում են .proto ֆայլերում, որտեղ սահմանված են մեթոդը, հարցումը և պատասխանը: Իրադարձությունների վրա հիմնված. Տվյալների սեփականատեր ծառայությունը հրապարակում է իրադարձություններ այնպիսի բրոքերի, ինչպիսիք են Kafka-ն կամ RabbitMQ-ն, և բաժանորդները սպառում են դրանք: Պայմանագիրն այստեղ միջոցառման ձևաչափն է: Կառուցվածքային փոփոխությունները կատարվում են տարբերակված թեմաների կամ հաղորդագրությունների միջոցով: Տարբերակի վերահսկում Անկախ նրանից, թե որ մոդելն է, ինտերֆեյսի վրա տարբերակի վերահսկումն իրականացնելը և՛ հնարավոր է, և՛ կարևոր: Օրինակ՝ REST-ում մենք ունենք /api/v1/… և /api/v2/: GRPC/protobuf-ի հետ կան հզոր մեխանիզմներ հետընթաց/առաջընթաց համատեղելիության համար. նոր դաշտեր, հաղորդագրություններ և մեթոդներ կարող են ավելացվել առանց հին հաճախորդները կոտրելու, մինչդեռ մյուսները նշված են որպես հնացած: Իրադարձությունների վրա հիմնված ճարտարապետություններում դուք կարող եք զուգահեռաբար հրապարակել իրադարձությունների հին և նոր ձևաչափերը, մինչև բոլոր սպառողները տեղափոխվեն: Բաշխված պատասխանատվություն Հիմնարար սկզբունքն այն է, որ թիմը, որը տիրապետում է տվյալներին, պետք է որոշի, թե ինչպես պահել և կառավարել դրանք, բայց նրանք չպետք է ուղղակիորեն մուտքագրեն այլ ծառայություններ: Մյուսները պետք է անցնեն API-ի միջոցով՝ ի տարբերություն օտարերկրյա տվյալների խմբագրման: Սա հանգեցնում է պատասխանատվության ավելի հստակ բաշխման. Եթե A ծառայությունը խափանված է, ապա դա շտկելու ծառայության պարտականությունն է ոչ թե հարևանները: Ծառայությունների փոխազդեցության օրինակներ Մեկ թիմում Առաջին հայացքից, եթե ամեն ինչ մեկ թիմում է, ինչո՞ւ բարդացնել ամեն ինչ API-ով: Իրականում, նույնիսկ եթե դուք ունեք մեկ արտադրանք, որը բաժանված է մոդուլների, ընդհանուր աղյուսակը կարող է հանգեցնել նույն խնդիրների: Ավելի լավ է ստեղծել «ֆասադ» կամ «միկրոծառայություն», որը պատկանում է «պատվերների» աղյուսակին, օրինակ, և այնուհետև այլ մոդուլներ (օրինակ՝ վերլուծականները) կոչեն այս ֆասադ/ծառայություն: Սա պարզ է դարձնում պայմանագրի սկզբունքը և հեշտացնում է վրիպազերծումը: Օրինակ՝ Պատվերների ծառայությունը պատվերների աղյուսակի սեփականատերն է, և Billing ծառայությունն ուղղակիորեն մուտք չի գործում այդ աղյուսակը. այն զանգեր է կատարում պատվերների ծառայության վերջնակետեր՝ պատվերի մանրամասները ստանալու կամ պատվերը որպես վճարված նշելու համար: Երկու թիմերի միջև Ավելի բարձր մակարդակում, երբ երկու կամ ավելի թիմեր պատասխանատու են տարբեր ոլորտների համար, սկզբունքները մնում են նույնը: Օրինակ՝ Ա թիմը պատասխանատու է ապրանքների կատալոգի ծառայության համար, որը պարունակում է տեղեկատվություն յուրաքանչյուր ապրանքի մասին (գին, մատչելիություն, հատկանիշներ): Բ թիմը հոգ է տանում զամբյուղի սպասարկման մասին: Եթե B թիմն ուղղակիորեն հարցումներ կատարի A թիմին պատկանող «Կատալոգ» աղյուսակին, A-ում ներքին սխեմայի ցանկացած փոփոխություն (օրինակ՝ դաշտերի ավելացում, կառուցվածքի փոփոխություն) կարող է ազդել Բ թիմի վրա: Ճիշտ մոտեցումը API-ի օգտագործումն է. A թիմը տրամադրում է վերջնակետեր, ինչպիսիք են , և այլն, և B թիմը օգտագործում է այդ մեթոդները: Եթե A-ն ի վիճակի է աջակցել ավելի հին և նոր տարբերակներին, նրանք կարող են թողարկել /v2, ինչը B-ին ժամանակ է տալիս միգրացիայի համար: GET /catalog/items GET /catalog/items/{id} Կազմակերպչական ասպեկտներ և առավելություններ Թափանցիկ հաղորդակցություն Պաշտոնական պայմանագրով բոլոր փոփոխությունները տեսանելի են՝ Swagger/OpenAPI-ում, .proto ֆայլերում կամ իրադարձությունների փաստաթղթերում: Ցանկացած թարմացում կարող է նախօրոք քննարկվել, պատշաճ կերպով փորձարկվել և պլանավորվել՝ անհրաժեշտության դեպքում հետ համատեղելիության ռազմավարություններով: Ավելի արագ զարգացում Մեկ ծառայության փոփոխությունները ավելի քիչ ազդեցություն են ունենում մյուսների վրա: Թիմը չպետք է անհանգստանա մեկ ուրիշին «կոտրելու» մասին, եթե նրանք պատշաճ կերպով կառավարեն նոր և հին դաշտերը կամ վերջնակետերը՝ ապահովելով սահուն անցում: Մուտքի և անվտանգության կառավարում API-ի դարպասները, նույնականացումը և թույլտվությունը (JWT, OAuth) ստանդարտ են ծառայությունների համար, բայց գրեթե անհնար է ընդհանուր աղյուսակի դեպքում: Ավելի հեշտ է կարգավորել մուտքը (ով կարող է զանգահարել, որ մեթոդներին), պահել տեղեկամատյանները, հետևել օգտագործման վիճակագրությանը և սահմանել քվոտաներ: Սա համակարգը դարձնում է ավելի անվտանգ և կանխատեսելի: Եզրակացություն Տվյալների բազայի համօգտագործվող աղյուսակը ավելի շուտ կատարման դետալ է, քան ծառայությունների միջև համաձայնություն, ուստի պայմանագիր չի համարվում: Բազմաթիվ խնդիրները (բարդ տարբերակների ձևավորում, քաոսային փոփոխություններ, անհասկանալի սեփականության իրավունք, անվտանգություն և կատարողականի ռիսկեր) երկարաժամկետ հեռանկարում այս մոտեցումն անհիմն են դարձնում: Ճիշտ մոտեցումը է, որը նշանակում է փոխազդեցության սահմանում պաշտոնական ձևավորման միջոցով և հետևելով այն սկզբունքին, որ յուրաքանչյուր ծառայություն մնում է իր տվյալների սեփականատերը: Սա ոչ միայն օգնում է նվազեցնել տեխնիկական պարտքը, այլև մեծացնում է թափանցիկությունը, արագացնում է արտադրանքի զարգացումը և հնարավորություն է տալիս անվտանգ փոփոխություններ կատարել՝ առանց տվյալների բազայի սխեմաների հրդեհաշիջման: Contract First-ն Դա և՛ տեխնիկական խնդիր է (ինչպես ձևավորել և ինտեգրվել), և՛ կազմակերպչական (ինչպես են թիմերը հաղորդակցվում և կառավարում փոփոխությունները): Եթե ցանկանում եք, որ ձեր արտադրանքը աճի առանց տվյալների բազայի սխեմաների հետ կապված անվերջ արտակարգ իրավիճակների հետ գործ ունենալու, ապա դուք պետք է սկսեք մտածել պայմանագրերի, այլ ոչ թե տվյալների բազայի ուղղակի հասանելիության մասին:
