በይነመረብ ላይ ኩቻ ጽሑፎች о የአገልግሎት መረብ (የአገልግሎት መረብ)፣ እና ሌላ እዚህ አለ። ሆራይ! ግን ለምን? ከዛም እንደ ዶከር እና ኩበርኔትስ ያሉ የመያዣ መድረኮች ከመምጣታቸው በፊት ከ10 አመት በፊት የአገልግሎት መረቦች ቢታዩ ጥሩ ነበር ብዬ ሃሳቤን መግለጽ እፈልጋለሁ። የእኔ አመለካከት ከሌሎች የተሻለ ወይም የከፋ ነው እያልኩ አይደለም፣ ነገር ግን የአገልግሎት መረቦች በጣም ውስብስብ እንስሳት ስለሆኑ፣ በርካታ የአመለካከት ነጥቦች እነርሱን በደንብ ለመረዳት ይረዳሉ።

ከመቶ በማይክሮ አገልግሎት ሰጪዎች ላይ ስለተገነባው እና በሺዎች የሚቆጠሩ በኮንቴይነር የተያዙ አፕሊኬሽኖችን ስለሚደግፈው ስለ dotCloud መድረክ አወራለሁ። እሱን በማዘጋጀት እና በማስጀመር ያጋጠሙንን ተግዳሮቶች እና የአገልግሎት መረቦች እንዴት ሊረዱ እንደሚችሉ (ወይም እንደማይችሉ) እገልጻለሁ።

የdotCloud ታሪክ

ስለ ዶትክላውድ ታሪክ እና ለዚህ መድረክ የአርክቴክቸር ምርጫዎችን ጽፌያለሁ፣ ነገር ግን ስለ አውታረ መረብ ንብርብር ብዙ አልተናገርኩም። ወደ ንባብ ዘልቀው መግባት ካልፈለጉ የመጨረሻው ጽሑፍ ስለ dotCloud፣ ዋናው ቁም ነገር ባጭሩ ይህ ነው፡ ደንበኞች ብዙ አይነት አፕሊኬሽኖችን (ጃቫ፣ ፒኤችፒ፣ ፓይዘን...) እንዲያሄዱ የሚያስችል የPaaS ፕላትፎርም-እንደ አገልግሎት ነው። አገልግሎቶች (MongoDB፣ MySQL፣ Redis...) እና እንደ Heroku ያለ የስራ ሂደት፡ ኮድዎን ወደ መድረክ ይሰቅላሉ፣ የመያዣ ምስሎችን ይገነባል እና ያሰማራቸዋል።

ትራፊክ ወደ dotCloud መድረክ እንዴት እንደሚመራ እነግርዎታለሁ። በተለይ አሪፍ ስለነበር አይደለም (ስርአቱ ለጊዜው ጥሩ ቢሰራም!) ግን በዋነኛነት በዘመናዊ መሳሪያዎች እንዲህ አይነት ንድፍ በቀላሉ በአጭር ጊዜ ውስጥ መጠነኛ በሆነ ቡድን ሊተገበር ስለሚችል በቡድን መካከል ያለውን ትራፊክ መምራት ከፈለጉ የማይክሮ አገልግሎቶች ወይም የመተግበሪያዎች ስብስብ። በዚህ መንገድ አማራጮቹን ማወዳደር ይችላሉ-ሁሉንም ነገር እራስዎ ካዳበሩት ወይም ነባር የአገልግሎት መረብን ከተጠቀሙ ምን ይከሰታል. መደበኛው ምርጫ እራስዎ ማድረግ ወይም መግዛት ነው.

ለተስተናገዱ መተግበሪያዎች የትራፊክ መሄጃ

በdotCloud ላይ ያሉ መተግበሪያዎች HTTP እና TCP የመጨረሻ ነጥቦችን ሊያጋልጡ ይችላሉ።

HTTP የመጨረሻ ነጥቦች በተለዋዋጭ ወደ ጭነት አመጣጣኝ ክላስተር ውቅረት ተጨምሯል። Hipache. ይህ ዛሬ ሀብቶች ከሚያደርጉት ጋር ተመሳሳይ ነው። Ingress በ Kubernetes እና የጭነት ሚዛን እንደ ትራፊክ.

