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

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

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

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

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

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

На ниво контролна равнина:

• Прилагане на политики за маршрутизиране и балансиране на трафика
• Управление на повторения и изчаквания, откриване на "мъртви" възли (прекъсване на верига), управление на ситуации на повреда (инжектиране на грешки) и осигуряване на стабилност (устойчивост) на услугите чрез други механизми
• Удостоверяване/упълномощаване на повикване
• Отпадане на показатели (наблюдаемост)

Кръгът от потребители, които се интересуват от развитието на тази технология, е много широк - от малки стартиращи компании до големи интернет корпорации, като 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. За да тествате новата версия, можете също да използвате освобождаване на канарче - преминете към новата версия само 10% от трафика или заявките от пилотна група клиенти. Основният трафик отива към старата версия, нищо не се поврежда.

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

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

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

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

Защо е необходимо персонализиране на услугата Mesh

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

Услуга за обработка на събития

Да си представим, че трябва да направим обработка на събитията в реално време – система, която анализира действията на клиента в реално време и може веднага да му направи подходяща оферта. За да реализирате тази функционалност, използвайте архитектурен модел, наречен управлявана от събития архитектура (EDA). Нито една от текущите Service Mesh не поддържа такива модели и това е много важно, особено за една банка!

Доста странно е, че "дистанционното повикване" Remote Procedure Call (RPC) се поддържа от всички версии на Service Mesh, но те не са приятели с EDA. Тъй като Service Mesh е вид модерна разпределена интеграция, а EDA е много подходящ архитектурен модел, който ви позволява да правите уникални неща по отношение на потребителското изживяване.

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

Услуга за прехвърляне на файлове

В допълнение към EDA би било хубаво да можете да прехвърляте файлове: в мащаба на предприятието много често е възможна само интеграция на файлове. По-специално се използва ETL (Extract, Transform, Load) архитектурен модел. В него, като правило, всички обменят изключително файлове: използват се големи данни, които е неуместно да се тъпчат с отделни заявки. Възможността за първоначална поддръжка на прехвърляне на файлове в Enterprise Service Mesh ви дава гъвкавостта, от която се нуждае вашият бизнес.

Услуга за оркестрация

Големите организации почти винаги имат различни екипи, които правят различни продукти. Например в една банка едни екипи работят с депозити, а други с кредитни продукти и има много такива случаи. Това са различни хора, различни екипи, които правят своите продукти, разработват свои собствени API и ги предоставят на други. И много често има нужда от композиране на тези услуги, както и внедряване на сложна логика за последователно извикване на набор от API. За да се реши този проблем, е необходимо решение в интеграционния слой, което ще опрости цялата тази съставна логика (извикване на няколко API, описание на маршрута на заявката и т.н.). Това е услугата за оркестрация в Enterprise Service Mesh.

AI и ML

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

API Gateway Service (API Gateway)

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

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

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

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

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

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

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