API එකක් ලෙස වගුවක්? මායාවන් සහ යථාර්ථය

හැඳින්වීම

සේවා අන්තර්ක්‍රියා සන්දර්භය තුළ "කොන්ත්‍රාත්තුවක්" යනු කුමක්ද?

අන්තර්ක්‍රියා කරන සේවා මොඩියුලවල සන්දර්භය තුළ, නොවැළැක්විය හැකි ප්‍රශ්නයක් මතු වේ: සන්නිවේදනය සිදුවන්නේ කුමන නීති මගින්ද ? තොරතුරු තාක්ෂණ නිෂ්පාදන වලදී, "කොන්ත්‍රාත්තුවක්" යනු පද්ධති අතර ගලා යන දත්ත සහ එය සම්ප්‍රේෂණය වන ආකාරය පිළිබඳ විධිමත් අවබෝධයක් නියෝජනය කරයි. මෙයට දත්ත ආකෘතිය (JSON, Protobuf, ආදිය), ව්‍යුහාත්මක අංග (ක්ෂේත්‍ර, දත්ත වර්ග), සන්නිවේදන ප්‍රොටෝකෝලය (REST, gRPC, පණිවිඩ පෝලිම්) සහ අනෙකුත් පිරිවිතරයන් ඇතුළත් වේ.

කොන්ත්‍රාත්තුවක් විවෘතභාවය (ලැබෙන සහ යවන දේ සෑම කෙනෙකුම දනී), පුරෝකථනය කිරීමේ හැකියාව (අපට කොන්ත්‍රාත්තුව යාවත්කාලීන කර අනුවාද පවත්වා ගත හැකිය) සහ විශ්වසනීයත්වය (අපි හොඳින් කළමනාකරණය කළ වෙනස්කම් සිදු කළහොත් අපගේ පද්ධතිය අසාර්ථක නොවනු ඇත) සහතික කරයි.

මිනිසුන් දත්ත සමුදායේ වගුවක් "කොන්ත්‍රාත්තුවක්" ලෙස තෝරා ගැනීමට නැඹුරු වන්නේ ඇයි?

ප්‍රායෝගිකව, සෑම කෙනෙකුම ක්ෂුද්‍ර සේවා, “කොන්ත්‍රාත්තු” සහ API ගැන කතා කළත්, අපි බොහෝ විට මිනිසුන් ප්‍රවේශය අනුගමනය කරන ආකාරය දකිමු: “API ගොඩනැගීම වෙනුවට දත්ත සමුදාය තුළ බෙදාගත් වගුවක් නිර්මාණය නොකරන්නේ ඇයි?”

• ඓතිහාසික හෝ සංවිධානාත්මක පුරුද්ද: සෑම දෙයක්ම සෑම විටම එක් සමාගමක් තුළ එක් දත්ත සමුදා පද්ධතියක ගබඩා කර ඇති විට, රෝදය නැවත නිර්මාණය කරන්නේ ඇයි?

• "ඉක්මන් විසඳුමක්" යන මානසිකත්වය: අපි ලියන්නෙමු, ඔබ කියවන්නේ අවසර නීති සැකසීමෙන් සහ API පිරිවිතර සැලසුම් කිරීමෙන් තොරවය.

• "විශාල දත්ත" තර්කය: ගිගාබයිට් දස දහස් ගණනක් හෝ සිය ගණනක් දත්ත සමඟ වැඩ කරන විට, බෙදාගත් වගුවකට සෘජු මාරු කිරීම සරල, වේගවත් සහ වඩා ලාභදායී ලෙස පෙනේ, නමුත් ප්‍රායෝගිකව, එය පරිමාණය සහ කාර්ය සාධන ගැටළු මෙන්ම දත්ත හිමිකාරිත්ව ගැටළු ද නිර්මාණය කරයි.

