Прим. прев.: Service mesh — явление, което все още няма устойчива превод на български (преди повече от 2 години предложихме вариант „мрежа за услуги“, а малко по-късно някои колеги започнаха активно да популяризират съчетанието „услужна сито“). Постоянните разговори за тази технология доведоха до ситуация, в която маркетинговата и техническата съставки са твърде плътно преплетени. Този забележителен материал от един от авторите на оригиналния термин цели да внесе яснота за инженерите и не само.
Комикс от
Въведение
Ако сте инженер-програмист, работещ някъде в областта на бекенд системите, терминът „service mesh“ вероятно вече е намерил твърдо място в съзнанието ви през последните няколко години. Поради странно стечение на обстоятелствата, това словосъчетание все по-силно завладява индустрията, а хипът и свързаните с него рекламни предложения нарастват като снежна топка, спускаща се по склон и не проявяваща никакви признаци на забавяне.
Service mesh се зароди в размазаните, тенденциозни води на екосистемата cloud native. За съжаление, това означава, че значителната част от свързаната с нея полемика варира от „нискокалорна бърбория“ до — ако използваме технически термин — откровена глупост. Но ако се отсеят всички шумове, може да се открие, че 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, която събира метрики от прокси-сървъри, както и други компоненти, като дестинация (откриване на услуги), identity (център за сертификация, CA) и public-api (ендпойнти за уеб и 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 трябва да бъдат бързи,тъй като на всяко извикване се падат две обращения към проксито: едно от страна на клиента, едно — от страна на сървъра.
- Също така прокситата трябва да бъдат малки, и лекава.Всяко ще консумира ресурси от паметта и ЦП, а консумацията ще нараства линейно с приложението.
- Ще ви е необходим механизъм за разполагане и актуализиране на голямо количество проксита. Правенето на това ръчно не е вариант.
Общо взето, service mesh изглежда така (поне от височина птичия поглед): разгръщате куп userspace-прокси, които „правят нещо“ с вътрешния, междусервисен трафик, и използвате control plane за мониторинг и управление на тях.
Сега е време за въпроса „Защо?“
За какво е необходим 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 решава днес. Обаче самият 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 задачата да ги прикрепи където е възможно и voilà! На изхода получавате service mesh, като цялата механика на нейното разгръщане се управлява от Kubernetes. (Поне от височината на птичия поглед. Разбира се, в този процес има много нюанси.)
В заключение: причината, поради която service mesh стана популярна точно сега, а не преди десет години, е, че Kubernetes и Docker не само значително увеличиха потребността от нея, опростявайки реализацията на приложенията като набори от многожични микросервиси, но и съществено намалиха разходите за нейното експлоатиране, осигурявайки механизми за разгръщане и поддръжка на паркове от sidecar-прокси.
Защо има толкова много разговори за service mesh?
Предупреждение: в този раздел прибягвам до всякакви предположения, догадки, измислици и вътрешна информация.
Ако потърсите фразата «service mesh», ще се натъкнете на множество преработено нискокалорично съдържание, странни проекти и калейдоскоп от изкривявания, достойни за ехо-камера. Това е присъщо за всяка нова модна технология, но в случая с service mesh проблемът е особено изразен. Защо?
Е, част от вината е моя. Направих всичко възможно да популяризирам Linkerd и service mesh при всяка удобна възможност чрез безброй публикации в блогове и статии, подобно на тази. Но не съм толкова мощен. За да отговорим на този въпрос, е необходимо да поговорим малко за общата ситуация. А да говорим за нея не е възможно, без да споменем един проект: — open-source service mesh, разработван в партньорство с Google, IBM и Lyft.
(Тези три компании имат напълно различни роли: участието на Lyft изглежда се свежда единствено до името; те са автори на Envoy, но не използват Istio или участват в неговото развитие. IBM участва в разработката на Istio и го използва. Google активно участва в разработката на Istio, но, доколкото мога да съдя, наистина не го използва.)
Проектът Istio е забележителен с две характеристики. Първо, това са огромните маркетингови усилия, които Google, по-специално, полага за популяризирането му. По мои оценки, повечето хора, запознати с концепцията за service mesh в момента, за първи път чуха за нея благодарение на Istio. Втората характеристика е, колко лошо беше прието Istio. В този въпрос очевидно съм заинтересована страна, но опитвайки се да остана максимално обективен, все пак не мога да не , не особено характерно (въпреки че не уникално: наум ми идва systemd, …) за Open Source проект.
(На практика, изглежда, Istio има проблеми не само със сложността и UX, но и с производителността. Например, по време на , извършена от трета страна, специалистите откриха ситуации, в които задръжките на Istio (tail latency) са 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). Най-вероятно ще се окажете в ситуация с множество микросервизи, написани от различни хора. Всички те взаимодействат помежду си и са свързани в клуб от runtime зависимости, а вие трябва да намерите начин да се справите с всичко това. Използването на 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
