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

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

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

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

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

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

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

• Прилагане на политики за маршрутизиране и балансиране на трафика
• Управление на повторения и таймаути, идентифициране на "мертви" възли (circuit breaking), управление на сбойни ситуации (injecting faults) и осигуряване на устойчивост (resilience) на услугите чрез други механизми
• Аутентификация/авторизация на повиквания
• Отхвърляне на метрики (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, на транспортно ниво са изолирани както от мрежата, така и едно от друго: няма никаква връзка между тях. В същото време разработчикът получава пълен контрол над своите сервисии.

Не може да не се отбележи, че обновяването на разпределени приложения в среда, в която се използва 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?

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

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

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

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

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

Служба за поддръжка на специфични протоколи и формати на данни (шлюз АС)

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

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

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

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