එබැවින්, දත්ත හුවමාරුව සඳහා බෙදාගත් වගුවක් භාවිතා කිරීම කාර්යක්ෂම හා ඉක්මන් ප්‍රතිඵල සඳහා ප්‍රශස්ත කර ඇති බවක් පෙනෙන්නට තිබුණද, එය දිගු කාලීනව විවිධ තාක්ෂණික සහ සංවිධානාත්මක අභියෝග ජනනය කරයි. කෙසේ වෙතත්, කණ්ඩායම් දත්ත හුවමාරුව සඳහා බෙදාගත් වගු තෝරා ගන්නා විට, ක්‍රියාත්මක කිරීමේදී ඔවුන්ට බොහෝ ගැටළු වලට මුහුණ දීමට සිදුවිය හැකිය.

“දත්ත සමුදායේ වගුවක්” කොන්ත්‍රාත්තුවක් නොවන්නේ ඇයි (සහ එය ප්‍රති-රටාවක් වන්නේ ඇයි).

පැහැදිලිව නිර්වචනය කරන ලද අතුරු මුහුණතක් නොමැතිකම

සේවාවන් REST/gRPC/GraphQL හරහා සන්නිවේදනය කරන විට, ඒවාට විධිමත් අර්ථ දැක්වීමක් ඇත: OpenAPI (Swagger), protobuf යෝජනා ක්‍රම හෝ GraphQL යෝජනා ක්‍රම. මේවා කුමන සම්පත් (අන්ත ලක්ෂ්‍ය) තිබේද, කුමන ක්ෂේත්‍ර අපේක්ෂා කරන්නේද, ඒවායේ වර්ග සහ ඉල්ලීම්/ප්‍රතිචාර ආකෘති විස්තරාත්මකව නිර්වචනය කරයි. 'බෙදාගත් වගුවක්' කොන්ත්‍රාත්තුවක් ලෙස ක්‍රියා කරන විට විධිමත් විස්තරයක් නොමැත: කොන්ත්‍රාත්තුවේ විධිමත් විස්තරයක් නොමැත; වගු යෝජනා ක්‍රමය (DDL) පමණක් ලබා ගත හැකි අතර එය පවා හොඳින් ලේඛනගත කර නොමැත. වගු ව්‍යුහයේ ඕනෑම සුළු වෙනස් කිරීමක් (උදා: තීරුවක් එකතු කිරීම හෝ මකා දැමීම, දත්ත වර්ග වෙනස් කිරීම) මෙම වගුවෙන් කියවන හෝ ලියන අනෙකුත් කණ්ඩායම්වලට බලපෑ හැකිය.

අනුවාදකරණය සහ පරිණාම ගැටළු

API අනුවාදකරණය සාමාන්‍ය පුරුද්දකි: අපට v1, v2, ආදිය තිබිය හැකි අතර, අපට පසුගාමී අනුකූලතාව පවත්වා ගත හැකි අතර පසුව ක්‍රමයෙන් සේවාදායකයින් නව අනුවාද වෙත ගෙන යා හැකිය. දත්ත සමුදා වගු සඳහා, අපට ඇත්තේ DDL මෙහෙයුම් පමණි (උදා: ALTER TABLE ), ඒවා නිශ්චිත DB එන්ජිමකට තදින් සම්බන්ධ කර ඇති අතර සංක්‍රමණ ප්‍රවේශමෙන් හැසිරවීම අවශ්‍ය වේ.

පාරිභෝගිකයින්ට ඔවුන්ගේ විමසුම් යාවත්කාලීන කිරීමට අවශ්‍ය වන යෝජනා ක්‍රම වෙනස්කම් පිළිබඳව ඇඟවීම් යැවිය හැකි මධ්‍යගත පද්ධතියක් නොමැත. එහි ප්‍රතිඵලයක් ලෙස, “මේසය යට” ගනුදෙනු සිදුවිය හැකිය: යමෙකුට “හෙට, අපි X තීරුව Y ලෙස වෙනස් කරමු” යනුවෙන් කතාබහක පළ කළ හැකිය, නමුත් සෑම කෙනෙකුම නියමිත වේලාවට සූදානම් වනු ඇති බවට සහතිකයක් නොමැත.

