Защо правим Enterprise Service Mesh

Service Mesh — известен архитектурен патерн за интеграция на микросервизи и преминаване към облачна инфраструктура. Днес е доста трудно да се заобиколи без него в облачно-контейнерния свят. На пазара вече са налични няколко open-source реализации на service mesh, но функционалността, надеждността и сигурността им не винаги са достатъчни, особено когато става въпрос за изискванията на големи финансови компании от мащаба на цяла страна. Затова в Сбертех решихме да кастомизираме Service Mesh и искаме да разкажем какво е страхотно в Service Mesh, какво не е толкова и какво смятаме да направим с това.

Популярността на шаблона Service Mesh нараства с популярността на облачните технологии. Той представлява отделен инфраструктурен слой, който опростява взаимодействието между различни мрежови услуги. Съвременните облачни приложения се състоят от стотици и дори хиляди такива услуги, всяка от които може да има хиляди копия.

Взаимодействието между тези услуги и управлението им е ключовата задача на Service Mesh. Всъщност това е мрежова модел от множество проксита, управлявани централизирано и изпълняващи набор от много полезни функции.

На ниво прокси (data plane):

• Назначаване и разпространение на политики за маршрутизиране и балансировка на трафика
• Разпространение на ключове, сертификати, токени
• Събиране на телекометрия, генериране на метрики за мониторинг
• Интеграция с инфраструктура за сигурност и мониторинг

На ниво управляващ контрол (control plane):

• Прилагане на политики за маршрутизиране и балансировка на трафика
• Управление на повторения и таймаути, определяне на "мъртви" възли (сircuit breaking), управление на фалитни ситуации (injecting faults) и осигуряване на устойчивост (resilience) на услугите чрез други механизми
• Аутентификация/авторизация на извиквания
• Отхвърляне на метрики (observability)

Кръгът на потребителите, заинтересовани в развитието на тази технология, е много широк — от малки стартиращи компании до големи интернет корпорации, например PayPal.

За какво е необходим Service Mesh в корпоративния сектор

Използването на Service Mesh носи много очевидни предимства. На първо място, това е просто удобно за разработчиците: за написването на кода появява се технологична платформа, който значително опростява интеграцията в облачната инфраструктура, тъй като транспортният слой е напълно изолиран от приложната логика.

Освен това, Service Mesh опростява отношенията между доставчици и потребители. Днес на доставчиците и потребителите на API им е много по-лесно да се споразумеят за интерфейсите и договорите сами, без да привлекат специален интеграционен посредник и арбитър – корпоративна сервисна шина. Този подход значително влияе на два показателя. Увеличава се скоростта на пускане на нова функционалност на пазара (time-to-market), но в същото време нараства цената на решението, тъй като интеграцията трябва да се извършва самостоятелно. Използването на Service Mesh от екипите, разработващи бизнес функционалност, позволява запазването на баланса. В крайна сметка, доставчиците на API могат да се фокусират изключително върху приложната част на своя сервис и просто да го публикуват в Service Mesh — API веднага ще бъде достъпен за всички клиенти, а качеството на интеграцията ще бъде готово за производство и няма да изисква нито ред допълнителен код.

Следващото предимство е, че разработчикът, използвайки Service Mesh, се фокусира изцяло върху бизнес функционалността — върху продуктова, а не технологична част на своя сервис. Например, вече не е нужно да се мисли как, в ситуация когато сервизът ще бъде извикан по мрежата, може да се случи прекъсване на връзката. Освен това, Service Mesh помага да се балансира трафикът между копия на един и същ сервис: ако едно от копията 'умре', системата ще пренасочи целия трафик към оставащите живи копия.

Service Mesh — е добра основа за създаване на разпределени приложения, която крие от клиента детайлите на осигуряване на повикванията на неговите сървиси както отвътре, така и отвън. Всички приложения, използващи Service Mesh, на транспортно ниво са изолирани както от мрежата, така и едно от друго: няма никаква връзка между тях. В същото време разработчикът получава пълен контрол върху своите сървиси.

Не може да не се отбележи, че обновяването на разпределените приложения в среда, в която се използва Service Mesh, става по-лесно. Например, blue/green разгръщане, при което за инсталация са налични две среда на приложението, едната от които не се обновява и е в режим на изчакване. Възстановяването на предишната версия в случай на неуспешен релиз се извършва от специален рутер, с което Service Mesh се справя отлично.. За тестване на новата версия може да се използва и канарена версия — пренасочете към новата версия само 10% от трафика или заявки от пилотна група клиенти. Основният трафик остава на старата версия, нищо не се разваля.

