🥇Service Mesh: какво трябва да знае всеки софтуерен инженер за най-горещата технология

Забележка. превод: Сервизната мрежа е явление, което все още няма стабилен превод на руски (преди повече от 2 години предложихме опцията „мрежа за услуги“, а малко по-късно някои колеги започнаха активно да популяризират комбинацията „сервизно сито“). Постоянното говорене за тази технология доведе до ситуация, в която маркетинговите и техническите компоненти са твърде тясно преплетени. Този прекрасен материал от един от авторите на оригиналния термин има за цел да осигури яснота за инженери и други.

Комикс от Себастиан Касерес

въведение

Ако сте софтуерен инженер, който работи някъде в пространството на бекенд системите, терминът „сервизна мрежа“ вероятно вече е станал здраво вкоренен в съзнанието ви през последните няколко години. Благодарение на странно съвпадение, тази фраза завладява индустрията все повече и повече, а шумът и промоционалните оферти, свързани с нея, нарастват като снежна топка, летяща надолу и не показва признаци на забавяне.

Service mesh е роден в мътните, предубедени води на родната облачна екосистема. За съжаление, това означава, че голяма част от споровете около него варират от „нискокалорични разговори“ до – да използваме технически термин – откровени глупости. Но ако пресечете целия шум, ще откриете, че сервизната мрежа има много реална, дефинирана и важна функция.

В тази публикация ще се опитам да направя точно това: да осигуря честно, задълбочено, ориентирано към инженерите ръководство за сервизна мрежа. Няма да отговоря просто на въпроса: "Какво е?", - но също "Защо?"И "Защо сега?". И накрая, ще се опитам да очертая защо (по мое мнение) тази конкретна технология предизвика такъв луд шум, което само по себе си е интересна история.

Кто я?