පැහැදිලි හිමිකාරිත්වයක් නැත

පැහැදිලිව නිර්වචනය කරන ලද API එකක් ඇති විට, එය අයිති කාටද යන්න පැහැදිලි වේ: API ප්‍රකාශකයා ලෙස සේවය කරන සේවාව. කණ්ඩායම් කිහිපයක් එකම දත්ත සමුදා වගුව භාවිතා කරන විට, ව්‍යුහය තීරණය කළ යුත්තේ කාටද සහ ගබඩා කළ යුතු ක්ෂේත්‍ර මොනවාද සහ ඒවා අර්ථ නිරූපණය කරන්නේ කෙසේද යන්න පිළිබඳව ව්‍යාකූලත්වයක් පවතී. එහි ප්‍රතිඵලයක් ලෙස, වගුව “කිසිවෙකුගේ දේපළක් නොවේ” බවට පත්විය හැකි අතර, සෑම වෙනස්කමක්ම ගවේෂණයක් බවට පත්වේ: “ඔවුන් පැරණි තීරුව භාවිතා කරන්නේ නම් අපි එම අනෙක් කණ්ඩායම සමඟ පරීක්ෂා කළ යුතුයි!”

ආරක්ෂක සහ ප්‍රවේශ පාලන ගැටළු

බොහෝ කණ්ඩායම් වලට දත්ත සමුදාය වෙත ප්‍රවේශය තිබේ නම්, මේසයකට කියවීමට සහ ලිවීමට හැක්කේ කාටද යන්න නිරීක්ෂණය කිරීම දුෂ්කර ය. අනවසර සේවාවන්ට දත්ත ඔවුන් සඳහා අදහස් නොකළද ඒවාට ප්‍රවේශ විය හැකි අවස්ථාවක් තිබේ. API එකක් සමඟ එවැනි ගැටළු කළමනාකරණය කිරීම පහසුය: ඔබට ප්‍රවේශ අයිතිවාසිකම් පාලනය කළ හැකිය (කුමන ක්‍රමවලට ඇමතිය හැකිද), සත්‍යාපනය සහ අවසරය භාවිතා කළ හැකි අතර, කවුරුන් කුමක් ඇමතුවේද යන්න නිරීක්ෂණය කළ හැකිය. වගුවක් සමඟ, එය වඩාත් සංකීර්ණ වේ.

අභ්‍යන්තර ව්‍යුහය මත යැපීම

දත්ත වලට කරන ඕනෑම අභ්‍යන්තර වෙනස් කිරීමක් (දර්ශක ප්‍රතිසංවිධානය කිරීම, වගුව කොටස් කිරීම, දත්ත සමුදාය වෙනස් කිරීම) ගෝලීය ගැටලුවක් බවට පත්වේ. වගුව පොදු අතුරු මුහුණතක් ලෙස ක්‍රියා කරන්නේ නම්, හිමිකරුට සියලුම බාහිර පාඨකයින්ට සහ ලේඛකයින්ට අනතුරක් නොකර අභ්‍යන්තර වෙනස්කම් කළ නොහැක.

වේදනා ලකුණු සහ ප්‍රායෝගිකව ඇති වන සාමාන්‍ය ගැටළු

වෙනස්කම් සම්බන්ධීකරණය කිරීම

මෙය වඩාත්ම වේදනාකාරී අංගයයි: ඊළඟ දවසේ සැලැස්ම වෙනස් වන බව තවත් කණ්ඩායමකට දැනුම් දෙන්නේ කෙසේද ?