የጎራ ስም ዶትክላውድ ሎድ ሚዛኖችን የሚያመለክት ከሆነ ደንበኞች በተገቢው ጎራዎች ከኤችቲቲፒ የመጨረሻ ነጥቦች ጋር ይገናኛሉ። ምንም ልዩ ነገር የለም።

TCP የመጨረሻ ነጥቦች ከወደብ ቁጥር ጋር ተያይዟል፣ እሱም ወደ ሁሉም ኮንቴይነሮች በአከባቢ ተለዋዋጮች በኩል ይተላለፋል።

ደንበኞች ተገቢውን የአስተናጋጅ ስም (እንደ gateway-X.dotcloud.com ያለ ነገር) እና የወደብ ቁጥርን በመጠቀም ከTCP የመጨረሻ ነጥቦች ጋር መገናኘት ይችላሉ።

ይህ የአስተናጋጅ ስም ወደ “nats” አገልጋይ ዘለላ ይፈታል (ከዚህ ጋር ያልተዛመደ ናቶች), የሚመጡትን የቲሲፒ ግንኙነቶች ወደ ትክክለኛው መያዣ (ወይንም በጭነት-ሚዛናዊ አገልግሎቶችን ወደ ትክክለኛው መያዣዎች) ያመራቸዋል.

ስለ ኩበርኔትስ የምታውቁት ከሆነ ይህ ምናልባት አገልግሎቶችን ያስታውሰዎታል መስቀለኛ መንገድ.

በdotCloud መድረክ ላይ ምንም ተመሳሳይ አገልግሎቶች አልነበሩም ክላስተርአይፒ: ለቀላልነት አገልግሎቶች ከውስጥ እና ከመድረክ ውጭ በተመሳሳይ መንገድ ይደርሱ ነበር።

ሁሉም ነገር በቀላሉ የተደራጀ ነበር፡ የኤችቲቲፒ እና የቲሲፒ ማዘዋወር ኔትወርኮች የመጀመሪያ ትግበራዎች እያንዳንዳቸው ጥቂት መቶ የሚሆኑ የፓይዘን መስመሮች ብቻ ነበሩ። መድረኩ ሲያድግ እና ተጨማሪ መስፈርቶች ሲታዩ የተጣሩ ቀላል (ዋህ እላለሁ) አልጎሪዝም።

የነባር ኮድ ሰፋ ያለ ማደስ አያስፈልግም። በተለየ ሁኔታ, 12 ነጥብ መተግበሪያዎች በአከባቢ ተለዋዋጮች የተገኘውን አድራሻ በቀጥታ መጠቀም ይችላል።

ይህ ከዘመናዊ የአገልግሎት መረብ እንዴት ይለያል?

የተወሰነ ታይነት. ለTCP ማዞሪያ መረብ ምንም አይነት መለኪያ አልነበረንም። ወደ ኤችቲቲፒ ማዘዋወር ስንመጣ፣ የኋለኞቹ ስሪቶች ዝርዝር የኤችቲቲፒ ሜትሪክስ ከስህተት ኮዶች እና የምላሽ ጊዜዎች ጋር አስተዋውቀዋል፣ ነገር ግን የዘመናዊ አገልግሎት ማሻሻያዎች የበለጠ ይሄዳሉ፣ ለምሳሌ እንደ ፕሮሜቲየስ ካሉ የመለኪያ አሰባሰብ ስርዓቶች ጋር ውህደትን ያቀርባል።

ታይነት ከአሰራር አንፃር ብቻ ሳይሆን (ችግሮችን መላ ለመፈለግ ለማገዝ)፣ ነገር ግን አዲስ ባህሪያትን በሚለቁበት ጊዜም አስፈላጊ ነው። ስለ ደህንነት ነው። ሰማያዊ-አረንጓዴ ማሰማራት и የካናሪ ማሰማራት.