Здравейте всички! Моето име е Уилям Морган. Аз съм един от създателите Linkerd — първият сервизен меш проект и проектът, който е виновен за появата на термина сервизна мрежа като такъв (съжалявам момчета!). (Забележка прев.: Между другото, в зората на появата на този термин, преди повече от 2,5 години, ние вече преведохме ранния материал на същия автор, озаглавен „Какво представлява мрежата на услугата и защо ми е необходима [за облачно приложение с микроуслуги]?".) Аз също глава Плаващ е стартираща компания, която създава страхотни мрежести услуги като Linkerd и Гмуркане.

Сигурно се досещате, че имам много пристрастно и субективно мнение по този въпрос. Въпреки това ще се опитам да сведа пристрастията до минимум (с изключение на един раздел: „Защо се говори толкова много за сервизната мрежа?“, - в който все пак ще споделя моите предубедени идеи). Също така ще направя всичко възможно, за да направя това ръководство възможно най-обективно. За конкретни примери ще разчитам предимно на опита на Linkerd, като същевременно ще посоча разликите (ако има такива), за които знам при внедряването на други типове мрежи за услуги.

Добре, време е да преминем към екстрите.

Какво е сервизна мрежа?

Въпреки цялата реклама, структурата на мрежовата услуга е доста проста. Това е просто куп проксита на потребителското пространство, разположени „до“ услугите (ще поговорим малко за това какво е „следващото“ по-късно), плюс набор от контролни процеси. Прокситата се наричат колективно план за данни, и процесите на управление се извикват контролна равнина. Равнината на данни прихваща повиквания между услуги и прави „всякакви различни неща“ с тях; Контролната равнина, съответно, координира поведението на проксито и осигурява достъп за вас, т.е. оператор, към API, позволявайки мрежата да бъде манипулирана и измервана като цяло.

Какъв вид прокси е това? Това е TCP прокси, поддържащ слой 7 (т.е. „вземайки предвид“ слой 7 на OSI модела) като HAProxy и NGINX. Можете да изберете прокси по ваш вкус; Linkerd използва Rust прокси, просто наименуван linker-прокси. Събрахме го специално за сервизна мрежа. Други мрежи предпочитат други проксита (Envoy е често срещан избор). Изборът на прокси обаче е само въпрос на внедряване.

Какво правят тези прокси сървъри? Очевидно те прокси повиквания към и от услуги (стриктно погледнато, те действат като прокси и обратни проксита, обработвайки както входящи, така и изходящи повиквания). И те прилагат набор от функции, който се фокусира върху обажданията между услуги. Този фокус върху трафика между услугите е това, което отличава мрежовия прокси на услугата от, да речем, API шлюзове или входни проксита (последните се фокусират върху повиквания, идващи в клъстера от външния свят). (Забележка. превод: За сравнение на съществуващи контролери Ingress за Kubernetes, много от които използват вече споменатия Envoy, вижте тази статия.)

И така, подредихме равнината на данните. Контролната равнина е по-проста: това е набор от компоненти, които осигуряват цялата механика, от която равнината на данни се нуждае, за да работи по координиран начин, включително откриване на услуги, издаване на TLS сертификати, агрегиране на метрики и т.н. Равнината на данни информира контролната равнина за неговото поведение; на свой ред контролната равнина предоставя API, който ви позволява да променяте и наблюдавате поведението на равнината на данни като цяло.

По-долу е дадена диаграма на контролната равнина и равнината на данните в Linkerd. Както можете да видите, контролната равнина включва няколко различни компонента, включително екземпляр на Prometheus, който събира показатели от прокси сървъри, както и други компоненти като destination (откриване на услуга), identity (сертифициращ орган, CA) и public-api (крайни точки за уеб и CLI). За разлика от това, равнината на данни е обикновен linkerd-прокси до екземпляра на приложението. Това е просто логическа диаграма; При внедряване в реалния свят може да имате три реплики на всеки компонент на контролната равнина и стотици или хиляди проксита в равнината на данни.

(Сините правоъгълници в тази диаграма символизират границите на Kubernetes pods. Можете да видите, че контейнерите с linkerd-proxy са в същия pod като контейнерите на приложението. Тази схема е известна като кош контейнер.)

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

Друго важно последствие е, че сервизната мрежа изисква огромен брой пълномощници. Всъщност Linkerd прикачва linkerd-прокси към всяко копие на всяка услуга (други реализации добавят прокси към всеки възел/хост/виртуална машина. Това така или иначе е много). Такова активно използване на проксита само по себе си носи редица допълнителни усложнения:

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

Най-общо мрежовата мрежа на услугата изглежда така (поне от птичи поглед): разгръщате куп прокси сървъри на потребителското пространство, които „правят нещо“ с вътрешния трафик между услугите и използвате контролна равнина, за да ги наблюдавате и управлявате.

Сега е време да зададем въпроса "Защо?"

За какво е сервизна мрежа?

На онези, които за първи път са се сблъскали с идеята за сервизна мрежа, може да им бъде простено, че се чувстват малко притеснени. Дизайнът на услугата mesh означава, че не само ще увеличи латентността в приложението, но също така ще консумирайте ресурси и ще добави куп нови механизми в инфраструктурата. Първо настройвате сервизна мрежа и след това изведнъж установявате, че трябва да обслужвате стотици (ако не и хиляди) проксита. Въпросът е кой ще направи това доброволно?

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

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

Например в Linkerd (както в повечето мрежи) функционалността е фокусирана предимно върху HTTP извиквания, включително HTTP/2 и gRPC*. Функционалността е доста богата - може да се раздели на три класа:

Характеристики, свързани с надеждност. Повтарящи се заявки, изчакване, канарски подход (разделяне/пренасочване на трафик) и др.
Характеристики, свързани с наблюдение. Обобщаване на успеваемост, закъснения и обеми заявки за всяка услуга или отделни направления; изграждане на топологични карти на услуги и др.
Характеристики, свързани с сигурност. Взаимен TLS, контрол на достъпа и др.

* От гледна точка на Linkerd gRPC практически не се различава от HTTP/2: той просто използва protobuf в полезния товар. От гледна точка на разработчика двете неща, разбира се, са различни.

Много от тези механизми работят на ниво заявка (оттук и "L7 прокси"). Например, ако услугата Foo направи HTTP повикване към услугата Bar, linkerd-проксито от страната на Foo може да извърши интелигентно балансиране на натоварването и да насочи повикванията от Foo към екземплярите на Bar въз основа на наблюдаваното забавяне; може да повтори заявката, ако е необходимо (и ако е идемпотентна); може да записва кода на отговора и времето за изчакване и т.н. По същия начин linkerd-proxy от страната на лентата може да отхвърли заявка, ако тя не е разрешена или лимитът на заявката е надвишен; може да запише закъснение от своя страна и др.

Прокси сървърите могат да „направят нещо“ и на ниво връзка. Например linkerd-proxy от страната на Foo може да инициира TLS връзка, а linkerd-proxy от страната на Bar може да я прекрати и двете страни могат взаимно да проверяват TLS сертификатите*. Това осигурява не само криптиране между услугите, но и криптографски сигурен начин за идентифициране на услуги: Foo и Bar могат да „докажат“, че са тези, за които се представят.

* „Взаимен на приятел“ означава, че клиентският сертификат също е проверен (взаимен TLS). В "класическия" TLS, например между браузър и сървър, обикновено се проверява сертификатът само на едната страна (сървъра).

Независимо дали работят на ниво заявка или връзка, важно е да се подчертае, че всички мрежови функции на услугата са оперативен характер. Linkerd не е в състояние да трансформира семантиката на полезния товар - например добавяне на полета към JSON фрагмент или извършване на промени в protobuf. Ще говорим за тази важна функция по-късно, когато говорим за ESB и мидълуер.

Това е наборът от функции, които сервизната мрежа предлага. Възниква въпросът: защо не ги внедрите директно в приложението? И защо изобщо да се занимавате с прокси?

Защо сервизната мрежа е добра идея

Въпреки че възможностите на мрежата за услуги са вълнуващи, нейната основна стойност всъщност не се крие в нейните характеристики. В крайна сметка ние Мога имплементирайте ги директно в приложението (ще видим по-късно, че това е произходът на сервизната мрежа). За да се опитаме да го обобщим в едно изречение, стойността на сервизната мрежа е: той предоставя функции, които са критични за изпълнението на модерен сървърен софтуер по последователен начин в целия стек и независимо от кода на приложението.

Нека анализираме това предложение.

«Характеристики, критични за работата на модерен сървърен софтуер" Ако създавате сървърно приложение за транзакции, което е свързано с публичния интернет, приема заявки от външния свят и отговаря на тях в рамките на кратко време - например уеб приложение, API сървър и по-голямата част от други съвременни приложения - и ако го внедрите като набор от услуги, които синхронно взаимодействат една с друга, и ако непрекъснато надграждате този софтуер, добавяте нови функции и ако сте принудени да поддържате тази система в работно състояние по време на процеса на модификация - в това случай, поздравления, вие създавате модерен сървърен софтуер. И всички тези страхотни функции, изброени по-горе, всъщност се оказват критични за вас. Приложението трябва да е надеждно, сигурно и трябва да можете да наблюдавате какво прави. Това са точно въпросите, които service mesh помага да се решат.

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

«Униформа за целия стек" Функционалността, осигурена от мрежата на услугата, не е само критична за мисията. Те се отнасят за всички услуги в приложението, независимо от това на какъв език са написани, каква рамка използват, кой ги е написал, как са били внедрени и всякакви други тънкости на тяхното разработване и използване.

«Независимо от кода на приложението" И накрая, сервизната мрежа не само осигурява последователна функционалност в целия стек, но и по начин, който не изисква приложението да бъде редактирано. Фундаменталната основа на мрежовата функционалност на услугата, включително задачи за конфигуриране, актуализиране, работа, поддръжка и т.н., се намира изцяло на ниво платформа и е независима от приложението. Приложението може да се промени, без да се засяга мрежата на услугата. От своя страна мрежата на услугата може да се променя без участието на приложението.

Накратко, сервизната мрежа не само осигурява жизненоважна функционалност, но също така го прави по глобален, унифициран и независим от приложението начин. И така, въпреки че функционалността на мрежата на услугата може да бъде имплементирана в кода на услугата (например като библиотека, включена във всяка услуга), този подход няма да осигури еднообразието и независимостта, които са толкова ценни в случая на мрежа на услугата.

И всичко, което трябва да направите, е да добавите куп проксита! Обещавам, че много скоро ще разгледаме оперативните разходи, свързани с добавянето на тези проксита. Но първо нека спрем и да разгледаме тази идея за независимост от различни гледни точки. хора.

На кого помага сервизната мрежа?

Колкото и неудобно да е, за да стане една технология важна част от екосистемата, тя трябва да бъде приета от хората. И така, кой се интересува от сервизната мрежа? Кой има полза от използването му?

Ако разработвате модерен сървърен софтуер, можете грубо да мислите за вашия екип като за група собственици на услугикоито заедно разработват и прилагат бизнес логика, и собственици на платформа, разработвайки вътрешната платформа, върху която работят тези услуги. В малки организации това може да са едни и същи хора, но с разрастването на компанията тези роли са склонни да стават по-изразени и дори разделени на подроли... (Тук има много да се каже за променящата се природа на devops, организационното въздействие на микроуслугите и т.н.) n. Но засега нека приемем тези описания като дадени).

