ඔබගේ Apache APISIX වින්‍යාසය වියළන ආකාරය

Don't Repeat Yourself හෝ DRY යනු මෘදුකාංග සංවර්ධනයේ වැදගත් මූලධර්මයකි. Apache APISIX වින්‍යාසය සඳහා එය යෙදිය යුතු ආකාරය මෙම සටහන ඔබට පෙන්වනු ඇත.

වියළි මූලධර්මය

"ඔබම පුනරුච්චාරණය නොකරන්න" (DRY) යනු වෙනස් වීමට ඉඩ ඇති තොරතුරු පුනරාවර්තනය වීම අඩු කිරීම, වෙනස් වීමට ඇති ඉඩකඩ අඩු වියුක්ත කිරීම් සමඟ එය ප්‍රතිස්ථාපනය කිරීම හෝ අතිරික්තය ප්‍රථමයෙන් වළක්වන දත්ත සාමාන්‍යකරණය භාවිතා කිරීම අරමුණු කරගත් මෘදුකාංග සංවර්ධනයේ මූලධර්මයකි. .

-- විකිපීඩියාව - ඔබම නැවත නොකියන්න

DRY පිටුපස ඇති ප්‍රධාන අදහස නම්, ඔබ නැවත නැවතත් තොරතුරු වෙනස් කරන්නේ නම්, ඔබ වෙනස් කළ තොරතුරු ස්ථාන කිහිපයකින් යාවත්කාලීන කළ යුතුය. එය අමතර වෑයමක් පමණක් නොවේ; ඔබට එය අමතක වී විවිධ ස්ථානවල විවිධ තොරතුරු ලබා ගැනීමට අවස්ථාවක් තිබේ. දෝෂ නිවැරදි කිරීමේදී DRY බැබළෙයි.

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

අනුපිටපත් කරන පුද්ගලයා සහ සවි කරන පුද්ගලයා වෙනස් වීමට ඇති ඉඩකඩ වැඩිය. ස්නිපටය බෙදාගත හැකි ලෙස නැවත සකස් කර ඇති අතර ඒ වෙනුවට ස්ථාන දෙකෙන් කතා කර ඇත්නම්, ඔබට අවශ්‍ය වන්නේ මෙම එක් ස්ථානයක පමණක් දෝෂය නිවැරදි කිරීමයි.

බොහෝ අය DRY කේතය සමඟ සම්බන්ධ කරයි. කෙසේ වෙතත්, එය වඩාත් සීමාකාරී සහ මුල් අදහසට පටහැනි විය හැකිය.

මෙම මූලධර්මය ඇන්ඩි හන්ට් සහ ඩේව් තෝමස් විසින් ඔවුන්ගේ The Pragmatic Programmer පොතෙහි සකස් කර ඇත. දත්ත සමුදා ක්‍රම, පරීක්ෂණ සැලසුම්, ගොඩනැගීමේ පද්ධතිය, ප්‍රලේඛනය පවා ඇතුළත් කිරීමට ඔවුන් එය පුළුල් ලෙස යොදයි.

-- විකිපීඩියාව - ඔබම නැවත නොකියන්න

ශබ්ද වින්‍යාස පද්ධති DRY හෝ එය දිරිමත් කරයි.

Apache APISIX හි වියළන්න

Apache APISIX ස්ථාන දෙකක DRY වින්‍යාසය ලබා දෙයි.

DRY Upstreams

ඊ-වාණිජ්‍ය සන්දර්භයක් තුළ, Apache APISIX හි මාර්ගයක් නිර්වචනය කිරීමට ඔබේ ආරම්භක ගමන බොහෝ විට පහත පරිදි ආරම්භ වේ:

 routes: - id: 1 name: Catalog uri: /products* upstream: nodes: "catalog:8080": 1

ඔබ APISIX ගැන හුරුපුරුදු නම්, අපි /products URI යටතේ නාමාවලියට මාර්ගයක් නිර්වචනය කළෙමු. කෙසේ වෙතත්, ගැටලුවක් තිබේ: ඔබට බොහෝ විට පාරිභෝගිකයන් වීමට අවශ්‍ය වනු ඇත නාමාවලිය බ්‍රවුස් කිරීමට නමුත් නිෂ්පාදන සෑදීමෙන්, මැකීමෙන් හෝ යාවත්කාලීන කිරීමෙන් මිනිසුන් වැළැක්වීමට අවශ්‍ය වේ. එහෙත්, මාර්ගය සෑම HTTP ක්‍රමයක්ම පෙරනිමියෙන් ගැලපේ.

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

 routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] #1 uri: /products* upstream: #2 nodes: "catalog:8080": 1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] #3 uri: /products* plugins: key-auth: ~ #4 upstream: #2 nodes: "catalog:8080": 1

1. ගැලපීම
2. උඩුගං බලා අනුපිටපත්!
3. තරඟ කළමනාකරණය
4. මෙම මාර්ගය භාවිතා කළ හැක්කේ සත්‍යාපිත පාරිභෝගිකයින්ට පමණි; key-auth යනු මේ සඳහා ඇති සරලම ප්ලගිනයයි

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

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