• වගු අනුවාදය යාවත්කාලීන කිරීම සඳහා සාර්ථක අවස්ථාවක්: හිමිකරු පැරණි එකට සමාන්තරව යාවත්කාලීන කරන ලද යෝජනා ක්‍රමයක් සහිත නව වගුවක් නිර්මාණය කරයි. පැරණි අනුවාදය වත්මන් පාරිභෝගිකයින්ට ප්‍රවේශ විය හැකි අතර හිමිකරු ඔවුන්ට පණිවිඩයක් යවයි, "නව ව්‍යුහය තිබේ; ලියකියවිලි සහ කාලසීමාවන් පරීක්ෂා කරන්න. අනුවාද දෙකම පවතින අතරතුර කරුණාකර සංක්‍රමණය වන්න."

• කෙසේ වෙතත්, OLAP තත්ත්වයකදී හෝ විශාල දත්ත පරිමාවන් සමඟ, සමාන්තර වගු දෙකක් පවත්වා ගැනීම සුළුපටු කාර්යයක් නොවේ. පැරණි සිට නව යෝජනා ක්‍රමයට දත්ත ගෙන යන ආකාරය ද ඔබ තීරණය කළ යුතුය. මේ සඳහා සමහර විට සැලසුම් කළ අක්‍රීය කාලය හෝ ඉතා සංකීර්ණ යටිතල පහසුකම් අවශ්‍ය විය හැකිය. මෙම ක්‍රියාවලිය අනිවාර්යයෙන්ම අවදානම් සහ අමතර වැඩ යන දෙකම හඳුන්වා දෙයි.

දත්ත අඛණ්ඩතා ගැටළු

තීරණාත්මක දත්ත තෝරා ගැනීමට සහ යාවත්කාලීන කිරීමට බහු කණ්ඩායම් බෙදාගත් වගුවක් භාවිතා කරන විට, එය පහසුවෙන් "යුධ පිටියක්" බවට පත්විය හැකිය. එහි ප්‍රතිඵලය වන්නේ ව්‍යාපාර තර්කනය විවිධ සේවාවන් හරහා විසිරී යාම සහ දත්ත අඛණ්ඩතාව පිළිබඳ මධ්‍යගත පාලනයක් නොමැති වීමයි. විශේෂිත ක්ෂේත්‍රයක් නිශ්චිත ආකාරයකින් ගබඩා කර ඇත්තේ ඇයි, එය යාවත්කාලීන කළ හැක්කේ කාටද සහ එය හිස්ව තැබුවහොත් කුමක් සිදුවේද යන්න දැන ගැනීම ඉතා අපහසු වේ.

නිදොස්කරණය සහ අධීක්ෂණ අභියෝග

උදාහරණයක් ලෙස, වගුව කැඩී යයි සිතමු: නරක දත්ත තිබේ නම් හෝ යමෙකු තීරණාත්මක පේළි කිහිපයක අගුලක් ගෙන තිබේ නම්. ගැටලුවේ මූලාශ්‍රය හඳුනා ගැනීම සඳහා බොහෝ විට DB ප්‍රවේශය ඇති සෑම කණ්ඩායමකටම ගැටලුව ඇති කළේ කුමන විමසුමද යන්න තීරණය කිරීමට අවශ්‍ය විය හැකිය. එය බොහෝ විට පැහැදිලි නැත: මෙයින් අදහස් කරන්නේ එක් කණ්ඩායමක විමසුම දත්ත සමුදාය අගුළු දමා තිබිය හැකි අතර තවත් කණ්ඩායමක විමසුම නිරීක්ෂණය කළ හැකි දෝෂය ඇති කරන බවයි.

තනි නෝඩයක අසාර්ථකත්වය සෑම කෙනෙකුම පහළට ඇද දමයි.