От тази гледна точка, очевидните бенефициенти на услугата mesh са собствениците на платформата. В края на краищата, в крайна сметка целта на екипа на платформата е да създаде вътрешна платформа, на която собствениците на услуги да могат да прилагат бизнес логика и да го правят по начин, който гарантира, че са възможно най-независими от мътните детайли на нейната работа. Мрежовата мрежа на услугата не само предлага възможности, които са критични за постигането на тази цел, но и по начин, който на свой ред не налага зависимости на собствениците на услуги.

Собствениците на услуги също печелят, макар и по по-косвен начин. Целта на собственика на услугата е да бъде възможно най-продуктивен при внедряването на логиката на бизнес процеса и колкото по-малко трябва да се тревожи за оперативни проблеми, толкова по-добре. Вместо да се налага да се справят с прилагането, да речем, на политики за повторен опит или TLS, те могат да се съсредоточат единствено върху бизнес целите и да се надяват платформата да се погрижи за останалото. Това е голямо предимство за тях.

Организационната стойност на такова разделение между собствениците на платформи и услуги не може да бъде надценена. Мисля, че тя допринася основен принос към стойността на мрежата на услугата.

Научихме този урок, когато един ранен фен на Linkerd ни каза защо са избрали сервизна мрежа: защото им позволява да „сведат разговорите до минимум“. Ето някои подробности: момчетата от една голяма компания мигрираха платформата си към Kubernetes. Тъй като приложението обработваше чувствителна информация, те искаха да криптират всички комуникации в клъстерите. Ситуацията обаче беше усложнена от наличието на стотици услуги и стотици екипи за разработка. Перспективата да се свържат с всички и да ги убедят да включат поддръжката на TLS в плановете си изобщо не ги направи щастливи. След като инсталираха Linkerd, те се прехвърлиха отговорност от разработчици (от гледна точка на които това беше ненужен проблем) до платформингисти, за които това беше приоритет от най-високо ниво. С други думи, Linkerd реши за тях не толкова технически проблем, колкото организационен.