මාර්ග සාරාංශය සමඟින්, APISIX DRY ක්‍රියාත්මක කිරීමට Upstream සාරාංශයක් ඉදිරිපත් කරයි. අපට ඉහත කොටස මෙසේ නැවත ලිවිය හැක.

 upstreams: - id: 1 #1 name: Catalog nodes: "catalog:8080": 1 routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /products* upstream_id: 1 #2 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /products* upstream_id: 1 #2 plugins: key-auth: ~

1. හැඳුනුම්පත 1 සමඟ ඉහළ ධාරාවක් නිර්වචනය කරන්න
2. මාර්ගයේ එය යොමු කරන්න

ස්ථල විද්‍යාවේ යම් දෙයක් සිදු වුවහොත්, අපි වෙනස් කිරීම යාවත්කාලීන කළ යුත්තේ තනි Upstream හි පමණි.

upstream embedded නිර්වචනය කිරීම සහ upstream_id සමඟ එය යොමු කිරීම අන්‍යෝන්‍ය වශයෙන් බැහැර බව සලකන්න.

DRY ප්ලගින වින්‍යාසය

APISIX ඔබට ප්ලගින සාරාංශය සමඟින් ඔබේ වින්‍යාසය වියළීමට උදවු කළ හැකි තවත් ප්‍රදේශයක්. APISIX බොහෝ විශේෂාංග ක්‍රියාත්මක කරයි, සියල්ලම නොවේ නම්, ප්ලගීන හරහා

අපගේ API මත මාර්ගය පදනම් වූ අනුවාදය ක්‍රියාත්මක කරමු. අපි එය යොමු කිරීමට පෙර URL එක නැවත ලිවිය යුතුයි.

 routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] #1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] #1

1. යොමු කිරීමට පෙර /v1 උපසර්ගය ඉවත් කරන්න

ඉහත upstream මෙන්, plugins කොටස අනුපිටපත් කර ඇත. අපට කැප වූ ප්ලගින වින්‍යාස වස්තුවක ප්ලගින වින්‍යාසය ද සාධක කළ හැකිය. පහත ස්නිපටයට ඉහත එක හා සමාන බලපෑමක් ඇත:

 plugin_configs: - id: 1 #1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 #2 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 #2

1. කැප වූ වස්තුවක ප්ලගින වින්‍යාසය සාධක කරන්න
2. එය යොමු කරන්න

මට වින්‍යාසයේ කොටසක් මග හැරී ඇති බව විචක්ෂණශීලී පාඨකයින් දැක ඇති: auth-key අභිරහස් ලෙස අතුරුදහන් විය! ඇත්ත වශයෙන්ම, මම එය ඉවත් කළේ පැහැදිලිකම සඳහා ය.

upstream සහ upstream_id මෙන් නොව, plugins සහ plugin_config_id අන්‍යෝන්‍ය වශයෙන් බැහැර නොවේ . නැතිවූ plugin එකතු කිරීමෙන් අපට ගැටළුව විසඳා ගත හැක:

 routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 plugins: key-auth: ~ #1

1. එය නිවැරදි කරන්න!

මේ ආකාරයෙන්, ඔබට බෙදාගත් වින්‍යාසය plugin_config වස්තුවකට ගෙන යා හැකි අතර එය අදාළ ස්ථානයට නිශ්චිත එකක් තබා ගන්න. නමුත් විවිධ වින්‍යාසයන් සහිත එකම ප්ලගිනය plugin_config හි සහ කෙලින්ම route භාවිතා කරන්නේ නම් කුමක් කළ යුතුද? ලියකියවිලි ඒ ගැන ඉතා පැහැදිලිය:

Consumer > Consumer Group > Route > Plugin Config > Service

කෙටියෙන් කිවහොත්, route ඇති plugin වින්‍යාසය plugin_config_id හි වින්‍යාසය ප්‍රතික්ෂේප කරයි. consumer තුළ ඇති key-auth ප්ලගිනය සඳහා apikey විචල්‍යය ලබා දීමට සහ එය මාර්ගයක පමණක් සැකසීමට එය අපට ඉඩ දෙයි. APISIX විසින් එක් එක් consumer සඳහා යතුර සොයාගෙන භාවිතා කරනු ඇත!

නිගමනය

DRY යනු කේතය පමණක් නොවේ; එය පොදුවේ දත්ත කළමනාකරණය ගැන ය. වින්‍යාසය යනු දත්ත වන අතර එම නිසා මෙම සාමාන්‍ය කුඩය යටතට වැටේ.

APISIX DRY විකල්ප දෙකක් ඉදිරිපත් කරයි: එකක් upstream - upstream_id , සහ එකක් plugin සඳහා - plugin_config_id . උඩුගං තනිකර ඇත; ප්ලගින යටපත් කිරීමට ඉඩ සලසයි.

යාන්ත්‍රණ දෙකම ඔබේ වින්‍යාසය වියලීමට සහ දිගු කාලීනව එය වඩාත් නඩත්තු කළ හැකි බවට පත් කිරීමට උපකාරී වේ.

තවදුරටත් යාමට:

• ඔබම නැවත නොකරන්න මූලධර්මය
• වින්‍යාස ඒකාබද්ධ කිරීමේ ප්‍රමුඛතාවය

2024 සැප්තැම්බර් 1 වන දින A Java Geek හි මුලින් ප්‍රකාශයට පත් කරන ලදී