Прим. перев.: Service mesh - явище, яке ще не має стійкого перекладу російською мовою (понад 2 роки тому ми пропонували варіант «сітка для сервісів», а трохи пізніше деякі колеги стали активно просувати поєднання «сервісне сито»). Постійні розмови про цю технологію призвели до ситуації, в якій надто тісно переплелися маркетингова та технічна складові. Цей чудовий матеріал від одного з авторів оригінального терміну покликаний внести ясність інженерам і не тільки.
Комікс від
Запровадження
Якщо ви інженер-програміст, який працює десь у районі бекенд-систем, термін «service mesh», ймовірно, вже міцно закріпився у вашій свідомості за останні кілька років. Завдяки дивному збігу обставин, це словосполучення захоплює галузь все сильніше, а хайп і пов'язані з ним рекламні пропозиції наростають наче снігова куля, що летить вниз схилом і не подає ніяких ознак уповільнення.
Service mesh зародилася у каламутних, тенденційних водах екосистеми cloud native. На жаль, це означає, що значна частина пов'язаної з нею полеміки варіюється від "низькокалорійної балаканини" до - якщо скористатися технічним терміном - відвертої нісенітниці. Але якщо відсіяти весь шум, можна виявити, що у service mesh є цілком реальна, певна та важлива функція.
У цій публікації я спробую зробити саме це: уявити чесне, глибоке, орієнтоване на інженерів посібник з service mesh. Я збираюся відповісти не лише на запитання: "Що це таке?", - але і «Навіщо?», а також «Чому саме зараз?». Нарешті, спробую описати, чому (на мою думку) саме ця технологія викликала такий божевільний ажіотаж, що саме собою цікава історія.
Хто я?
Привіт всім! Мене звати . Я є одним із творців — найпершого проекту service mesh та проекту, який винен у появі терміна сервісна сітка як такого (вибачте, хлопці!). (Прим перекл.: До речі, на зорі появи цього терміну, понад 2,5 роки тому, ми вже перекладали ранній матеріал того ж автора під назвою «".) Також я очолюю - Стартап, що займається створенням таких класних service mesh-штук, як Linkerd і .
Ви, напевно, здогадуєтеся, що в мене дуже упереджена і суб'єктивна думка з цього питання. Втім, я намагатимуся звести тенденційність до мінімуму (за винятком одного розділу: "Чому так багато розмов про service mesh?", - У якому все ж таки поділюся своїми упередженими ідеями). Також я докладу всіх сил до того, щоб зробити це керівництво максимально об'єктивним. У конкретних прикладах я переважно покладатимуся на досвід Linkerd, при цьому вказуючи на відомі мені відмінності (якщо вони є) у реалізації інших типів service mesh.
Окей, час переходити до смакота.
Що таке сервіс mesh?
Незважаючи на весь хайп, структурно служба mesh влаштована досить просто. Це лише купа userspace-проксі, розташованих «поряд» із сервісами (потім ми трохи поговоримо про те, що таке «поряд»), плюс набір процесів, що управляють. Проксі разом отримали назву тарифний план, А керуючі процеси називаються контрольна площина. Data plane перехоплює виклики між сервісами та робить з ними «різне-різне»; control plane, відповідно, координує поведінку проксі та забезпечує доступ вам, тобто. оператора, до API, дозволяючи маніпулювати мережею та вимірювати її як єдине ціле.
Що це за проксі? Це TCP-проксі категорії «Layer 7-aware» (тобто «враховують» 7 рівень моделі OSI) на кшталт HAProxy та NGINX. Можна вибрати проксі на свій смак; Linkerd використовує проксі на Rust, нехитро названий . Ми зібрали його спеціально для служби 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 можна використовувати з монолітами, але це явно надмірно заради єдиного проксі, та й її функціонал навряд чи буде затребуваний.
Інший важливий наслідок полягає в тому, що служба 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.
Такий набір функцій, які пропонує служба mesh. Виникає питання: чому б не реалізувати їх безпосередньо у додатку? І навіщо взагалі зв'язуватися із проксі?
Чому service mesh – це гарна ідея
Хоча можливості service mesh захоплюють уяву, її основна цінність насправді не в функціях. Зрештою, ми можем реалізувати їх у додатку (пізніше ми побачимо, що таке було походження service mesh). Якщо спробувати висловити цю думку одним реченням, цінність service mesh полягає в наступному: вона надає функції, критично важливі для роботи сучасного серверного програмного забезпечення, однаковим для всього стека та незалежним від коду програми чином.
Давайте проаналізуємо цю пропозицію.
«Функції, що критично важливі для роботи сучасного серверного програмного забезпечення». Якщо ви створюєте транзакційну серверну програму, пов'язану з публічним інтернетом, приймає запити із зовнішнього світу і відповідає на них протягом короткого часу — наприклад, веб-додаток, API-сервер, та й переважна більшість інших сучасних додатків, — і якщо ви реалізуєте його як набір з сервісів, які синхронно взаємодіють один з одним, і якщо ви постійно модернізуєте це програмне забезпечення, додаючи нові можливості, і якщо ви змушені підтримувати цю систему в працездатному стані в процесі модифікації — у цьому випадку вітаю вас, ви займаєтеся створенням сучасного серверного програмного забезпечення . І всі ці чудові функції, наведені вище, насправді виявляються критично важливими для вас. Програма повинна бути надійною, безпечною, і ви повинні мати можливість спостерігати за тим, що воно робить. Саме ці питання і допомагає вирішити служба mesh.
(Окей, у попередній абзац все ж таки пробралася моя переконаність у тому, що цей підхід є сучасним способом створювати серверне ПЗ. Інші воліють розробляти моноліти, «реактивні мікросервіси» та інші штуки, що не підпадають під визначення, наведене вище. У цих людей, напевно, є свою думку, відмінну від моєї, у свою чергу, я вважаю, що вони «не мають рації» (хоча в будь-якому випадку service mesh для них не надто корисна).
«Єдиним для всього стеку». Функції, що надаються службами mesh, не просто критично важливі. Вони застосовуються до всіх сервісів у додатку незалежно від того, якою мовою ті написані, який фреймворк використовують, хто їх написав, як вони були розгорнуті і від інших тонкощів їх розробки та застосування.
«Незалежним від коду програми». Нарешті, service mesh не тільки надає єдині функціональні можливості для всього стека - вона робить це способом, що не вимагає редагування програми. Фундаментальна основа функціональності service mesh, включаючи завдання налаштування, оновлення, експлуатації, обслуговування і т.д., знаходиться виключно на рівні платформи і незалежна від додатка. Програма може змінюватися, не торкаючись service mesh. У свою чергу, служба 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 — це швидше рішення не технічної, а соціо-технічної проблеми. (Дякую за знайомство з цим терміном.)
Чи вирішить служба mesh всі мої проблеми?
Так. У сенсі ні!
Якщо подивитися на три класи функцій, озвучених вище: надійність, безпека та спостережуваність, стає зрозуміло, що service mesh не є повноцінним рішенням для жодної з цих проблем. Хоча Linkerd може надсилати повторні запити (якщо знає, що вони ідемпотентні), він не може приймати рішення про те, що повертати користувачу, якщо сервіс остаточно впав — такі рішення має приймати додаток. Linkerd може вести статистику успішних запитів, проте він не в змозі зазирнути в сервіс і надати його внутрішні метрики - подібний інструментарій має бути у додатку. І хоча Linkerd здатний організовувати mTLS, повноцінні рішення у справі забезпечення безпеки потребують значно більшого.
Підмножина функцій у цих областях, пропонованих service mesh, відносяться до фічам платформи. Під цим я маю на увазі функції, які:
- Незалежні від бізнес-логіки. Спосіб, яким ведеться побудова гістограм викликів між Foo та Bar, зовсім не залежить від того, чому Foo викликає Bar.
- Важко правильно реалізувати. У Linkerd повторні спроби параметризуються всякими накрученими штуками на кшталт бюджетів повторних спроб (retry budgets), оскільки нехитрий підхід у лоб у реалізації подібних речей напевно призведе до виникнення так званої «лавини запитів» (Retry storm) та інших проблем, характерних для розподілених систем.
- Найбільш ефективні, коли застосовуються однаково. Механізм TLS має сенс у тому випадку, коли застосовується скрізь.
Оскільки ці функції реалізовані на рівні проксі (а не на рівні програми), служба mesh надає їх на рівні платформи, а не програми. Таким чином, не важливо, якою мовою написані сервіси, який фреймворк вони використовують, хто їх написав і чому. Проксі працюють за межами всіх цих подробиць, а фундаментальна основа цієї функціональності, включаючи завдання налаштування, оновлення, експлуатації, обслуговування і т. д., лежить виключно на рівні платформи.
Приклади можливостей service mesh
Підсумовуючи, хочу сказати, що служба mesh не є повним рішенням для забезпечення надійності, спостережуваності або безпеки. Розмах цих областей передбачає обов'язкову участь власників сервісів, Ops/SRE-команд та інших суб'єктів компанії. Service mesh надає лише "зріз" на рівні платформи для кожної з цих областей.
Чому service mesh стала популярною саме зараз?
Ймовірно, зараз ви ставите питання: окей, якщо service mesh настільки хороша, чому ми не почали розгортати мільйони проксі в стеку років десять тому?
Є банальна відповідь на це питання: десять років тому всі будували моноліти, і служба 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 вирішує сьогодні. Однак самої служби 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 сервісів). Додайте до цього контейнери як механізм упаковки, що заохочує мультимовну реалізацію, і отримайте масу нових додатків, реалізованих у формі мікросервісів, написаних різними мовами — саме те середовище, для якого так добре підходить служба 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 наша стратегія полягала в тому, щоб ігнорувати шум, продовжувати концентруватися на вирішенні реальних проблем співтовариства і, по суті, чекати, коли ажіотаж вщухне. Зрештою, хайп піде на спад, і ми зможемо продовжувати спокійно працювати.
Поки що нам усім доведеться трохи потерпіти.
Чи знадобиться служба mesh мені, скромному software engineer?
З відповіддю це питання допоможе визначитися наступний опитувальник:
Ви займаєтеся виключно реалізацією бізнес-логіки? У цьому випадку служба mesh вам не знадобиться. Тобто, звичайно, ви можете нею зацікавитися, але в ідеалі service mesh не повинна прямо впливати на що-небудь у вашому оточенні. Продовжуйте працювати над тим, за що платять.
Ви підтримуєте платформу у компанії, яка використовує Kubernetes? Так, у цьому випадку service mesh вам необхідна (звичайно, якщо ви не використовуєте K8s просто для запуску моноліту або пакетної обробки, але тоді я хотів би поцікавитися, навіщо вам K8s). Швидше за все, ви опинитеся в ситуації з багатьма мікросервісами, написаними різними людьми. Всі вони взаємодіють один з одним і пов'язані в клубок runtime-залежностей, а вам потрібно знайти спосіб впоратися з усім цим. Застосування Kubernetes дозволяє вибрати service mesh під себе. Для цього ознайомтеся з їхніми можливостями та особливостями та дайте відповідь на запитання, чи підходить вам взагалі якийсь проект з наявних (рекомендую почати дослідження з Linkerd).
Ви займаєтеся платформою в компанії, яка не використовує Kubernetes, але використовує мікросервіси? У цьому випадку служба mesh вам буде корисною, проте її використання буде нетривіальним. Звичайно, ви можете імітувати роботу service mesh, розмістивши купу проксі, але важливою перевагою Kubernetes є саме модель розгортання: обслуговування цих проксі вручну вимагатиме набагато більших часу, сил та витрат.
Ви відповідаєте за платформу у компанії, яка працює з монолітами? У цьому випадку служба mesh вам, ймовірно, не потрібна. Якщо ви працюєте з монолітами (або навіть з наборами монолітів), які мають чітко визначені і рідко змінюються патерни взаємодії, то service mesh мало що зможе запропонувати вам. Отже, можете просто не помічати її і сподіватися, що вона зникне як страшний сон.
Висновок
Напевно, service mesh все-таки не варто називати «найхай-технологією світу» — ця сумнівна честь, ймовірно, належить біткоїну або ІІ. Можливо, вона входить до першої п'ятірки. Але якщо пробитися крізь шари шуму і гамма, стає зрозуміло, що служба mesh приносить реальну користь тим, хто створює програми в Kubernetes.
Я хотів би, щоб ви спробували Linkerd — його встановлення в кластері Kubernetes (або навіть у Minikube на ноутбуці) , і ви зможете самі побачити, про що я говорю.
FAQ
— Якщо я ігноруватиму service mesh, вона зникне?
— Мушу вас засмутити: service mesh з нами надовго.
- Але я НЕ ХОЧУ використовувати service mesh!
- Ну і не треба! Тільки почитайте мій опитувальник вище, щоб зрозуміти, чи варто ознайомитись хоча б з її азами.
— Хіба це не старе добре ESB/Middleware під новим соусом?
— Service mesh займається експлуатаційною логікою, а не значеннєвою. сервісної шини підприємства (). Збереження цього поділу допомагає службі mesh уникнути тієї ж долі.
— Чим сервіс mesh відрізняється від API-шлюзів?
— Існує мільйон статей на цю тему. Просто погуглить.
- Envoy – це service mesh?
- Ні, Envoy - це не служба mesh, це проксі-сервер. Його можна використовувати для організації service mesh (і багато іншого - це проксі загального призначення). Але сам по собі він не є сервісним меню.
- Network Service Mesh - це Service Mesh?
- Ні. Незважаючи на назву, це не service mesh (як вам чудеса маркетингу?).
— Чи допоможе service mesh із моєю реактивною асинхронною системою на базі черги повідомлень?
— Ні, служба mesh вам не допоможе.
- Яку послугу mesh мені використовувати?
- їжу зрозуміло.
- Стаття - відстій! / Автора – на мило!
— Будь ласка, поділіться посиланням на неї з усіма друзями, щоб вони змогли переконатися в цьому!
Подяки
Як ви могли здогадатися за назвою, цю статтю надихнули фантастичний трактат Jay Kreps «». Я зустрів Jay'я десять років тому, коли брав інтерв'ю в Linked In, і з тих пір він служить натхненням для мене.
Хоча я люблю називати себе «розробником Linkerd», реальність така, що я скоріше maintainer файлу README.md у проекті. Над Linkerd сьогодні працює , , людей, і цей проект не відбувся без участі чудової спільноти контріб'юторів та користувачів.
І на завершення особлива подяка творцю Linkerd, (primus inter pares), Який разом зі мною багато років тому пірнув з головою у всю цю суєту з service mesh.
PS від перекладача
Читайте також у нашому блозі:
- «»;
- «»;
- «»;
- «»;
- «».
Джерело: habr.com