የማዞሪያ ቅልጥፍና በተጨማሪም ውስን ነው. በdotCloud ማዞሪያ መረብ ውስጥ፣ ሁሉም ትራፊክ የተወሰኑ የማዞሪያ ኖዶች ዘለላ ውስጥ ማለፍ ነበረባቸው። ይህ ማለት በርካታ የAZ (የተገኝነት ዞን) ድንበሮችን ማቋረጥ እና መዘግየትን በእጅጉ ይጨምራል። በአንድ ገጽ ከመቶ በላይ የSQL መጠይቆችን ሲያደርግ እና ለእያንዳንዱ ጥያቄ ከSQL አገልጋይ ጋር አዲስ ግንኙነት የከፈተ የመላ መፈለጊያ ኮድ አስታውሳለሁ። በአገር ውስጥ ሲሰራ ገጹ ወዲያውኑ ይጫናል፣ ነገር ግን በdotCloud ውስጥ ለመጫን ጥቂት ሰከንዶች ይወስዳል ምክንያቱም እያንዳንዱ የTCP ግንኙነት (እና ቀጣይ የSQL መጠይቅ) በአስር ሚሊሰከንዶች ይወስዳል። በዚህ ጉዳይ ላይ የማያቋርጥ ግንኙነቶች ችግሩን ፈቱ.

ዘመናዊ የአገልግሎት መረቦች እንደነዚህ ያሉትን ችግሮች ለመቋቋም የተሻሉ ናቸው. በመጀመሪያ ደረጃ, ግንኙነቶች መተላለፉን ያረጋግጣሉ ምንጩ ውስጥ. አመክንዮአዊ ፍሰቱ ተመሳሳይ ነው- клиент → меш → сервис, አሁን ግን መረቡ በአካባቢው ይሰራል እና በርቀት ኖዶች ላይ አይደለም, ስለዚህ ግንኙነቱ клиент → меш አካባቢያዊ እና በጣም ፈጣን (በሚሊሰከንዶች ምትክ ማይክሮሰከንዶች) ነው.

ዘመናዊ የአግልግሎት ማሻሻያዎችም የበለጠ ብልህ የጭነት ማመጣጠን ስልተ ቀመሮችን ተግባራዊ ያደርጋሉ። የደጋፊዎችን ጤና በመከታተል ብዙ ትራፊክ ወደ ፈጣን የኋላ ጓሮዎች መላክ ይችላሉ፣ ይህም አጠቃላይ አፈፃፀሙን ያሻሽላል።

ደህንነት ይሻላል። የdotCloud ማዞሪያው መረብ ሙሉ በሙሉ በEC2 Classic ላይ ይሰራል እና ትራፊክን አላመሰጠረም (አንድ ሰው በEC2 አውታረ መረብ ትራፊክ ላይ አነፍናፊ ካስቀመጠ ቀድሞውንም ትልቅ ችግር ውስጥ ነበራችሁ በሚል ግምት)። ዘመናዊ የአገልግሎት መረቦች ሁሉንም ትራፊክዎቻችንን በግልፅ ይከላከላሉ፣ ለምሳሌ፣ በጋራ TLS ማረጋገጫ እና በቀጣይ ምስጠራ።

ለመድረክ አገልግሎቶች ትራፊክ ማዘዋወር

እሺ፣ በመተግበሪያዎች መካከል ስላለው የትራፊክ ፍሰት ተወያይተናል፣ ግን ስለ dotCloud መድረክ ራሱስ?

መድረኩ ራሱ ለተለያዩ ተግባራት ኃላፊነት ያላቸው ወደ መቶ የሚጠጉ ጥቃቅን አገልግሎቶችን ያቀፈ ነበር። አንዳንዶቹ የሌሎችን ጥያቄዎች ተቀብለዋል፣ እና አንዳንዶቹ ከሌሎች አገልግሎቶች ጋር የተገናኙ ነገር ግን ግንኙነቶችን እራሳቸው ያልተቀበሉ የበስተጀርባ ሰራተኞች ነበሩ። ያም ሆነ ይህ, እያንዳንዱ አገልግሎት ለመገናኘት የሚያስፈልጉትን አድራሻዎች የመጨረሻ ነጥቦችን ማወቅ አለበት.