බෙදාගත් දත්ත සමුදායක් යනු අසාර්ථක වීමේ තනි ලක්ෂ්‍යයකි. එය අක්‍රිය වුවහොත්, බොහෝ සේවාවන් ඒ සමඟම අක්‍රිය වනු ඇත. එක් සේවාවක අධික විමසුම් හේතුවෙන් දත්ත සමුදායට කාර්ය සාධනය පිළිබඳ ගැටළු ඇති විට, සියලුම සේවාවන් ගැටළු වලට මුහුණ දෙයි. පැහැදිලි API සහ දත්ත හිමිකාරිත්වය සහිත ආකෘතියක, සෑම කණ්ඩායමක්ම ඔවුන්ගේ සේවාවේ ලබා ගැනීමේ හැකියාව සහ කාර්ය සාධනය පිළිබඳ ප්‍රවීණයන් වන බැවින්, එක් සංරචකයක අසාර්ථකත්වයක් අනෙක් අයට ප්‍රචාරය නොවේ.

වෙනම කියවීමට පමණක් අනුරුවක් ලබා දීමෙන් ගැටළුව විසඳෙන්නේ නැත.

පොදු සම්මුතියක් නම්: “අපගේ ප්‍රධාන දත්ත සමුදායට බලපෑමක් නොකර ඔබට විමසිය හැකි වන පරිදි කියවීමට පමණක් අනුරුවක් අපි ඔබට ලබා දෙන්නෙමු.” මුලදී, එය සමහර පැටවීමේ ගැටළු විසඳිය හැකිය, නමුත්:

• අනුවාද ගැටළු තවමත් පවතී. ප්‍රධාන ගැටළුව වන්නේ, ප්‍රධාන වගු ව්‍යුහය වෙනස් වන විට, අනුරුවේ ව්‍යුහය ද යම් ප්‍රමාදයකින් වෙනස් වීමයි.

• ප්‍රතිවර්තන ප්‍රමාදය දත්ත තත්වයන් අනපේක්ෂිත වීමට හේතු විය හැක, විශේෂයෙන් විශාල දත්ත කට්ටල සමඟ.

• හිමිකාරිත්වය තවමත් පැහැදිලි නැත: ආකෘතිය, ව්‍යුහය සහ භාවිත නීති නිර්වචනය කරන්නේ කවුද? අනුරුවක් තවමත් වෙනත් කෙනෙකුගේ දත්ත සමුදායේ "කෑල්ලක්" වේ.

සේවා අන්තර්ක්‍රියාව නිසි ලෙස සැලසුම් කරන්නේ කෙසේද (පළමුව කොන්ත්‍රාත්තුව)

ගිවිසුමක පැහැදිලි අර්ථ දැක්වීමක්.

නවීන නිර්මාණ පිළිවෙත් (උදාහරණයක් ලෙස, "API පළමුව" හෝ "කොන්ත්‍රාත්තුව පළමුව") විධිමත් අතුරුමුහුණත් අර්ථ දැක්වීමකින් ආරම්භ වේ. OpenAPI/Swagger, protobuf, හෝ GraphQL යෝජනා ක්‍රම භාවිතා වේ. මේ ආකාරයෙන්, පුද්ගලයින් සහ යන්ත්‍ර යන දෙකම ලබා ගත හැකි අන්ත ලක්ෂ්‍ය මොනවාද, අවශ්‍ය ක්ෂේත්‍ර මොනවාද සහ භාවිතා කරන දත්ත වර්ග මොනවාදැයි දනී.

දත්ත හිමිකරු ලෙස සේවය

ක්ෂුද්‍ර සේවා (හෝ මොඩියුලර් පවා) ගෘහ නිර්මාණ ශිල්පයක, උපකල්පනය වන්නේ එක් එක් සේවාව එහි දත්ත සම්පූර්ණයෙන්ම හිමිකර ගන්නා බවයි. එය ව්‍යුහය, ගබඩාව සහ ව්‍යාපාර තර්කනය නිර්වචනය කරන අතර එම API වෙත සියලු බාහිර ප්‍රවේශයන් සඳහා API එකක් සපයයි. කිසිවෙකුට 'වෙනත් කෙනෙකුගේ' දත්ත සමුදාය ස්පර්ශ කළ නොහැක: නිල අන්ත ලක්ෂ්‍ය හෝ සිදුවීම් පමණි. වෙනස්කම් ප්‍රශ්නයට ලක්වන සෑම අවස්ථාවකම මෙය ජීවිතය පහසු කරන අතර දොස් පැවරිය යුත්තේ කාටද යන්න සැමවිටම පැහැදිලිය.

