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