Превод на статията: Модел на нишки на Envoy - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

Намерих тази статия за доста интересна и тъй като Envoy най-често се използва като част от „istio“ или просто като „входен контролер“ на kubernetes, повечето хора нямат същото пряко взаимодействие с него, както например с типичните Инсталации на Nginx или Haproxy. Въпреки това, ако нещо се счупи, би било добре да разберете как работи отвътре. Опитах се да преведа възможно най-голяма част от текста на руски език, включително специални думи; за тези, които смятат, че е болезнено да гледат това, оставих оригиналите в скоби. Добре дошли в котка.

Техническата документация на ниско ниво за кодовата база на Envoy в момента е доста оскъдна. За да поправя това, планирам да направя поредица от публикации в блогове за различните подсистеми на Envoy. Тъй като това е първата статия, моля, кажете ми какво мислите и какво може да ви интересува в бъдещи статии.

Един от най-често срещаните технически въпроси, които получавам относно Envoy, е да поискам описание на ниско ниво на модела на нишки, който използва. В тази публикация ще опиша как Envoy картографира връзките към нишките, както и системата Thread Local Storage, която използва вътрешно, за да направи кода по-паралелен и по-високопроизводителен.

Преглед на нишките

Envoy използва три различни типа потоци:

• Основен: Тази нишка контролира стартирането и прекратяването на процеса, цялата обработка на API на XDS (xDiscovery Service), включително DNS, проверка на изправността, общо управление на клъстера и времето за изпълнение, нулиране на статистиката, администриране и общо управление на процеси - сигнали на Linux, горещ рестарт и т.н. се случва в тази нишка е асинхронно и "неблокиращо". Като цяло основната нишка координира всички процеси с критична функционалност, които не изискват голямо количество CPU за изпълнение. Това позволява повечето контролен код да бъде написан така, сякаш е еднонишков.
• работник: По подразбиране Envoy създава работна нишка за всяка хардуерна нишка в системата, това може да се контролира чрез опцията --concurrency. Всяка работна нишка изпълнява „неблокиращ“ цикъл на събития, който отговаря за прослушването на всеки слушател; към момента на писане (29 юли 2017 г.) няма шардинг на слушателя, приемане на нови връзки, инстанциране на филтърен стек за връзката и обработка на всички входно/изходни (IO) операции по време на живота на връзката. Отново, това позволява повечето кодове за обработка на връзката да бъдат написани, сякаш са еднонишкови.
• Промиване на файлове: Всеки файл, който Envoy записва, главно регистрационни файлове за достъп, в момента има независима блокираща нишка. Това се дължи на факта, че записът във файлове, кеширани от файловата система, дори когато се използва O_NONBLOCK понякога може да се блокира (въздишка). Когато работните нишки трябва да пишат във файл, данните всъщност се преместват в буфер в паметта, където в крайна сметка се изчистват през нишката файл флъш. Това е една област от код, където технически всички работни нишки могат да блокират едно и също заключване, докато се опитват да запълнят буфер на паметта.

Обработка на връзката

Както беше обсъдено накратко по-горе, всички работни нишки слушат всички слушатели без никакво шардинг. По този начин ядрото се използва за елегантно изпращане на приети сокети към работни нишки. Съвременните ядра като цяло са много добри в това, те използват функции като повишаване на приоритета на вход/изход (IO), за да се опитат да запълнят дадена нишка с работа, преди да започнат да използват други нишки, които също слушат на същия сокет, и също така не използват кръгов режим заключване (Spinlock) за обработка на всяка заявка.
След като връзката бъде приета в работна нишка, тя никога не напуска тази нишка. Цялата по-нататъшна обработка на връзката се обработва изцяло в работната нишка, включително всяко поведение при пренасочване.

Това има няколко важни последици:

• Всички пулове за връзки в Envoy са присвоени на работна нишка. Така че, въпреки че пуловете за HTTP/2 връзки правят само една връзка към всеки хост нагоре по веригата наведнъж, ако има четири работни нишки, ще има четири HTTP/2 връзки на хост нагоре по веригата в стабилно състояние.
• Причината Envoy да работи по този начин е, че като държи всичко в една работна нишка, почти целият код може да бъде написан без блокиране и сякаш е еднонишков. Този дизайн улеснява писането на много код и се мащабира невероятно добре до почти неограничен брой работни нишки.
• Един от основните изводи обаче е, че от гледна точка на пул памет и ефективност на връзката, всъщност е много важно да конфигурирате --concurrency. Наличието на повече работни нишки от необходимото ще изразходва памет, ще създаде повече неактивни връзки и ще намали скоростта на групиране на връзки. В Lyft нашите пратени контейнери с кош работят с много ниска едновременност, така че производителността приблизително съответства на услугите, до които се намират. Изпълняваме Envoy като крайно прокси само при максимална едновременност.

Какво означава неблокиране?

