Прим. прев.: Service mesh — явление, което все още няма утвърден превод на български (преди повече от 2 години предлагахме вариант "мрежа за услуги", а малко по-късно някои колеги започнаха активно да популяризират комбинацията "услугова цедка"). Постоянните разговори около тази технология доведоха до ситуация, в която маркетинговият и техническият аспекти са прекалено преплетени. Този страхотен материал от един от авторите на оригиналния термин има за цел да внесе яснота за инженерите и не само.
Комикс от
Въведение
Ако сте софтуерен инженер, който работи някъде в сферата на бекенд системите, терминът "service mesh" вероятно вече е намерил трайно място в съзнанието ви през последните няколко години. Поради странно стечение на обстоятелствата, тази фраза завладява индустрията все повече, а хайпът и свързаните с него рекламни предложения нарастват като снежна топка, която се търкаля надолу по склона и не показва признаци на забавяне.
Service mesh започна в мътни, тенденциозни води на облачната екосистема. За съжаление, това означава, че значителна част от свързаните с нея дебати варират от "нискокалорични приказки" до — ако използваме техническия термин — откровена глупост. Но ако отсеем целия шум, можем да установим, че service mesh изпълнява напълно реална, определена и важна функция.
В тази публикация ще се опитам да направя точно това: да представя честно, задълбочено и ориентирано към инженерите ръководство за service mesh. Ще се опитам да отговоря не само на въпроса: "Какво е това?", — но и "Защо?", а също така "Защо точно сега?". Накрая, ще се опитам да очертая защо (по мое мнение) точно тази технология предизвика такъв луд интерес, което само по себе си е интересна история.
Кой съм аз?
Здравейте на всички! Казвам се . Аз съм един от създателите на — най-първия проект service mesh и проекта, който е отговорен за появата на термина service mesh както такъв (съжалявам, момчета!). (Прим прев.: Между другото, в зората на появата на този термин, повече от 2.5 години назад, вече превеждахме ранно материал на същия автор под заглавие "».) Също така ръководя — стартъп, който се занимава с изграждането на такива страхотни неща за service mesh, като Linkerd и .
Вероятно, догадывате се, че имам доста пристрастно и субективно мнение по този въпрос. Въпреки това, ще се постарая да сведа тенденциозността до минимум (с изключение на една част: „Защо има толкова много разговори за service mesh?“, — където все пак ще споделя своите предвзяти идеи). Също така ще положа всички усилия, за да направя това ръководство възможно най-обективно. В конкретните примери основно ще разчитам на опита на Linkerd, като същевременно посоча известните ми разлики (ако има такива) в реализирането на други типове service mesh.
Добре, време е да преминем към вкусните неща.
Какво е service mesh?
Въпреки целия шум, структурно service mesh е доста просто. Това е просто куп userspace-прокси, разположени „близо“ до услугите (по-късно ще поговорим малко за това какво означава „близо“), плюс набор от управляващи процеси. Прокси в съвкупност получиха името data plane, а управляващите процеси се наричат control plane. Data plane прихваща повикванията между услугите и прави с тях „всякакви неща“; control plane, съответно, координира поведението на прокси и осигурява достъп за вас, т.е. оператора, до API, позволявайки манипулиране на мрежата и измерването ѝ като цяло.
Какво представляват тези проксита? Това са TCP-прокси от категория „Layer 7-aware“ (т.е. „вземащи предвид“ 7-мо ниво на модела OSI) като HAProxy и NGINX. Можете да изберете прокси по свой вкус; Linkerd използва прокси, написан на Rust, наречен . Ние го създадохме специално за service mesh. Останалите mesh'и предпочитат различни прокси (Envoy е често срещан избор). Въпреки това, изборът на прокси е просто въпрос на реализация.
Какво правят тези прокси сървъри? Очевидно, те проксират повикванията към услугите и от тях (строго погледнато, те изпълняват ролята на прокси и обратни прокси, обработвайки както входящи, така и изходящи повиквания). И те реализират набор от функции, фокусирани върху повикванията между услугите. Този фокус върху трафика между услугите и отличава service mesh-прокситата от, да кажем, API шлюзовете или ingress-прокситата (последните се фокусират върху повикванията, постъпващи в клъстера от външния свят). (Прим. прев.: сравнение на съществуващите Ingress контролери за Kubernetes, много от които използват вече споменатия Envoy, вижте в .)
И така, с data plane сме наясно. Control plane е по-простичко устроен: това е набор от компоненти, които осигуряват цялата механика, необходима на data plane, за да работи координирано. Включва откритие на услуги, издаване на TLS сертификати, агрегация на метрики и т.н. Data plane информира control plane за своето поведение; от своя страна, control plane предоставя API, позволяващ да променяте и следите поведението на data plane като единно цяло.
По-долу е представена схемата на control plane и data plane в Linkerd. Както може да се види, control plane включва няколко различни компонента, включително инстанция на Prometheus, която събира метрики от проксита, както и други компоненти, като destination (откритие на услуги), identity (център за сертификация, CA) и public-api (endpoint'и за web и CLI). За разлика от това, data plane представлява прост linkerd-proxy до инстанцията на приложението. Това е само логическа схема; в реални условия, при внедряване, можете да имате три реплики на всеки компонент от control plane и стотици или хиляди проксита в data plane.
(Сините правоъгълници на тази схема символизират границите на pod'овете в Kubernetes. Видно е, че контейнерите с linkerd-proxy са в същия pod с контейнерите на приложението. Подобна схема е известна като sidecar-контейнер..)
Архитектурата на service mesh има няколко важни последици. На първо място, тъй като задачата на проксито е да прихваща извиквания между услугите, service mesh е смислено само ако вашето приложение е построено върху определен набор от услуги. Mesh може да се намери може да се използва с монолити, но това е явно излишно за един единствен прокси и функционалността ѝ едва ли ще бъде незабавно необходима.
Друга важна последица е, че service mesh изисква огромно количество проксита. Всъщност, Linkerd свързва linkerd-proxy към всяка инстанция на всяка услуга (други реализации добавят прокси към всеки възел/хост/виртуална машина. Във всеки случай, това не е малко). Толкова активното използване на проксита само по себе си носи редица допълнителни усложнения:
- Проксито в data plane трябва да бъде бързо,тъй като за всяко извикване има двойка обращения към проксито: едно на страната на клиента, едно — на страната на сървъра.
- Също така, проксито трябва да бъде малко и и леко. Всяко от тях ще консумира ресурси, памет и CPU, и това потребление ще нараства линейно с приложението.. Все ще будет да използва ресурси от паметта и CPU, и това потребление ще нараства линейно с приложението.
- Ще ви е необходим механизъм за разширяване и актуализиране на голям брой проксита. Правенето на това ръчно не е вариант.
Като цяло, service mesh изглежда така (най-малкото от височината на птичи поглед): разширявате множество проксита в потребителското пространство, които "правят нещо" с вътрешния, междусервизен трафик, и използвате контролен панел за мониторинг и управление на тях.
Настъпи моментът за въпроса "Защо?"
За какво е необходим service mesh?
На тези, които за първи път се сблъскват с концепцията за service mesh, е простително да изпитват известен страх. Структурата на service mesh означава, че тя не само ще увеличи латентността в приложението, но и ще консумира ресурси и ще добави множество нови механизми в инфраструктурата. Първо инсталирате service mesh, а след това изведнъж откривате, че трябва да обслужвате стотици (ако не и хиляди) проксита. Въпросът е, кой би се нагладил на това?
Отговорът на този въпрос се състои от две части. Първо, оперативните разходи, свързани с разширяването на тези проксита, могат да бъдат значително намалени благодарение на някои промени, които се случват в екосистемата (повече за това по-късно).
На второ място, такова устройство е наистина отличен начин за въвеждане на допълнителна логика в системата. И не само защото с помощта на service mesh можете да добавите множество нови функции, но и защото можете да го направите, без да се намесвате в екосистемата. Всъщност цялата модель на service mesh е основана на този постулат: в мултисервизна система, независимо от това какво правят отделните услуги, трафикът между тях е идеалната точка за добавяне на функционалност.
Например, в Linkerd (както и в повечето mesh решения) функционалността е фокусирана предимно върху HTTP повиквания, включително HTTP/2 и gRPC*. Функционалността е доста богата — може да бъде разделена на три класа:
- Функции, свързани с надеждността. Повторни заявки, таймаути, канаречен подход (разделяне/пренасочване на трафика) и т.н.
- Функции, свързани с мониторинг.. Агрегиране на показатели за успешност, закъснения и обеми на заявките за всяка услуга или отделни направления; изграждане на топологични карти на услугите и т.н.
- Функции, свързани с безопасността. Mutual TLS, контрол на достъпа и т.н.
* От гледна точка на Linkerd, gRPC практически не се различава от HTTP/2: просто в полезната нагрузка се използва protobuf. От гледна точка на разработчика, тези неща, разбира се, се различават.
Мнозина от тези механизми работят на ниво заявки (оттук и "L7-прокси"). Например, ако сервиз Foo изпрати HTTP-заявка до сервиз Bar, linkerd-proxy от страна на Foo може да извърши интелигентно балансиране на натоварването и да насочва повиквания от Foo към инстанции на Bar в зависимост от наблюдаваното закъснение; може да повтори заявката при необходимост (и ако е идемпотентна); може да запише кода на отговора и времето на изчакване и т.н. Аналогично, linkerd-proxy от страна на Bar може да отхвърли заявката, ако тя не е разрешена или надвишава лимита на заявките; може да запише закъснението от своя страна и т.н.
Прокситата могат да "правят нещо" и на ниво свързване. Например, linkerd-proxy от страна на Foo може да инициира TLS-свързване, а linkerd-proxy от страна на Bar — да го прекъсне, и двете страни могат да проверят TLS-сертификатите една на друга*. Това осигурява не само криптиране между сервизите, но и криптографски безопасен начин за идентификация на сервизите: Foo и Bar могат да "докажат", че са това, за което се представят.
* "Една на друга" означава, че сертификатът на клиента също се проверява (взаимен TLS). В "класическия" TLS, например, между браузър и сървър, обикновено се проверява сертификатът само на едната страна (сървъра).
Независимо дали работят на ниво заявки или свързвания, е важно да се подчертае, че всички функции на service mesh имат експлоатационен характер. Linkerd не е в състояние да трансформира семантиката на полезната нагрузка — напр. да добави полета в JSON фрагмент или да направи промени в protobuf. За този важен аспект ще говорим по-късно, когато става въпрос за ESB и middleware.
Това е набор от функции, които предлага service mesh. Въпросът е: защо да не ги реализираме директно в приложението? И защо изобщо да се свързваме с проксита?
Защо service mesh е добра идея
Въпреки че възможностите на service mesh вдъхновяват въображението, основната й стойност всъщност не се крие във функциите. В крайна сметка, ние да да се изпълняват директно в приложението (по-късно ще видим, че това е произходът на service mesh). Ако се опитаме да изразим тази мисъл в едно изречение, стойността на service mesh се състои в следното: осигурява функции, които са критично важни за работата на съвременното сървърно софтуерно приложение, по един унифициран начин за целия стек и независимо от кода на приложението.
Нека да анализираме това изречение.
«Функции, критично важни за работата на съвременното сървърно софтуерно приложение». Ако създавате транзакционно сървърно приложение, свързано с публичния интернет, приемате запитвания от външния свят и отговаряте на тях в кратък срок — например, уеб приложение, API сървър, както и почти всички останали съвременни приложения, — и ако го реализирате като набор от услуги, които взаимодействат помежду си синхронно, и ако постоянно модернизирате този софтуер, добавяйки нови функции, и ако сте принудени да поддържате системата в работно състояние по време на модификацията — в този случай ви поздравявам, занимавате се със създаването на съвременен сървърен софтуер. И всичките тези чудесни функции, изброени по-горе, всъщност са критично важни за вас. Приложението трябва да бъде надеждно, сигурно, и трябва да имате възможност да наблюдавате какво прави. Именно тези въпроси решава service mesh.
(Добре, в предишния абзац все пак се прокрадна моята убеденост, че този подход е съвременен начин за създаване на сървърен софтуер. Други предпочитат да разработват монолити, „реактивни микросервизи“ и други неща, които не попада в описанието по-горе. Тези хора със сигурност имат свое мнение, различно от моето. От своя страна, считам, че те „не са прави“ — въпреки че в крайна сметка service mesh не е особено полезна за тях).
«Унифициран за целия стек». Функциите, предоставяни от service mesh, не са просто критично важни. Те се прилагат за всички услуги в приложението, независимо от това на какъв език са написани, какъв фреймуорк използват, кой ги е написал, как са разпространени и от всички останали детайли в тяхната разработка и приложение.
«Независимо от кода на приложениетоНакрая, service mesh не само предоставя унифицирани функционалности за целия стек — то го прави по начин, който не изисква редакция на приложението. Основата на функционалността на service mesh, включваща задачи по настройка, обновление, експлоатация, поддръжка и т.н., е изключително на ниво платформа и е независима от приложението. Приложението може да се променя, без да засяга service mesh. От своя страна, service mesh може да се променя без никакво участие на приложението.
С други думи, service mesh не само предоставя жизненоважни функции, но го прави по глобален, унифициран и независим от приложението начин. И затова, макар функционалността на service mesh да може да бъде реализирана в кода на услугата (например, под формата на библиотека, включена в всяка услуга), този подход не би осигурил хомогенност и независимост, които са толкова ценни за service mesh.
И всичко, което е необходимо, е да добавите много проксита! Обещавам, много скоро ще разгледаме експлоатационните разходи, свързани с добавянето на тези проксита. Но първо да спрем и да погледнем на идеята за независимост от гледна точка на различни хората.
Кому помага service mesh?
Колкото и неудобно да е това, за да стане дадена технология важна част от екосистемата, тя трябва да бъде приета от хората. Така че, кой се интересува от service mesh? Кой печели от нейното използване?
Ако разработвате съвременен сървърен софтуер, можете да си представите отбора си като група собственици на услуги, които заедно разработват и внедряват бизнес логиката, и собственици на платформи, които се занимават с разработването на вътрешната платформа, на която работят тези услуги. В малки организации това могат да бъдат едни и същи хора, но с нарастването на компанията тези роли обикновено стават по-изразени и дори се делят на подроли… (Тук може да се каже много за променящата се природа на devops, организационното влияние на микросервисите и т.н. Но за момента да приемем тези описания като данност).
От тази гледна точка, явните бенефициари на service mesh са собствениците на платформата. В края на краищата целта на екипа за платформата е да създаде вътрешна платформа, на която собствениците на услуги могат да реализират бизнес логиката си по начин, който гарантира максимална независимост от мрачните детайли на експлоатацията ѝ. Service mesh не само предлага възможности, критично важни за постигането на тази цел: тя го прави по начин, който, от своя страна, не налага зависимости на собствениците на услуги.
Собствениците на услуги също печелят, макар и по по-непосредствен начин. Целта на собственика на услуга е да бъде максимално продуктивен в реализирането на бизнес процесите и колкото по-малко трябва да се грижи за въпросите на експлоатацията, толкова по-добре. Вместо да се занимават с реализацията, да кажем, на политиките за повторни заявки или TLS, те могат да се съсредоточат изцяло върху бизнес задачите и да се надяват, че платформата ще се погрижи за всичко останало. За тях това е голямо предимство.
Организационната стойност на такова разделение между собствениците на платформи и услуги е трудно да се преоцени. Аз смятам, че тя внася основният принос в стойността на service mesh.
Научихме този урок, когато един от първите почитатели на Linkerd ни разказа защо избраха service mesh: защото им позволи да "намалят разговора до минимум". Ето малко подробности: хората от една голяма компания мигрираха платформата си в Kubernetes. Тъй като приложението работеше с конфиденциална информация, те искаха да криптират всички комуникации в клъстерите. Въпреки това ситуацията беше усложнена от стотиците услуги и стотиците екипи разработчици. Перспективата да се свържат с всички и да убедят да включат поддържане на TLS в плановете си изобщо не им допадаше. След инсталирането на Linkerd, те прехвърлиха отговорността от разработчиците (от гледна точка на които това бяха излишни притеснения) на платформерите, за които това беше приоритет от най-високо ниво. С други думи, Linkerd решаваше за тях не толкова технически, а по-скоро организационен проблем.
С други думи, service mesh е по-скоро решение не на технически, а на социо-технически проблем. (Благодаря на за запознаването с този термин.)
Ще реши ли service mesh всички мои проблеми?
Да. В смисъл, не!
Ако погледнем трите класа функции, споменати по-горе: надеждност, сигурност и наблюдаемост, става ясно, че service mesh не е пълноценен отговор на нито един от тези проблеми. Въпреки че Linkerd може да изпраща повторни заявки (ако знае, че те са идемпотентни), той не е в състояние да взема решения относно това какво да върне на потребителя, ако услугата окончателно се срина — такива решения трябва да взима приложението. Linkerd може да води статистика за успешни заявки, но не е в състояние да надникне в услугата и да предостави вътрешните й метрики — подобен инструментариум трябва да бъде наличен в приложението. И въпреки че Linkerd може да организира mTLS, пълноценните решения по отношение на сигурността изискват много повече.
Подмножество от функции в тези области, предлагани от service mesh, се отнасят до функциите на платформата. С това имам предвид функции, които:
- Не зависят от бизнес логиката. Начинът, по който се изграждат хистограми на повикванията между Foo и Bar, не зависи от факта, защо че Foo извиква Bar.
- Трудно е да се реализира правилно. В Linkerd повторните опити се параметризират чрез всякакви сложни неща като бюджети за повторни опити (retry budgets), тъй като елементарният подход при реализирането на подобни неща със сигурност ще доведе до така наречената “лавина от заявки” (retry storm) и други проблеми, характерни за разпределени системи.
- Най-ефективни, когато се прилагат последователно. Механизмът TLS има смисъл само когато се прилага навсякъде.
Тъй като тези функции са реализирани на ниво прокси (а не на ниво приложение), service mesh ги предоставя на ниво платформата, а не на приложение. Така че, няма значение на какъв език са написани услугите, какъв фреймуърк използват, кой ги е написал и защо. Прокситата работят извън всички тези подробности, а основата на тази функционалност, включително задачите за конфигуриране, обновяване, експлоатация, поддръжка и т.н., лежи изцяло на платформено ниво.
Примери за възможности на service mesh
В заключение, искажаю, че service mesh не е пълно решение за осигуряване на надеждност, наблюдаемост или сигурност. Обхватът на тези области предполага задължително участие на собствениците на услуги, екипите Ops/SRE и други субекти на компанията. Service mesh предоставя само "срез" на ниво платформа за всяка от тези области.
Защо service mesh стана популярна точно сега?
Вероятно в момента се питате: добре, ако service mesh е толкова добра, защо не започнахме да внедряваме милиони проксита в стека преди десет години?
Има банален отговор на този въпрос: десет години назад всички строяха монолити и на никого не беше нужна service mesh. Това е вярно, но, според мен, в такъв отговор се губи същността. Дори десет години назад концепцията за микросервици като обещаващ начин за изграждане на мащабни системи беше широко обсъждана и прилагана в компании като Twitter, Facebook, Google и Netflix. Общото впечатление – поне в тези части на индустрията, с които аз съм контактувал – беше, че микросервисите са "правилният начин" за изграждане на големи системи, дори и да беше ужасно трудно.
Разбира се, въпреки че десет години назад имаше компании, които експлоатираха микросервиси, те съвсем не внедряваха проксита навсякъде, за да създадат service mesh. Все пак, ако се вгледате внимателно, те правеха нещо подобно: в много от тези компании беше предписано да използват специална вътрешна библиотека за мрежово взаимодействие (понякога наричана библиотека с тежък клиент, fat client library).
Netflix имаше Hysterix, Google имаше Stubby, а Twitter – библиотеката Finagle. Finagle, например, беше задължителна за всяка нова услуга в Twitter. Тя обработваше както клиентската, така и сървърната част на връзките, позволяваше повторни заявки, поддържаще маршрутизация на заявките, балансировка на натоварването и измервания. Тя осигуряваше последователен слой на надеждност и наблюдаемост за целия стек на Twitter, независимо от това с какво точно се занимаваше услугата. Разбира се, тя работеше само за JVM езици и се основаваше на програмна модел, който трябваше да се използва за всичкото приложение. Въпреки това, функционалните й възможности бяха почти идентични с тези на service mesh. (Наистина, първата версия на Linkerd всъщност беше Finagle, опакован в форма на прокси.)
Преди десет години съществуваха не само микросервизи, но и специализирани библиотеки за прото-сервизна мрежа, които решаваха същите проблеми, които днес решава service mesh. Въпреки това самата service mesh все още не беше налична. Трябваше да настъпи още една промяна, преди тя да се появи.
И именно тук се крие по-дълбокият отговор, скрит в друга промяна, случила се през последните 10 години: настъпи драстично намаление на разходите за внедряване на микросервизи. Споменатите по-горе компании, които използваха микросервизи преди десет години: Twitter, Netflix, Facebook, Google, бяха компании с огромен мащаб и ресурси. Те имаха не само нужда, но и възможност да изграждат, внедряват и експлоатират големи приложения на базата на микросервизи. Енергията и усилията, вложени от инженерите на Twitter в прехода от монолитен към микросервисен подход, просто са вдъхновяващи. (Честно казано, както и фактът, че това се е случило.) Този вид инфраструктурни маневри преди време бяха невъзможни за по-малките компании.
Да се пренесем в настоящето. Днес съществуват стартапи, където съотношението на микросервизи към разработчици е 5:1 (или дори ), и повече от това, те успешно се справят с тях! Ако стартап от 5 души е в състояние без усилие да експлоатира 50 микросервиза, значи нещо явно е намалило разходите за внедряване.
1500 микросервиза в Monzo; всяка линия е предписано мрежово правило, разрешаващо трафика.
Рязкото намаление на разходите за експлоатация на микросервизи е резултат от един процес: увеличението на популярността на контейнерите и оркестраторите. Именно в това се състои дълбокият отговор на въпроса какво е допринесло за появата на service mesh. Една и съща технология направи привлекателни както service mesh, така и микросервизите: Kubernetes и Docker.
Защо? Ами, Docker решава един голям проблем — проблема с опаковането. Опаковащият приложение и неговите (не мрежови) runtime зависимости в контейнер, Docker превръща приложението в взаимозаменяем единица, която може да бъде разположена и стартирана навсякъде. В същото време той значително опростява експлоатацията на многоезичен стек: тъй като контейнерът е атомарна единица на изпълнение, за целите на внедряване и експлоатация не е важно какво се намира вътре, независимо дали е приложение на JVM, Node, Go, Python или Ruby. Просто го стартиране и готово.
Kubernetes повишава всичко на ново ниво. Сега, когато има много "изпълними неща" и множество машини, на които могат да бъдат стартирани, възниква нуждата от инструмент, способен да ги свързва помежду им. В широк смисъл, вие давате на Kubernetes множество контейнери и множество машини, а той ги свързва помежду им (разбира се, това е динамичен и постоянно променящ се процес: нови контейнери преминават през системата, машини се стартират и спират и т.н. Но Kubernetes отчита всичко това).
След настройка на Kubernetes разходите за внедряване и експлоатация на една услуга се различават слабо от разходите за внедряване и експлоатация на десет услуги (всъщност, те са практически идентични и за 100 услуги). Добавете към това контейнерите като механизъм за опаковане, насърчаващи многоезичната реализация, и получавате множество нови приложения, реализирани като микросервизи, написани на различни езици — точно тази среда, за която service mesh е изключително подходящ.
И така, стигнахме до отговора на въпроса защо идеята за service mesh стана популярна точно сега: онова еднородие, което Kubernetes осигурява за услугите, пряко се прилага към експлоатационните задачи, стоящи пред service mesh. Опаковате прокси в контейнери, давате на Kubernetes задачата да ги прикрепи навсякъде, където е възможно, и воала! На изхода получавате service mesh, като цялата механика за внедряване се управлява от Kubernetes. (Поне от височината на птичи поглед. Разбира се, в този процес има много нюанси.)
В заключение: причината, поради която service mesh стана популярна точно сега, а не преди десет години, е, че Kubernetes и Docker не само значително увеличиха потребността от нея, опростявайки реализацията на приложенията като набори от многоезични микросервизи, но и значително намалиха разходите за нейното експлоатиране, осигурявайки механизми за внедряване и поддръжка на паркове от sidecar-прокси.
Защо настъпва толкова много разговори за service mesh?
Предупреждение: в тази секция прибягвам до всякакви предположения, догадки, измишления и вътрешна информация.
Когато търсите термина «service mesh», ще се натъкнете на куп репортиран нискокалоричен контент, странни проекти и калейдоскоп от изкривявания, достоен за ехо-камера. Всеки модерен новотехнологичен продукт носи подобни предизвикателства, но за case service mesh проблемът е особено изострен. Защо?
Отчасти вината е моя. Направих всичко възможно, за да популяризирам Linkerd и service mesh при всяка удобна възможност, чрез безброй публикации в блогове и статии, подобни на тази. Но не съм толкова могъщ. За да отговоря на този въпрос наистина, трябва да поговорим малко за общата ситуация. А не можем да говорим за нея, без да споменем един проект: — service mesh с отворен код, разработван съвместно от Google, IBM и Lyft.
(Трите компании играят напълно различни роли: участието на Lyft по същество се свежда до само име; те са автори на Envoy, но не използват Istio или не участват в неговото разработване. IBM е ангажирана в разработката на Istio и го използва. Google активно участва в разработката на Istio, но, доколкото мога да оценя, всъщност не го използва.)
Проектът Istio се отличава с две основни характеристики. Първата е огромните маркетингови усилия, които Google, по-специално, полага за неговото популяризиране. Според моите оценки, повечето хора, запознати с концепцията за service mesh в момента, са я научили за пръв път благодарение на Istio. Втората характеристика е колко зле Istio е приет. Очевидно, аз съм заинтересована страна, но опитвайки се да остана максимално обективен, не мога да не , което не е много характерно (макар и не уникално: наум ми идва systemd, …) за проект с отворен код.
(На практика, изглежда, че Istio има проблеми не само с трудността и UX, но и с производителността. Например, по време на , проведена от трета страна, експерти установяват случаи, в които задържането на латиността (tail latency) на Istio е 100 пъти по-високо от съответния показател на Linkerd, както и случаи с недостатъчни ресурси, когато Linkerd успешно функционира, а Istio напълно спира работа.)
Оставя настрани моите теории за това защо се е случило, смятам, че въодушевлението около service mesh може да се обясни с участието на Google. А именно, комбинацията от следните три фактора:
- настойчиво промотиране на Istio от страна на Google;
- съответно неодобрително и критично отношение към проекта;
- недавен стремителен ръст на популярността на Kubernetes, спомените за който все още са свежи.
Заедно тези фактори се обединяват в някакво опияняващо, безкислородно обкръжение, в което способността за рационално мислене отслабва, и остава само чудна разновидност .
От гледна точка на Linkerd, бих описал това като двусмислено благо. Имам предвид, прекрасно е, че service mesh навлезе в мейнстрийма — нещо, което не се случи през 2016-та, когато Linkerd едва се появи и наистина беше трудно да привлечеш вниманието на околните към проекта. Сега такъв проблем няма! Но лошото е, че ситуацията с service mesh днес е толкова объркана, че практически е невъзможно да разбереш кои проекти наистина попадат в категорията service mesh (да не говорим за това да разбереш кой от тях е най-подходящ за конкретния случай на използване). Това, безспорно, пречи на всички (и, определено, в някои случаи Istio или друг проект може да подхожда повече от Linkerd, тъй като последният не е универсално решение).
От страна на Linkerd нашата стратегия беше да игнорираме шума, да продължим да се фокусираме върху решаването на реални проблеми на общността и по същество да изчакаме, когато вълнението затихне. В крайна сметка хайпът ще спадне и ще можем спокойно да работим.
Засега всички трябва да се потърпим малко.
Ще е полезен ли service mesh на мен, скромния софтуерен инженер?
С отговора на този въпрос ще помогне следният въпросник:
Занимавате ли се изключително с реализиране на бизнес логика? В такъв случай service mesh няма да ви е полезен. Тоест, разбира се, можете да се заинтересувате от нея, но в идеалния случай service mesh не трябва да влияе пряко на нищо в вашето обкръжение. Продължете да работите по това, за което ви плащат.
Поддържате ли платформа в компания, която използва Kubernetes? Да, в этом случае service mesh ви е необходима (разбира се, ако не използвате K8s просто за стартиране на монолит или пакетна обработка — но тогава бих искал да попитам, за какво ви е K8s). Най-вероятно ще се окажете в ситуация с множество микросервизи, написани от различни хора. Всички те взаимодействат помежду си и са свързани в клубък от зависимости в выполняемото време, а вие трябва да намерите начин да се справите с всичко това. Използването на Kubernetes позволява да изберете service mesh, която да отговаря на вашите нужди. За целта се запознайте с техните възможности и особености и отговорете на въпроса дали изобщо някой от наличните проекти ви е подходящ (препоръчвам да започнете с Linkerd).
Занимавате ли се с платформа в компания, която НЕ използва Kubernetes, но използва микросервизи? В този случай service mesh ви е полезна, но използването ѝ ще бъде нетривиално. Разбира се, можете да имитирате работата на service mesh, разпределяйки куп проксита, но важното предимство на Kubernetes е именно моделът на разгръщане: обслужването на тези проксита ръчно ще изисква много повече време, усилия и разходи.
Отговаряте ли за платформа в компания, която работи с монолити? В този случай service mesh вероятно не ви е необходима. Ако работите с монолити (или дори с набори от монолити), които имат ясно определени и рядко променящи се модели на взаимодействие, то service mesh няма какво да ви предложи. Така че можете просто да я игнорирате и да се надявате, че ще изчезне като лош сън...
Заключение
Може би service mesh не бива все пак да се нарича „най-хиповата технология на света“ — тази съмнителна чест вероятно принадлежи на биткойн или ИИ. Може би попада в топ пет. Но ако се пробиете през слоевете шум и гама, става ясно, че service mesh носи реална полза на тези, които създават приложения в Kubernetes.
Бих искал да опитате Linkerd — инсталацията му в кластер Kubernetes (или дори в Minikube на лаптоп) , и сами ще видите за какво говоря.
ЧЗВ
— Ако игнорирам service mesh, ще изчезне ли тя?
— Трябва да ви огорча: service mesh е с нас за дълго.
— Но НЕ ИСКАМ да използвам service mesh!
— Е, не е необходимо! Просто прочетете моята анкета по-горе, за да разберете дали поне трябва да научите основите на нея.
— Нали не е това старото добро ESB/middleware под нова форма?
— Service mesh се занимава с експлоатационната логика, а не с чувството. на корпоративната сервисна шина (). Запазването на това разделение помага на service mesh да избегне същата участ.
— С какво service mesh се различава от API шлюзовете?
— Има милион статии по тази тема. Просто потърсете в Google.
— Envoy е ли service mesh?
— Не, Envoy не е service mesh, а прокси-сервер. Може да се използва за организиране на service mesh (и много повече - това е прокси за общо предназначение). Но сам по себе си той не е service mesh.
— Network Service Mesh е ли service mesh?
— Не. Въпреки името, това не е service mesh (чудо на маркетинга?).
— Ще помогне ли service mesh на моята реактивна асинхронна система, основана на опашка от съобщения?
— Не, service mesh няма да ви помогне.
— Каква service mesh да използвам?
— , очевидно.
— Статията е ужасна! / Автора — на мило!
— Моля, споделете линк към нея с всичките си приятели, за да могат да се уверят!
Благодарности
Както можете да предположите от заглавието, тази статия беше вдъхновена от фантастичния труд на Jay Kreps «». Срещнах Jay десет години назад, когато правех интервю в LinkedIn, и оттогава той ми е вдъхновение.
Въпреки че обичам да се наричам «разработчик на Linkerd», реалността е, че по-скоро съм поддържач на файла README.md в проекта. С Linkerd днес работят , , хора, и този проект не би съществувал без участието на невероятната общност от сътрудници и потребители.
И накрая, специална благодарност на създателя на Linkerd, (primus inter pares), който заедно с мен много години назад се гмурна в цялата тази суета около service mesh.
P.S. от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «»;
- «».
Източник: habr.com