ብዙ ከፍተኛ ደረጃ አገልግሎቶች ከላይ የተገለጸውን የማዞሪያ መረብ ሊጠቀሙ ይችላሉ። በእርግጥ፣ ብዙዎቹ የdotCloud ከመቶ በላይ የማይክሮ ሰርቪስ እንደ መደበኛ መተግበሪያ በdotCloud መድረክ ላይ ተሰማርተዋል። ነገር ግን አነስተኛ ቁጥር ያላቸው ዝቅተኛ ደረጃ አገልግሎቶች (በተለይም ይህንን የመተላለፊያ መረብን የሚተገበሩ) ቀለል ያለ ነገር ያስፈልጋቸው ነበር ፣ ጥቂት ጥገኛዎች (በራሳቸው ላይ ጥገኛ ስላልሆኑ - የድሮው የዶሮ እና የእንቁላል ችግር)።

እነዚህ ዝቅተኛ ደረጃ፣ ተልእኮ-ወሳኝ አገልግሎቶች ኮንቴይነሮችን በማሄድ በጥቂት ቁልፍ ኖዶች ላይ ተዘርግተዋል። በዚህ አጋጣሚ መደበኛ የመድረክ አገልግሎቶች ጥቅም ላይ አልዋሉም: አገናኝ, መርሐግብር እና ሯጭ. ከዘመናዊ የእቃ መያዢያ መድረኮች ጋር ማወዳደር ከፈለጉ፣ የመቆጣጠሪያ አውሮፕላንን እንደመሮጥ ነው። docker run ስራውን ወደ ኩበርኔትስ ከማስተላለፍ ይልቅ በቀጥታ በመስቀለኛ መንገድ ላይ. በፅንሰ-ሀሳብ ውስጥ በጣም ተመሳሳይ ነው። የማይንቀሳቀሱ ሞጁሎች (ፖድስ), የሚጠቀመው kubeadm ወይም bootkube ራሱን የቻለ ዘለላ ሲነሳ።

እነዚህ አገልግሎቶች ቀላል እና ድፍድፍ በሆነ መንገድ ተጋልጠዋል፡ የ YAML ፋይል ስማቸውን እና አድራሻቸውን ዘርዝሯል፤ እና እያንዳንዱ ደንበኛ የዚህን YAML ፋይል ቅጂ ለማሰማራት መውሰድ ነበረበት።

በአንድ በኩል፣ እንደ Zookeeper ያሉ የውጪ ቁልፍ/ዋጋ ማከማቻ ድጋፍ ስለማይፈልግ እጅግ በጣም አስተማማኝ ነው (አስታውስ፣ ወዘተ ወይም ቆንስል በዚያን ጊዜ አልነበረም)። በሌላ በኩል አገልግሎቶችን ለማንቀሳቀስ አስቸጋሪ አድርጎታል. እንቅስቃሴ በተደረገ ቁጥር ሁሉም ደንበኞች የዘመነ YAML ፋይል (እና ዳግም ሊነሳ የሚችል) ይደርሳቸዋል። በጣም ምቹ አይደለም!

በመቀጠል እያንዳንዱ ደንበኛ ከአካባቢያዊ ተኪ አገልጋይ ጋር የተገናኘበትን አዲስ እቅድ መተግበር ጀመርን። ከአድራሻ እና ወደብ ይልቅ የአገልግሎቱን የወደብ ቁጥር ማወቅ እና በ በኩል መገናኘት ብቻ ነው የሚያስፈልገው localhost. የአካባቢው ተኪ ይህንን ግንኙነት ይቆጣጠራል እና ወደ ትክክለኛው አገልጋይ ያስተላልፋል። አሁን፣ ጀርባውን ወደ ሌላ ማሽን ወይም ስኬል ሲያንቀሳቅሱ፣ ሁሉንም ደንበኞች ከማዘመን ይልቅ፣ እነዚህን ሁሉ የአካባቢ ፕሮክሲዎች ማዘመን ብቻ ያስፈልግዎታል። እና ዳግም ማስጀመር አያስፈልግም።