Накратко, сервизната мрежа е по-скоро решение, не техническо, но социално-технически проблеми. (Благодаря ти Синди Шридхаран за въвеждането на този термин.)

Сервизната мрежа ще реши ли всичките ми проблеми?

да Искам да кажа, не!

Ако разгледате трите класа функции, посочени по-горе - надеждност, сигурност и видимост - става ясно, че мрежата на услугата не е пълно решение на нито един от тези проблеми. Въпреки че Linkerd може да преиздава заявки (ако знае, че са идемпотентни), той не е в състояние да вземе решения какво да върне на потребителя, ако услугата е трайно неуспешна - тези решения трябва да бъдат взети от приложението. Linkerd може да поддържа статистика на успешните заявки, но не може да разгледа услугата и да предостави нейните вътрешни показатели - приложението трябва да има такива инструменти. И въпреки че Linkerd е в състояние да организира mTLS, пълноценните решения за сигурност изискват много повече.

Подмножество от функциите в тези области, предлагани от мрежата на услугата, се отнасят до характеристики на платформата. С това имам предвид функции, които:

Независимо от бизнес логиката. Начинът, по който се конструират хистограмите на повикванията между Foo и Bar, е напълно независим от защо Фу се обажда на Бар.
Трудно за правилно изпълнение. В Linkerd повторните опити са параметризирани с всякакви фантастични неща като бюджети за повторни опити (опитайте отново бюджети), тъй като несложният, пряк подход към прилагането на подобни неща със сигурност ще доведе до появата на така наречената „лавина от заявки“ (повторен опит за буря) и други проблеми, характерни за разпределените системи.
Най-ефективен, когато се прилага равномерно. TLS механизмът има смисъл само ако се прилага навсякъде.