ක්‍රියාත්මක කිරීමේ උදාහරණ

• REST/HTTP: සේවාවක් GET /items , POST /items වැනි අන්ත ලක්ෂ්‍ය ප්‍රකාශයට පත් කරන අතර, සේවාලාභීන් හොඳින් අර්ථ දක්වා ඇති දත්ත යෝජනා ක්‍රමයක් (DTO) සමඟ ඉල්ලීම් කරයි.

• gRPC / ද්විමය ප්‍රොටෝකෝල: gRPC/protobuf හි, සේවාව සහ පණිවිඩ විධිමත් ලෙස .proto ගොනු තුළ අර්ථ දක්වා ඇති අතර, ක්‍රමය, ඉල්ලීම සහ ප්‍රතිචාරය අර්ථ දක්වා ඇති .proto ගොනු වෙත වෙනස්කම් සරලව සිදු කෙරේ.

• සිදුවීම් මත පදනම් වූ: දත්ත හිමිකාරීත්ව සේවාව Kafka හෝ RabbitMQ වැනි තැරැව්කරුවෙකුට සිදුවීම් ප්‍රකාශයට පත් කරන අතර ග්‍රාහකයින් ඒවා පරිභෝජනය කරයි. මෙහි කොන්ත්‍රාත්තුව සිදුවීම් ආකෘතියයි. ව්‍යුහාත්මක වෙනස්කම් සිදු කරනු ලබන්නේ අනුවාදගත මාතෘකා හෝ පණිවිඩ හරහා ය.

අනුවාද පාලනය

කුමන ආකෘතියක් වුවත්, අතුරුමුහුණත මත අනුවාද පාලනය ක්‍රියාත්මක කිරීම කළ හැකි සහ අත්‍යවශ්‍ය වේ. උදාහරණයක් ලෙස:

• REST හි, අපට /api/v1/… සහ /api/v2/ ඇත.

• gRPC/protobuf සමඟ, පසුගාමී/ඉදිරි ගැළපුම සඳහා ප්‍රබල යාන්ත්‍රණ තිබේ - පැරණි සේවාදායකයින් බිඳ දැමීමකින් තොරව නව ක්ෂේත්‍ර, පණිවිඩ සහ ක්‍රම එකතු කළ හැකි අතර අනෙක් ඒවා අතහැර දැමූ ලෙස සලකුණු කර ඇත.

• සිදුවීම්-ධාවනය කරන ලද ගෘහ නිර්මාණ ශිල්පය තුළ, සියලුම පාරිභෝගිකයින් සංක්‍රමණය වන තෙක් ඔබට පැරණි සහ නව සිදුවීම් ආකෘති සමාන්තරව ප්‍රකාශයට පත් කළ හැකිය.

බෙදා හරින ලද වගකීම

මූලික මූලධර්මයක් නම්, දත්ත හිමි කණ්ඩායමට එය ගබඩා කර කළමනාකරණය කරන්නේ කෙසේද යන්න තීරණය කළ යුතු බවයි, නමුත් ඔවුන් වෙනත් සේවාවන් සඳහා සෘජු ලිවීමේ ප්‍රවේශය ලබා නොදිය යුතුය. විදේශීය දත්ත සංස්කරණය කිරීමට ප්‍රතිවිරුද්ධව අනෙක් අය API හරහා යා යුතුය. මෙය පැහැදිලි වගකීම් බෙදාහැරීමක් ලබා දෙයි: සේවාව A කැඩී ඇත්නම්, එය නිවැරදි කිරීම A සේවාවේ වගකීම වන අතර එහි අසල්වැසියන් නොවේ.

සේවා අන්තර්ක්‍රියා සඳහා උදාහරණ

