Хөөе Хабр! Би нийтлэлийн орчуулгыг та бүхэнд толилуулж байна зохиогч нь Мэтт Клейн.
Энэ удаад би үйлчилгээний торон бүрэлдэхүүн хэсэг, өгөгдлийн болон удирдлагын хавтгайн аль алиных нь тайлбарыг "хүсч, орчуулсан". Энэ тайлбар надад хамгийн ойлгомжтой, сонирхолтой санагдсан бөгөөд хамгийн чухал нь "Заавал хэрэгтэй юу?"
"Үйлчилгээний тор" гэсэн санаа сүүлийн хоёр жилийн хугацаанд улам бүр түгээмэл болж (10 оны 2017-р сарын XNUMX-ны анхны нийтлэл) болон орон зайд оролцогчдын тоо нэмэгдэхийн хэрээр нийт хүмүүсийн дунд төөрөгдөл харьцангуй нэмэгдэж байгааг би харж байна. өөр өөр шийдлүүдийг хэрхэн харьцуулах, харьцуулах талаар технологийн нийгэмлэг.
Нөхцөл байдлыг миний долдугаар сард бичсэн дараах жиргээнүүдээр хамгийн сайн дүгнэж болно.
Үйлчилгээний сүлжээний төөрөгдөл №1: Linkerd ~ = Nginx ~ = Haproxy ~ = Элч. Тэдний хэн нь ч Истиотой тэнцэхгүй. Istio бол огт өөр зүйл юм. 1 /
Эхнийх нь өгөгдлийн онгоцууд юм. Тэд өөрсдөө юу ч хийдэггүй. Тэд өөр зүйлд дуртай байх ёстой. 2/
Istio бол эд ангиудыг хооронд нь холбодог хяналтын онгоцны жишээ юм. Энэ бол өөр давхарга юм. /Төгсгөл
Өмнөх жиргээнүүдэд хэд хэдэн өөр төслүүдийг (Linkerd, NGINX, HAProxy, Envoy, and Istio) дурдсан боловч илүү чухал нь өгөгдлийн хавтгай, үйлчилгээний тор, удирдлагын хавтгай гэсэн ерөнхий ойлголтуудыг танилцуулж байна. Энэ нийтлэлээрээ би нэг алхам ухарч, "өгөгдлийн онгоц", "удирдлагын онгоц" гэсэн нэр томъёог маш өндөр түвшинд ярьж, дараа нь жиргээнд дурдсан төслүүдэд энэ нэр томъёо хэрхэн хамаарах талаар ярих болно.
Үйлчилгээний сүлжээ гэж юу вэ?
Зураг 1: Үйлчилгээний торны тойм
1 зураг Үйлчилгээний сүлжээ гэсэн ойлголтыг хамгийн энгийн түвшинд харуулсан. Үйлчилгээний дөрвөн кластер (AD) байдаг. Үйлчилгээний тохиолдол бүр локал прокси сервертэй холбоотой байдаг. Нэг програмын жишээн дэх бүх сүлжээний траффик (HTTP, REST, gRPC, Redis гэх мэт) нь локал проксигоор дамжуулан зохих гадаад үйлчилгээний кластерууд руу дамждаг. Ингэснээр програмын жишээ нь сүлжээг бүхэлд нь мэддэггүй бөгөөд зөвхөн өөрийн локал проксиг мэддэг. Үнэндээ түгээсэн системийн сүлжээг үйлчилгээнээс хассан.
Өгөгдлийн хавтгай
Үйлчилгээний сүлжээнд програмын хувьд дотоодод байрлах прокси сервер нь дараах ажлуудыг гүйцэтгэдэг.
- Үйлчилгээний нээлт. Таны өргөдөлд ямар үйлчилгээ/програмууд байгаа вэ?
- Эрүүл мэндийн үзлэг. Үйлчилгээний нээлтээр буцаасан үйлчилгээний тохиолдлууд эрүүл бөгөөд сүлжээний урсгалыг хүлээн авахад бэлэн үү? Үүнд идэвхтэй (жишээ нь хариу/эрүүл мэндийн үзлэг) болон идэвхгүй (жишээ нь эрүүл бус үйлчилгээний төлөвийн шинж тэмдэг болгон 3 дараалсан 5xx алдааг ашиглах) эрүүл мэндийн шалгалтыг багтааж болно.
- Чиглүүлэлт. REST үйлчилгээнээс "/foo" гэсэн хүсэлтийг хүлээн авахдаа хүсэлтийг аль үйлчилгээний кластер руу илгээх ёстой вэ?
- Ачааллыг тэнцвэржүүлэх. Чиглүүлэлтийн явцад үйлчилгээний кластер сонгогдсоны дараа хүсэлтийг аль үйлчилгээний инстант руу илгээх вэ? Ямар хугацаатай вэ? Хэлхээ таслах ямар тохиргоотой вэ? Хэрэв хүсэлт амжилтгүй болбол дахин оролдох уу?
- Баталгаажуулалт ба зөвшөөрөл. Ирж буй хүсэлтийн хувьд дуудлагын үйлчилгээг mTLS эсвэл өөр механизм ашиглан криптографийн аргаар тодорхойлж/зөвшөөрөх боломжтой юу? Хэрэв энэ нь хүлээн зөвшөөрөгдсөн/зөвшөөрөгдсөн бол үйлчилгээнд хүссэн үйлдлийг (төгсгөлийн цэг) дуудах боломжтой юу эсвэл баталгаажуулаагүй хариуг буцааж өгөх ёстой юу?
- Ажиглах чадвар. Нарийвчилсан статистик, бүртгэл/лог болон тархсан ул мөрийн өгөгдлийг хүсэлт тус бүрээр үүсгэх ёстой бөгөөд ингэснээр операторууд тархсан хөдөлгөөний урсгал болон гарч ирэх үед дибаг хийх асуудлыг ойлгох боломжтой болно.
Өгөгдлийн хавтгай нь үйлчилгээний торонд өмнөх бүх цэгүүдийг хариуцдаг. Үнэн хэрэгтээ, үйлчилгээний локал прокси (хажуугийн машин) нь өгөгдлийн хавтгай юм. Өөрөөр хэлбэл, өгөгдлийн онгоц нь үйлчилгээ рүү эсвэл үйлчилгээнээс илгээсэн сүлжээний пакет бүрийг нөхцөлт дамжуулах, дамжуулах, хянах үүрэгтэй.
Хяналтын онгоц
Өгөгдлийн хавтгайд локал прокси өгдөг сүлжээний хийсвэрлэл нь ид шидтэй(?). Гэсэн хэдий ч, прокси В үйлчилгээний "/foo" замыг хэрхэн мэддэг вэ? Прокси хүсэлтээр дүүргэсэн үйлчилгээний нээлтийн өгөгдлийг хэрхэн ашиглах вэ? Ачаалал тэнцвэржүүлэх, завсарлага, хэлхээг таслах гэх мэт параметрүүдийг хэрхэн тохируулсан бэ? Цэнхэр/ногоон арга эсвэл хөдөлгөөнт шилжилтийн аргыг ашиглан програмыг хэрхэн байрлуулах вэ? Системийн хэмжээнд таниулах болон зөвшөөрлийн тохиргоог хэн тохируулах вэ?
Дээрх бүх зүйл нь үйлчилгээний торны хяналтын хавтгайн хяналтанд байдаг. Удирдлагын онгоц нь тусгаарлагдсан харьяалалгүй проксиг авч, тэдгээрийг тархсан систем болгон хувиргадаг.
Миний бодлоор олон технологичид өгөгдлийн хавтгай ба хяналтын онгоц гэсэн тусдаа ойлголтыг төөрөлдүүлж байгаагийн шалтгаан нь ихэнх хүмүүсийн хувьд мэдээллийн хавтгай нь танил байдаг бол удирдлагын хавтгай нь гадаад/ ойлгогддоггүйтэй холбоотой юм. Бид физик сүлжээний чиглүүлэгч болон шилжүүлэгчтэй удаан хугацааны турш ажиллаж байна. Пакет/хүсэлт нь А цэгээс В цэг рүү шилжих ёстой бөгөөд үүнийг хийхийн тулд техник хангамж, програм хангамж ашиглаж болно гэдгийг бид ойлгож байна. Програм хангамжийн шинэ үеийн прокси нь бидний удаан хугацаанд хэрэглэж ирсэн хэрэгслүүдийн зүгээр л гоёмсог хувилбарууд юм.
Зураг 2: Хүний удирдлагын онгоц
Гэсэн хэдий ч ихэнх сүлжээний операторууд системийн энэ хэсгийг ямар ч технологийн бүрэлдэхүүн хэсэгтэй холбодоггүй байж болох ч бид удирдлагын онгоцыг удаан хугацаанд ашиглаж ирсэн. Шалтгаан нь энгийн:
Өнөөдөр ашиглагдаж байгаа ихэнх удирдлагын онгоцууд нь... бид.
дээр зураг 2 Миний "Хүний удирдлагын онгоц" гэж нэрлэдэг зүйлийг харуулж байна. Өнөөг хүртэл түгээмэл хэвээр байгаа энэ төрлийн байршуулалтад магадгүй ууртай хүний оператор статик тохиргоог скриптээр үүсгэж, тусгай процессоор дамжуулан бүх прокси дээр байрлуулдаг. Дараа нь прокси энэ тохиргоог ашиглаж эхэлж, шинэчлэгдсэн тохиргоог ашиглан өгөгдлийн хавтгайг боловсруулж эхэлнэ.
Зураг 3: Нарийвчилсан үйлчилгээний торон удирдлагын хавтгай
дээр зураг 3 үйлчилгээний торны "өргөтгөсөн" хяналтын хавтгайг харуулж байна. Энэ нь дараах хэсгүүдээс бүрдэнэ.
- Хүн: Бүхэл бүтэн системтэй холбоотой өндөр түвшний шийдвэр гаргадаг хүн (уурлах нь бага гэж найдаж байна) байсаар байна.
- Хяналтын онгоцны UI: Хүн системийг удирдахын тулд зарим төрлийн хэрэглэгчийн интерфейстэй харилцдаг. Энэ нь вэб портал, командын мөрийн програм (CLI) эсвэл бусад интерфейс байж болно. Хэрэглэгчийн интерфэйсийг ашигласнаар оператор дэлхийн системийн тохиргооны параметрүүдэд хандах боломжтой, тухайлбал:
- Байршуулах хяналт, хөх/ногоон ба/эсвэл хөдөлгөөнийг аажмаар шилжүүлэх
- Баталгаажуулалт ба зөвшөөрлийн сонголтууд
- Чиглүүлэлтийн хүснэгтийн үзүүлэлтүүд, жишээлбэл, А програм "/foo"-н талаар мэдээлэл авахыг хүссэн үед
- Ачаалал тэнцвэржүүлэгчийн тохиргоо, тухайлбал завсарлага, дахин оролдлого, хэлхээг таслах тохиргоо гэх мэт.
- Ажлын ачаалал төлөвлөгч: Үйлчилгээнүүд нь Kubernetes эсвэл Nomad зэрэг зарим төрлийн хуваарь/зохицуулалтын системээр дамжуулан дэд бүтэц дээр явагддаг. Төлөвлөгч нь үйлчилгээг өөрийн орон нутгийн прокситэй хамт ачаалах үүрэгтэй.
- Үйлчилгээний нээлт. Төлөвлөгч нь үйлчилгээний тохиолдлуудыг эхлүүлж, зогсоох үед эрүүл мэндийн байдлын талаар үйлчилгээний нээлтийн системд мэдээлдэг.
- Sidecar прокси тохиргооны API : Орон нутгийн прокси нь операторын оролцоогүйгээр эцэст нь тогтвортой загвар ашиглан янз бүрийн системийн бүрэлдэхүүн хэсгүүдээс төлөвийг динамик байдлаар гаргаж авдаг. Одоо ажиллаж байгаа бүх үйлчилгээний инстанцууд болон локал прокси серверүүдээс бүрдсэн бүхэл систем нь эцэстээ нэг экосистемд нэгддэг. Envoy's universal data plane API нь энэ нь практикт хэрхэн хэрэгждэгийн нэг жишээ юм.
Үндсэндээ хяналтын хавтгайн зорилго нь өгөгдлийн хавтгайд хүлээн зөвшөөрөгдөх бодлогыг тогтоох явдал юм. Илүү дэвшилтэт хяналтын онгоцууд нь зарим системийн илүү олон хэсгийг оператороос салгаж, зөв ажиллах тохиолдолд гар ажиллагаа бага шаарддаг!...
Мэдээллийн хавтгай ба хяналтын хавтгай. Мэдээллийн хавтгай ба удирдлагын хавтгайн хураангуй
- Үйлчилгээний тор мэдээллийн хавтгай: Систем дэх пакет/хүсэлт бүрт нөлөөлнө. Хэрэглээ/үйлчилгээг илрүүлэх, эрүүл мэндийг шалгах, чиглүүлэлт хийх, ачааллыг тэнцвэржүүлэх, баталгаажуулалт/зөвшөөрөл, ажиглалтыг хариуцна.
- Үйлчилгээний торны хяналтын онгоц: Үйлчилгээний сүлжээн дэх бүх ажиллаж байгаа өгөгдлийн онгоцуудын бодлого, тохиргоог хангана. Систем дээрх ямар ч багц/хүсэлтэд хүрч болохгүй. Хяналтын хавтгай нь бүх өгөгдлийн онгоцыг тархсан систем болгон хувиргадаг.
Одоогийн төслийн ландшафт
Дээрх тайлбарыг ойлгосны дараа үйлчилгээний тор төслийн өнөөгийн байдлыг харцгаая.
- Өгөгдлийн онгоцууд: Linkerd, NGINX, HAProxy, Envoy, Traefik
- Хяналтын онгоцууд: Istio, Nelson, SmartStack
Дээрх шийдэл тус бүрийг нарийвчлан шинжлэхийн оронд би яг одоо экосистемд ихээхэн төөрөгдөл үүсгэж байгаа гэж үзэж буй зарим зүйлийг товч дурдах болно.
Linkerd нь 2016 оны эхээр үйлчилгээний торонд зориулсан анхны өгөгдлийн онгоцны прокси серверүүдийн нэг байсан бөгөөд үйлчилгээний тор дизайны загварт анхаарал хандуулж, мэдлэгийг дээшлүүлэх гайхалтай ажлыг хийсэн. Үүнээс хойш 6 сарын дараа Элч Линкерд нэгдсэн (хэдийгээр тэр 2015 оны сүүлээс Lyft-т ажиллаж байсан). Linkerd болон Envoy бол үйлчилгээний торыг хэлэлцэх үед хамгийн их дурдагддаг хоёр төсөл юм.
Истио 2017 оны тавдугаар сард зарласан. Istio төслийн зорилго нь дээр харуулсан өргөтгөсөн хяналтын онгоцтой маш төстэй юм зураг 3. Istio-д зориулсан элч нь анхдагч прокси юм. Тиймээс, Istio нь хяналтын хавтгай, Элч нь мэдээллийн хавтгай юм. Богино хугацаанд Istio маш их сэтгэл хөдлөлийг төрүүлж, бусад өгөгдлийн онгоцууд Envoy-ийг орлохоор нэгтгэж эхлэв (Linkerd болон NGINX хоёулаа Istio-тэй нэгдэж байгааг харуулсан). Нэг хяналтын хавтгайд өөр өөр өгөгдлийн онгоцыг ашиглаж болно гэдэг нь хяналтын хавтгай ба мэдээллийн хавтгай нь хоорондоо нягт холбоотой байх албагүй гэсэн үг юм. Envoy's generic data plane API зэрэг API нь системийн хоёр хэсгийн хооронд гүүр болж чаддаг.
Нелсон ба SmartStack нар хяналтын хавтгай ба өгөгдлийн хавтгайг тусгаарлаж харуулахад тусалдаг. Нелсон нь Envoy-г прокси болгон ашигладаг бөгөөд HashiCorp стек дээр суурилсан үйлчилгээний торонд найдвартай хяналтын онгоцыг бүтээдэг, i.e. Номад гэх мэт. SmartStack нь үйлчилгээний торны шинэ давалгааны анхных байж магадгүй юм. SmartStack нь HAProxy эсвэл NGINX-ийн эргэн тойронд хяналтын хавтгайг бүтээж, мэдээллийн хавтгайгаас хяналтын хавтгайг үйлчилгээний торноос салгах чадварыг харуулдаг.
Үйлчилгээний тор бүхий микросервис архитектур улам бүр анхаарал татаж байна (зөв!), илүү олон төсөл, үйлдвэрлэгчид энэ чиглэлд ажиллаж эхэлж байна. Ирэх хэдэн жилийн хугацаанд бид мэдээллийн болон хяналтын хавтгайд маш их шинэлэг зүйл хийхээс гадна өөр өөр бүрэлдэхүүн хэсгүүдийг холихыг харах болно. Эцсийн эцэст микро үйлчилгээний архитектур нь операторын хувьд илүү ил тод, ид шидтэй (?) болох ёстой.
Уурлах нь багасна гэж найдаж байна.
Гол санаанууд
- Үйлчилгээний тор нь өгөгдлийн болон хяналтын хавтгай гэсэн хоёр өөр хэсгээс бүрдэнэ. Хоёр бүрэлдэхүүн хэсэг шаардлагатай бөгөөд тэдгээргүйгээр систем ажиллахгүй.
- Хяналтын онгоцыг хүн бүр мэддэг бөгөөд энэ үед удирдлагын онгоц нь та байж магадгүй юм!
- Бүх өгөгдлийн онгоцууд онцлог, гүйцэтгэл, тохируулга, өргөтгөл зэргээрээ хоорондоо өрсөлддөг.
- Удирдлагын бүх онгоцууд онцлог, тохируулга, өргөтгөл, ашиглахад хялбар байдлаараа хоорондоо өрсөлддөг.
- Нэг хяналтын хавтгайд зөв хийсвэрлэл болон API-г агуулж болох тул олон өгөгдлийн онгоцыг ашиглах боломжтой.
Эх сурвалж: www.habr.com