Тъй като тези функции се изпълняват на прокси ниво (а не на ниво приложение), сервизната мрежа ги предоставя на платформа, а не приложения. По този начин няма значение на какъв език са написани услугите, каква рамка използват, кой ги е написал и защо. Прокситата работят извън всички тези подробности и фундаменталната основа на тази функционалност, включително задачи за конфигуриране, актуализиране, работа, поддръжка и т.н., лежи единствено на ниво платформа.

Примери за мрежови възможности на услугата

За да обобщим, сервизната мрежа не е цялостно решение за надеждност, видимост или сигурност. Обхватът на тези области изисква участието на собственици на услуги, екипи Ops/SRE и други фирмени субекти. Сервизната мрежа предоставя само „отрез“ на ниво платформа за всяка от тези области.

Защо сервизната мрежа стана популярна точно сега?

Досега вероятно се чудите: добре, ако мрежата на услугата е толкова добра, защо не започнахме да внедряваме милиони проксита в стека преди десет години?

Има банален отговор на този въпрос: преди десет години всички изграждаха монолити и никой не се нуждаеше от сервизна мрежа. Това е вярно, но според мен този отговор пропуска смисъла. Дори преди десет години концепцията за микроуслугите като обещаващ начин за изграждане на широкомащабни системи беше широко обсъждана и прилагана в компании като Twitter, Facebook, Google и Netflix. Общото мнение – поне в частите на индустрията, с които се сблъсках – беше, че микроуслугите са „правилният начин“ за изграждане на големи системи, дори и да е адски трудно.

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

Netflix имаше Hysterix, Google имаше Stubby, Twitter имаше библиотеката Finagle. Finagle, например, беше задължителен за всяка нова услуга в Twitter. Обработваше както клиентската, така и сървърната страна на връзките, позволяваше повтарящи се заявки, поддържаше маршрутизиране на заявки, балансиране на натоварването и измерване. Той осигури постоянен слой на надеждност и видимост в целия стек на Twitter, независимо от това какво прави услугата. Разбира се, той работеше само за JVM езици и беше базиран на програмен модел, който трябваше да се използва за цялото приложение. Функционалността му обаче беше почти същата като тази на сервизната мрежа. (Всъщност първата версия на Linkerd беше просто Finagle, обвит в прокси форма.)

По този начин преди десет години имаше не само микроуслуги, но и специални прото-услуги-мрежови библиотеки, които решаваха същите проблеми, които service mesh решава днес. Тогава обаче самата сервизна мрежа не съществуваше. Трябваше да има още една смяна, преди тя да се появи.