(እንዲሁም በቲኤልኤስ ግንኙነቶች ውስጥ ያለውን ትራፊክ ለማካተት እና በተቀባዩ በኩል ሌላ ተኪ አገልጋይ ለማስቀመጥ ታቅዶ ነበር ፣ እንዲሁም የተቀባዩ አገልግሎት ሳይሳተፍ የTLS የምስክር ወረቀቶችን ማረጋገጥ ፣ ግንኙነቶችን በ ላይ ብቻ ለመቀበል የተዋቀረ ነው ። localhost. በዚህ ላይ ተጨማሪ).

ይህ በጣም ተመሳሳይ ነው SmartStack ከAirbnb፣ ነገር ግን ልዩነቱ SmartStack ተተግብሯል እና ወደ ምርት መሰራጨቱ ነው፣ የዶትክላውድ የውስጥ ማዘዋወር ሥርዓት ግን dotCloud Docker በሚሆንበት ጊዜ ተጠብቆ ነበር።

እኔ በግሌ SmartStackን እንደ ኢስቲዮ፣ ሊንከርድ እና ቆንስል ኮኔክት ካሉ ስርዓቶች ቀዳሚዎች አንዱ እንደሆነ አድርጌ እቆጥረዋለሁ ምክንያቱም ሁሉም ተመሳሳይ ስርዓተ-ጥለት ስለሚከተሉ ነው።

• በእያንዳንዱ መስቀለኛ መንገድ ላይ ፕሮክሲ ያሂዱ።
• ደንበኞች ከፕሮክሲው ጋር ይገናኛሉ።
• የመቆጣጠሪያው አውሮፕላኑ የኋላ ሽፋኖች ሲቀየሩ የተኪ ውቅርን ያዘምናል።
• ... ትርፍ!

የአገልግሎት መረብ ዘመናዊ አተገባበር

ዛሬ ተመሳሳይ ፍርግርግ መተግበር ካስፈለገን ተመሳሳይ መርሆችን ልንጠቀም እንችላለን። ለምሳሌ፣ በቦታ ውስጥ ያሉትን አድራሻዎች የአገልግሎት ስሞችን በማዘጋጀት የውስጥ ዲ ኤን ኤስ ዞንን ያዋቅሩ 127.0.0.0/8. ከዚያ በእያንዳንዱ የአገልግሎት አድራሻ (በዚያ ንዑስ አውታረ መረብ ውስጥ) ግንኙነቶችን በመቀበል በእያንዳንዱ መስቀለኛ መንገድ HAProxy ን በክላስተር ውስጥ ያሂዱ 127.0.0.0/8) እና ሸክሙን ወደ ተገቢው የጀርባ አከባቢዎች ማዞር / ማመጣጠን. የHAProxy ውቅር መቆጣጠር ይቻላል። confdየጀርባ መረጃን በ etcd ወይም Consul ውስጥ እንዲያከማቹ እና አስፈላጊ ሆኖ ሲገኝ የተሻሻለውን ውቅረት ወደ HAProxy እንዲገፋፉ ያስችልዎታል።

ኢስቲዮ እንዴት እንደሚሰራ ይህ በጣም ቆንጆ ነው! ግን ከአንዳንድ ልዩነቶች ጋር:

• ይጠቀማል መልእክተኛ ተኪ ከ HAProxy ይልቅ.
• በetd ወይም በኮንሱል ፈንታ በKubernetes API በኩል የኋላ ውቅረትን ያከማቻል።
• አገልግሎቶች ከ127.0.0.0/8 ይልቅ በውስጥ ሳብኔት (Kubernetes ClusterIP አድራሻዎች) ላይ የተመደቡ ናቸው።
• በደንበኛው እና በአገልጋዮች መካከል የጋራ TLS ማረጋገጫን ለመጨመር ተጨማሪ አካል (Citadel) አለው።
• እንደ ወረዳ መሰባበር፣ የተከፋፈለ ፍለጋ፣ የካናሪ ማሰማራት፣ ወዘተ የመሳሰሉ አዳዲስ ባህሪያትን ይደግፋል።