Също така Service Mesh ни предоставя контрол на SLA в реално време. Системата от разпределени проксита няма да позволи да се провали услугата, когато някой от клиентите надвиши определената му квота. Ако пропускателната способност по API е ограничена, никой няма да може да направи DDoS атака с голям брой транзакции: Service Mesh стои пред услугата и не пропуска излишен трафик. Той просто ще бъде отблъснат на интеграционния слой, а самите услуги ще продължат да работят, без да го забелязват.

Ако компанията иска да намали разходите за развитие на интеграционни решения, Service Mesh също предлага решение: може да се премине на open-source версия от търговските продукти. Нашият Enterprise Service Mesh се основава на open-source версия на Service Mesh.

Още едно предимство — наличието на единен пълен набор от интеграционни услуги. Тъй като цялата интеграция се изгражда през този междинен слой, можем да управляваме целия интеграционен трафик и връзките между приложенията, които формират бизнес ядрото на компанията. Това е много удобно.

И накрая Service Mesh подтиква компанията да премине към динамична инфраструктура. В момента много компании се насочват към контейнеризация. Разделянето на монолита на микросервиси и внедряването им по елегантен начин е актуална тема. Но когато се опитвате да преведете на нова архитектура система, която вече много години работи в продукция, веднага се сблъсквате с редица проблеми: трудно е да натъпчете всичко това в контейнери и да го разположите на платформа. А внедряването, синхронизацията и взаимодействието на тези разпределени компоненти е още една сложна тема. Как ще комуникират помежду си? Няма ли да има каскадни повреди? Service Mesh помага да се реши част от тези проблеми и да се улесни миграцията от старата архитектура към новата, благодарение на това, че можем да забравим за логиката на мрежовия обмен.

Защо е нужна кастомизация на Service Mesh

В нашата компания съжителстват стотици системи и модули, а runtime е много натоварен. Следователно простият модел, при който една система извиква друга и получава отговор, не е достатъчен, защото в production искаме повече. Какво още е нужно от корпоративния Service Mesh?

Сервис за обработка на събития

Представете си, че трябва да направим реално времево обработване на събития — система, която анализира действията на клиента в реално време и веднага може да му направи релевантно предложение. За реализиране на подобна функционалност се използва архитектурен модел, наречен 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. Тези данни могат да бъдат анализирани с помощта на AI, machine learning и др., а след това, на базата на резултатите от анализа, да се направят полезни неща. Беше уместно поне частично да се предаде управлението на целия този мрежови трафик и извиквания на приложенията, интегрирани в Service Mesh, на изкуствения интелект.

Услуга API Gateway (Шлюз API)

Обикновено в Service Mesh има прокси и услуги, които комуникират помежду си в рамките на доверен периметър. Но съществуват и външни контрагенти. Изискванията към API, предоставяни на тази група потребители, са значително по-сериозни. Разделяме тази задача на две основни части.

• Сигурност. Въпроси, свързани с ddos, уязвимости на протоколите, приложенията, операционните системи и т.н.
• Масштаби. Когато броят на API, които трябва да предоставим на клиентите, достига хиляди или дори стотици хиляди, възниква необходимост от средство за управление на този набор от API. Нужно е постоянно да се следят API: работят ли или не, в какъв статус са, какъв трафик има, каква статистика и т.н. Шлюзът API трябва да се справя с тази задача, правейки целия процес управляем и безопасен. Благодарение на този компонент Enterprise Service Mesh може лесно да публикува както вътрешен API, така и външен.

Услуга за поддръжка на специфични протоколи и формати на данни (прозорец AS)

Към момента повечето решения за Service Mesh могат да работят нативно само с трафик HTTP и HTTP2 или в ограничен режим на ниво TCP/IP. При Enterprise Service Mesh се появяват много други много специфични протоколи за предаване на данни. Някои системи могат да използват брокери на съобщения, а други са интегрирани на ниво бази данни. Ако в компанията има SAP, той също може да използва собствена система за интеграция. Всичко това работи и представлява важна част от бизнеса.

Не може просто да се каже: "Нека се откажем от наследствени системи и да направим нови, които да могат да използват Service Mesh". За да свържем всичките стари системи с новите (на базата на микросервисна архитектура), системите, които могат да използват Service Mesh, ще се нуждаят от някакъв адаптер, посредник или шлюз. Съгласете се, би било хубаво, ако той идва в комплект с услугата. Шлюзът AS точно това може да поддържа, независимо от вида на интеграцията. Представете си, просто инсталирате Enterprise Service Mesh и той е вече готов да взаимодейства с всички протоколи, които ви трябват. За нас такъв подход е много важен.

Така си представяме корпоративната версия на Service Mesh (Enterprise Service Mesh). Описаната персонализация решава повечето проблеми, които възникват при опити да се използват готови open-source версии на интеграционната платформа. Появила се само преди две години, архитектурата Service Mesh продължава да се развива и ние сме радостни, че можем да направим принос в нейното развитие. Надяваме се, че нашият опит ще бъде полезен за вас.

Източник: habr.com