И тук се крие по-дълбокият отговор, скрит в друга промяна, настъпила през последните 10 години: разходите за внедряване на микроуслуги са спаднали драстично. Компаниите, споменати по-горе, които използваха микроуслуги преди десет години – Twitter, Netflix, Facebook, Google – бяха компании с огромен мащаб и огромни ресурси. Те не само имаха необходимостта, но и способността да изграждат, внедряват и управляват големи приложения, базирани на микроуслуги. Енергията и усилията, които инженерите на Twitter влагат, за да преминат от монолитен подход към микроуслуги, са невероятни. (За да бъда честен, такъв е и фактът, че успя.) Тогава този вид инфраструктурни маневри бяха невъзможни за по-малките компании.

Бързо напред към настоящето. Днес има стартиращи компании, при които съотношението на микроуслугите към разработчиците е 5:1 (или дори 10:1), и нещо повече – справят се успешно с тях! Ако стартъп от 5 души може лесно да управлява 50 микроуслуги, тогава нещо очевидно е намалило разходите за тяхното внедряване.

1500 микросервизи в Monzo; всеки ред е предписано мрежово правило, което позволява трафик

Драматичното намаляване на разходите за оперативни микроуслуги е резултат от един процес: нарастващата популярност на контейнерите и оркестранти. Именно това е дълбокият отговор на въпроса какво е допринесло за появата на сервизния меш. Същата технология направи привлекателни както сервизните мрежи, така и микроуслугите: Kubernetes и Docker.

Защо? Е, Docker решава един голям проблем - проблема с опаковането. Чрез опаковане на приложение и неговите (извън мрежата) зависимости по време на изпълнение в контейнер, Docker превръща приложението във взаимозаменяема единица, която може да бъде хоствана и изпълнявана навсякъде. В същото време значително опростява работата многоезичен Стек: Тъй като контейнерът е атомна единица за изпълнение, за внедряване и оперативни цели, няма значение какво има вътре, било то JVM, Node, Go, Python или Ruby приложение. Просто го стартирате и това е.

Kubernetes пренася всичко на следващото ниво. Сега, когато има тонове „неща за стартиране“ и тонове машини, на които да ги управлявате, има нужда от инструмент, който може да ги свърже едно с друго. В по-широк смисъл вие давате на Kubernetes много контейнери и много машини и той ги свързва една срещу друга (разбира се, това е динамичен и непрекъснато променящ се процес: нови контейнери се движат из системата, машините стартират и спират , и т.н. Kubernetes обаче взема всичко това предвид ).

След като Kubernetes бъде конфигуриран, разходите за време за внедряване и експлоатация на една услуга са малко по-различни от разходите за внедряване и управление на десет услуги (всъщност те са почти еднакви за 100 услуги). Добавете към това контейнерите като механизъм за опаковане, който насърчава многоезичното внедряване, и ще имате множество нови приложения, внедрени под формата на микроуслуги, написани на различни езици - точно вида среда, за която мрежата на услугата е толкова подходяща.

И така, стигаме до отговора на въпроса защо идеята за мрежа за услуги стана популярна сега: хомогенността, която Kubernetes предоставя за услугите, се отнася директно към оперативните предизвикателства, пред които е изправена мрежата за услуги. Пакетирате прокситата в контейнери, давате на Kubernetes задачата да ги залепи навсякъде, където може, и готово! В резултат на това получавате сервизна мрежа, докато цялата механика на нейното внедряване се управлява от Kubernetes. (Поне от птичи поглед. Разбира се, има много нюанси в този процес.)

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

Защо се говори толкова много за сервизната мрежа?

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

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

Е, част от това е моя вина. Работя усилено, за да популяризирам Linkerd и мрежовата мрежа на услугата при всяка възможност, която имам чрез безброй публикации в блогове и статии като тази. Но аз не съм толкова могъщ. За да отговорим наистина на този въпрос, трябва да поговорим малко за цялостната ситуация. И е невъзможно да се говори за това, без да се спомене един проект: Истио е мрежова услуга с отворен код, разработена съвместно от Google, IBM и Lyft.