Терминът "неблокиращ" е използван няколко пъти досега, когато се обсъжда как работят основните и работните нишки. Целият код е написан при предположението, че нищо никога не е блокирано. Това обаче не е съвсем вярно (кое не е съвсем вярно?).

Envoy използва няколко дълги заключвания на процеси:

• Както беше обсъдено, когато записвате регистрационни файлове за достъп, всички работни нишки придобиват една и съща ключалка, преди буферът на регистрационния файл в паметта да бъде запълнен. Времето за задържане на заключването трябва да е много малко, но е възможно заключването да бъде оспорено при висока едновременност и висока пропускателна способност.
• Envoy използва много сложна система за обработка на статистики, които са локални за нишката. Това ще е тема на отделна публикация. Все пак ще спомена накратко, че като част от локалната обработка на статистиката на нишката, понякога е необходимо да се получи заключване на централен „хранилище за статистика“. Това заключване никога не трябва да се изисква.
• Основната нишка периодично трябва да се координира с всички работни нишки. Това се прави чрез „публикуване“ от основната нишка към работните нишки, а понякога и от работните нишки обратно към основната нишка. Изпращането изисква заключване, така че публикуваното съобщение да може да бъде в опашка за по-късна доставка. Тези ключалки никога не трябва да бъдат сериозно оспорвани, но въпреки това технически могат да бъдат блокирани.
• Когато Envoy запише журнал в потока от системни грешки (стандартна грешка), той получава заключване на целия процес. Като цяло локалното регистриране на Envoy се счита за ужасно от гледна точка на производителността, така че не е обърнато много внимание на подобряването му.
• Има няколко други произволни заключвания, но нито едно от тях не е критично за производителността и никога не трябва да се оспорва.

Локално съхранение на нишки

Поради начина, по който Envoy разделя отговорностите на главната нишка от отговорностите на работната нишка, има изискване сложната обработка да може да се извърши на главната нишка и след това да се предостави на всяка работна нишка по силно паралелен начин. Този раздел описва Envoy Thread Local Storage (TLS) на високо ниво. В следващия раздел ще опиша как се използва за управление на клъстер.


Както вече беше описано, главната нишка обработва практически цялата функционалност на равнината на управление и контрол в процеса Envoy. Контролната равнина тук е малко претоварена, но когато я погледнете в рамките на самия процес Envoy и я сравните с пренасочването, което правят работните нишки, има смисъл. Общото правило е, че процесът на основната нишка върши известна работа и след това трябва да актуализира всяка работна нишка според резултата от тази работа. в този случай работната нишка не трябва да придобива заключване при всеки достъп.

Системата TLS (локално съхранение на нишки) на Envoy работи по следния начин:

• Кодът, изпълняван в основната нишка, може да разпредели TLS слот за целия процес. Въпреки че това е абстрахирано, на практика това е индекс във вектор, осигуряващ O(1) достъп.
• Основната нишка може да инсталира произволни данни в своя слот. Когато това стане, данните се публикуват във всяка работна нишка като нормално събитие за цикъл на събития.
• Работните нишки могат да четат от своя TLS слот и да извличат всички локални за нишката данни, налични там.

Въпреки че е много проста и невероятно мощна парадигма, тя е много подобна на концепцията за блокиране на RCU (четене-копиране-актуализация). По същество работните нишки никога не виждат промени в данните в TLS слотовете, докато работата работи. Промяната настъпва само през периода на почивка между работните събития.

Envoy използва това по два различни начина:

• Чрез съхраняване на различни данни във всяка работна нишка, данните могат да бъдат достъпни без никакво блокиране.
• Чрез поддържане на споделен указател към глобални данни в режим само за четене на всяка работна нишка. По този начин всяка работна нишка има брой референтни данни, който не може да бъде намален, докато работата се изпълнява. Само когато всички работници се успокоят и качат нови споделени данни, старите данни ще бъдат унищожени. Това е идентично с RCU.

Нишки за актуализиране на клъстер

В този раздел ще опиша как TLS (локално хранилище на нишки) се използва за управление на клъстер. Управлението на клъстери включва xDS API и/или DNS обработка, както и проверка на здравето.


Управлението на клъстерния поток включва следните компоненти и стъпки:

1. Мениджърът на клъстери е компонент в рамките на Envoy, който управлява всички известни клъстери нагоре по веригата, API на услугата за откриване на клъстер (CDS), API на услугата за тайно откриване (SDS) и услугата за откриване на крайна точка (EDS), DNS и активни външни проверки. Той е отговорен за създаването на „евентуално последователен“ изглед на всеки възходящ клъстер, който включва открити хостове, както и здравословно състояние.
2. Проверката на изправността извършва активна проверка на изправността и докладва промените в изправното състояние на мениджъра на клъстера.
3. CDS (услуга за откриване на клъстери) / SDS (услуга за тайно откриване) / EDS (услуга за откриване на крайни точки) / DNS се извършват, за да се определи членството в клъстер. Промяната на състоянието се връща на мениджъра на клъстера.
4. Всяка работна нишка непрекъснато изпълнява цикъл на събитие.
5. Когато мениджърът на клъстера определи, че състоянието на клъстера се е променило, той създава нова моментна снимка само за четене на състоянието на клъстера и я изпраща на всяка работна нишка.
6. По време на следващия тих период работната нишка ще актуализира моментната снимка в разпределения TLS слот.
7. По време на I/O събитие, което трябва да определи хоста за балансиране на натоварването, инструментът за балансиране на натоварването ще поиска TLS (локално съхранение на нишки) слот, за да получи информация за хоста. Това не изисква ключалки. Имайте предвид също, че TLS може също да задейства събития за актуализиране, така че балансьорите на натоварването и други компоненти да могат да преизчислят кешове, структури от данни и т.н. Това е извън обхвата на тази публикация, но се използва на различни места в кода.