እስቲ አንዳንድ ልዩነቶችን በፍጥነት እንመልከታቸው።

መልእክተኛ ተኪ

የመልእክተኛው ፕሮክሲ የተፃፈው በሊፍት ነው [የኡበር ተወዳዳሪ በታክሲ ገበያ - በግምት። መስመር]። በብዙ መልኩ ከሌሎች ፕሮክሲዎች (ለምሳሌ HAProxy፣ Nginx፣ Traefik...) ጋር ተመሳሳይ ነው፣ ነገር ግን ሊፍት የነሱን የፃፈው ሌሎች ፕሮክሲዎች የጎደሏቸውን ባህሪያት ስለሚያስፈልጋቸው ነው፣ እና ነባሩን ከማራዘም ይልቅ አዲስ መስራት ብልህ መስሎ ነበር።

መልእክተኛ በራሱ ጥቅም ላይ ሊውል ይችላል. ከሌሎች አገልግሎቶች ጋር መገናኘት የሚያስፈልገው ልዩ አገልግሎት ካለኝ ከኤንኤን ጋር እንዲገናኝ ማዋቀር፣ ከዚያም በተለዋዋጭ አዋቅር እና ከሌሎች አገልግሎቶች ቦታ ጋር እንደገና ማዋቀር እችላለሁ፣ እንደ ታይነት ያሉ ብዙ ተጨማሪ ተግባራትን እያገኘሁ ነው። ከብጁ የደንበኛ ቤተ-መጽሐፍት ወይም የጥሪ ዱካዎችን ወደ ኮዱ ውስጥ ከማስገባት ይልቅ፣ ትራፊክ ወደ መልእክተኛ እንልካለን፣ እና ለእኛ መለኪያዎችን ይሰበስባል።

ነገር ግን መልእክተኛ እንደ መስራት ይችላል የውሂብ አውሮፕላን (የውሂብ አውሮፕላን) ለአገልግሎት መረብ. ይህ ማለት መልእክተኛ አሁን ለዚህ አገልግሎት መረብ ተዋቅሯል ማለት ነው። የመቆጣጠሪያ አውሮፕላን (የመቆጣጠሪያ አውሮፕላን).

የመቆጣጠሪያ አውሮፕላን

ለቁጥጥር አውሮፕላን፣ ኢስቲዮ በኩበርኔትስ ኤፒአይ ላይ ይመሰረታል። ይህ confd ከመጠቀም በጣም የተለየ አይደለምበመረጃ ማከማቻ ውስጥ ያሉትን የቁልፍ ስብስቦች ለማየት በ etcd ወይም Consul ላይ የሚመረኮዝ። ኢስቲዮ የኩበርኔትስ ሀብቶችን ስብስብ ለማየት የኩበርኔትስ ኤፒአይን ይጠቀማል።

በዚህ እና ከዚያ መካከልእኔ በግሌ ይህ ጠቃሚ ሆኖ አግኝቼዋለሁ የኩበርኔትስ ኤፒአይ መግለጫየሚነበበው፡-

የኩበርኔትስ ኤፒአይ አገልጋይ ለኤፒአይ ሃብቶች ማከማቻ፣ እትም፣ ማረጋገጫ፣ ማዘመን እና ፍቺን የሚያቀርብ "ደደብ አገልጋይ" ነው።

ኢስቲዮ ከኩበርኔትስ ጋር ለመስራት የተነደፈ ነው; እና ከ Kubernetes ውጭ ለመጠቀም ከፈለጉ የ Kubernetes API አገልጋይ (እና ወዘተd አጋዥ አገልግሎት) ምሳሌን ማስኬድ ያስፈልግዎታል።

የአገልግሎት አድራሻዎች

ኢስቲዮ ኩበርኔትስ በሚመድባቸው የClusterIP አድራሻዎች ላይ ይተማመናል፣ ስለዚህ የኢስቲዮ አገልግሎቶች የውስጥ አድራሻ ይቀበላሉ (በክልሉ ውስጥ አይደለም) 127.0.0.0/8).

