Заўв. перав.: 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, а кіраўнікі працэсы называюцца самалёт кіравання. 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-кантэйнер.)
Архітэктура служба Mesh мае некалькі важных наступстваў. Па-першае, паколькі задача проксі - перахапляць выклікі паміж сэрвісамі, service mesh мае сэнс толькі ў тым выпадку, калі ваша прыкладанне стваралася на нейкі набор сэрвісаў. Mesh можна выкарыстоўваць з маналітамі, але гэта відавочна залішне дзеля аднаго адзінага проксі, ды і яе функцыянал ці наўрад будзе запатрабаваны.
Іншае важнае наступства складаецца ў тым, што service mesh патрабуе вялізнага колькасці проксі. Насамрэч, Linkerd чапляе linkerd-proxy да кожнага асобніка кожнага сэрвісу (іншыя рэалізацыі дадаюць проксі да кожнага вузла/хасту/віртуальнай машыны. У любым выпадку, гэта нямала). Гэтак актыўнае выкарыстанне проксі само па сабе нясе шэраг дадатковых ускладненняў:
- Проксі ў data plane павінны быць хуткімі, паколькі на кожны выклік прыходзіцца пара зваротаў да проксі: адно на баку кліента, адно - на баку сервера.
- Таксама проксі павінны быць невялікімі и легкаважнымі. Кожная будзе спажываць рэсурсы памяці і CPU, і гэта спажыванне будзе лінейна расці разам з дадаткам.
- Вам спатрэбіцца механізм для разгортвання і абнаўленні вялікай колькасці проксі. Рабіць гэта ўручную - не варыянт.
Увогуле, service mesh выглядае так (прынамсі, з вышыні птушынага палёту): вы разгортваеце кучу userspace-проксі, якія "нешта робяць" з унутраным, міжсэрвісным трафікам, і выкарыстоўваеце control plane для маніторынгу і кіраванні імі.
Надышла чарга пытання «Навошта?»
Навошта патрэбная служба 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 могуць "даказаць", што яны тыя, кім сябе называюць.
* "Адзін аднаго" азначае, што сертыфікат кліента таксама правяраецца (mutual 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.
І ўсё, што для гэтага трэба, - дадаць кучу проксі! Абяцаю, вельмі хутка мы разгледзім эксплуатацыйныя выдаткі, звязаныя з даданнем гэтых проксі. Але спачатку давайце спынімся і зірнем на гэтую ідэю аб незалежнасці з пункту гледжання розных. людзей.
Каму дапамагае служба 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 задачу прыляпіць іх куды толькі можна, і вуаля! На вынахадзе атрымліваеце service mesh, пры гэтым усёй механікай яе разгортвання запраўляе Kubernetes. (Прынамсі, з вышыні птушынага палёту. Вядома, у гэтым працэсе ёсць мноства нюансаў.)
Падводзячы вынік: прычына, па якой service mesh стала папулярнай менавіта цяпер, а не дзесяць гадоў таму, складаецца ў тым, што Kubernetes і Docker не толькі значна павялічылі. патрэба у ёй, спрасціўшы рэалізацыю прыкладанняў як набораў мультымоўных мікрасэрвісаў, але і істотна скарацілі выдаткі на яе эксплуатацыю, забяспечыўшы механізмы разгортвання і падтрымкі паркаў sidecar-проксі.
Чаму так шмат размоваў аб service mesh?
Папярэджанне: у гэтым раздзеле я звяртаюся да ўсялякіх здагадак, здагадак, выдумак і ўнутранай інфармацыі.
Правёўшы пошук па фразе "service mesh", вы натыкнецеся на кучу перапрацаванага нізкакаларыйнага кантэнту, дзіўных праектаў і калейдаскопа скажэнняў, годных рэха-камеры. Любы моднай новай тэхналогіі ўласціва гэта, але ў выпадку service mesh праблема стаіць асабліва востра. Чаму?
Ну, часткова гэта мая віна. Я прыкладаў усе сілы, каб прасунуць Linkerd і service mesh пры любой зручнай магчымасці, шляхам незлічоных публікацый у блогу і артыкулаў, падобных да гэтай. Але я не настолькі магутны. Каб сапраўды адказаць на гэтае пытанне, варта крыху пагаварыць аб агульнай сітуацыі. А казаць пра яе немагчыма, не згадаўшы адзін праект: – service mesh з адкрытым зыходным кодам, якая распрацоўваецца сумесна Google, IBM і Lyft.
(У гэтых трох кампаній зусім розныя ролі: удзел Lyft, падобна, зводзіцца да адной толькі назову; яны з'яўляюцца аўтарамі Envoy, але не выкарыстоўваюць Istio або ўдзельнічаюць у яго распрацоўцы. IBM удзельнічае ў распрацоўцы Istio і выкарыстоўвае яго. Google актыўна ўдзельнічае ў распрацоўцы Istio , але, наколькі магу судзіць, на самой справе не выкарыстоўвае яго.)
Праект Istio адметны двума асаблівасцямі. Па-першае, гэта вялізныя маркетынгавыя намаганні, якія Google, у прыватнасці, прыкладае да яго прасоўванні. Па маіх ацэнках, большасць людзей, дасведчаных аб канцэпцыі service mesh у цяперашні час, упершыню пазналі пра яе дзякуючы Istio. Другая асаблівасць заключаецца ў тым, наколькі дрэнна Istio быў прыняты. У гэтым пытанні я, відавочна, бок зацікаўлены, але спрабуючы заставацца максімальна аб'ектыўным, усё ж не магу не , не вельмі-то характэрны (хоць і не ўнікальны: на розум прыходзіць systemd, …) для Open Source-праекта.
(На практыцы ў 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 мне, сціпламу software engineer?
З адказам на гэтае пытанне дапаможа вызначыцца наступны апытальнік:
Вы займаецеся выключна рэалізацыяй бізнэс-логікі? У гэтым выпадку 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-шлюзаў?
- Існуе мільён артыкулаў на гэтую тэму. Проста пагугліце.
- 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'я XNUMX гадоў таму, калі браў інтэрв'ю ў Linked In, і з тых часоў ён служыць натхненнем для мяне.
Хоць я люблю называць сябе "распрацоўшчыкам Linkerd", рэальнасць такая, што я хутчэй maintainer файла README.md у праекце. Над Linkerd сёння працуе , , людзей, і гэты праект не адбыўся б без удзелу выдатнай супольнасці кантрыб'ютараў і карыстальнікаў.
І ў завяршэнне асаблівая падзяка стваральніку Linkerd, (primus inter pares), Які разам са мной шмат гадоў таму нырнуў з галавой ва ўсю гэтую мітусню з service mesh.
PS ад перакладчыка
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «»;
- «»;
- «.
Крыніца: habr.com