Забележка. превод: Авторът на тази статия (Luc Perkins) е защитник на разработчиците в организацията CNCF, която е дом на проекти с отворен код като Linkerd, SMI (Service Mesh Interface) и Kuma (между другото, чудили ли сте се защо Istio е не е в този списък? .). Още веднъж опитвайки се да донесе на DevOps общността по-добро разбиране на модерния шум, наречен „сервизна мрежа“, той изброява 16 характерни възможности, които подобни решения предоставят.
Днес ― една от най-горещите теми в областта на софтуерното инженерство (и с право!). Мисля, че тази технология е невероятно обещаваща и бих искал да я видя широко разпространена (когато има смисъл, разбира се). Въпреки това, той все още е заобиколен от аура на мистерия за повечето хора. В същото време дори тези, които всеизвестен с него често е трудно да се формулират предимствата му и какви точно са (включително вашите наистина). В тази статия ще се опитам да коригирам ситуацията, като изброя различни случаи на употреба "сервизни мрежи"*.
* Забележка прев.: тук и по-нататък в статията точно този превод („сервизна мрежа”) ще се използва за все още новия термин сервизна мрежа.
Но първо искам да направя няколко коментара:
- Никога не съм работил със сервизни мрежи или съм ги използвал извън проекти, започнати за собственото ми образование. От друга страна, аз бях този, който написа куп документация за вътрешния сервизен меш на Twitter през 2015 г. (тогава дори не се наричаше „сервизен меш“) и участвах в разработването на уебсайта и документацията за , така че това означава нещо.
- Моят списък е приблизителен и непълен. Възможно е да има непознати за мен случаи на употреба и вероятно ще се появят нови опции с течение на времето, когато технологията се развива и нейната популярност нараства.
- В същото време не всяка съществуваща реализация на мрежова услуга поддържа всички изброени случаи на употреба. Следователно, моите твърдения като „мрежата на услугата може...“ трябва да се чете като „индивидуални и може би всички популярни реализации на мрежа на услугата могат...“.
- Редът на примерите не прави разлика.
Кратък списък:
- откриване на услуги;
- криптиране;
- удостоверяване и оторизация;
- балансиране на натоварването;
- прекъсване на веригата;
- автоматично мащабиране;
- разгръщания на канарчета;
- синьо-зелени разгръщания;
- Преглед на здравето;
- намаляване на натоварването;
- отразяване на трафика;
- изолация;
- ограничаване на скоростта на заявка, повторни опити и изчакване;
- телеметрия;
- одит;
- визуализация.
1. Откриване на услуга
TL;DR: Свържете се с други услуги в мрежата, като използвате прости имена.
Услугите трябва да могат автоматично да се „намират“ една друга, използвайки подходящи имена - например, service.api.production, pets/staging или cassandra. Облачните среди са еластични и едно име може да скрие много екземпляри на услуга. Ясно е, че в такава ситуация е физически невъзможно да се кодират всички IP адреси.
Плюс това, когато една услуга намери друга, тя трябва да може да изпраща заявки до тази услуга, без да се страхува, че те ще се окажат на входа на нейната повредена инстанция. С други думи, сервизната мрежа трябва да следи изправността на всички екземпляри на услугата и да поддържа списъка с хостове възможно най-актуален.
Всяка сервизна мрежа прилага механизма за откриване на услуга по различен начин. В момента най-често срещаният начин е делегирането на външни процеси като Kubernetes DNS. В миналото в Twitter използвахме система за именуване за тази цел . В допълнение, мрежовата технология на услугата прави възможно появата на персонализирани механизми за именуване (въпреки че все още не съм виждал никаква SM реализация с такава функционалност).
2. Криптиране
TL;DR: Отървете се от некриптирания трафик между услугите и направете този процес автоматизиран и мащабируем.
Хубаво е да знаете, че нападателите не могат да проникнат във вашата вътрешна мрежа. Защитните стени вършат чудесна работа за това. Но какво ще стане, ако хакер влезе вътре? Ще може ли да прави каквото си иска с вътрешносервизния трафик? Да се надяваме, че това все пак няма да се случи. За да предотвратите този сценарий, трябва да внедрите мрежа с нулево доверие, в която целият трафик между услугите е криптиран. Повечето съвременни сервизни мрежи постигат това чрез взаимно (взаимен TLS, mTLS). В някои случаи mTLS работи в цели облаци и клъстери (мисля, че междупланетните комуникации някой ден ще бъдат подредени по подобен начин).
Разбира се, за mTLS мрежова мрежа по желание. Всяка услуга може да се грижи за собствения си TLS, но това означава, че ще трябва да намерите начин да генерирате сертификати, да ги разпространявате между хостове на услуги и да включите код в приложението, което ще зарежда тези сертификати от файлове. Да, не забравяйте да подновявате тези сертификати на редовни интервали. Сервизните мрежи автоматизират mTLS със системи като , които от своя страна автоматизират процеса на издаване и ротация на сертификати.
3. Удостоверяване и оторизация
TL;DR: Установете кой е подателят на заявката и определете какво му е позволено да прави, преди заявката дори да достигне до услугата.
Службите често искат да знаят който изпълнява заявката (удостоверяване) и използвайки тази информация, решава че дадено лице има право да прави (упълномощаване). В този случай местоимението „кой“ може да скрие:
- Други услуги. Това се нарича "удостоверяване" връстник" Например обслужване
webиска достъп до услугатаdb. Сервизните мрежи обикновено решават такива проблеми с помощта на mTLS: сертификатите в този случай действат като необходимия идентификатор. - Някои човешки потребители. Това се нарича "удостоверяване" заявка" Например потребител
haxor69иска да си купи нова лампа. Сервизните мрежи осигуряват различни механизми, напр. .Много от нас са направили това в кода на приложението. Влиза заявка, разглеждаме масата
users, намерете потребителя и сравнете паролата, след което проверете колонатаpermissionsи т.н. В случай на мрежова мрежа за услуга, това се случва преди заявката дори да достигне услугата.
След като установим от кого идва заявката, трябва да определим какво има право да прави този субект. Някои сервизни мрежи ви позволяват да задавате основни политики (за това кой какво може да прави) като YAML файлове или на командния ред, докато други предлагат интеграция с рамки като . Крайната цел е вашите услуги да приемат всяка заявка, при условие че идва от доверен източник и това действие е разрешено.
4. Балансиране на натоварването
TL; DR: Разпределете натоварването между екземпляри на услуга според конкретен модел.
„Услуга“ в рамките на секция за услуги много често се състои от много идентични екземпляри. Например днес услугата cache се състои от 5 екземпляра, като утре броят им може да нарасне до 11. Заявките са изпратени на cache, трябва да се разпределят в съответствие с конкретна цел. Например минимизирайте забавянето или увеличете максимално вероятността да стигнете до работещ екземпляр. Най-често използваният алгоритъм е Round-robin, но има и много други - например претегленият метод (претеглено) заявки (можете да изберете предпочитани цели), звън (пръстен) хеширане (използване на последователно хеширане в хостове нагоре) или метод на най-малко заявки (предпочитание се дава на екземпляра с най-малко заявки).
Класическите балансьори имат други функции, като например HTTP кеширане и DDoS защита, но те не са много подходящи за трафик изток-запад (т.е. за трафик, протичащ в рамките на център за данни - прибл. превод) (типичен обхват на мрежата на услугата). Разбира се, не е необходимо да използвате мрежова мрежа за услуга за балансиране на натоварването, но ви позволява да задавате и контролирате политики за балансиране за всяка услуга от централизиран контролен слой, като по този начин елиминирате необходимостта от стартиране и конфигуриране на отделни балансьори на натоварване в стека на мрежата .
5. Прекъсване на веригата
TL;DR: Спрете трафика към проблемната услуга и контролирайте щетите в най-лошия случай.
Ако по някаква причина услугата не може да се справи с трафика, сервизната мрежа предоставя няколко опции за решаване на този проблем (други ще бъдат обсъдени в съответните раздели). Прекъсването на веригата е най-тежкият вариант за изключване на услуга от трафика. Само по себе си обаче няма смисъл - необходим е резервен план. Може да се осигури обратно налягане () към услуги, които отправят заявки (само не забравяйте да конфигурирате мрежата на вашата услуга за това!), или, например, оцветяване на страницата със състоянието в червено и пренасочване на потребителите към друга версия на страницата с „падащ кит“ („Twitter е надолу”).
Сервизните мрежи не само ви позволяват да дефинирате кога ще последва изключване и че това ще последва. В този случай „кога“ може да включва произволна комбинация от определени параметри: общия брой заявки за определен период, броя на паралелните връзки, чакащи заявки, активни повторни опити и др.
Вероятно не искате да злоупотребявате с прекъсване на веригата, но е хубаво да знаете, че имате резервен план в случай на авария.
6. Автоматично мащабиране
TL;DR: Увеличете или намалете броя на екземплярите на услугата в зависимост от посочените критерии.
Сервизните мрежи не са програмисти за планиране, така че не са изпълняват мащабиране на себе си. Въпреки това, те могат да предоставят информация за това кои плановици ще базират своите решения. Тъй като мрежите на услугите имат достъп до целия трафик между услугите, те имат обширна информация за това какво се случва: кои услуги изпитват проблеми, кои услуги са много слабо натоварени (капацитетът, разпределен за тях, се губи) и т.н.
Например, Kubernetes мащабира услугите въз основа на използването на процесора и паметта на подовете (вижте нашия доклад "“- прибл. превод), но ако решите да мащабирате въз основа на друг показател (в нашия случай свързан с трафика), ще ви трябва специален показател. Управление показва как да направите това с , и , но самият процес е доста сложен. Бихме искали мрежата на услугата да опрости това, като ни позволи просто да зададем условия като „увеличете броя на екземплярите на услугата auth, ако броят на чакащите заявки надвиши прага в рамките на минута."
7. Канарски внедрявания
TL;DR: Тествайте нови функции или версии на услуги върху подгрупа от потребители.
Да приемем, че разработвате SaaS продукт и възнамерявате да пуснете страхотна нова негова версия. Тествахте го в постановката и се получи страхотно. Но все още има известни опасения относно поведението й в реални условия. С други думи, трябва да тествате новата версия върху реални проблеми, без да рискувате доверието на потребителите. Внедряването на Canary е чудесно за това. Те ви позволяват да демонстрирате нова функция на подгрупа потребители. Тази подгрупа може да се състои от най-лоялните потребители или тези, които работят с безплатната версия на продукта, или потребители, които са изразили желание да бъдат „опитни зайчета“.
Мрежите на услугите реализират това, като ви позволяват да посочите критерии, които определят кой ще види коя версия на приложението и съответно да насочват трафика. За самите услуги обаче нищо не се променя. Версия 1.0 на услугата вярва, че всички заявки идват от потребители, които трябва да я видят, а версия 1.1 вярва в същото за своите потребители. Междувременно можете да промените процента на трафик между старата и новата версия, пренасочвайки нарастващ брой потребители към новата, ако тя работи стабилно и вашите „морски свинчета“ дават зелена светлина.
8. Синьо-зелени внедрявания
TL;DR: Пуснете страхотна нова функция, но бъдете готови веднага да върнете всичко обратно.
значение е да пусне нова „синя“ услуга, пускайки я успоредно със старата „зелена“. Ако всичко върви гладко и новата услуга работи добре, тогава старата може постепенно да бъде деактивирана. (Уви, някой ден тази нова „синя“ услуга ще повтори съдбата на „зелената“ и ще изчезне...) Синьо-зелените внедрявания се различават от канарските по това, че новата функция покрива всички наведнъж потребители (не част); Въпросът тук е да имате готово „безопасно пристанище“, в случай че нещо се обърка.
Сервизните мрежи предлагат много удобен начин за тестване на „синя“ услуга и незабавно превключване към работеща „зелена“ услуга в случай на проблеми. Да не говорим за факта, че по пътя те предоставят много информация (вижте „Телеметрия“ по-долу) за работата на „сините“, което помага да се разбере дали е готово за пълна работа.
Забележка. превод: Можете да прочетете повече за различни стратегии за внедряване в Kubernetes (включително споменатите канарче, синьо/зелено и други) в .
9. Здравна проверка
TL;DR: Проследявайте кои екземпляри на услугата са функционални и отговаряйте на тези, които вече не функционират.
Преглед на здравето (Преглед на здравето) помага да се реши дали екземплярите на услугата са готови да приемат и обработват трафик. Например, в случай на HTTP услуги, проверката на състоянието може да изглежда като GET заявка към крайната точка /health... Отговор 200 OK ще означава, че екземплярът е здрав, всеки друг - че не е готов да получава трафик. Сервизните мрежи ви позволяват да посочите както начина, по който ще се проверява функционалността, така и честотата, с която ще се извършва тази проверка. След това тази информация може да се използва за други цели - например за балансиране на натоварването и прекъсване на веригата.
По този начин проверката на здравето не е самостоятелен случай на употреба, а обикновено се използва за постигане на други цели. Също така, в зависимост от резултатите от проверките на изправността, може да са необходими действия, външни за други цели на мрежата на услугата: например актуализиране на страницата за състояние, създаване на проблем в GitHub или попълване на билет за JIRA. А service mesh предлага удобен механизъм за автоматизиране на всичко това.
10. Намаляване на натоварването
TL;DR: Пренасочване на трафика в отговор на временен пик в използването.
Ако дадена услуга е претоварена с трафик, можете временно да пренасочите част от този трафик към друго място (т.е. „изхвърляне“, „прехвърляне“ (навес) него там). Например към резервна услуга или център за данни, или към постоянен тема. В резултат на това услугата ще продължи да обработва някои заявки, вместо да се срине и да спре да обработва всичко напълно. Премахването на натоварването е за предпочитане пред прекъсването на веригата, но все пак не е препоръчително да се злоупотребява с него. Той помага за предотвратяване на каскадни повреди, които причиняват срив на услуги надолу по веригата.
11. Паралелизиране/отразяване на трафика
TL;DR: Изпратете една заявка до няколко места едновременно.
Понякога има нужда да изпратите заявка (или определена селекция от заявки) до няколко услуги наведнъж. Типичен пример е изпращането на част от производствения трафик към промеждутъчна услуга. Основният производствен уеб сървър изпраща заявка до услугата надолу по веригата products.production и само на него. И сервизната мрежа интелигентно копира тази заявка и я изпраща до products.staging, за което уеб сървърът дори не знае.
Друг свързан случай на използване на мрежова мрежа на услугата, който може да бъде приложен върху паралелизиране на трафика, е . Това включва изпращане на едни и същи заявки до различни версии на услугата и проверка дали всички версии се държат еднакво. Все още не съм срещал реализация на мрежова услуга с интегрирана система за регресионно тестване като , но самата идея изглежда обещаваща.
12. Изолация
TL;DR: Разбийте мрежата на услугите си на мини-мрежи.
Също известен като сегментиранеИзолацията е изкуството да се раздели сервизна мрежа на логически отделни сегменти, които не знаят нищо един за друг. Изолацията е малко като създаване на виртуални частни мрежи. Фундаменталната разлика е, че все още можете да се насладите на всички предимства на мрежата на услугата (като откриване на услуга), но с допълнителна сигурност. Например, ако нападател успее да проникне в услуга в една подмрежа, той няма да може да види какви услуги се изпълняват в други подмрежи или да прихване техния трафик.
Освен това ползите могат да бъдат и организационни. Може да искате да подмрежите услугите си въз основа на структурата на вашата компания и да освободите разработчиците от когнитивното натоварване от необходимостта да имат предвид цялата мрежа на услугата.
13. Ограничаване на скоростта на заявка, повторни опити и изчакване
TL;DR: Вече не е необходимо да включвате дребните задачи за управление на заявки във вашата кодова база.
Всички тези неща могат да се считат за отделни случаи на употреба, но реших да ги комбинирам поради една обща характеристика: те поемат задачите за управление на жизнения цикъл на заявката, които обикновено се обработват от библиотеките на приложенията. Ако разработвате уеб сървър в Ruby on Rails (не е интегриран със сервизна мрежа), който прави заявки към бекенд услуги чрез , приложението ще трябва да реши какво да прави, ако N заявки са неуспешни. Вие също ще трябва да разберете колко трафик тези услуги ще могат да обработват и твърдо да кодират тези параметри с помощта на специална библиотека. Освен това приложението ще трябва да реши кога е време да се откаже и да остави заявката да изчезне (въз основа на времето за изчакване). И за да промените някой от горните параметри, уеб сървърът ще трябва да бъде спрян, преконфигуриран и стартиран отново.
Прехвърлянето на тези задачи към сервизна мрежа не само означава, че разработчиците на услуги няма да трябва да мислят за тях, но и че те могат да бъдат разглеждани по по-глобален начин. Ако се използва сложна верига от услуги, да речем A -> B -> C -> D -> E, трябва да се вземе предвид целият жизнен цикъл на заявката. Ако задачата е да се удължат изчакванията в услуга C, логично е това да се направи наведнъж, а не на части: чрез актуализиране на кода на услугата и изчакване, докато заявката за изтегляне бъде приета и CI системата внедри актуализираната услуга.
14. Телеметрия
TL;DR: Съберете цялата необходима (и не съвсем) информация от услугите.
Телеметрията е общ термин, който включва показатели, разпределено проследяване и регистрационни файлове. Сервизните мрежи предлагат механизми за събиране и обработка на трите вида данни. Тук нещата стават малко замъглени, защото броят на възможните опции е твърде голям. За събиране на метрики има и други инструменти, които могат да се използват за събиране на трупи , , и др. (например ClickHouse с нашия за K8s - прибл. превод), за разпределено проследяване има и така нататък. Всяка сервизна мрежа може да поддържа някои инструменти, но не и други. Ще бъде интересно да видим дали проектът може осигуряват известна конвергенция.
В този случай предимството на услугата mesh технология е, че контейнерите с кош могат по принцип да събират всички горепосочени данни от своите услуги. С други думи, имате на ваше разположение една единствена система за събиране на телеметрични данни и мрежата на услугите може да обработва цялата тази информация по различни начини. Например:
- крайни регистрационни файлове от определена услуга в CLI;
- следете обема на заявките от мрежовото табло на услугата;
- събирайте разпределени следи и ги препращайте към система като Jaeger.
Внимание, субективна преценка: Най-общо казано, телеметрията е област, в която силните смущения от сервизната мрежа са нежелателни. Събирането на основна информация и проследяването в движение на някои златни показатели като процент на успеваемост на заявките и латентност е добре, но да се надяваме, че няма да видим появата на стекове на Франкенщайн, които се опитват да заменят специализирани системи, някои от които вече са се доказали и са добре проучени .
15. Одит
TL;DR: Тези, които забравят уроците на историята, са обречени да ги повтарят.
Одитът е изкуството да се наблюдават важни събития в една система. В случай на мрежа за услуги това може да означава проследяване кой е направил заявки към конкретни крайни точки за конкретни услуги или колко пъти е настъпило събитие, свързано със сигурността, през последния месец.
Ясно е, че одитът е много тясно свързан с телеметрията. Разликата е, че телеметрията обикновено се свързва с неща като производителност и техническа цялост, докато одитът може да се отнася до правни и други въпроси, които надхвърлят строго техническата сфера (например съответствие с GDPR - Общия регламент на ЕС за защита на данните).
16. Визуализация
TL;DR: Да живее React.js - неизчерпаем източник на фантастични интерфейси.
Може да има по-добър термин, но не го знам. Имам предвид просто графично представяне на сервизна мрежа или някои от нейните компоненти. Тези визуализации могат да включват индикатори като средни закъснения, информация за конфигурацията на коша, резултати от проверка на състоянието и предупреждения.
Работата в среда, ориентирана към обслужване, включва много по-високо когнитивно натоварване в сравнение с Негово Величество Монолита. Следователно когнитивният натиск трябва да бъде намален на всяка цена. Опростеният графичен интерфейс за сервизна мрежа с възможност за щракване върху бутон и получаване на желания резултат може да бъде решаващ за нарастването на популярността на тази технология.
Не бяха включени в списъка
Първоначално възнамерявах да включа още няколко случая на употреба в списъка, но след това реших да не го правя. Ето ги, заедно с причините за моето решение:
- Център за множество данни. По мое мнение, това не е толкова случай на употреба, колкото тясна и специфична област на приложение на сервизни мрежи или някакъв набор от функции като откриване на услуга.
- Влизане и излизане. Това е свързана област, но аз се ограничих (може би изкуствено) до случая на използване на „трафик изток-запад“. Влизането и излизането заслужават отделна статия.
Заключение
Това е всичко за сега! Отново, този списък е много произволен и най-вероятно непълен. Ако смятате, че съм пропуснал нещо или съм объркал нещо, моля, свържете се с мен в Twitter (). Моля, спазвайте правилата за приличие.
PS от преводача
Заглавната илюстрация към статията е базирана на изображение от статията ““ (от Грегъри Маккинън). Той показва как някои функционалности от приложения (в зелено) са се преместили в сервизна мрежа, която осигурява взаимовръзки между тях (в синьо).
Прочетете също в нашия блог:
- «»;
- «»;
- «".
Източник: www.habr.com