ያለ ኢስቲዮ ያለ የኩበርኔትስ ክላስተር ውስጥ ለተወሰነ አገልግሎት ወደ ክላስተር አይፒ አድራሻ የሚወስድ ትራፊክ በኩቤ-ፕሮክሲ ተጠልፎ ወደዚያ የተኪ ጀርባ ይላካል። ስለ ቴክኒካል ዝርዝሮቹ ፍላጎት ካሎት kube-proxy ወደ ክላስተርአይፒ አድራሻ የሚሄዱትን የመድረሻ አይፒ አድራሻዎችን እንደገና ለመፃፍ የiptables ደንቦችን (ወይም IPVS ሎድ ባላንስተሮች፣እንደተቀናበረው) ያዘጋጃል።

አንዴ ኢስቲዮ በኩበርኔትስ ክላስተር ላይ ከተጫነ ለተወሰነ ሸማች ወይም ሙሉው የስም ቦታ መያዣን በማስተዋወቅ በግልፅ እስኪነቃ ድረስ ምንም ነገር አይቀየርም። sidecar ወደ ብጁ ፖድ. ይህ መያዣ ወደ ሌሎች አገልግሎቶች የሚሄደውን ትራፊክ ለመጥለፍ እና ትራፊክን ወደ መልእክተኛ ለማዞር የመልእክት ምሳሌን ይሽከረከራል እና የ iptables ደንቦችን ያዘጋጃል።

ከ Kubernetes ዲ ኤን ኤስ ጋር ሲዋሃድ ይህ ማለት የእኛ ኮድ በአገልግሎት ስም ሊገናኝ ይችላል እና ሁሉም ነገር “ልክ ይሰራል” ማለት ነው። በሌላ አነጋገር፣ የእኛ ኮድ እንደ መጠይቆችን ያወጣል። http://api/v1/users/4242ከዚያ api ጥያቄን መፍታት 10.97.105.48, የ iptables ደንቦቹ ከ 10.97.105.48 ግንኙነቶችን ያቋርጡ እና ወደ አካባቢያዊ የመልዕክት ተኪ ያስተላልፋሉ እና ያ የአካባቢ ተኪ ጥያቄውን ወደ ትክክለኛው የጀርባ ኤፒአይ ያስተላልፋል። ፊው!

ተጨማሪ ጥብስ

ኢስቲዮ ከጫፍ እስከ ጫፍ ምስጠራን እና ማረጋገጫን በmTLS (የጋራ TLS) ያቀርባል። አንድ አካል ይባላል ግልብጥብጥ.

አንድ አካልም አለ ሚክሴር, የትኛውን መልእክተኛ መጠየቅ ይችላል እያንዳንዳቸው እንደ ራስጌዎች፣ የኋለኛ ክፍል ጭነት፣ ወዘተ ባሉ የተለያዩ ሁኔታዎች ላይ በመመስረት ስለዚያ ጥያቄ ልዩ ውሳኔ እንዲያደርጉ ይጠይቁ… ጥሩ እንደ ተኪ)።

እና፣ በእርግጥ፣ ታይነትን ጠቅሰናል፡ መልዕክተኛው የተከፋፈለ ክትትል በሚያደርግበት ጊዜ ከፍተኛ መጠን ያላቸውን መለኪያዎች ይሰበስባል። በማይክሮ ሰርቪስ አርክቴክቸር ውስጥ፣ አንድ ነጠላ የኤፒአይ ጥያቄ በማይክሮ ሰርቪስ A፣ B፣ C እና D ማለፍ ካለበት፣ ሲገባ፣ የተከፋፈለ ፍለጋ ለጥያቄው ልዩ መለያ ይጨምረዋል እና ይህን መለያ ለእነዚህ ሁሉ ማይክሮ አገልግሎቶች በቀረቡ ጥያቄዎች ያከማቻል፣ ይህም ይፈቅዳል። የሚያዙ ሁሉም ተዛማጅ ጥሪዎች፣ መዘግየቶች፣ ወዘተ.

ይገንቡ ወይም ይግዙ