(Трите компании имат много различни роли: участието на Lyft изглежда е само на име; те са автори на Envoy, но не използват или участват в разработката на Istio. IBM участва и използва разработката на Istio. Google участва активно в разработката на Istio разработка, но всъщност не го използва, доколкото мога да преценя.)

Проектът Istio се отличава с две неща. Първо, има огромни маркетингови усилия, които Google, по-специално, полага за популяризирането му. Бих преценил, че повечето хора, запознати с концепцията за мрежова услуга днес, първо са научили за нея чрез Istio. Второто нещо е колко зле беше приет Istio. По този въпрос аз очевидно съм заинтересована страна, но опитвайки се да остана максимално обективен, пак не мога да помогна марка много отрицателен поведение, не много отличителен (макар и не уникален: systemd идва на ум, сравнение беше извършено вече многократно...) за проект с отворен код.

(На практика Istio изглежда има проблеми не само със сложността и UX, но и с производителността. Например, по време Оценки за ефективност на LinkerВ проучване на трета страна изследователите откриха ситуации, при които латентността на опашката на Istio е 100 пъти по-висока от тази на Linkerd, както и ситуации с недостиг на ресурси, при които Linkerd продължава да функционира успешно, докато Istio спира да работи напълно.)

Като оставим настрана моите теории защо се е случило това, вярвам, че огромното вълнение около услугата mesh се обяснява с участието на Google. А именно комбинация от следните три фактора:

Натрапчивата реклама на Istio от Google;
съответно неодобрително, критично отношение към проекта;
неотдавнашното стремително нарастване на популярността на Kubernetes, спомените за което са все още свежи.

Заедно тези фактори се комбинират, за да създадат зашеметяваща среда без кислород, в която способността за рационална преценка е отслабена и остава само странното разнообразие. лалета мания.

От гледна точка на Линкърд, това е... което бих описал като смесена благословия. Искам да кажа, страхотно е, че мрежовата мрежа на услугите навлезе в мейнстрийма по начин, по който не беше през 2016 г., когато Linkerd стартира за първи път, и беше наистина трудно да накараш хората да обърнат внимание на проекта. Сега няма такъв проблем! Но лошата новина е, че ландшафтът на мрежовата услуга е толкова объркващ днес, че е почти невъзможно да се разбере кои проекти всъщност принадлежат към категорията на мрежовата услуга (да не говорим за това кой е най-подходящ за конкретен случай на употреба). Това определено е проблем за всички (и определено има някои случаи, в които Istio или друг проект е по-подходящ от Linkerd, тъй като последното все още не е универсално решение).

От страна на Linkerd, нашата стратегия беше да игнорираме шума, да продължим да се фокусираме върху решаването на реални проблеми на общността и по същество да изчакаме рекламата да утихне. В крайна сметка шумът ще отшуми и можем да продължим да работим спокойно.

Междувременно всички ще трябва да имаме малко търпение.

Ще ми бъде ли полезна сервизната мрежа, скромен софтуерен инженер?

Следният въпросник ще ви помогне да отговорите на този въпрос:

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

Поддържате ли платформата в компания, която използва Kubernetes? Да, в този случай имате нужда от сервизна мрежа (освен ако, разбира се, не използвате K8s само за изпълнение на монолитна или пакетна обработка - но тогава бих искал да попитам защо имате нужда от K8s). Вероятно ще се окажете с много микроуслуги, написани от различни хора. Всички те взаимодействат помежду си и са свързани в плетеница от зависимости по време на изпълнение и вие трябва да намерите начин да се справите с всичко това. Използването на Kubernetes ви позволява да изберете сервизна мрежа „за себе си“. За да направите това, запознайте се с техните възможности и функции и отговорете на въпроса дали някой от наличните проекти е подходящ за вас (препоръчвам да започнете проучването си с Linkerd).

