![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
እራስህን አትድገም ወይም DRY በሶፍትዌር ልማት ውስጥ ጠቃሚ መርህ ነው። ይህ ልጥፍ ወደ Apache APISIX ውቅር እንዴት እንደሚተገበር ያሳየዎታል።
"ራስህን አትድገም" (DRY) የመረጃ ድግግሞሾችን በመቀነስ ሊለወጡ የሚችሉ መረጃዎችን በመቀነስ፣ የመለወጥ እድላቸው አነስተኛ በሆነ ረቂቅ በመተካት ወይም የውሂብ ኖርማልላይዜሽን በመጠቀም የሶፍትዌር ልማት መርህ ነው። .
ከDRY በስተጀርባ ያለው ዋናው ሃሳብ እራስዎን ከደገሙ እና መረጃው ከተቀየረ, የተለወጠውን መረጃ በበርካታ ቦታዎች ማዘመን አለብዎት. ተጨማሪ ጥረት ብቻ አይደለም; ስለሱ የመርሳት እና በተለያዩ ቦታዎች ላይ የተለያዩ መረጃዎችን የማግኘት እድል አለ. DRY የሳንካ ጥገና ላይ ያበራል።
ስህተት ያለበትን የኮድ ቅንጣቢ አስቡት። እስቲ አስቡት አሁን ቅንጣቢውን በሁለት የተለያዩ ቦታዎች ገልብጠውታል። አሁን በእነዚህ ሁለት ቦታዎች ላይ ስህተቱን ማስተካከል አለብዎት, እና ያ ቀላል ክፍል ነው; ስለ ማባዛቱ በመጀመሪያ ማወቅ በጣም ከባድ ነው።
የሚባዛው ሰው እና የሚያስተካክለው የተለያየ የመሆን እድሉ ከፍተኛ ነው። ቅንጣቢው ሊጋራ የሚችል ተብሎ በአዲስ መልክ ከተሰራ እና በምትኩ ከሁለቱ ቦታዎች ከተጠራ፣በዚህ አንድ ቦታ ላይ ስህተቱን ማስተካከል ብቻ ያስፈልግዎታል።
ብዙ ሰዎች DRYን ከኮድ ጋር ያዛምዳሉ። ሆኖም ግን, ከዋናው ሀሳብ የበለጠ ውስን እና ተቃራኒ ሊሆን ይችላል.
መርሆው በአንዲ ሀንት እና ዴቭ ቶማስ The Pragmatic Programmer በተሰኘ መጽሐፋቸው ተቀርጿል። የውሂብ ጎታ ንድፎችን, የሙከራ እቅዶችን, የግንባታ ስርዓቱን እና ሰነዶችን ጭምር ለማካተት በሰፊው ይተገብራሉ.
የድምፅ ውቅር ስርዓቶች DRYን ይፈቅዳሉ ወይም ያበረታቱታል።
Apache APISIX DRY ውቅር በሁለት ቦታዎች ያቀርባል።
በኢ-ኮሜርስ አውድ ውስጥ፣ በApache APISIX ላይ ያለውን መንገድ ለመወሰን የጀማሪ ጉዞዎ ምናልባት በሚከተለው መልኩ ይጀምራል።
routes: - id: 1 name: Catalog uri: /products* upstream: nodes: "catalog:8080": 1
APISIXን የምታውቁ ከሆነ፣ ወደ ካታሎግ የሚወስደውን መንገድ በ /products
ዩአርአይ ገለፅን። ነገር ግን፣ አንድ ችግር አለ፡ ምናልባት ደንበኞች ሊሆኑ የሚችሉ ካታሎጉን እንዲያስሱ ይፈልጋሉ ነገር ግን ሰዎች ምርቶችን እንዳይፈጥሩ፣ እንዳይሰርዙ ወይም እንዳያዘምኑ መከልከል ይፈልጋሉ። ሆኖም መንገዱ በነባሪነት ከእያንዳንዱ የኤችቲቲፒ ዘዴ ጋር ይዛመዳል።
ሁሉም ሰው በነጻነት ማሰስ እንዲችል ካታሎጉን እንዲያስተዳድሩ የተረጋገጡ ተጠቃሚዎች ብቻ መፍቀድ አለብን። ይህንን አካሄድ ተግባራዊ ለማድረግ መንገዱን ለሁለት መክፈል አለብን፡-
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
key-auth
ለዚህ በጣም ቀላሉ ተሰኪ ነው።
የደህንነት ጉዳዩን በተቻለ መጠን በቀላል መንገድ አስተካክለነዋል፡ በመገልበጥ። ይህን በማድረግ upstream
ክፍል አባዛነው። ቶፖሎጂን መለወጥ ካስፈለገን ለምሳሌ ኖዶችን በመጨመር ወይም በማስወገድ በሁለት ቦታዎች ላይ ማድረግ አለብን. የ DRY መርህን ያሸንፋል.
በገሃዱ ዓለም ሁኔታዎች፣ በተለይም ኮንቴይነሮችን በሚያካትቱበት ጊዜ፣ nodes
በመዘርዘር upstream
አይተገብሩትም። በምትኩ የቶፖሎጂ ለውጦችን ለማስተናገድ ተለዋዋጭ የአገልግሎት ግኝትን መተግበር አለብህ። ሆኖም፣ የአገልግሎት ግኝቱን ውቅረት ወይም አተገባበር መቀየር ሲፈልጉ ነጥቡ አሁንም ይቆማል። ስለዚህ፣ የእኔ ነጥብ በአንጓዎች እና በአገልግሎት ግኝቶች ላይ በእኩልነት ይሠራል።
ከመስመር ማጠቃለያው ጋር፣ APISIX DRYን ለመተግበር ወደ ላይ የሚወጣ ረቂቅ ያቀርባል። ከላይ ያለውን ቅንጭብ እንደሚከተለው ልንጽፈው እንችላለን፡-
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
ወደ ላይ ያለውን ዥረት ይግለጹ
በቶፖሎጂ ውስጥ የሆነ ነገር ከተከሰተ ለውጡን ማዘመን ያለብን በነጠላ Upstream ላይ ብቻ ነው።
የተካተተውን upstream
ዥረት መግለፅ እና በ upstream_id
ማጣቀስ እርስ በርስ የሚጣረሱ መሆናቸውን ልብ ይበሉ።
APISIX የእርስዎን ውቅረት በ Plugin abstraction ለማድረቅ የሚረዳዎት ሌላ ቦታ። APISIX ሁሉንም ባይሆን በፕለጊኖች አማካኝነት አብዛኞቹን ባህሪያት ይተገበራል።
በእኛ ኤፒአይ ላይ በዱካ ላይ የተመሠረተ ሥሪትን እንተግብረው። ዩአርኤሉን ከማስተላለፍዎ በፊት እንደገና መፃፍ አለብን።
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
/v1
ቅድመ ቅጥያውን ያስወግዱ
ልክ upstream
እንደሚታየው፣ plugins
ክፍል የተባዛ ነው። እንዲሁም የተሰኪውን ውቅረት በተወሰነ Plugin Config ነገር ውስጥ መመዘን እንችላለን። የሚከተለው ቅንጣቢ ከላይ ካለው ጋር ተመሳሳይ ውጤት አለው፡
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
አስተዋይ አንባቢዎች የማዋቀሪያው ክፍል እንደጎደለኝ አስተውለው ይሆናል፡ የ 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
በዚህ መንገድ የተጋራውን ውቅረት ወደ 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
. የላይ ዥረቶች ብቸኛ ናቸው; ፕለጊኖች ከልክ በላይ መቃወም ይፈቅዳሉ.
ሁለቱም ዘዴዎች ውቅርዎን ለማድረቅ እና በረጅም ጊዜ ውስጥ የበለጠ እንዲቆይ ለማድረግ ሊረዱዎት ይገባል።
የበለጠ ለመሄድ፡-
በመጀመሪያ በሴፕቴምበር 1፣ 2024 በ A Java Geek ላይ ታትሟል