Използвайки горната процедура, Envoy може да обработва всяка заявка без никакво блокиране (освен както е описано по-горе). Освен сложността на самия TLS код, по-голямата част от кода не трябва да разбира как работи многонишковостта и може да бъде написана еднопоточно. Това прави по-голямата част от кода по-лесен за писане в допълнение към превъзходната производителност.

Други подсистеми, които използват TLS

TLS (Thread local storage) и RCU (Read Copy Update) се използват широко в Envoy.

Примери за използване:

• Механизъм за промяна на функционалността по време на изпълнение: Текущият списък с активирана функционалност се изчислява в главната нишка. След това на всяка работна нишка се дава моментна снимка само за четене, използвайки RCU семантика.
• Подмяна на маршрутни таблици: За таблици с маршрути, предоставени от RDS (Route Discovery Service), таблиците с маршрути се създават в главната нишка. Моментната снимка само за четене впоследствие ще бъде предоставена на всяка работна нишка с помощта на RCU (Read Copy Update) семантика. Това прави промяната на маршрутните таблици атомарно ефективна.
• Кеширане на HTTP заглавки: Както се оказа, изчисляването на HTTP заглавката за всяка заявка (докато се изпълнява ~25K+ RPS на ядро) е доста скъпо. Envoy изчислява централно заглавката приблизително на всеки половин секунда и я предоставя на всеки работник чрез TLS и RCU.

Има и други случаи, но предишните примери трябва да предоставят добро разбиране за какво се използва TLS.

Известни капани в производителността

Докато Envoy се представя доста добре като цяло, има няколко забележителни области, които изискват внимание, когато се използва с много висока едновременност и пропускателна способност:

• Както е описано в тази статия, понастоящем всички работни нишки придобиват заключване при запис в буфера на паметта на журнала за достъп. При висока едновременност и висока пропускателна способност ще трябва да групирате регистрационните файлове за достъп за всяка работна нишка за сметка на доставката извън реда при запис в крайния файл. Като алтернатива можете да създадете отделен журнал за достъп за всяка работна нишка.
• Въпреки че статистиката е силно оптимизирана, при много висока едновременност и пропускателна способност вероятно ще има атомарно съревнование за отделни статистики. Решението на този проблем е броячи на работна нишка с периодично нулиране на централните броячи. Това ще бъде обсъдено в следваща публикация.
• Текущата архитектура няма да работи добре, ако Envoy се внедри в сценарий, при който има много малко връзки, които изискват значителни ресурси за обработка. Няма гаранция, че връзките ще бъдат равномерно разпределени между работните нишки. Това може да бъде решено чрез прилагане на балансиране на работни връзки, което ще позволи обмен на връзки между работни нишки.

Заключение

Моделът за нишки на Envoy е проектиран да осигурява лекота на програмиране и масивен паралелизъм за сметка на потенциално разточителна памет и връзки, ако не е конфигуриран правилно. Този модел му позволява да работи много добре при много голям брой нишки и производителност.
Както споменах накратко в Twitter, дизайнът може също така да работи върху пълен мрежов стек в потребителски режим, като DPDK (Data Plane Development Kit), което може да доведе до конвенционални сървъри, обработващи милиони заявки в секунда с пълна L7 обработка. Ще бъде много интересно да видим какво ще бъде изградено през следващите няколко години.
Един последен бърз коментар: много пъти са ме питали защо избрахме C++ за Envoy. Причината остава, че той все още е единственият широко използван индустриален език, на който може да бъде изградена архитектурата, описана в тази публикация. C++ определено не е подходящ за всички или дори за много проекти, но за определени случаи на употреба той все още е единственият инструмент за свършване на работата.

Връзки към код

Връзки към файлове с интерфейси и реализации на заглавки, обсъдени в тази публикация:

• github.com/lyft/envoy/blob/master/include/envoy/thread_local/thread_local.h
• github.com/lyft/envoy/blob/master/source/common/thread_local/thread_local_impl.h
• github.com/lyft/envoy/blob/master/include/envoy/upstream/cluster_manager.h
• github.com/lyft/envoy/blob/master/source/common/upstream/cluster_manager_impl.h

Източник: www.habr.com