තනි කණ්ඩායමක් තුළ

මුලින්ම බැලූ බැල්මට, සියල්ල එක කණ්ඩායමක තිබේ නම්, API එකකින් දේවල් සංකීර්ණ කරන්නේ ඇයි? යථාර්ථයේ දී, ඔබට තනි නිෂ්පාදනයක් මොඩියුලවලට බෙදා තිබුණත්, බෙදාගත් වගුවක් එකම ගැටළු වලට තුඩු දිය හැකිය.

• උදාහරණයක් ලෙස, 'ඇණවුම්' වගුව හිමි "මුහුණත" හෝ "ක්ෂුද්‍ර සේවාවක්" නිර්මාණය කිරීම වඩා හොඳය, ඉන්පසු අනෙකුත් මොඩියුල (විශ්ලේෂණ වැනි) මෙම මුහුණත/සේවාව ලෙස හැඳින්වේ.

• මෙය කොන්ත්‍රාත් මූලධර්මය පැහැදිලිව තබා ගන්නා අතර නිදොස්කරණය සරල කරයි.

උදාහරණයක් ලෙස, ඇණවුම් සේවාව ඇණවුම් වගුවේ හිමිකරු වන අතර, බිල්පත් සේවාව එම වගුවට සෘජුවම ප්‍රවේශ නොවේ - එය ඇණවුම් විස්තර ලබා ගැනීමට හෝ ඇණවුමක් ගෙවූ ලෙස සලකුණු කිරීමට ඇණවුම් සේවාවේ අන්ත ලක්ෂ්‍ය වෙත ඇමතුම් ලබා දෙයි.

කණ්ඩායම් දෙකක් අතර

ඉහළ මට්ටමක දී, කණ්ඩායම් දෙකක් හෝ වැඩි ගණනක් විවිධ ක්ෂේත්‍ර සඳහා වගකිව යුතු විට, මූලධර්ම එලෙසම පවතී. උදාහරණයක් ලෙස:

• එක් එක් අයිතමය පිළිබඳ තොරතුරු (මිල, ලබා ගත හැකි බව, ගුණාංග) අඩංගු නිෂ්පාදන නාමාවලි සේවාව සඳහා A කණ්ඩායම වගකිව යුතුය.

• සාප්පු කරත්ත සේවාව B කණ්ඩායම බලා ගනී.

B කණ්ඩායම A කණ්ඩායමට අයත් “නාමාවලි” වගුව සෘජුවම විමසන්නේ නම්, A හි ඕනෑම අභ්‍යන්තර යෝජනා ක්‍රම වෙනස්වීමක් (උදා: ක්ෂේත්‍ර එකතු කිරීම, ව්‍යුහය වෙනස් කිරීම) B කණ්ඩායමට බලපෑ හැකිය.

නිසි ප්‍රවේශය වන්නේ API එකක් භාවිතා කිරීමයි: කණ්ඩායම A GET /catalog/items , GET /catalog/items/{id} , වැනි අන්ත ලක්ෂ්‍ය සපයන අතර B කණ්ඩායම එම ක්‍රම භාවිතා කරයි. A පැරණි සහ නව අනුවාදයන්ට සහාය වීමට සමත් නම්, ඔවුන්ට /v2 නිකුත් කළ හැකි අතර, එමඟින් B හට සංක්‍රමණය වීමට කාලය ලැබේ.

ආයතනික අංශ සහ ප්‍රතිලාභ

විනිවිද පෙනෙන සන්නිවේදනය

විධිමත් ගිවිසුමක් සමඟ, සියලු වෙනස්කම් දෘශ්‍යමාන වේ: Swagger/OpenAPI, .proto ගොනු හෝ සිදුවීම් ලියකියවිලි වල. ඕනෑම යාවත්කාලීන කිරීමක් කලින් සාකච්ඡා කළ හැකිය, නිසි ලෙස පරීක්ෂා කළ හැකිය, සහ අවශ්‍ය පරිදි පසුගාමී අනුකූලතා උපාය මාර්ග සමඟ කාලසටහන්ගත කළ හැකිය.