ኢስቲዮ ውስብስብ በመሆን መልካም ስም አለው። በአንጻሩ፣ በዚህ ጽሑፍ መጀመሪያ ላይ የገለጽኩትን የማዞሪያ መረብ መገንባት አሁን ያሉትን መሣሪያዎች በመጠቀም ቀላል ነው። ስለዚህ፣ በምትኩ የእራስዎን የአገልግሎት መረብ መፍጠር ምክንያታዊ ነው?

መጠነኛ ፍላጎቶች ካሉን (ታይነት ፣ የወረዳ ተላላፊ እና ሌሎች ረቂቅ ነገሮች አንፈልግም) ፣ ከዚያ ሀሳቦች የራሳችንን መሣሪያ ለማዳበር ይመጣሉ። ነገር ግን Kubernetes ን ከተጠቀምን, እንኳን ላያስፈልግ ይችላል ምክንያቱም Kubernetes ቀድሞውኑ ለአገልግሎት ፍለጋ እና ጭነት ማመጣጠን መሰረታዊ መሳሪያዎችን ያቀርባል.

ነገር ግን የላቁ መስፈርቶች ካሉን የአገልግሎት መረብ "መግዛት" በጣም የተሻለ አማራጭ ይመስላል። (ይህ ሁልጊዜ "ግዢ" አይደለም ምክንያቱም ኢስቲዮ ክፍት ምንጭ ነው፣ ነገር ግን እሱን ለመረዳት፣ ለማሰማራት እና ለማስተዳደር አሁንም የኢንጂነሪንግ ጊዜ ማፍሰስ አለብን።)

Istioን፣ Linkerd ወይም Consul Connectን ልመርጥ?

እስካሁን የተነጋገርነው ስለ ኢስቲዮ ብቻ ነው, ግን ይህ ብቸኛው የአገልግሎት መረብ አይደለም. ታዋቂ አማራጭ - ሊንከርድ, እና ተጨማሪ አለ የቆንስል ግንኙነት.

ምን መምረጥ?

እውነቱን ለመናገር እኔ አላውቅም። በአሁኑ ጊዜ ለዚህ ጥያቄ መልስ ለመስጠት ብቁ ነኝ ብዬ አላስብም። ጥቂቶች አሉ። የሚስብ ጽሑፎች ከእነዚህ መሳሪያዎች ጋር በማነፃፀር እና እንዲያውም መለኪያዎች.

አንዱ ተስፋ ሰጪ አካሄድ እንደ መሳሪያ መጠቀም ነው። ሱፐርግሎ. በአገልግሎት መረብ የተጋለጡትን ኤፒአይዎች ለማቃለል እና ለማዋሃድ የአብስትራክሽን ንብርብርን ይተገብራል። ልዩ (እና በእኔ አስተያየት በአንፃራዊነት ውስብስብ) የተለያዩ የአገልግሎት መረቦችን ከመማር ይልቅ የሱፐርግሎልን ቀለል ያሉ ግንባታዎችን መጠቀም እንችላለን - እና በቀላሉ ከአንዱ ወደ ሌላው መቀየር እንችላለን፣ ይህም የኤችቲቲፒ መገናኛዎችን እና የኋላ መከለያዎችን የሚገልፅ መካከለኛ የውቅር ቅርጸት እንዳለን ነው። ለNginx፣ HAProxy፣ Traefik፣ Apache ትክክለኛውን ውቅር የማመንጨት...

ከኢስቲዮ እና ሱፐርግሎሎ ጋር ትንሽ ነካሁ፣ እና በሚቀጥለው መጣጥፍ ላይ ሱፐርግሎልን በመጠቀም ኢስቲዮ ወይም ሊንከርድን እንዴት ወደ ነባሩ ክላስተር እንደሚጨምሩ እና የኋለኛው ደግሞ ስራውን እንዴት እንደሚያከናውን ፣ ማለትም ከ ለመቀየር እንደሚፈቅድ ማሳየት እፈልጋለሁ። ውቅሮችን ሳይተካ አንድ የአገልግሎት መረብ ወደ ሌላ።

ምንጭ: hab.com