Сайн байна уу, би бол Сергей Еланцев, би хөгжиж байна Yandex.Cloud дээр. Өмнө нь би Yandex порталын L7 тэнцвэржүүлэгчийг хөгжүүлэх ажлыг удирдаж байсан - хамт олон намайг юу ч хийсэн тэнцвэржүүлэгч болж хувирдаг гэж хошигнодог. Би Хабрын уншигчдад үүлэн платформ дээрх ачааллыг хэрхэн зохицуулах, энэ зорилгод хүрэх хамгийн тохиромжтой хэрэгсэл гэж юу гэж үзэж байгаа, мөн энэ хэрэгслийг хэрхэн бүтээх рүү явж байгааг хэлэх болно.
Эхлээд зарим нэр томъёог танилцуулъя:
- VIP (Виртуал IP) - тэнцвэржүүлэгч IP хаяг
- Сервер, backend, instance - програм ажиллуулж буй виртуал машин
- RIP (Бодит IP) - серверийн IP хаяг
- Healthcheck - серверийн бэлэн байдлыг шалгаж байна
- Availability Zone, AZ - дата төвийн тусгаарлагдсан дэд бүтэц
- Бүс нутаг - янз бүрийн AZ-ийн нэгдэл
Ачаалал тэнцвэржүүлэгчид гурван үндсэн ажлыг шийддэг: тэд тэнцвэржүүлэх ажлыг өөрөө гүйцэтгэдэг, үйлчилгээний алдааг тэсвэрлэх чадварыг сайжруулж, масштабыг хялбаршуулдаг. Хөдөлгөөний автомат удирдлагын тусламжтайгаар алдааг тэсвэрлэх чадварыг баталгаажуулдаг: тэнцвэржүүлэгч нь програмын төлөв байдлыг хянаж, амьд байдлын шалгалтыг даваагүй тохиолдлуудыг тэнцвэржүүлэхээс хасдаг. Ачааллыг тохиолдлуудад жигд хуваарилах, мөн тохиолдлын жагсаалтыг шууд шинэчлэх замаар масштабыг баталгаажуулдаг. Хэрэв тэнцвэржүүлэлт хангалттай жигд биш бол зарим тохиолдлууд хүчин чадлынхаа хязгаараас хэтэрсэн ачааллыг хүлээн авч, үйлчилгээний найдвартай байдал буурах болно.
Ачаалал тэнцвэржүүлэгчийг ихэвчлэн ажиллаж буй OSI загварын протоколын давхаргаар ангилдаг. Cloud Balancer нь TCP түвшинд ажилладаг бөгөөд энэ нь дөрөв дэх давхарга болох L4-тэй тохирч байна.
Үүлэн тэнцвэржүүлэгчийн архитектурын тойм руу шилжье. Бид нарийвчилсан түвшинг аажмаар нэмэгдүүлэх болно. Бид тэнцвэржүүлэгчийн бүрэлдэхүүн хэсгүүдийг гурван ангилалд хуваадаг. Тохируулгын хавтгай анги нь хэрэглэгчийн харилцан үйлчлэлийг хариуцдаг бөгөөд системийн зорилтот төлөвийг хадгалдаг. Удирдлагын хавтгай нь системийн одоогийн төлөвийг хадгалж, үйлчлүүлэгчээс таны инстанс руу траффик хүргэх шууд үүрэг бүхий өгөгдлийн түвшний ангиллын системийг удирддаг.
Өгөгдлийн хавтгай
Траффик нь хилийн чиглүүлэгч гэж нэрлэгддэг үнэтэй төхөөрөмжүүд дээр дуусдаг. Гэмтлийг тэсвэрлэх чадварыг нэмэгдүүлэхийн тулд хэд хэдэн ийм төхөөрөмж нэг мэдээллийн төвд нэгэн зэрэг ажилладаг. Дараа нь траффик тэнцвэржүүлэгчид очдог бөгөөд тэдгээр нь үйлчлүүлэгчдэд зориулсан BGP-ээр дамжуулан бүх AZ-д дурын дамжуулалтын IP хаягийг зарладаг.
Траффик нь ECMP-ээр дамждаг - энэ нь чиглүүлэлтийн стратеги бөгөөд үүний дагуу зорилтот чиглэлд хэд хэдэн адил сайн маршрут байж болно (манай тохиолдолд зорилтот IP хаяг нь очих газар байх болно) бөгөөд тэдгээрийн аль нэгээр нь пакетуудыг илгээж болно. Мөн бид хэд хэдэн хүртээмжтэй бүсэд дараах схемийн дагуу ажиллахыг дэмждэг: бид бүс бүрт хаягийг сурталчилж, замын хөдөлгөөн хамгийн ойрын нэг рүү явж, хязгаараас хэтрэхгүй. Дараа нь нийтлэлд бид замын хөдөлгөөнд юу тохиолдох талаар илүү дэлгэрэнгүй авч үзэх болно.
Онгоцыг тохируулах
Тохиргооны хавтгайн гол бүрэлдэхүүн хэсэг нь API бөгөөд үүгээр дамжуулан тэнцвэржүүлэгчтэй хийх үндсэн үйлдлүүдийг гүйцэтгэдэг: жишээнүүдийг үүсгэх, устгах, бүрэлдэхүүнийг өөрчлөх, эрүүл мэндийн үзлэгийн үр дүнг авах гэх мэт. Энэ нь нэг талаас REST API бөгөөд нөгөө талаас бусад тохиолдолд бид Cloud-д gRPC хүрээг ихэвчлэн ашигладаг тул REST-ийг gRPC руу "орчуулж", дараа нь зөвхөн gRPC ашигладаг. Аливаа хүсэлт нь Yandex.Cloud-ийн ажилчдын нийтлэг цөөрөм дээр гүйцэтгэгддэг хэд хэдэн асинхрон идемпотент даалгавруудыг бий болгоход хүргэдэг. Даалгавруудыг хүссэн үедээ түр зогсоож, дахин эхлүүлэх боломжтой байдлаар бичсэн байдаг. Энэ нь үйл ажиллагааны цар хүрээ, давтагдах чадвар, бүртгэлийг баталгаажуулдаг.
Үүний үр дүнд API-ийн даалгавар нь Go дээр бичигдсэн тэнцвэржүүлэгч үйлчилгээний хянагч руу хүсэлт гаргах болно. Энэ нь тэнцвэржүүлэгч нэмэх, хасах, арын хэсэг болон тохиргооны бүрэлдэхүүнийг өөрчлөх боломжтой.
Энэ үйлчилгээ нь өөрийн төлөвийг Yandex мэдээллийн санд хадгалдаг бөгөөд энэ нь та удахгүй ашиглах боломжтой болно. Yandex.Cloud дээр, бид аль хэдийн , нохойн хоолны үзэл баримтлал үйлчилдэг: хэрэв бид өөрсдөө манай үйлчилгээг ашигладаг бол үйлчлүүлэгчид маань ч бас ашиглахдаа баяртай байх болно. Yandex мэдээллийн сан нь ийм үзэл баримтлалыг хэрэгжүүлэх жишээ юм. Бид бүх мэдээллээ YDB-д хадгалдаг бөгөөд мэдээллийн санг хадгалах, өргөжүүлэх талаар бодох шаардлагагүй: эдгээр асуудлууд бидний хувьд шийдэгдэж, бид мэдээллийн санг үйлчилгээ болгон ашигладаг.
Тэнцвэржүүлэгч хянагч руу буцъя. Үүний үүрэг бол тэнцвэржүүлэгчийн талаархи мэдээллийг хадгалах, виртуал машины бэлэн байдлыг шалгах даалгаварыг эрүүл мэндийн хяналтын хянагч руу илгээх явдал юм.
Эрүүл мэндийн хяналтын хянагч
Энэ нь шалгах дүрмийг өөрчлөх хүсэлтийг хүлээн авч, тэдгээрийг YDB-д хадгалж, эрүүл мэндийн хяналтын цэгүүдийн хооронд даалгавруудыг хуваарилж, үр дүнг нэгтгэн мэдээллийн санд хадгалж, ачааллын тэнцвэржүүлэгч хянагч руу илгээдэг. Энэ нь эргээд өгөгдлийн хавтгай дахь кластерын бүтцийг өөрчлөх хүсэлтийг ачааллын тэнцвэржүүлэгч-зангилаа руу илгээдэг бөгөөд үүнийг би доор хэлэлцэх болно.
Эрүүл мэндийн үзлэгийн талаар илүү дэлгэрэнгүй ярилцъя. Тэдгээрийг хэд хэдэн ангилалд хувааж болно. Аудит нь өөр өөр амжилтын шалгууртай байдаг. TCP шалгалт нь тодорхой хугацааны дотор холболтыг амжилттай тогтоох шаардлагатай. HTTP шалгалт нь амжилттай холболт болон 200 статус код бүхий хариултыг шаарддаг.
Түүнчлэн, шалгалтууд нь үйлдлийн ангиллаар ялгаатай байдаг - тэдгээр нь идэвхтэй, идэвхгүй байдаг. Идэвхгүй шалгалт нь ямар нэгэн онцгой арга хэмжээ авахгүйгээр замын хөдөлгөөнд юу болж байгааг хянадаг. Энэ нь L4 дээр тийм ч сайн ажилладаггүй, учир нь энэ нь дээд түвшний протоколуудын логикоос шалтгаална: L4 дээр үйл ажиллагаа хэр удаан үргэлжилсэн, холболт сайн эсвэл муу байсан эсэх талаар мэдээлэл байхгүй. Идэвхтэй шалгалт нь тэнцвэржүүлэгчээс серверийн тохиолдол бүрт хүсэлт илгээхийг шаарддаг.
Ачаалал тэнцвэржүүлэгчдийн дийлэнх нь амьд байдлын шалгалтыг өөрсдөө хийдэг. Cloud дээр бид өргөтгөх чадварыг нэмэгдүүлэхийн тулд системийн эдгээр хэсгүүдийг салгахаар шийдсэн. Энэхүү арга нь эрүүл мэндийн үзлэгт хамрагдах хүсэлтийн тоог хадгалахын зэрэгцээ тэнцвэржүүлэгчдийн тоог нэмэгдүүлэх боломжийг бидэнд олгоно. Шалгалтыг бие даасан эрүүл мэндийн хяналтын цэгүүдээр гүйцэтгэдэг бөгөөд тэдгээрийн дундуур шалгах зорилтуудыг хуваах, хувилах болно. Та бүтэлгүйтэж болзошгүй тул нэг хостоос шалгалт хийх боломжгүй. Дараа нь бид түүний шалгасан тохиолдлын төлөвийг авахгүй. Бид дор хаяж гурван эрүүл мэндийн хяналтын цэгийн аль ч тохиолдлыг шалгадаг. Бид тогтмол хэш алгоритмыг ашиглан зангилаа хоорондын шалгалтын зорилгыг хуваана.
Тэнцвэр болон эрүүл мэндийн үзлэгийг салгах нь асуудалд хүргэж болзошгүй юм. Хэрэв эрүүл мэндийн хяналтын цэг нь тэнцвэржүүлэгчийг алгасаж (одоогоор замын хөдөлгөөнд үйлчилдэггүй) хүсэлт гаргавал хачирхалтай нөхцөл байдал үүснэ: нөөц амьд байгаа мэт боловч траффик түүнд хүрэхгүй. Бид энэ асуудлыг ингэж шийддэг: тэнцвэржүүлэгчээр дамжуулан эрүүл мэндийн үзлэгийг эхлүүлэх баталгаатай. Өөрөөр хэлбэл, үйлчлүүлэгчид болон эрүүл мэндийн үзлэгээс ирсэн траффик бүхий пакетуудыг шилжүүлэх схем нь хамгийн бага ялгаатай: хоёр тохиолдолд пакетууд тэнцвэржүүлэгчид хүрч, зорилтот эх үүсвэрт хүргэх болно.
Үүний ялгаа нь үйлчлүүлэгчид VIP-д хүсэлт гаргадаг бол эрүүл мэндийн хяналтынхан RIP бүрт хүсэлт гаргадаг. Энд нэг сонирхолтой асуудал гарч ирж байна: бид хэрэглэгчиддээ саарал IP сүлжээнд нөөц бий болгох боломжийг олгодог. Үйлчилгээгээ тэнцвэржүүлэгчийн ард нуусан хоёр өөр үүл эзэмшигч байна гэж төсөөлөөд үз дээ. Тэд тус бүр 10.0.0.1/24 дэд сүлжээнд ижил хаягтай нөөцтэй. Та тэдгээрийг ямар нэгэн байдлаар ялгах чадвартай байх ёстой бөгөөд энд Yandex.Cloud виртуал сүлжээний бүтцэд шумбах хэрэгтэй. Дэлгэрэнгүй мэдээллийг хэсгээс авах нь дээр , сүлжээ нь олон давхаргат бөгөөд дэд сүлжээний id-ээр ялгагдах туннелуудтай болсон нь одоо бидний хувьд чухал юм.
Эрүүл мэндийг шалгах цэгүүд нь бараг IPv6 хаягийг ашиглан тэнцвэржүүлэгчидтэй холбогдоно. Хаяг хаяг нь IPv6 хаягтай, хэрэглэгчийн дэд сүлжээний ID-тай IPv4 хаяг юм. Траффик тэнцвэржүүлэгчид хүрч, түүнээс IPv4 нөөцийн хаягийг гаргаж, IPv6-г IPv4-ээр сольж, пакетыг хэрэглэгчийн сүлжээнд илгээдэг.
Урвуу урсгал нь ижил аргаар явагддаг: тэнцвэржүүлэгч нь очих газар нь эрүүл мэндийн хяналтынхны саарал сүлжээ гэдгийг харж, IPv4-ийг IPv6 болгон хөрвүүлдэг.
VPP - өгөгдлийн онгоцны зүрх
Тэнцвэржүүлэгч нь Cisco-ийн сүлжээний траффикийг багцаар боловсруулахад зориулагдсан бүтэц болох Vector Packet Processing (VPP) технологийг ашиглан хэрэгждэг. Манай тохиолдолд уг хүрээ нь хэрэглэгчийн орон зайн сүлжээний төхөөрөмжийн удирдлагын номын сангийн дээд талд ажилладаг - Data Plane Development Kit (DPDK). Энэ нь пакет боловсруулах өндөр гүйцэтгэлийг баталгаажуулдаг: цөмд тасалдал бага тохиолддог ба цөмийн орон зай болон хэрэглэгчийн зай хооронд контекст шилжүүлэгч байхгүй.
VPP нь багцуудыг багц болгон нэгтгэснээр системээс илүү их гүйцэтгэлийг шахдаг. Гүйцэтгэлийн ашиг нь орчин үеийн процессорууд дээр кэшийг түрэмгий ашигласнаар ирдэг. Өгөгдлийн кэшийг хоёуланг нь ашигладаг (пакетуудыг "векторуудаар боловсруулдаг", өгөгдөл нь хоорондоо ойрхон байдаг) ба зааврын кэшүүд: VPP-д пакет боловсруулах нь графикийн дагуу хийгддэг бөгөөд зангилаанууд нь ижил үүрэг гүйцэтгэдэг функцуудыг агуулдаг.
Жишээлбэл, IP пакетуудыг VPP-д боловсруулах нь дараах дарааллаар явагдана: эхлээд пакетын толгойг задлан шинжлэх зангилаанд задлан шинжилж, дараа нь тэдгээрийг чиглүүлэлтийн хүснэгтийн дагуу пакетуудыг цааш дамжуулдаг зангилаа руу илгээдэг.
Бага зэрэг хатуу. VPP-ийн зохиогчид процессорын кэшийг ашиглахад буулт хийхийг тэвчдэггүй тул пакетуудын векторыг боловсруулах ердийн код нь гарын авлагын векторжуулалтыг агуулдаг: "бид дараалалд дөрвөн пакет байна" гэх мэт нөхцөл байдлыг боловсруулдаг боловсруулах давталт байдаг. дараа нь хоёрын хувьд адилхан, дараа нь - нэг нь. Урьдчилан авчрах зааврыг ихэвчлэн кэш рүү өгөгдөл ачаалахын тулд дараагийн давталтуудад хандах хандалтыг хурдасгахад ашигладаг.
n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
// ...
while (n_left_from >= 4 && n_left_to_next >= 2)
{
// processing multiple packets at once
u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
// ...
/* Prefetch next iteration. */
{
vlib_buffer_t *p2, *p3;
p2 = vlib_get_buffer (vm, from[2]);
p3 = vlib_get_buffer (vm, from[3]);
vlib_prefetch_buffer_header (p2, LOAD);
vlib_prefetch_buffer_header (p3, LOAD);
CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
}
// actually process data
/* verify speculative enqueues, maybe switch current next frame */
vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
to_next, n_left_to_next,
bi0, bi1, next0, next1);
}
while (n_left_from > 0 && n_left_to_next > 0)
{
// processing packets by one
}
// processed batch
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}Тиймээс Healthchecks нь IPv6-аар VPP-тэй ярилцдаг бөгөөд энэ нь тэднийг IPv4 болгон хувиргадаг. Үүнийг бид алгоритмын NAT гэж нэрлэдэг график дахь зангилаа хийдэг. Урвуу урсгалын хувьд (мөн IPv6-аас IPv4 рүү хөрвүүлэх) ижил алгоритмын NAT зангилаа байдаг.
Тэнцвэржүүлэгч үйлчлүүлэгчдийн шууд урсгал нь өөрөө тэнцвэржүүлэх ажлыг гүйцэтгэдэг графикийн зангилаануудаар дамждаг.
Эхний зангилаа нь наалттай сессүүд юм. Энэ нь хэшийг хадгалдаг тогтоосон хуралдааны хувьд. 5-tuple нь мэдээлэл дамжуулах үйлчлүүлэгчийн хаяг, порт, траффик хүлээн авах боломжтой нөөцийн хаяг, портууд, түүнчлэн сүлжээний протоколыг агуулдаг.
5-tuple хэш нь дараагийн тогтмол хэш зангилаанд бага тооцоолол хийхээс гадна тэнцвэржүүлэгчийн ард байгаа нөөцийн жагсаалтын өөрчлөлтийг илүү сайн зохицуулахад тусалдаг. Тэнцвэржүүлэгч дээр ямар ч сесс байхгүй пакет ирэхэд түүнийг тогтмол хэш зангилаа руу илгээдэг. Тогтмол хэшинг ашиглан тэнцвэржүүлэлт хийгдэх газар: бид "амьд" нөөцийн жагсаалтаас нөөцийг сонгоно. Дараа нь пакетуудыг NAT зангилаа руу илгээдэг бөгөөд энэ нь очих хаягийг орлуулж, шалгах дүнг дахин тооцоолдог. Таны харж байгаагаар бид VPP-ийн дүрмийг дагаж мөрддөг - дуртай байх, процессорын кэшийн үр ашгийг нэмэгдүүлэхийн тулд ижил төстэй тооцооллыг бүлэглэх.
Тогтмол хэш хийх
Бид яагаад үүнийг сонгосон бэ, энэ нь юу вэ? Нэгдүгээрт, өмнөх даалгаврыг авч үзье - жагсаалтаас нөөцийг сонгох.
Тогтворгүй хэштэй бол ирж буй пакетийн хэшийг тооцоолж, энэ хэшийг нөөцийн тоонд хуваах үлдэгдлээр жагсаалтаас нөөцийг сонгоно. Жагсаалт өөрчлөгдөөгүй хэвээр байгаа бол энэ схем сайн ажилладаг: бид үргэлж ижил 5-тай багцуудыг ижил жишээ рүү илгээдэг. Жишээлбэл, зарим эх сурвалж эрүүл мэндийн үзлэгт хариу өгөхөө больсон бол хэшийн нэлээд хэсэг нь сонголт өөрчлөгдөх болно. Үйлчлүүлэгчийн TCP холболтууд эвдэрнэ: өмнө нь А инстанцад хүрч байсан пакет нь энэ пакетийн сессийг сайн мэдэхгүй В инстанцад хүрч эхэлж болно.
Тогтмол хэш нь тайлбарласан асуудлыг шийддэг. Энэ ойлголтыг тайлбарлах хамгийн хялбар арга бол: танд нөөцийг хэшээр (жишээ нь, IP: портоор) түгээх бөгж байгаа гэж төсөөлөөд үз дээ. Нөөцийг сонгох нь дугуйг өнцгөөр эргүүлэх бөгөөд энэ нь багцын хэшээр тодорхойлогддог.
Энэ нь нөөцийн бүтэц өөрчлөгдөх үед хөдөлгөөний дахин хуваарилалтыг багасгадаг. Нөөцийг устгах нь зөвхөн нөөцийн байрлаж байсан тогтмол хэшлэх цагирагийн хэсэгт л нөлөөлнө. Нөөц нэмэх нь түгээлтийг өөрчилдөг боловч бидэнд наалттай сессийн зангилаа байгаа бөгөөд энэ нь аль хэдийн байгуулагдсан сессийг шинэ нөөц рүү шилжүүлэхгүй байх боломжийг олгодог.
Тэнцвэржүүлэгч ба нөөцийн хоорондох шууд урсгалд юу тохиолдохыг бид авч үзсэн. Одоо буцах замын хөдөлгөөнийг харцгаая. Энэ нь алгоритмын NAT, өөрөөр хэлбэл үйлчлүүлэгчийн урсгалд урвуу NAT 44, эрүүл мэндийн үзлэгийн урсгалын хувьд NAT 46-аар дамжуулан шалгах урсгалтай ижил хэв маягийг дагадаг. Бид өөрсдийн схемийг дагаж мөрддөг: бид эрүүл мэндийн үзлэгийн урсгал болон бодит хэрэглэгчийн урсгалыг нэгтгэдэг.
Loadbalancer-зангилаа ба угсарсан бүрэлдэхүүн хэсгүүд
VPP дахь тэнцвэржүүлэгч ба нөөцийн бүрэлдэхүүнийг орон нутгийн үйлчилгээ - ачааллын тэнцвэржүүлэгч-зангилаа мэдээлдэг. Энэ нь ачаалал тэнцвэржүүлэгч-хянагчаас үйл явдлын урсгалыг захиалж, одоогийн VPP төлөв болон хянагчаас хүлээн авсан зорилтот төлөвийн хоорондох ялгааг зурах боломжтой. Бид хаалттай системийг олж авдаг: API-ийн үйл явдлууд тэнцвэржүүлэгч хянагч руу ирдэг бөгөөд энэ нь нөөцийн "амьдрал" -ыг шалгахын тулд эрүүл мэндийн хяналтын хянагчдад даалгавар өгдөг. Энэ нь эргээд эрүүл мэндийн хяналтын цэгт даалгавар өгч, үр дүнг нэгтгэсний дараа тэнцвэржүүлэгч хянагч руу буцааж илгээдэг. Loadbalancer-node нь хянагчаас үйл явдалд бүртгүүлж, VPP-ийн төлөвийг өөрчилдөг. Ийм системд үйлчилгээ бүр хөрш зэргэлдээх үйлчилгээний талаар юу шаардлагатайг л мэддэг. Холболтын тоо хязгаарлагдмал бөгөөд бид өөр өөр сегментүүдийг бие даан ажиллуулах, масштаблах чадвартай.
Ямар асуудлаас зайлсхийсэн бэ?
Хяналтын хавтгай дахь манай бүх үйлчилгээнүүд Go-д бичигдсэн бөгөөд сайн масштабтай, найдвартай шинж чанартай байдаг. Go нь хуваарилагдсан системийг бий болгох олон нээлттэй эхийн номын сантай. Бид GRPC-ийг идэвхтэй ашигладаг, бүх бүрэлдэхүүн хэсэг нь үйлчилгээний нээлтийн нээлттэй эх сурвалжийг агуулдаг - манай үйлчилгээнүүд бие биенийхээ гүйцэтгэлийг хянаж, найрлагыг нь динамикаар өөрчилж чаддаг бөгөөд үүнийг GRPC тэнцвэржүүлэхтэй холбосон. Хэмжилтийн хувьд бид мөн нээлттэй эхийн шийдлийг ашигладаг. Мэдээллийн хавтгайд бид зохих гүйцэтгэлтэй, их хэмжээний нөөцтэй болсон: төмөр сүлжээний карт гэхээсээ илүү VPP-ийн гүйцэтгэлд найдах тавцан угсрах нь маш хэцүү болсон.
Асуудлууд ба шийдлүүд
Юу нь тийм сайн ажиллаагүй юм бэ? Go нь санах ойн автомат удирдлагатай боловч санах ой алдагдсан хэвээр байна. Тэдэнтэй харьцах хамгийн хялбар арга бол goroutines ажиллуулж, тэдгээрийг зогсоохоо санах явдал юм. Takeaway: Go програмынхаа санах ойн хэрэглээг ажиглаарай. Ихэнхдээ сайн үзүүлэлт бол горутинуудын тоо юм. Энэ түүхэнд нэг давуу тал бий: Go програмаас санах ойн зарцуулалт, ажиллаж байгаа goroutines болон бусад олон параметрүүдийг багтаасан ажиллах үеийн өгөгдлийг олж авахад хялбар байдаг.
Мөн Go нь функциональ тест хийхэд хамгийн сайн сонголт биш байж магадгүй юм. Тэдгээр нь нэлээд дэлгэрэнгүй бөгөөд "CI доторх бүх зүйлийг багцаар ажиллуулах" стандарт арга нь тэдэнд тийм ч тохиромжтой биш юм. Үнэн хэрэгтээ функциональ тестүүд нь илүү их нөөц шаарддаг бөгөөд бодит хугацаа хэтрүүлдэг. Үүнээс болж CPU нь нэгжийн туршилтаар завгүй байгаа тул туршилт амжилтгүй болж магадгүй юм. Дүгнэлт: Боломжтой бол "хүнд" туршилтыг нэгжийн туршилтаас тусад нь хийнэ.
Микросервисийн үйл явдлын архитектур нь цул бүтэцтэй харьцуулахад илүү төвөгтэй байдаг: олон арван өөр машин дээр лог цуглуулах нь тийм ч тохиромжтой биш юм. Дүгнэлт: Хэрэв та бичил үйлчилгээ хийвэл мөшгих талаар нэн даруй бодоорой.
Бидний төлөвлөгөө
Бид дотоод тэнцвэржүүлэгч, IPv6 тэнцвэржүүлэгчийг ажиллуулж, Kubernetes скриптүүдийн дэмжлэгийг нэмж, үйлчилгээгээ үргэлжлүүлэн хуваах болно (одоогоор зөвхөн healthcheck-node болон healthcheck-ctrl-г хуваах боломжтой), шинэ эрүүл мэндийн шалгалтыг нэмж, мөн шалгалтын ухаалаг нэгтгэлийг хэрэгжүүлэх болно. Бид үйлчилгээгээ бие биентэйгээ шууд бус, харин мессежийн дарааллаар харилцдаг байхын тулд илүү бие даасан болгох боломжийг судалж байна. Саяхан Cloud дээр SQS-тэй нийцтэй үйлчилгээ гарч ирэв .
Саяхан Yandex Load Balancer-ийг олон нийтэд танилцууллаа. Судлах Үйлчилгээнд зориулж тэнцвэржүүлэгчийг өөрт тохирсон байдлаар удирдаж, төслүүдийнхээ алдааг тэсвэрлэх чадварыг нэмэгдүүлээрэй!
Эх сурвалж: www.habr.com