වේගවත් සංවර්ධනය

එක් සේවාවක වෙනස්කම් අනෙක් අයට අඩු බලපෑමක් ඇති කරයි. නව සහ පැරණි ක්ෂේත්‍ර හෝ අන්ත ලක්ෂ්‍ය නිසි ලෙස කළමනාකරණය කර, සුමට සංක්‍රාන්තියක් සහතික කරන්නේ නම්, කණ්ඩායමට වෙනත් කෙනෙකු "බිඳ දැමීම" ගැන කරදර විය යුතු නැත.

ප්‍රවේශය සහ ආරක්ෂක කළමනාකරණය

API ද්වාර, සත්‍යාපනය සහ අවසරය (JWT, OAuth) සේවා සඳහා සම්මත වේ, නමුත් බෙදාගත් වගුවක් සමඟ එය කළ නොහැකි තරම්ය. ප්‍රවේශය සියුම් ලෙස සකස් කිරීම (කුමන ක්‍රම ඇමතීමට හැකිද), ලොග් තබා ගැනීම, භාවිත සංඛ්‍යාලේඛන නිරීක්ෂණය කිරීම සහ කෝටා පැනවීම පහසුය. මෙය පද්ධතිය ආරක්ෂිත සහ වඩාත් පුරෝකථනය කළ හැකි කරයි.

නිගමනය

දත්ත සමුදායේ බෙදාගත් වගුවක් යනු සේවා අතර ගිවිසුමක් නොව ක්‍රියාත්මක කිරීමේ විස්තරයකි, එබැවින් එය කොන්ත්‍රාත්තුවක් ලෙස නොසැලකේ. බොහෝ ගැටළු (සංකීර්ණ අනුවාදකරණය, අවුල් සහගත වෙනස්කම්, අපැහැදිලි හිමිකාරිත්වය, ආරක්ෂාව සහ කාර්ය සාධන අවදානම්) මෙම ප්‍රවේශය දිගු කාලීනව පිළිගත නොහැකි කරයි.

නිවැරදි ප්‍රවේශය වන්නේ කොන්ත්‍රාත්තුව පළමුව යන්නයි , එහි තේරුම විධිමත් සැලසුමක් හරහා අන්තර්ක්‍රියා නිර්වචනය කිරීම සහ සෑම සේවාවක්ම එහි දත්තවල හිමිකරු ලෙස පවතින බවට මූලධර්මය අනුගමනය කිරීමයි. මෙය තාක්ෂණික ණය අඩු කිරීමට පමණක් නොව විනිවිදභාවය වැඩි කිරීමට, නිෂ්පාදන සංවර්ධනය වේගවත් කිරීමට සහ දත්ත සමුදා යෝජනා ක්‍රම මත ගිනි නිවීමේ කටයුතුවල යෙදීමෙන් තොරව ආරක්ෂිත වෙනස්කම් සක්‍රීය කිරීමට උපකාරී වේ.

එය තාක්ෂණික ගැටළුවක් (සැලසුම් කර ඒකාබද්ධ කරන්නේ කෙසේද) සහ ආයතනික ගැටළුවක් (කණ්ඩායම් වෙනස්කම් සන්නිවේදනය කරන සහ කළමනාකරණය කරන ආකාරය) යන දෙකම වේ. දත්ත සමුදා යෝජනා ක්‍රම සම්බන්ධයෙන් නිමක් නැති හදිසි අවස්ථා වලට මුහුණ නොදී ඔබේ නිෂ්පාදනය වර්ධනය වීමට ඔබට අවශ්‍ය නම්, ඔබ සෘජු දත්ත සමුදා ප්‍රවේශයට වඩා කොන්ත්‍රාත්තු අනුව සිතීම ආරම්භ කළ යුතුය.