Բարև ձեզ, ես աշխատում եմ DRD KP նախագծի թիմում (անիվների հավաքածուների կյանքի ցիկլի մոնիտորինգի համար բաշխված տվյալների ռեեստր): Այստեղ ես ուզում եմ կիսվել մեր թիմի փորձով՝ այս նախագծի համար ձեռնարկությունների բլոկչեյն մշակելու տեխնոլոգիայի սահմանափակումների ներքո: Ես հիմնականում կխոսեմ Hyperledger Fabric-ի մասին, բայց այստեղ նկարագրված մոտեցումը կարող է էքստրապոլացվել ցանկացած թույլատրված բլոկչեյնի վրա: Մեր հետազոտության վերջնական նպատակն է պատրաստել ձեռնարկատիրական բլոկչեյն լուծումներ, որպեսզի վերջնական արտադրանքը հաճելի լինի օգտագործման համար և ոչ այնքան դժվար՝ պահպանելը:
Բացահայտումներ, անսպասելի լուծումներ չեն լինի, և այստեղ առանձնահատուկ զարգացումներ չեն ընդգծվի (քանի որ չունեմ): Ես պարզապես ուզում եմ կիսվել իմ համեստ փորձով, ցույց տալ, որ «դա հնարավոր էր» և, հավանաբար, մեկնաբանություններում կարդալ լավ և ոչ այնքան լավ որոշումներ կայացնելու այլ մարդկանց փորձի մասին:
Խնդիր. բլոկչեյնները դեռ չեն ծավալվում
Այսօր շատ ծրագրավորողների ջանքերն ուղղված են բլոկչեյնը դարձնել իսկապես հարմար տեխնոլոգիա, և ոչ թե ժամային ռումբ՝ գեղեցիկ փաթաթում: Պետական ալիքները, լավատեսական հավաքագրումը, պլազման և բեկորները հավանաբար սովորական կդառնան: Մի օր. Կամ գուցե TON-ը կրկին հետաձգի գործարկումը վեց ամսով, և հաջորդ Plasma Group-ը կդադարի գոյություն ունենալ: Մենք կարող ենք հավատալ հաջորդ ճանապարհային քարտեզին և գիշերը կարդալ փայլուն սպիտակ թերթեր, բայց այստեղ և հիմա մենք պետք է ինչ-որ բան անենք մեր ունեցածով: Շա՛տ արեք:
Ընթացիկ նախագծում մեր թիմի առջեւ դրված խնդիրն ընդհանուր առմամբ այսպիսին է. Անհրաժեշտ է DLT-ի վրա ստեղծել լուծում, որը կաշխատի սովորական ԱՀ-ների վրա՝ առանց կատարողականի հատուկ պահանջների և կապահովի օգտագործողի փորձը ոչ ավելի վատ, քան կենտրոնացված հաշվապահական համակարգերը: Լուծման հիմքում ընկած տեխնոլոգիան պետք է նվազագույնի հասցնի տվյալների վնասակար մանիպուլյացիայի հնարավորությունը, ահա թե ինչու է բլոկչեյնը:
Սպիտակ թերթերից և լրատվամիջոցներից ստացված կարգախոսները մեզ խոստանում են, որ հաջորդ զարգացումը թույլ կտա մեզ վայրկյանում միլիոնավոր գործարքներ կատարել: Ի՞նչ է դա իրականում:
Mainnet Ethereum-ը ներկայումս աշխատում է ~30 tps արագությամբ: Միայն դրա պատճառով դժվար է այն ընկալել որպես բլոկչեյն որևէ կերպ հարմար կորպորատիվ կարիքների համար: Թույլատրված լուծումների թվում կան հենանիշներ, որոնք ցույց են տալիս 2000 tps () կամ 3000 tps (, հրապարակման մեջ մի փոքր ավելի քիչ կա, բայց պետք է հաշվի առնել, որ հենանիշն իրականացվել է հին կոնսենսուսային շարժիչի վրա): Եղել է , որը տվել է ոչ ամենավատ արդյունքները՝ 20000 tps, բայց առայժմ սա ընդամենը ակադեմիական հետազոտություն է, որը սպասում է դրա կայուն իրականացմանը։ Քիչ հավանական է, որ կորպորացիան, որը կարող է իրեն թույլ տալ պահպանել բլոկչեյն մշակողների բաժինը, համակերպվի նման ցուցանիշների հետ: Բայց խնդիրը միայն թողունակությունը չէ, կա նաև ուշացում:
Ժամկետանցություն
Գործարքի մեկնարկի պահից մինչև համակարգի կողմից դրա վերջնական հաստատումը ուշացումը կախված է ոչ միայն հաղորդագրության վավերացման և պատվիրման բոլոր փուլերով անցնելու արագությունից, այլև բլոկի ձևավորման պարամետրերից: Նույնիսկ եթե մեր բլոկչեյնը մեզ թույլ է տալիս կատարել 1000000 tps արագությամբ, բայց պահանջում է 10 րոպե 488 ՄԲ բլոկ ստեղծելու համար, արդյոք դա մեզ համար ավելի հեշտ կդառնա՞:
Եկեք ավելի մոտիկից նայենք Hyperledger Fabric-ում գործարքի կյանքի ցիկլին՝ հասկանալու համար, թե որտեղ է ծախսվում ժամանակը և ինչպես է այն առնչվում արգելափակման գեներացման պարամետրերին:
վերցված այստեղից:
(1) Հաճախորդը ստեղծում է գործարք, ուղարկում է այն հաստատող գործընկերներին, վերջիններս նմանակում են գործարքը (կիրառում են շղթայական կոդով կատարված փոփոխությունները ընթացիկ վիճակի վրա, բայց մի պարտավորվում մատյանում) և ստանում RWSet՝ բանալիների անուններ, տարբերակներ և արժեքներ . Վերցված է CouchDB-ի հավաքածուից, (2) աջակցողները հաճախորդին հետ են ուղարկում ստորագրված RWSet, (3) հաճախորդը կամ ստուգում է բոլոր անհրաժեշտ հասակակիցների (հաստատողների) ստորագրությունների առկայությունը, այնուհետև գործարքն ուղարկում է պատվիրման ծառայությանը։ , կամ ուղարկում է այն առանց ստուգման (ստուգումը դեռ կկայանա ավելի ուշ), պատվիրման ծառայությունը ձևավորում է բլոկ և (4) հետ է ուղարկում բոլոր գործընկերներին, ոչ միայն հաստատողներին. հասակակիցները ստուգում են, որ ընթերցված հավաքածուի հիմնական տարբերակները համընկնում են տվյալների բազայի տարբերակների հետ, բոլոր հաստատողներն ունեն ստորագրություններ, և վերջապես կատարում են արգելափակումը:
Բայց սա դեռ ամենը չէ։ «Պատվիրողը կազմում է բլոկ» բառերը թաքցնում են ոչ միայն գործարքների պատվիրումը, այլ նաև 3 հաջորդական ցանցային հարցումներ առաջնորդից դեպի հետևորդներ և հետադարձ. իրենց տեղեկամատյանում, ուղարկում է ղեկավարին հաջողված կրկնօրինակման հաստատում, առաջնորդը հանձնում է հաղորդագրությունը, ուղարկում է ստանձնման հաստատում հետևորդներին, հետևորդները պարտավորվում են: Որքան փոքր է բլոկի ձևավորման չափը և ժամանակը, այնքան հաճախ պատվիրող ծառայությունը պետք է կոնսենսուս հաստատի. Hyperledger Fabric-ն ունի բլոկների ձևավորման երկու պարամետր՝ BatchTimeout - բլոկի ձևավորման ժամանակը և BatchSize - բլոկի չափը (գործարքների քանակը և բլոկի չափը բայթերով): Հենց որ պարամետրերից մեկը հասնում է սահմանին, թողարկվում է նոր բլոկ: Որքան շատ պատվերի հանգույցներ, այնքան ավելի երկար կպահանջվի: Հետեւաբար, դուք պետք է մեծացնեք BatchTimeout-ը և BatchSize-ը: Բայց քանի որ RWSets-ները տարբերակված են, որքան մեծ է մեր բլոկը, այնքան մեծ է MVCC կոնֆլիկտների հավանականությունը: Բացի այդ, քանի որ BatchTimeout-ը մեծանում է, UX-ը աղետալիորեն դեգրադացվում է: Այս խնդիրների լուծման հետևյալ սխեման ինձ խելամիտ և ակնհայտ է թվում.
Ինչպե՞ս խուսափել բլոկի վերջնականացման սպասելուց և չկորցնել գործարքի կարգավիճակին հետևելու հնարավորությունը
Որքան երկար է ձևավորման ժամանակը և բլոկի չափը, այնքան բարձր է բլոկչեյնի թողունակությունը: Մեկը ուղղակիորեն չի բխում մյուսից, բայց պետք է հիշել, որ RAFT-ում կոնսենսուսի հաստատումը պահանջում է երեք ցանցային հարցումներ առաջնորդից դեպի հետևորդներ և հետադարձ: Որքան շատ պատվերի հանգույցներ, այնքան ավելի երկար կպահանջվի: Որքան փոքր է բլոկի ձևավորման չափը և ժամանակը, այնքան շատ են նման փոխազդեցությունները: Ինչպե՞ս մեծացնել գեներացման ժամանակը և բլոկի չափը՝ առանց վերջնական օգտագործողի համար համակարգի արձագանքման ժամանակը մեծացնելու:
Նախ, մենք պետք է ինչ-որ կերպ լուծենք MVCC կոնֆլիկտները, որոնք առաջացել են բլոկի մեծ չափի պատճառով, որը կարող է ներառել նույն տարբերակով տարբեր RWSets: Ակնհայտ է, որ հաճախորդի կողմից (բլոկչեյն ցանցի հետ կապված, սա կարող է լինել հետին պլան, և ես դա նկատի ունեմ) ձեզ անհրաժեշտ է. MVCC կոնֆլիկտների կարգավորիչ, որը կարող է լինել կա՛մ առանձին ծառայություն, կա՛մ սովորական դեկորատոր՝ զանգի վերևում, որը սկսում է գործարքը կրկնակի տրամաբանությամբ:
Կրկնել փորձը կարող է իրականացվել էքսպոնենցիալ ռազմավարությամբ, բայց հետո հետաձգումը նույնքան էքսպոնենցիալ կերպով կնվազի: Այսպիսով, դուք պետք է օգտագործեք կամ պատահական կրկնվող փորձը որոշակի փոքր սահմաններում, կամ մշտական: Առաջին տարբերակում հնարավոր բախումների վրա աչքով:
Հաջորդ քայլը հաճախորդի փոխազդեցությունը համակարգի հետ ասինխրոն դարձնելն է, որպեսզի այն չսպասի 15, 30 կամ 10000000 վայրկյան, որը մենք կսահմանենք որպես BatchTimeout: Բայց միևնույն ժամանակ անհրաժեշտ է պահպանել կարողությունը՝ ստուգելու, որ գործարքով նախաձեռնված փոփոխությունները գրանցված են/չեն գրանցվում բլոկչեյնում։
Տվյալների բազան կարող է օգտագործվել գործարքի կարգավիճակը պահելու համար: Ամենապարզ տարբերակը CouchDB-ն է՝ օգտագործման հեշտության պատճառով. տվյալների բազան ունի UI out of box, REST API, և դուք կարող եք հեշտությամբ կարգավորել դրա կրկնօրինակումը և փոխանակումը: Դուք կարող եք պարզապես առանձին հավաքածու ստեղծել նույն CouchDB օրինակում, որն օգտագործում է Fabric-ը՝ իր համաշխարհային վիճակը պահելու համար: Մենք պետք է պահենք այս տեսակի փաստաթղթերը:
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Այս փաստաթուղթը գրվում է տվյալների բազայում՝ նախքան գործարքը գործընկերներին ուղարկելը, կազմակերպության ID-ն վերադարձվում է օգտագործողին (նույն ID-ն օգտագործվում է որպես բանալի), եթե սա ստեղծման գործողություն է, և այնուհետև Status, TxID և Error դաշտերը. թարմացվում է, քանի որ համապատասխան տեղեկատվություն է ստացվում հասակակիցներից:
Այս սխեմայում օգտատերը չի սպասում բլոկի վերջնական ձևավորմանը՝ 10 վայրկյան դիտելով էկրանի վրա պտտվող անիվը, նա ստանում է ակնթարթային պատասխան համակարգից և շարունակում է աշխատել։
Գործարքների կարգավիճակները պահելու համար մենք ընտրեցինք BoltDB-ն, քանի որ մենք պետք է խնայենք հիշողությունը և չենք ցանկանում ժամանակ վատնել ցանցային փոխազդեցության վրա առանձին տվյալների բազայի սերվերի հետ, հատկապես, երբ այս փոխազդեցությունը տեղի է ունենում պարզ տեքստային արձանագրության միջոցով: Ի դեպ, անկախ նրանից՝ դուք օգտագործում եք CouchDB վերը նկարագրված սխեման իրագործելու համար, թե պարզապես համաշխարհային վիճակ պահելու համար, ամեն դեպքում իմաստ ունի օպտիմալացնել տվյալների պահպանման եղանակը CouchDB-ում: Լռելյայնորեն, CouchDB-ում b-tree հանգույցների չափը 1279 բայթ է, ինչը շատ ավելի փոքր է, քան սկավառակի հատվածի չափը, ինչը նշանակում է, որ և՛ ծառի ընթերցումը, և՛ հավասարակշռումը վերականգնելը կպահանջի ավելի ֆիզիկական մուտք դեպի սկավառակ: Օպտիմալ չափը համապատասխանում է ստանդարտին և կազմում է 4 կիլոբայթ: Օպտիմալացնելու համար մենք պետք է սահմանենք պարամետրը btree_chunk_size-ը հավասար է 4096-ի CouchDB կազմաձևման ֆայլում: BoltDB-ի համար նման ձեռքով միջամտություն .
Հետճնշում. բուֆերային ռազմավարություն
Բայց հաղորդագրությունները կարող են շատ լինել: Ավելին, քան համակարգը կարող է կառավարել, ռեսուրսները կիսելով մի տասնյակ այլ ծառայությունների հետ, բացի գծապատկերում ներկայացվածներից, և այս ամենը պետք է անթերի աշխատի նույնիսկ այն մեքենաների վրա, որոնց վրա Intellij Idea-ի գործարկումը չափազանց հոգնեցուցիչ կլինի:
Հաղորդակցման համակարգերի՝ արտադրողի և սպառողի տարբեր հզորության խնդիրը լուծվում է տարբեր ձևերով։ Տեսնենք, թե ինչ կարող էինք անել։
ՆետվելովՄենք կարող ենք պնդել, որ մենք ի վիճակի ենք մշակել առավելագույնը X գործարքներ T վայրկյանում: Այս սահմանաչափը գերազանցող բոլոր հարցումները մերժվում են: Սա բավականին պարզ է, բայց հետո կարող եք մոռանալ UX-ի մասին:
ՎերահսկումՍպառողը պետք է ունենա ինչ-որ ինտերֆեյս, որի միջոցով, կախված ծանրաբեռնվածությունից, նա կարող է վերահսկել արտադրողի TPS-ը: Վատ չէ, բայց դա պարտավորություններ է պարտադրում հաճախորդի ծրագրավորողներին, որոնք բեռ են ստեղծում այս ինտերֆեյսի իրականացման համար: Սա մեզ համար անընդունելի է, քանի որ բլոկչեյնը ապագայում ինտեգրվելու է երկար ժամանակ գոյություն ունեցող մեծ թվով համակարգերի։
ԲուֆերինգՄուտքային տվյալների հոսքին դիմակայելու փոխարեն, մենք կարող ենք բուֆերացնել այս հոսքը և մշակել այն պահանջվող արագությամբ: Ակնհայտ է, որ սա լավագույն լուծումն է, եթե մենք ցանկանում ենք լավ օգտվողի փորձ տրամադրել: Մենք իրականացրել ենք բուֆեր՝ օգտագործելով հերթ RabbitMQ-ում:
Երկու նոր գործողություններ են ավելացվել սխեմային. (1) API-ին ուղղված հարցումը ստանալուց հետո հերթում տեղադրվում է գործարք կանչելու համար անհրաժեշտ պարամետրերով հաղորդագրություն, և հաճախորդը ստանում է հաղորդագրություն, որ գործարքն ընդունվել է. համակարգը, (2) backend-ը կարդում է տվյալները հերթից կազմաձևում նշված արագությամբ. սկսում է գործարք և թարմացնում տվյալները կարգավիճակի պահեստում:
Այժմ դուք կարող եք ավելացնել ձևավորման ժամանակը և արգելափակել հզորությունը այնքան, որքան ցանկանում եք՝ թաքցնելով ուշացումները օգտվողից:
Այլ գործիքներ
Այստեղ շղթայական կոդի մասին ոչինչ չասվեց, քանի որ, որպես կանոն, դրա մեջ օպտիմալացնելու բան չկա։ Շղթայական ծածկագիրը պետք է լինի հնարավորինս պարզ և ապահով. դա այն ամենն է, ինչ պահանջվում է դրանից: Շրջանակն օգնում է մեզ գրել շղթայական կոդը պարզ և ապահով S7 Techlab-ից և ստատիկ անալիզատորից .
Բացի այդ, մեր թիմը մշակում է մի շարք կոմունալ ծառայություններ Fabric-ի հետ աշխատանքը պարզ և հաճելի դարձնելու համար. , կոմունալ համար (ավելացնելով/հեռացնելով կազմակերպություններ, RAFT հանգույցներ), օգտակար համար . Եթե ցանկանում եք նպաստել, ապա ողջունում եք:
Ամփոփում
Այս մոտեցումը թույլ է տալիս հեշտությամբ փոխարինել Hyperledger Fabric-ը Quorum-ով, այլ մասնավոր Ethereum ցանցերով (PoA կամ նույնիսկ PoW), զգալիորեն նվազեցնել իրական թողունակությունը, բայց միևնույն ժամանակ պահպանել նորմալ UX (ինչպես բրաուզերում օգտագործողների, այնպես էլ ինտեգրված համակարգերի համար): Երբ սխեմայում Fabric-ը Ethereum-ով փոխարինում եք, ձեզ միայն անհրաժեշտ կլինի փոխել կրկնակի ծառայության/դեկորատորի տրամաբանությունը՝ MVCC-ի կոնֆլիկտների մշակումից մինչև ատոմային աննախադեպ ավելացում և նորից ուղարկում: Բուֆերավորումը և կարգավիճակի պահպանումը հնարավորություն տվեցին անջատել արձագանքման ժամանակը բլոկի ձևավորման ժամանակից: Այժմ դուք կարող եք ավելացնել հազարավոր պատվերի հանգույցներ և չվախենալ, որ բլոկները շատ հաճախ են ձևավորվում և բեռնում են պատվիրման ծառայությունը:
Հիմնականում դա այն ամենն է, ինչ ես ուզում էի կիսվել: Ես ուրախ կլինեմ, եթե սա ինչ-որ մեկին օգնի իր աշխատանքում:
Source: www.habr.com