Анхаарна уу. орчуулга.: Үйлчилгээний тор нь Орос хэл рүү орчуулга нь хараахан гараагүй байгаа үзэгдэл юм (2 жилийн өмнө бид "үйлчилгээний тор" гэсэн сонголтыг санал болгосон бөгөөд хэсэг хугацааны дараа зарим хамт олон "үйлчилгээний шигшүүр" хослолыг идэвхтэй сурталчилж эхэлсэн). Энэ технологийн талаар байнга ярих нь маркетинг, техникийн бүрэлдэхүүн хэсгүүд нь хоорондоо хэт нягт уялдаатай байдалд хүргэсэн. Анхны нэр томъёоны зохиогчдын нэгээс авсан энэхүү гайхамшигтай материал нь инженерүүд болон бусад хүмүүст ойлгомжтой болгох зорилготой юм.
Хошин шог
Танилцуулга
Хэрэв та програм хангамжийн инженер бол арын системийн орон зайд хаа нэгтээ ажиллаж байгаа бол "үйлчилгээний сүлжээ" гэсэн нэр томьёо сүүлийн хоёр жилийн хугацаанд таны оюун санаанд аль хэдийн бат суусан байх магадлалтай. Хачирхалтай тохиолдлын ачаар энэ хэллэг энэ салбарыг улам бүр эзэмдэж, үүнтэй холбоотой шуугиан, сурталчилгааны саналууд нь цасан бөмбөлөг уруудан нисч байгаа мэт өсөж, удаашрах шинж тэмдэггүй байна.
Үйлчилгээний тор нь үүлний уугуул экосистемийн булингартай, хэвийсэн усанд төрсөн. Харамсалтай нь энэ нь түүнийг тойрсон маргааны ихэнх хэсэг нь "илчлэг багатай яриа" -аас эхлээд техникийн нэр томъёог ашиглах - шууд утгагүй зүйл гэсэн үг юм. Гэхдээ хэрэв та бүх чимээ шуугианыг таслан зогсоовол үйлчилгээний тор нь маш бодитой, тодорхойлогдсон, чухал үүрэгтэй болохыг олж мэдэх болно.
Энэ нийтлэлд би үүнийг хийхийг хичээх болно: үйлчилгээний торонд үнэнч, гүнзгий, инженерт чиглэсэн гарын авлагыг өгөх болно. Би зөвхөн асуултанд хариулахгүй: "Энэ юу вэ?", - Гэхдээ бас "Яагаад?"Тэгээд "Яагаад одоо гэж?". Эцэст нь би энэ технологи яагаад ийм галзуу шуугиан тарьсаныг (миний бодлоор) тайлбарлахыг хичээх болно, энэ нь өөрөө сонирхолтой түүх юм.
Би хэн бэ
Сайн уу! Миний нэр . Би бүтээгчдийн нэг - хамгийн анхны үйлчилгээний торон төсөл болон нэр томъёоны харагдах буруутай төсөл үйлчилгээний тор ийм байна (уучлаарай залуусаа!). (Тайлбар орчуул.: Дашрамд хэлэхэд, энэ нэр томъёо гарч ирэхэд 2,5 жилийн өмнө бид нэгэн зохиолчийн "Гарчигтай анхны материалыг орчуулсан.".) Би бас толгойлдог нь Linkerd, гэх мэт гайхалтай үйлчилгээний сүлжээг бий болгодог стартап юм .
Энэ асуудалд би маш өрөөсгөл, субъектив үзэл бодолтой байгааг та бүхэн таамаглаж байгаа байх. Гэсэн хэдий ч, би хамгийн бага (нэг хэсгийг эс тооцвол: "Үйлчилгээний сүлжээний талаар яагаад ийм их ярьдаг вэ?", - үүн дээр би урьдаас бодож байсан санаагаа хуваалцах болно). Би энэ гарын авлагыг аль болох бодитой болгохын тулд чадах бүхнээ хийх болно. Тодорхой жишээнүүдийн хувьд би бусад үйлчилгээний торны төрлийг хэрэгжүүлэхэд миний мэддэг ялгааг (хэрэв байгаа бол) зааж өгөхийн зэрэгцээ Линкердийн туршлагад тулгуурлана.
За, сайхан зүйлс рүү шилжих цаг боллоо.
Үйлчилгээний тор гэж юу вэ?
Бүх шуугиан тарьсан ч үйлчилгээний торны бүтэц нь маш энгийн. Энэ бол үйлчилгээнүүдийн "хажууд" байрлах хэрэглэгчийн талбарын прокси (цаашид "дараагийн" гэж юу болох талаар бага зэрэг ярих болно), мөн хяналтын процессуудын багц юм. Төлөөлөгчдийг хамтад нь дууддаг өгөгдлийн хавтгай, хяналтын процессууд гэж нэрлэдэг хяналтын онгоц. Өгөгдлийн онгоц нь үйлчилгээнүүдийн хоорондох дуудлагыг таслан зогсоож, тэдэнтэй "бүх төрлийн өөр зүйл" хийдэг; Үүний дагуу хяналтын хавтгай нь проксины үйл ажиллагааг зохицуулж, танд нэвтрэх боломжийг олгодог, жишээлбэл. оператор, API руу шилжүүлснээр сүлжээг бүхэлд нь удирдах, хэмжих боломжийг олгодог.
Энэ ямар прокси вэ? Энэ бол Layer 7-г мэддэг TCP прокси юм (өөрөөр хэлбэл OSI загварын 7-р давхаргыг "харгалзаж") HAProxy болон NGINX гэх мэт. Та өөрийн үзэмжээр прокси сонгож болно; Linkerd нь зүгээр л нэрлэсэн Rust прокси ашигладаг . Бид үүнийг үйлчилгээний торонд зориулж тусгайлан нийлүүлдэг. Бусад тор нь бусад проксиг илүүд үздэг (Элчлэгч нь нийтлэг сонголт юм). Гэхдээ прокси сонгох нь зөвхөн хэрэгжүүлэх асуудал юм.
Эдгээр прокси серверүүд юу хийдэг вэ? Мэдээжийн хэрэг, тэд үйлчилгээ рүү болон үйлчилгээ рүү залгах дуудлагыг проксигоор хийдэг (хатуухан хэлэхэд тэд прокси болон урвуу прокси болж, ирж буй болон гарч буй дуудлагыг хариуцдаг). Мөн тэд дуудлагад анхаарлаа төвлөрүүлдэг функцүүдийн багцыг хэрэгжүүлдэг хооронд нь үйлчилгээ. Үйлчилгээ хоорондын траффик дээр ийм анхаарал хандуулж байгаа нь үйлчилгээний сүлжээний прокси-г жишээ нь API гарц эсвэл нэвтрэх прокси (сүүлийнх нь гаднах ертөнцөөс кластерт ирж буй дуудлага)-аас ялгадаг зүйл юм. (Анхаарна уу. орчуулга.: Ихэнх нь аль хэдийн дурдсан элчийг ашигладаг Kubernetes-д зориулсан одоо байгаа Ingress хянагчдыг харьцуулахыг үзнэ үү. .)
Тиймээс бид өгөгдлийн онгоцыг ангилсан. Хяналтын хавтгай нь илүү энгийн: энэ нь үйлчилгээний нээлт, TLS гэрчилгээ олгох, хэмжигдэхүүнийг нэгтгэх гэх мэт өгөгдлийн хавтгайд уялдаа холбоотой ажиллахад шаардлагатай бүх механикыг хангадаг бүрэлдэхүүн хэсгүүдийн багц юм. Өгөгдлийн хавтгай нь түүний зан байдал; эргээд хяналтын хавтгай нь өгөгдлийн хавтгайн үйл ажиллагааг бүхэлд нь өөрчлөх, хянах боломжийг олгодог API-г өгдөг.
Linkerd дахь удирдлагын болон өгөгдлийн хавтгайн диаграммыг доор харуулав. Таны харж байгаагаар хяналтын хавтгай нь хэд хэдэн өөр бүрэлдэхүүн хэсгүүдийг агуулдаг бөгөөд үүнд прокси серверүүдээс хэмжигдэхүүнүүдийг цуглуулдаг Prometheus жишээ, түүнчлэн бусад бүрэлдэхүүн хэсгүүд орно. destination (үйлчилгээний нээлт), identity (гэрчилгээний эрх бүхий байгууллага, CA) болон public-api (вэб болон CLI-д зориулсан төгсгөлийн цэгүүд). Үүний эсрэгээр, өгөгдлийн хавтгай нь програмын жишээний дэргэдэх энгийн linkerd-proxy юм. Энэ бол зүгээр л логик диаграмм; Бодит орчинд байршуулах үед та удирдлагын хавтгай бүрэлдэхүүн хэсэг бүрийн гурван хуулбар, өгөгдлийн хавтгайд хэдэн зуу, мянган прокситэй байж болно.
(Энэ диаграм дээрх цэнхэр тэгш өнцөгтүүд нь Kubernetes pods-ийн хил хязгаарыг бэлэгддэг. Та linkerd-proxy-тэй контейнерууд нь хэрэглээний контейнертэй нэг подволд байгааг харж болно. Энэ схемийг дараах нэрээр нэрлэдэг. хажуугийн сав.)
Үйлчилгээний торон архитектур нь хэд хэдэн чухал ач холбогдолтой. Нэгдүгээрт, прокси-ийн үүрэг бол үйлчилгээнүүдийн хоорондох дуудлагыг таслан зогсоох явдал тул таны програмыг тодорхой багц үйлчилгээнд зориулж бүтээсэн тохиолдолд үйлчилгээний сүлжээ нь утга учиртай болно. Торон болно monoliths-тай ашиглах, гэхдээ энэ нь нэг проксигийн хувьд илүүдэхгүй бөгөөд түүний ажиллагаа нь эрэлт хэрэгцээтэй байх магадлал багатай юм.
Өөр нэг чухал үр дагавар бол үйлчилгээний торыг шаарддаг асар том проксигийн тоо. Үнэн хэрэгтээ, Linkerd нь үйлчилгээ бүрийн тохиолдол бүрт linkerd-proxy-г хавсаргадаг (бусад хэрэгжүүлэлтүүд нь зангилаа/хост/виртуал машин бүрт прокси нэмдэг. Энэ нь ямар ч байсан маш их зүйл юм). Ийм проксиг идэвхтэй ашиглах нь өөрөө хэд хэдэн нэмэлт хүндрэл үүсгэдэг.
- Өгөгдлийн хавтгай дахь прокси байх ёстой хурдан, учир нь дуудлага бүрийн хувьд прокси руу хэд хэдэн дуудлага ирдэг: нэг нь үйлчлүүлэгч талд, нөгөө нь сервер талд.
- Мөн прокси байх ёстой жижиг и хөнгөн жинтэй. Тус бүр санах ой болон CPU-ийн нөөцийг ашиглах бөгөөд энэ хэрэглээ нь программыг дагаж шугаман өсөх болно.
- Танд олон тооны прокси байршуулах, шинэчлэх механизм хэрэгтэй болно. Үүнийг гараар хийх нь сонголт биш юм.
Ерөнхийдөө үйлчилгээний тор нь иймэрхүү харагддаг (ядаж л шувууны нүдээр): та дотоод, үйлчилгээ хоорондын урсгалаар "ямар нэгэн зүйл хийдэг" олон тооны хэрэглэгчийн талбарт прокси байршуулж, тэдгээрийг хянах, удирдахын тулд хяналтын онгоц ашигладаг.
Одоо "Яагаад?" Гэсэн асуултыг асуух цаг болжээ.
Үйлчилгээний тор нь юунд зориулагдсан вэ?
Үйлчилгээний торны санааг анх олж мэдсэн хүмүүс бага зэрэг айдас төрүүлснээ уучилж болно. Үйлчилгээний торны загвар нь програмын хоцролтыг нэмэгдүүлээд зогсохгүй бас болно гэсэн үг юм хэрэглэх нөөц ба нэмэх болно дэд бүтцийн олон шинэ механизмууд. Эхлээд та үйлчилгээний сүлжээг тохируулж, дараа нь гэнэт хэдэн зуун (хэрэв мянга биш бол) проксид үйлчлэх шаардлагатай болдог. Хэн сайн дураараа үүнийг хийх вэ гэдэг асуулт гарч ирнэ.
Энэ асуултын хариулт нь хоёр хэсэгтэй. Нэгдүгээрт, эдгээр проксиг ашиглахтай холбоотой гүйлгээний зардлыг экосистемд гарч буй зарим өөрчлөлтийн ачаар мэдэгдэхүйц бууруулж болно (энэ талаар дараа нь).
Хоёрдугаарт, ийм төхөөрөмж нь системд нэмэлт логикийг нэвтрүүлэх гайхалтай арга юм. Үйлчилгээний тор нь маш олон шинэ функцийг нэмж өгдөг төдийгүй экосистемд саад учруулахгүйгээр хийх боломжтой байдаг. Үнэн хэрэгтээ үйлчилгээний бүхэл бүтэн загвар нь энэ үндэслэл дээр суурилдаг: олон үйлчилгээний системд, юу ч байсан хийж байна хувь хүний үйлчилгээ, замын хөдөлгөөн тэдний хооронд функцийг нэмэх хамгийн тохиромжтой цэг юм.
Жишээлбэл, Linkerd-д (ихэнх торонд байдаг шиг) функц нь ихэвчлэн HTTP/2 болон gRPC* зэрэг HTTP дуудлагад төвлөрдөг. Функциональ байдал нь нэлээд баялаг бөгөөд үүнийг гурван ангилалд хувааж болно.
- -тай холбоотой шинж чанарууд найдвартай байдал. Дахин давтагдах хүсэлт, завсарлага, канарын хандлага (трафикийг хуваах/дахин чиглүүлэх) гэх мэт.
- -тай холбоотой шинж чанарууд хяналт тавих. Үйлчилгээ эсвэл тусдаа чиглэл бүрийн амжилтын хувь хэмжээ, саатал, хүсэлтийн хэмжээг нэгтгэх; үйлчилгээний топологийн зураг зурах гэх мэт.
- -тай холбоотой шинж чанарууд аюулгүй байдал. Харилцан TLS, хандалтын хяналт гэх мэт.
* Linkerd-ийн үүднээс авч үзвэл gRPC нь HTTP/2-оос бараг ялгаагүй: энэ нь зүгээр л ачаалалд protobuf ашигладаг. Хөгжүүлэгчийн үүднээс авч үзвэл хоёр зүйл мэдээж өөр.
Эдгээр механизмуудын ихэнх нь хүсэлтийн түвшинд ажилладаг (иймээс "L7 прокси"). Жишээлбэл, Foo үйлчилгээ нь Bar үйлчилгээ рүү HTTP дуудлага хийвэл Foo талд байгаа linkerd-proxy нь ачааллын ухаалаг тэнцвэржүүлэлт хийж, ажиглагдсан хоцрогдол дээр үндэслэн Foo-с Bar instance-ээс дуудлагыг чиглүүлэх боломжтой; шаардлагатай бол хүсэлтийг давтаж болно (хэрэв энэ нь сул дорой бол); Энэ нь хариултын код, хугацаа дуусах гэх мэтийг бичиж болно. Үүний нэгэн адил, Бар талын linkerd-proxy нь хүсэлтийг зөвшөөрөхгүй эсвэл хүсэлтийн хязгаараас хэтэрсэн тохиолдолд татгалзаж болно; өөрийн талын саатал зэргийг бүртгэж болно.
Прокси нь холболтын түвшинд "ямар нэгэн зүйл хийх" боломжтой. Жишээлбэл, Foo талын linkerd-proxy нь TLS холболтыг эхлүүлж, Bar талын linkerd-proxy нь үүнийг цуцалж, хоёр тал бие биенийхээ TLS гэрчилгээг баталгаажуулах боломжтой*. Энэ нь зөвхөн үйлчилгээнүүдийн хооронд шифрлэлт төдийгүй үйлчилгээг таних криптографийн аюулгүй арга юм: Foo and Bar нь өөрсдийгөө хэн болохыг "баталж" чадна.
* "Найзын харилцан" гэдэг нь үйлчлүүлэгчийн гэрчилгээг мөн баталгаажуулсан гэсэн үг юм (харилцан TLS). "Сонгодог" TLS-д, жишээлбэл, хөтөч болон серверийн хооронд зөвхөн нэг талын (сервер) гэрчилгээг ихэвчлэн баталгаажуулдаг.
Тэд хүсэлт эсвэл холболтын түвшинд ажиллаж байгаа эсэхээс үл хамааран бүх үйлчилгээний сүлжээний функцууд байдаг гэдгийг онцлон тэмдэглэх нь зүйтэй. ажиллагаатай зан чанар. Linkerd нь ачааллын семантикийг өөрчлөх боломжгүй - жишээлбэл, JSON фрагмент дээр талбар нэмэх эсвэл protobuf-д өөрчлөлт оруулах. Бид дараа нь ESB болон дунд програмын талаар ярихдаа энэ чухал функцийн талаар ярих болно.
Энэ бол үйлчилгээний сүлжээний санал болгож буй функцүүдийн багц юм. Асуулт гарч ирдэг: яагаад тэдгээрийг шууд програмд хэрэглэж болохгүй гэж? Тэгээд ерөөсөө прокси хүнтэй яагаад санаа зовоод байгаа юм бэ?
Яагаад үйлчилгээний тор нь сайн санаа юм
Үйлчилгээний торны боломжууд нь сэтгэл хөдөлгөм боловч гол үнэ цэнэ нь түүний онцлог шинж чанарт оршдоггүй. Эцэст нь бид Болно тэдгээрийг програмд шууд хэрэгжүүлэх (энэ нь үйлчилгээний торны гарал үүсэл гэдгийг бид дараа нь харах болно). Үүнийг нэг өгүүлбэрээр дүгнэж үзэхэд үйлчилгээний сүлжээний үнэ цэнэ нь: Энэ нь орчин үеийн серверийн программ хангамжийг бүхэлд нь стек дээр тогтвортой ажиллуулахад чухал ач холбогдолтой, програмын кодоос хамааралгүйгээр хангадаг.
Энэ саналд дүн шинжилгээ хийцгээе.
«Орчин үеийн серверийн програм хангамжийг ажиллуулахад чухал ач холбогдолтой онцлогууд" Хэрэв та олон нийтийн интернетэд холбогдсон гүйлгээний серверийн програм үүсгэж байгаа бол гадаад ертөнцөөс ирсэн хүсэлтийг хүлээн авч, богино хугацаанд хариу өгөх боломжтой - жишээлбэл вэб програм, API сервер болон бусад орчин үеийн програмуудын дийлэнх нь. - хэрэв та үүнийг бие биентэйгээ синхроноор харилцдаг үйлчилгээний багц болгон хэрэгжүүлбэл, хэрэв та энэ програм хангамжийг байнга сайжруулж, шинэ боломжуудыг нэмж, өөрчлөх явцад энэ системийг хэвийн горимд байлгахаас өөр аргагүйд хүрвэл - үүнд тохиолдол, баяр хүргэе, та орчин үеийн серверийн програм хангамжийг бүтээж байна. Дээр дурдсан бүх гайхалтай шинж чанарууд нь таны хувьд маш чухал юм. Аппликешн нь найдвартай, аюулгүй байх ёстой бөгөөд та юу хийж байгааг нь ажиглах чадвартай байх ёстой. Эдгээр нь яг л үйлчилгээний тор нь шийдвэрлэхэд тусалдаг асуултууд юм.
(За, өмнөх догол мөрөнд энэ арга нь серверийн программ хангамжийг бий болгох орчин үеийн арга юм гэсэн миний итгэлийг оруулсан хэвээр байна. Бусад нь monoliths, "reactive microservices" болон дээрх тодорхойлолтод хамаарахгүй бусад зүйлсийг хөгжүүлэхийг илүүд үздэг. Эдгээр хүмүүс магадгүй өөрсдийн Миний бодол минийхээс өөр.Харин би тэднийг "буруу" гэж бодож байна - гэхдээ ямар ч тохиолдолд үйлчилгээний тор нь тэдэнд тийм ч ашигтай биш юм).
«Стекийг бүхэлд нь жигдрүүлнэ" Үйлчилгээний сүлжээгээр хангагдсан функцууд нь зөвхөн чухал үүрэг гүйцэтгэдэггүй. Тэдгээр нь ямар хэл дээр бичигдсэн, ямар хүрээ ашигладаг, хэн бичсэн, хэрхэн байршуулсан, хөгжүүлэлт, хэрэглээний бусад нарийн ширийн зүйлээс үл хамааран програмын бүх үйлчилгээнд хамаарна.
«Хэрэглээний кодоос хамааралгүй" Эцэст нь, үйлчилгээний тор нь бүх стек дээр тогтвортой ажиллагааг хангаад зогсохгүй, програмыг засварлах шаардлагагүй байдлаар хийдэг. Тохиргоо, шинэчлэх, ажиллуулах, засвар үйлчилгээ гэх мэт ажлуудыг багтаасан үйлчилгээний торон функцын үндсэн суурь нь бүхэлдээ платформын түвшинд байдаг бөгөөд програмаас хамааралгүй байдаг. Аппликейшн нь үйлчилгээний сүлжээнд нөлөөлөхгүйгээр өөрчлөгдөж болно. Хариуд нь үйлчилгээний тор нь програмын оролцоогүйгээр өөрчлөгдөж болно.
Товчхондоо, үйлчилгээний тор нь зөвхөн амин чухал үйл ажиллагааг хангаад зогсохгүй үүнийг дэлхий даяар, жигд, хэрэглээнээс хамааралгүй байдлаар гүйцэтгэдэг. Тиймээс үйлчилгээний торны функцийг үйлчилгээний кодонд (жишээлбэл, үйлчилгээ тус бүрд багтсан номын сан) хэрэгжүүлэх боломжтой боловч энэ арга нь үйлчилгээний торны хувьд тийм ч үнэ цэнэтэй нэгдмэл байдал, бие даасан байдлыг хангахгүй.
Та хийх ёстой зүйл бол олон тооны прокси нэмэх явдал юм! Бид удахгүй эдгээр проксиг нэмэхтэй холбоотой үйл ажиллагааны зардлыг харна гэж би амлаж байна. Гэхдээ эхлээд энэ тусгаар тогтнолын санааг янз бүрийн өнцгөөс харцгаая. хүн.
Үйлчилгээний тор нь хэнд тусалдаг вэ?
Технологийг экосистемийн чухал хэсэг болгохын тулд энэ нь эвгүй байсан ч хүмүүс үүнийг хүлээн зөвшөөрөх ёстой. Тэгвэл үйлчилгээний торыг хэн сонирхож байна вэ? Үүнийг ашиглах нь хэнд ашигтай вэ?
Хэрэв та орчин үеийн серверийн программ хангамжийг хөгжүүлж байгаа бол та өөрийн багийг нэг бүлэг гэж төсөөлж болно үйлчилгээний эзэдбизнесийн логикийг хамтдаа боловсруулж хэрэгжүүлдэг, мөн платформ эзэмшигчид, эдгээр үйлчилгээнүүд дээр ажилладаг дотоод платформыг хөгжүүлэх. Жижиг байгууллагуудад эдгээр нь ижил хүмүүс байж болох ч компани томрох тусам эдгээр үүрэг нь илүү тодрох, бүр дэд дүрүүдэд хуваагдах хандлагатай байдаг... (Дэвопуудын өөрчлөгдөж буй мөн чанарын талаар энд ярих зүйл их байна, бичил үйлчилгээний байгууллагын нөлөөлөл гэх мэт) n.Харин одоогоор эдгээр тайлбарыг өгөгдсөн байдлаар авч үзье).
Энэ үүднээс авч үзвэл үйлчилгээний сүлжээний тодорхой ашиг хүртэгчид нь платформ эзэмшигчид юм. Эцсийн эцэст, платформын багийн зорилго бол үйлчилгээний эзэд бизнесийн логикийг хэрэгжүүлэх дотоод платформыг бий болгож, үйл ажиллагааныхаа бүдэг бадаг нарийн ширийн зүйлсээс аль болох хараат бус байх нөхцлийг бүрдүүлэх явдал юм. Үйлчилгээний сүлжээ нь энэ зорилгод хүрэхэд чухал ач холбогдолтой чадавхийг санал болгодог төдийгүй, үйлчилгээ эзэмшигчдээс хараат байдлыг бий болгодоггүй.
Үйлчилгээний эзэд ч гэсэн илүү шууд бус байдлаар ашиг хүртдэг. Үйлчилгээний эзэмшигчийн зорилго бол бизнесийн үйл явцын логикийг хэрэгжүүлэхэд аль болох үр бүтээлтэй байх явдал бөгөөд үйл ажиллагааны асуудалд санаа зовох зүйл бага байх тусам сайн. Бодлого, TLS-ийг хэрэгжүүлэхийн оронд тэд зөвхөн бизнесийн зорилгод анхаарлаа төвлөрүүлж, платформ бусад асуудлыг шийднэ гэж найдаж байна. Энэ нь тэдний хувьд том давуу тал юм.
Платформ, үйлчилгээний эздийн хооронд ийм хуваагдлын зохион байгуулалтын үнэ цэнийг хэт үнэлж болохгүй. Тэр хувь нэмэр оруулдаг гэж бодож байна гол үйлчилгээний сүлжээний үнэ цэнэд оруулсан хувь нэмэр.
Линкердийн эртний шүтэн бишрэгчид яагаад үйлчилгээний торыг сонгосон тухайгаа ярихад бид энэ сургамжийг олж авсан: энэ нь тэдэнд "ярих дэлгүүрийг хамгийн бага байлгах" боломжийг олгосон юм. Энд зарим нэг мэдээлэл байна: нэг том компанийн залуус платформоо Кубернетес рүү шилжүүлсэн. Аппликейшн нь эмзэг мэдээллийг зохицуулдаг тул кластерууд дахь бүх харилцаа холбоог шифрлэхийг хүссэн. Гэсэн хэдий ч олон зуун үйлчилгээ, олон зуун хөгжүүлэлтийн багууд байдгаараа нөхцөл байдал хүндэрсэн. Хүн бүртэй холбоо барьж, TLS-ийн дэмжлэгийг төлөвлөгөөндөө оруулахыг ятгах нь тэднийг огт баярлуулсангүй. Linkerd суулгасны дараа тэд шилжүүлсэн өр төлбөр хөгжүүлэгчдээс (энэ нь шаардлагагүй асуудал байсан үүднээс) платформ тоглогчид хүртэл, тэдний хувьд энэ нь дээд түвшний тэргүүлэх чиглэл байв. Өөрөөр хэлбэл, Линкерд тэдний хувьд техникийн асуудал гэхээсээ илүү зохион байгуулалтын асуудлыг шийдсэн.
Товчхондоо, үйлчилгээний тор нь техникийн биш, харин илүү шийдэл юм нийгэм-техникийн Асуудлууд. (Баярлалаа Энэ нэр томъёог танилцуулсны төлөө.)
Үйлчилгээний сүлжээ миний бүх асуудлыг шийдэх үү?
Тиймээ. Үгүй ээ!
Хэрэв та дээр дурдсан найдвартай байдал, аюулгүй байдал, ажиглалт зэрэг шинж чанаруудын гурван ангиллыг харвал үйлчилгээний тор нь эдгээр асуудлын аль нэгийг нь бүрэн шийдэж чадахгүй нь тодорхой болно. Linkerd хүсэлтийг дахин гаргах боломжтой хэдий ч (хэрэв тэдгээр нь үл мэдэгдэх чадвартай гэдгийг мэдвэл) үйлчилгээ нь бүрмөсөн бүтэлгүйтсэн тохиолдолд хэрэглэгч рүү юу буцаах талаар шийдвэр гаргах боломжгүй байдаг - эдгээр шийдвэрийг программ гаргах ёстой. Linkerd нь амжилттай хүсэлтийн статистикийг хөтөлж болох боловч энэ үйлчилгээг судалж, дотоод хэмжүүрээ өгөх боломжгүй байдаг - програм нь ийм хэрэгсэлтэй байх ёстой. Хэдийгээр Linkerd нь mTLS зохион байгуулах чадвартай ч аюулгүй байдлын бүрэн шийдэл нь илүү их зүйлийг шаарддаг.
Үйлчилгээний сүлжээнээс санал болгож буй эдгээр хэсгүүдийн онцлог шинж чанаруудын нэг хэсэг нь холбоотой платформын онцлог. Үүгээр би дараах функцуудыг хэлж байна:
- Бизнесийн логикоос хамааралгүй. Foo болон Bar хоёрын хоорондох дуудлагын гистограммыг бүтээх арга нь үүнээс бүрэн хамааралгүй юм яагаад Фү Бар руу залгана.
- Зөв хэрэгжүүлэхэд хэцүү. Linkerd-д дахин оролдлого нь дахин оролдлого хийх төсөв гэх мэт бүх төрлийн гоёмсог зүйлсээр тохируулагдсан байдаг (төсвөө дахин оролдох), ийм зүйлийг хэрэгжүүлэхэд боловсронгуй бус, шууд хандах нь "хүсэлтийн нуранги" гэж нэрлэгддэг зүйл үүсэхэд хүргэх нь дамжиггүй. (шуурга дахин оролдох) болон тархсан системд хамаарах бусад асуудлууд.
- Нэг жигд түрхэхэд хамгийн үр дүнтэй. TLS механизмыг хаа сайгүй хэрэглэж байгаа тохиолдолд л утга учиртай.
Эдгээр функцууд нь прокси түвшинд (програмын түвшинд биш) хэрэгждэг тул үйлчилгээний тор нь тэдгээрийг хаягаар хангадаг платформ, програмууд биш. Тиймээс, үйлчилгээнүүд нь ямар хэл дээр бичигдсэн, ямар хүрээ ашигладаг, хэн, яагаад бичсэн нь хамаагүй. Прокси нь эдгээр бүх нарийн ширийн зүйлсээс гадуур ажилладаг бөгөөд тохиргоо хийх, шинэчлэх, ажиллуулах, засвар үйлчилгээ хийх гэх мэт үйл ажиллагааны үндсэн суурь нь зөвхөн платформын түвшинд байдаг.
Үйлчилгээний торны боломжуудын жишээ
Дүгнэж хэлэхэд, үйлчилгээний тор нь найдвартай байдал, ажиглалт, аюулгүй байдлын бүрэн шийдэл биш юм. Эдгээр талбайн хамрах хүрээ нь үйлчилгээний эзэд, Ops/SRE багууд болон бусад компанийн байгууллагуудын оролцоог шаарддаг. Үйлчилгээний тор нь зөвхөн эдгээр талбар бүрт платформ түвшний "зүсмэл" өгдөг.
Үйлчилгээний сүлжээ яагаад одоо алдартай болсон бэ?
Одоо та гайхаж байгаа байх: за, хэрэв үйлчилгээний сүлжээ маш сайн бол бид яагаад арван жилийн өмнө олон сая проксиг стект байрлуулж эхлээгүй юм бэ?
Энэ асуултад улиг болсон хариулт байна: XNUMX жилийн өмнө хүн бүр цул барьдаг байсан бөгөөд хэнд ч үйлчилгээний тор хэрэггүй байсан. Энэ үнэн, гэхдээ миний бодлоор энэ хариулт нь гол санааг алдсан байна. Арваад жилийн өмнө ч гэсэн том хэмжээний системийг бий болгох ирээдүйтэй арга болох микро үйлчилгээний тухай ойлголтыг Twitter, Facebook, Google, Netflix зэрэг компаниуд өргөнөөр хэлэлцэж, хэрэглэж байсан. Наад зах нь миний харилцаж байсан салбарын ерөнхий үзэл баримтлал бол микро үйлчилгээ нь том системийг бий болгох "зөв арга" юм, тэр ч байтугай хэцүү байсан ч гэсэн.
Мэдээжийн хэрэг, арваад жилийн өмнө бичил үйлчилгээ эрхэлдэг компаниуд байсан ч үйлчилгээний сүлжээг бий болгохын тулд хаа сайгүй прокси нааж байгаагүй. Гэсэн хэдий ч, хэрэв та анхааралтай ажиглавал тэд үүнтэй төстэй зүйлийг хийсэн: эдгээр компаниудын ихэнх нь сүлжээний харилцаа холбооны тусгай дотоод номын санг ашиглахыг шаарддаг (заримдаа зузаан үйлчлүүлэгчийн номын сан гэж нэрлэдэг, бүдүүн үйлчлүүлэгчийн номын сан).
Netflix-д Hysterix, Google-д Stubby, Twitter-д Finagle номын сан байсан. Жишээлбэл, Финагл нь Twitter-ийн шинэ үйлчилгээ бүрт заавал байх ёстой байсан. Энэ нь холболтын үйлчлүүлэгч болон серверийн талыг хоёуланг нь зохицуулж, давтан хүсэлт гаргах, хүсэлтийг чиглүүлэх, ачааллыг тэнцвэржүүлэх, хэмжилтийг дэмждэг. Энэ нь үйлчилгээ юу хийж байгаагаас үл хамааран Твиттерийн нийт стекийн найдвартай байдал, ажиглалтын түвшний тогтвортой байдлыг хангасан. Мэдээжийн хэрэг, энэ нь зөвхөн JVM хэл дээр ажилладаг байсан бөгөөд программыг бүхэлд нь ашиглах ёстой програмчлалын загвар дээр суурилсан байв. Гэсэн хэдий ч түүний ажиллагаа нь үйлчилгээний тортой бараг ижил байв. (Үнэндээ Linkerd-ийн анхны хувилбар нь прокси хэлбэрээр ороосон Finagle байсан.)
Ийнхүү арваад жилийн өмнө зөвхөн микро үйлчилгээнүүд биш, мөн үйлчилгээний тороор шийдэж байгаа асуудлуудыг шийддэг тусгай proto-service-mesh номын сангууд байсан. Гэсэн хэдий ч үйлчилгээний тор өөрөө тэр үед байгаагүй. Түүнийг гарч ирэхээс өмнө дахиад нэг ээлж байх ёстой байв.
Сүүлийн 10 жилийн хугацаанд гарсан өөр нэг өөрчлөлтөд нуугдаж буй илүү гүнзгий хариулт энд байна: бичил үйлчилгээг нэвтрүүлэх зардал эрс буурсан. Арван жилийн өмнө бичил үйлчилгээ ашигладаг дээр дурдсан компаниуд болох Twitter, Netflix, Facebook, Google зэрэг нь асар том цар хүрээтэй, асар их нөөцтэй компаниуд байсан. Тэд зөвхөн хэрэгцээ шаардлагаас гадна микро үйлчилгээнд суурилсан томоохон програмуудыг бүтээх, байршуулах, ажиллуулах чадвартай байсан. Твиттерийн инженерүүдийн цул хэлбэрээс микро үйлчилгээ рүү шилжихэд зарцуулсан эрч хүч, хүчин чармайлт үнэхээр гайхалтай юм. (Шударга байхын тулд энэ нь амжилттай болсон нь бас тийм юм.) Жижиг компаниудын хувьд ийм төрлийн дэд бүтцийн маневр хийх боломжгүй байсан.
Өнөөг хүртэл хурдан урагшил. Өнөөдөр стартапууд байдаг бөгөөд бичил үйлчилгээ болон хөгжүүлэгчид 5: 1 (эсвэл бүр ), үүнээс гадна тэд үүнийг амжилттай даван туулж чадна! Хэрэв 5 хүнтэй стартап 50 микро үйлчилгээг хялбархан ажиллуулж чадвал тэдгээрийг хэрэгжүүлэх зардлыг ямар нэг зүйл тодорхой бууруулсан байна.
Монзо дахь 1500 микро үйлчилгээ; мөр бүр нь урсгалыг зөвшөөрдөг тогтоосон сүлжээний дүрэм юм
Микро үйлчилгээний өртөг эрс буурсан нь нэг үйл явцын үр дүн юм. савны алдар нэр улам бүр нэмэгдсээр байна и найрал хөгжимчид. Энэ бол үйлчилгээний тор үүсэхэд юу нөлөөлсөн бэ гэсэн асуултын гүн хариулт юм. Ижил технологи нь үйлчилгээний тор болон микро үйлчилгээг хоёуланг нь сонирхол татахуйц болгосон: Kubernetes болон Docker.
Яагаад? За, Docker нэг том асуудлыг шийддэг - савлагааны асуудал. Програм болон түүний (сүлжээний бус) ажиллах үеийн хамаарлыг контейнерт савласнаар Docker програмыг хаана ч байрлуулж, ажиллуулж болох сольж болох нэгж болгон хувиргадаг. Үүний зэрэгцээ энэ нь үйл ажиллагааг ихээхэн хялбаршуулдаг олон хэлтэй Стек: Контейнер нь гүйцэтгэх атомын нэгж учраас байрлуулалт болон үйл ажиллагааны зорилгоор JVM, Node, Go, Python, эсвэл Ruby програм байхаас үл хамааран дотор нь юу байх нь хамаагүй. Та зүгээр л эхлүүлээд л болоо.
Кубернетес бүх зүйлийг дараагийн түвшинд аваачдаг. Одоо олон тонн "ажиллуулах зүйл" болон тэдгээрийг ажиллуулах олон тонн машин байгаа тул тэдгээрийг хооронд нь уялдуулах хэрэгсэл хэрэгтэй байна. Өргөн утгаараа та Кубернетесэд маш олон контейнер, маш олон машин өгдөг бөгөөд энэ нь тэдгээрийг бие биентэйгээ харьцуулж харуулдаг (мэдээж энэ нь динамик бөгөөд байнга өөрчлөгдөж байдаг үйл явц юм: шинэ савнууд системийг тойрон хөдөлж, машинууд ажиллаж, зогсдог. , гэх мэт. Гэсэн хэдий ч Кубернетес энэ бүгдийг харгалзан үздэг ).
Kubernetes-ийг тохируулсны дараа нэг үйлчилгээг байршуулах, ажиллуулах зардал нь арван үйлчилгээг байршуулах, ажиллуулах зардлаас бага зэрэг ялгаатай (үнэндээ 100 үйлчилгээний хувьд бараг ижил). Энэхүү савнууд дээр олон хэлээр нэвтрүүлэхийг дэмждэг сав баглаа боодлын механизм болгон нэмбэл, танд өөр өөр хэлээр бичигдсэн бичил үйлчилгээ хэлбэрээр хэрэгжсэн олон шинэ програмууд байгаа бөгөөд энэ нь үйлчилгээний тор нь маш тохиромжтой орчин юм.
Тиймээс, бид үйлчилгээний торны санаа яагаад түгээмэл болсон вэ гэсэн асуултын хариултанд ирлээ: Кубернетесийн үйлчилгээнд үзүүлж буй нэгэн төрлийн байдал нь үйлчилгээний торонд тулгарч буй үйл ажиллагааны сорилтод шууд хамаатай. Та проксиг саванд хийж, Кубернетесийг хаана ч хамаагүй наах даалгавар өг. Үүний үр дүнд та үйлчилгээний торыг олж авах бөгөөд түүнийг байрлуулах бүх механикийг Кубернетес удирддаг. (Наад зах нь шувууны нүдээр. Мэдээжийн хэрэг, энэ үйл явцад олон нюанс бий.)
Дүгнэж хэлэхэд: үйлчилгээний тор нь XNUMX жилийн өмнө биш, харин одоо түгээмэл болсон шалтгаан нь Кубернетес, Докер нар зөвхөн мэдэгдэхүйц нэмэгдсэнтэй холбоотой юм. хэрэгтэй Үүнд олон хэлний микро үйлчилгээний багц хэлбэрээр програмуудыг хэрэгжүүлэх ажлыг хялбаршуулсан боловч мэдэгдэхүйц бууруулсан. зардал түүний үйл ажиллагаанд зориулж, хажуугийн машины прокси флотыг байршуулах, дэмжих механизмаар хангах.
Үйлчилгээний торны талаар яагаад ийм их ярьдаг вэ?
Урьдчилан сэргийлэх: Энэ хэсэгт би бүх төрлийн таамаглал, таамаглал, зохиомол мэдээлэл, дотоод мэдээллийг ашигладаг.
"Үйлчилгээний тор" гэж хайвал та дахин боловсруулсан бага илчлэг агуулга, хачирхалтай төслүүд, цуурай камерт тохирохуйц гажилтын калейдоскоптой танилцах болно. Ямар ч гоёмсог шинэ технологи үүнийг хийдэг, гэхдээ үйлчилгээний торны хувьд асуудал ялангуяа хурцаар тавигддаг. Яагаад?
За нэг хэсэг нь миний буруу. Би үүнтэй төстэй тоо томшгүй олон блог нийтлэл, нийтлэлүүдийг үзэх боломж бүрдээ Linkerd болон үйлчилгээний сүлжээг сурталчлахын тулд шаргуу ажиллаж байна. Гэхдээ би тийм ч хүчтэй биш. Энэ асуултад үнэхээр хариулахын тулд бид ерөнхий нөхцөл байдлын талаар бага зэрэг ярих хэрэгтэй. Нэг төслийг дурдахгүйгээр энэ тухай ярих боломжгүй: Google, IBM, Lyft нарын хамтран боловсруулсан нээлттэй эхийн үйлчилгээний сүлжээ юм.
(Гурван компани тэс өөр үүрэг гүйцэтгэдэг: Lyft-ийн оролцоо нь зөвхөн нэрээр л байгаа мэт харагдаж байна; тэд Envoy-ийн зохиогчид боловч Istio-ийн хөгжүүлэлтийг ашигладаггүй эсвэл оролцдоггүй. IBM нь Istio-ийн хөгжүүлэлтэд оролцож, ашигладаг. Google Istio-ийн ажилд идэвхтэй оролцдог. хөгжүүлэлт , гэхдээ миний хэлж байгаагаар үүнийг ашигладаггүй.)
Istio төсөл нь хоёр зүйлээрээ онцлог юм. Нэгдүгээрт, Google ялангуяа үүнийг сурталчлахын тулд асар их маркетингийн хүчин чармайлт гаргаж байна. Өнөөдөр үйлчилгээний торны тухай ойлголттой хүмүүсийн ихэнх нь үүнийг Istio-ээр дамжуулан мэдсэн гэж би тооцоолж байна. Хоёрдахь зүйл бол Истио хэр муу хүлээж авсан бэ. Энэ асуудалд би мэдээж сонирхолтой хүн боловч аль болох бодитой байхыг хичээсэн ч тусалж чадахгүй байна , тийм ч өвөрмөц биш (гэхдээ өвөрмөц биш: systemd санаанд орж ирдэг, ...) Нээлттэй эхийн төсөлд зориулсан.
(Практик дээр Istio нь зөвхөн нарийн төвөгтэй байдал, UX-тай холбоотой асуудал төдийгүй гүйцэтгэлийн хувьд ч асуудалтай байдаг. Жишээ нь: Гуравдагч талын судалгаагаар судлаачид Istio-ийн сүүлний хоцролт нь Linkerd-ээс 100 дахин их байсан, мөн Истио бүрэн ажиллахаа больсон байхад Linkerd амжилттай ажиллаж байсан нөөцийн хомсдолтой нөхцөл байдлыг олж мэдсэн.)
Яагаад ийм зүйл болсон тухай онолоо орхиод, үйлчилгээний сүлжээний эргэн тойрон дахь асар их сэтгэл хөдлөлийг Google-ийн оролцоотой холбон тайлбарлаж байна гэж би үзэж байна. Тухайлбал, дараах гурван хүчин зүйлийн хослол.
- Google-ийн Istio-ийн интрузив сурталчилгаа;
- төсөлд үл нийцэх, шүүмжлэлтэй хандах хандлага;
- Кубернетесийн алдар нэр сүүлийн үеийн солирын өсөлт, дурсамж нь шинэ хэвээр байна.
Эдгээр хүчин зүйлүүд нийлээд хүчилтөрөгчгүй, ухаантай сэтгэх чадвар суларч, зөвхөн хачирхалтай олон янз байдал л үлддэг тэнэг, хүчилтөрөгчгүй орчинг бий болгодог. .
Линкердийн өнцгөөс харахад энэ бол ... миний холимог адислал гэж тодорхойлох зүйл юм. Линкерд анх 2016 онд ажиллаж байх үед үйлчилгээний сүлжээ үндсэн урсгалд нэвтэрсэн нь гайхалтай бөгөөд хүмүүсийг төсөлд анхаарлаа хандуулахад үнэхээр хэцүү байсан. Одоо тийм асуудал байхгүй! Гэвч муу мэдээ гэвэл үйлчилгээний торон ландшафт нь өнөөдөр маш будлиантай байгаа тул аль төсөл нь үйлчилгээний тор ангилалд хамаарахыг (тодорхой хэрэглээний тохиолдолд аль нь хамгийн тохиромжтойг ойлгох нь битгий хэл) ойлгох бараг боломжгүй юм. Энэ нь мэдээж хүн бүрийн хувьд хэлцэл юм (мөн Istio эсвэл өөр төсөл нь Linkerd-ээс илүү тохиромжтой зарим тохиолдол байдаг, учир нь сүүлийнх нь бүх нийтийн шийдэл биш хэвээр байна).
Линкердийн хувьд бидний стратеги бол чимээ шуугианыг үл тоомсорлож, нийгмийн бодит асуудлыг шийдвэрлэхэд анхаарлаа төвлөрүүлж, үндсэндээ шуугиан дэгдээхийг хүлээх явдал юм. Эцсийн дүндээ шуугиан тарьж, бид тайван ажлаа үргэлжлүүлэх болно.
Энэ хооронд бид бүгд жаахан тэвчээртэй байх хэрэгтэй.
Даруухан программ хангамжийн инженер надад үйлчилгээний тор хэрэг болох болов уу?
Дараах асуултын хуудас нь танд энэ асуултад хариулахад тусална.
Та зөвхөн бизнесийн логикийг хэрэгжүүлэхэд оролцдог уу? Энэ тохиолдолд үйлчилгээний тор нь танд ашиггүй болно. Энэ нь мэдээжийн хэрэг та үүнийг сонирхож магадгүй, гэхдээ үйлчилгээний тор нь таны хүрээлэн буй орчинд ямар нэгэн зүйлд шууд нөлөөлөх ёсгүй. Цалин авсан зүйл дээрээ үргэлжлүүлэн ажилла.
Та Kubernetes ашигладаг компанид платформыг дэмжиж байна уу? Тиймээ, энэ тохиолдолд танд үйлчилгээний тор хэрэгтэй (мэдээжийн хэрэг, та K8-ийг зөвхөн цул эсвэл багц боловсруулалт хийхэд ашиглахгүй бол - гэхдээ би танд яагаад K8 хэрэгтэй байгааг асуумаар байна). Та янз бүрийн хүмүүсийн бичсэн маш олон микро үйлчилгээтэй байх магадлалтай. Тэд бүгд бие биетэйгээ харилцаж, ажиллах хугацааны хамаарлын ээдрээтэй холбоотой байдаг тул та энэ бүхнийг шийдвэрлэх арга замыг олох хэрэгтэй. Kubernetes-ийг ашиглах нь танд "өөртөө" үйлчилгээний сүлжээг сонгох боломжийг олгоно. Үүнийг хийхийн тулд тэдгээрийн чадавхи, онцлогтой танилцаж, боломжтой төслүүдийн аль нэг нь танд тохирох эсэх асуултад хариулна уу (Би судалгаагаа Linkerd-ээс эхлүүлэхийг зөвлөж байна).
Та Kubernetes ашигладаггүй боловч микро үйлчилгээ ашигладаг компанийн платформ компани мөн үү? Энэ тохиолдолд үйлчилгээний тор нь танд ашигтай байх болно, гэхдээ түүний хэрэглээ нь өчүүхэн биш байх болно. Мэдээж та чадна дуурайх Олон тооны прокси байрлуулах замаар үйлчилгээний торонд ажилладаг боловч Kubernetes-ийн чухал давуу тал нь байршуулах загвар юм: эдгээр проксиг гараар засварлахад илүү их цаг хугацаа, хүчин чармайлт, зардал шаардагдана.
Та цул материалтай ажилладаг компанид платформыг хариуцдаг уу? Энэ тохиолдолд танд үйлчилгээний тор хэрэггүй байж магадгүй юм. Хэрэв та харилцан үйлчлэлийн хэв маяг нь сайн тодорхойлогддог, ховор өөрчлөгддөг цул чулуунуудтай (эсвэл бүр цул чулуунуудын цуглуулга) ажиллаж байгаа бол үйлчилгээний тор танд өгөх зүйл бага байх болно. Тиймээс та үүнийг үл тоомсорлож, муу зүүд шиг алга болно гэж найдаж болно ...
дүгнэлт
Магадгүй үйлчилгээний торыг "дэлхийн хамгийн алдартай технологи" гэж нэрлэх ёсгүй - энэ эргэлзээтэй нэр хүнд нь Bitcoin эсвэл AI-д хамаарах байх. Тэр шилдэг тавд багтсан байх. Гэхдээ хэрэв та дуу чимээний давхаргыг таслах юм бол үйлчилгээний тор нь Kubernetes дээр програм бүтээдэг хүмүүст бодит ашиг тус авчрах нь тодорхой болно.
Би таныг Kubernetes кластер дээр (эсвэл зөөврийн компьютер дээр Minikube) суулгаж байгаа Linkerd-г туршиж үзэхийг хүсч байна. , мөн миний юу яриад байгааг та өөрөө харж болно.
тусламж
- Хэрэв би үйлчилгээний торыг үл тоомсорловол энэ нь алга болох уу?
- Би таны урмыг хугалах ёстой: үйлчилгээний тор нь бидэнтэй удаан хугацаанд хамт байна.
- Гэхдээ би үйлчилгээний тор ашиглахыг хүсэхгүй байна!
- За, энэ шаардлагагүй! Та наад зах нь түүний үндсэн суурьтай танилцах хэрэгтэй эсэхийг ойлгохын тулд дээрх миний асуулгын хуудсыг уншаарай.
- Энэ шинэ соустай хуучин сайн ESB/middleware биш гэж үү?
— Үйлчилгээний тор нь семантик биш харин үйлдлийн логиктой холбоотой. байгууллагын үйлчилгээний автобус (). Энэхүү тусгаарлалтыг хадгалах нь үйлчилгээний сүлжээг ижил хувь тавилангаас зайлсхийхэд тусалдаг.
— Үйлчилгээний сүлжээ нь API гарцаас юугаараа ялгаатай вэ?
- Энэ сэдвээр сая сая нийтлэл байна. Зүгээр л Google-д оруулаарай.
- Элч бол үйлчилгээний сүлжээ мөн үү?
- Үгүй, Envoy бол үйлчилгээний сүлжээ биш, прокси сервер юм. Үүнийг үйлчилгээний торыг зохион байгуулахад ашиглаж болно (мөн бусад олон зүйл - энэ нь ерөнхий зориулалтын прокси юм). Гэхдээ энэ нь өөрөө үйлчилгээний тор биш юм.
— Сүлжээний үйлчилгээний тор нь үйлчилгээний сүлжээ мөн үү?
- Үгүй. Нэрийг нь үл харгалзан энэ нь үйлчилгээний сүлжээ биш юм (та маркетингийн гайхамшгуудад хэрхэн дуртай вэ?).
— Үйлчилгээний сүлжээ нь миний мессежийн дараалалд суурилсан реактив асинхрон системд туслах уу?
- Үгүй ээ, үйлчилгээний тор танд тус болохгүй.
— Би ямар үйлчилгээний тор ашиглах ёстой вэ?
- , ухаангүй.
- Өгүүллэг муу байна! / Зохиогчийг урьж байна!
- Энэ холбоосыг бүх найзуудтайгаа хуваалцаарай, ингэснээр тэд үүнийг харах болно!
Талархал
Гарчигнаас нь та таамаглаж байсанчлан энэ нийтлэлийг Жей Крепсийн гайхалтай зохиолоос санаа авсан болно "" Би Жейтэй арван жилийн өмнө Linked In дээр ярилцлага өгөхдөө танилцсан бөгөөд тэр цагаас хойш тэр надад урам зориг өгсөн.
Би өөрийгөө "Linkerd хөгжүүлэгч" гэж нэрлэх дуртай ч бодит байдал дээр би төслийн README.md файлыг илүү хөтлөгч болсон. Linkerd дээр өнөөдөр ажиллаж байна , , хүмүүс, мөн гайхалтай хувь нэмэр оруулагчид болон хэрэглэгчдийн оролцоогүйгээр энэ төсөл хэрэгжихгүй байсан.
Эцэст нь Linkerd-ийг бүтээгчдээ онцгой талархал илэрхийлье. (primus inter pares), олон жилийн өмнө надтай хамт үйлчилгээний тороор энэ бүх шуугиан руу толгойгоо гашилгаж байсан.
Орчуулагчийн жич
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «";
- «";
- «".
Эх сурвалж: www.habr.com