Вие сте платформена компания в компания, която НЕ използва Kubernetes, но използва микроуслуги? В този случай сервизната мрежа ще ви бъде полезна, но използването й ще бъде нетривиално. Разбира се можете да имитират работа мрежова услуга чрез поставяне на куп прокси сървъри, но важно предимство на Kubernetes е моделът на внедряване: ръчното поддържане на тези прокси сървъри ще изисква много повече време, усилия и разходи.

Вие отговаряте ли за платформата във фирма, която работи с монолити? В този случай вероятно нямате нужда от сервизна мрежа. Ако работите с монолити (или дори колекции от монолити), които имат добре дефинирани и рядко променящи се модели на взаимодействие, тогава сервизната мрежа няма да ви предложи много. Така че можете просто да го игнорирате и да се надявате, че ще изчезне като лош сън...

Заключение

Вероятно мрежовата услуга все още не трябва да се нарича „най-хипер технологията в света“ - тази съмнителна чест вероятно принадлежи на биткойн или AI. Тя вероятно е в челната петица. Но ако пресечете слоевете шум, става ясно, че мрежата на услугите носи реални ползи за тези, които създават приложения на Kubernetes.

Бих искал да опитате Linkerd - да го инсталирате на Kubernetes клъстер (или дори Minikube на лаптоп) отнема около 60 секунди, и сами виждате за какво говоря.

Често задавани въпроси

— Ако игнорирам сервизната мрежа, ще изчезне ли?
— Трябва да ви разочаровам: сервизната мрежа е с нас от дълго време.

- Но аз НЕ ИСКАМ да използвам сервизна мрежа!
- Е, не е необходимо! Просто прочетете моя въпросник по-горе, за да разберете дали трябва да се запознаете поне с основите му.

— Това не е ли добрият стар ESB/middleware с нов сос?
— Сервизната мрежа се занимава с оперативна логика, а не със семантична. Това беше основният недостатък корпоративен сервизен автобус (ESB). Поддържането на това разделение помага на сервизната мрежа да избегне същата съдба.

— Как се различава мрежовата мрежа от API шлюзовете?
— Има милион статии по тази тема. Просто го Google.

— Envoy е сервизна мрежа?
- Не, Envoy не е мрежова услуга, а прокси сървър. Може да се използва за организиране на сервизна мрежа (и много повече - това е прокси с общо предназначение). Но сама по себе си тя не е сервизна мрежа.

— Network Service Mesh е услуга?
- Не. Въпреки името, това не е сервизна мрежа (как ви харесват маркетинговите чудеса?).

— Ще помогне ли мрежата на услугата с моята реактивна асинхронна система, базирана на опашка за съобщения?
- Не, сервизната мрежа няма да ви помогне.

— Коя сервизна мрежа трябва да използвам?
- Linkerd, лесно.

- Статията е гадна! / Авторът е добре дошъл!
— Моля, споделете линка към него с всички ваши приятели, за да го видят!

Признания

Както може би се досещате от заглавието, тази статия е вдъхновена от фантастичния трактат на Джей Крепс "Дневникът: Какво трябва да знае всеки софтуерен инженер за обединяващата абстракция на данни в реално време" Срещнах Джей преди десет години, когато го интервюирах в Linked In и оттогава той е вдъхновение за мен.

Въпреки че обичам да се наричам „разработчик на Linkerd“, реалността е, че съм по-скоро поддържащ файла README.md на проект. Днес се работи по Linkerd много, много, много много хора и този проект нямаше да се случи без участието на чудесна общност от сътрудници и потребители.

И накрая, специални благодарности на създателя на Linkerd, Оливър Гулд (първичен сред равен), които заедно с мен преди много години се гмурнахме през глава в цялата тази суматоха със сервизната мрежа.

PS от преводача

Прочетете също в нашия блог:

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

Service Mesh: Какво трябва да знае всеки софтуерен инженер за най-горещите технологии