Service Mesh – відомий архітектурний патерн для інтеграції мікросервісів та переходу на хмарну інфраструктуру. Сьогодні у хмарно-контейнерному світі обійтися без нього досить складно. На ринку вже доступні кілька open-source реалізацій service mesh, але їхньої функціональності, надійності та безпеки далеко не завжди достатньо, особливо коли йдеться про вимоги великих фінансових компаній масштабу всієї країни. Тому ми в Сбертеху вирішили кастомізувати Service Mesh і хочемо розповісти про те, що Service Mesh круто, що не дуже і що ми з цим збираємося зробити.
Популярність шаблону Service Mesh зростає із популярністю хмарних технологій. Він є виділений інфраструктурний шар, який спрощує взаємодію між різними мережевими сервісами. Сучасні хмарні програми складаються з сотень і навіть тисяч таких сервісів, кожен з яких може мати тисячі копій.
Взаємодія між цими сервісами та керування ними – ключове завдання Service Mesh. Фактично це мережева модель з безлічі проксі, керована централізовано і виконує набір корисних функцій.
На рівні проксі (data plane):
- Призначення та поширення політик маршрутизації та балансування трафіку
- Розповсюдження ключів, сертифікатів, токенів
- Збір телеметрії, формування метрик моніторингу
- Інтеграція з інфраструктурою безпеки та моніторингу
На рівні керуючого контуру (control plane):
- Застосування політик маршрутизації та балансування трафіку
- Управління повторами та таймаутами, визначення «мертвих» вузлів (сircuit breaking), управління збійними ситуаціями (injecting faults) та забезпечення стійкості (resilence) сервісів через інші механізми
- Аутентифікація/авторизація дзвінків
- Відкидання метрик (observability)
Коло користувачів, зацікавлених у розвитку цієї технології, дуже широке - від невеликих стартапів до великих інтернет-корпорацій, наприклад, PayPal.
Для чого потрібен Service Mesh у корпоративному секторі
Використання Service Mesh приносить безліч очевидних переваг. Насамперед, це просто зручно розробникам: для написання коду з'являється технологічна платформа, яка суттєво спрощує інтеграцію до хмарної інфраструктури за рахунок того, що транспортний шар повністю ізольований від прикладної логіки.
Крім того, Service Mesh спрощує взаємини постачальників та споживачів. Сьогодні постачальникам та споживачам API набагато простіше домовитися про інтерфейси та контракти самостійно, не залучаючи для цього спеціального інтеграційного посередника та арбітра – корпоративну сервісну шину. Такий підхід суттєво впливає на два показники. Збільшується швидкість виведення нової функціональності ринку (time-to-market), та заодно підвищується вартість рішення, оскільки інтеграцію доводиться робити самостійно. Використання Service Mesh командами розробки бізнес-функціональності дозволяє зберегти тут баланс. У результаті постачальники API можуть сфокусуватися виключно на прикладній складовій свого сервісу і просто опублікувати його в Service Mesh - API відразу стане доступним всім клієнтам, а якість інтеграції буде production ready і не вимагатиме жодного рядка додаткового коду.
Наступною перевагою є те, що розробник, використовуючи Service Mesh, фокусується виключно на бізнес-функціональності — на продуктовій, а не на технологічній складовій свого сервісу. Наприклад, вже не доводиться думати про те, що в ситуації, коли сервіс викликатиметься по мережі, може статися обрив з'єднання. Крім того, Service Mesh допомагає збалансувати трафік між копіями одного і того ж сервісу: якщо одна з копій «померла», то система переключить весь трафік на живі копії, що залишилися.
Сервісна сітка - це хороша основа для створення розподілених програмяка приховує від клієнта деталі забезпечення викликів його сервісів як зсередини, так і зовні. Усі програми, що використовують Service Mesh, на транспортному рівні ізольовані і від мережі, і одна від одної: жодного зв'язку між ними немає. При цьому розробник отримує повний контроль за своїми сервісами.
Не можна не відзначити, що оновлення розподілених програм у середовищі, де використовується Service Mesh, стає простіше. Наприклад, blue/green-розгортання, при якому для установки доступні два середовища програми, одне з яких не оновлюється і знаходиться в режимі очікування. Відкат на минулу версію у разі невдалого релізу здійснюється спеціальним роутером, за роллю якого чудово справляється Service Mesh. Для обкатки нової версії можна використовувати і канарковий реліз — переключити на нову версію лише 10% трафіку чи запити від пілотної групи клієнтів. Основний трафік йде на стару версію, нічого не ламається.
Також Service Mesh дає нам контроль SLA у реальному часі. Система розподілених проксі не дозволить завалити сервіс, коли хтось із клієнтів перевищить видану квоту. Якщо пропускна спроможність API обмежена, ніхто не зможе задовольнити його великою кількістю транзакцій: Service Mesh стоїть перед сервісом і не пропускає зайвий трафік. Він просто відбиватиметься в інтеграційному шарі, а самі послуги продовжать працювати, не помічаючи цього.
Якщо компанія хоче скоротити витрати на розвиток інтеграційних рішень, Service Mesh також рятує: на його open-source версії можна перейти з комерційних продуктів. Наш Enterprise Service Mesh базується на open-source версії Service Mesh.
Ще одна перевага - наявність єдиного повноцінного набору інтеграційних сервісів. Оскільки вся інтеграція будується через цей проміжний шар, ми можемо керувати всім інтеграційним трафіком та зв'язками між програмами, які формують бізнес-ядро компанії. Це дуже зручно.
І наостанок Service Mesh стимулює компанію переходити на динамічну інфраструктуру. Зараз багато хто дивиться у бік контейнеризації. Розпилювати моноліт на мікросервіси, все це красиво впроваджувати – тема знаходиться на підйомі. Але коли ти намагаєшся перевести на нові рейки систему, яка вже багато років у продакшні, то одразу стикаєшся з цілим рядом проблем: заштовхати все це у контейнери та розгорнути на платформі непросто. А впровадження, синхронізація та взаємодія цих розподілених компонентів є ще однією складною темою. Як вони спілкуватимуться один з одним? Чи не буде каскадних збоїв? Service Mesh дозволяє вирішити частину цих проблем та полегшити міграцію зі старої архітектури на нову за рахунок того, що про логіку мережного обміну можна забути.
Навіщо потрібна кастомізація Service Mesh
У нас у компанії уживаються разом сотні систем та модулів, а runtime дуже навантажений. Так що простого патерна, коли одна система викликає іншу і отримує відповідь, недостатньо, тому що у production ми хочемо більшого. Що ще потрібно від корпоративного Service Mesh?
Сервіс обробки подій
Уявімо, що нам потрібно зробити real-time event processing - систему, яка в реальному часі аналізує дії клієнта і може одразу зробити йому релевантну пропозицію. Щоб реалізувати подібну функціональність, використовується архітектурний патерн під назвою event-driven architecture (EDA). Жоден з актуальних Service Mesh такі патерни нативно не підтримує, адже це дуже важливо, особливо для банку!
Досить дивно, що «віддалений виклик» Remote Procedure Call (RPC) підтримують усі версії Service Mesh, а з EDA вони не дружать. Тому що Service Mesh – це подібність сучасної розподіленої інтеграції, а EDA – дуже актуальний архітектурний патерн, який дозволяє робити унікальні речі щодо клієнтського досвіду.
Наш Enterprise Service Mesh цю проблему має вирішувати. Крім того, ми хочемо бачити в ньому реалізацію гарантованої доставки, потокової та комплексної обробки подій з використанням різноманітних фільтрів та шаблонів.
Сервіс передачі файлів
Крім EDA було б непогано мати можливість передавати файли: в масштабах Enterprise часто можлива тільки файлова інтеграція. Зокрема, використовується архітектурний патерн ETL (Extract, Transform, Load - "витяг, перетворення, завантаження"). У ньому, як правило, всі обмінюються виключно файлами: використовуються великі дані, які недоцільно пхати окремими запитами. Можливість нативної підтримки передачі файлів у Enterprise Service Mesh дає необхідну бізнесу гнучкість.
Сервіс оркестрації
У великих організаціях майже завжди є різні команди, які виготовляють різні продукти. Наприклад, у банку одні команди працюють із депозитами, а інші — із кредитними продуктами, і таких кейсів досить багато. Це різні люди, різні команди, які роблять свої продукти, розробляють свої API та надають їх іншим. І часто виникає потреба у композиції цих сервісів, і навіть імплементації складної логіки послідовного виклику набору API. Для вирішення цієї проблеми необхідне рішення в інтеграційному шарі, яке дозволить спростити всю цю композитну логіку (виклик кількох API, опис запитів і т.д.). Це і є сервіс оркестрації Enterprise Service Mesh.
AI та ML
Коли мікросервіси спілкуються через єдиний інтеграційний шар, Service Mesh, природно, знає про виклики кожного сервісу. Ми збираємо телеметрію: хто кого викликав, коли, як довго, скільки разів і таке інше. Коли цих сервісів сотні тисяч, а викликів — мільярди, все це накопичується і формує Big Data. Ці дані можна проаналізувати засобами ІІ, machine learning та ін., а потім зробити на основі результатів аналізу якісь корисні речі. Було б доречно хоча б частково передати штучному інтелекту управління всім цим мережевим трафіком та викликами додатків, інтегрованих у Service Mesh.
Сервіс API Gateway (Шлюз API)
Як правило, у Service Mesh є проксі та сервіси, які звертаються один з одним усередині довіреного периметра. Але є ще й зовнішні контрагенти. Вимоги до API, що надаються цій групі споживачів, набагато серйозніші. Це завдання ми ділимо на дві основні частини.
- Безпека. Питання, пов'язані з ddos, уразливістю протоколів, додатків, операційних систем тощо.
- Масштаби. Коли рахунок API, які потрібно віддати клієнтам, йде на тисячі або навіть сотні тисяч, виникає потреба в якомусь засобі управління цим набором API. Потрібно постійно відстежувати API: працюють вони чи ні, у якому статусі, який трафік йде, яка статистика тощо. Шлюз API повинен справлятися з цим завданням, роблячи весь процес керованим та безпечним. Завдяки цьому компоненту Enterprise Service Mesh навчається без зайвих складнощів публікувати як внутрішній API, так і зовнішній.
Сервіс підтримки специфічних протоколів та форматів даних (шлюз АС)
На даний момент більшість рішень Service Mesh вміють працювати тільки з трафіком HTTP і HTTP2 або в урізаному режимі на рівні TCP/IP. У Enterprise Service Mesh з'являється багато інших специфічних протоколів передачі. Одні системи можуть використовувати брокери повідомлень, інші інтегровані лише на рівні баз даних. Якщо компанія має SAP, він також може використовувати власну систему інтеграції. Причому все це працює та є важливою частиною бізнесу.
Не можна просто сказати: Давайте відмовимося від legacy і зробимо нові системи, які зможуть використовувати Service Mesh. Щоб подружити всі старі системи з новими (на мікросервісній архітектурі), системам, які можуть використовувати Service Mesh, знадобиться адаптер, посередник, шлюз. Погодьтеся, було б непогано, якби він постачався в коробці разом із сервісом. Шлюз АС таки може підтримати будь-який варіант інтеграції. Тільки уявіть, що ви просто встановлюєте Enterprise Service Mesh, і він уже готовий взаємодіяти з усіма протоколами, які вам потрібні. Для нас такий підхід дуже важливий.
Приблизно так представляємо корпоративну версію Service Mesh (Enterprise Service Mesh). Описана кастомізація вирішує більшість проблем, що виникають при спробах використовувати готові версії open-source інтеграційної платформи. З'явившись лише кілька років тому, архітектура Service Mesh продовжує розвиватися, і ми раді, що можемо зробити внесок у її розвиток. Сподіваємось, що наш досвід буде вам корисним.
Джерело: habr.com