Заўв. перав.: аўтар гэтага артыкула (Luc Perkins) — developer advocate у арганізацыі CNCF, якая з'яўляецца домам для такіх Open Source-праектаў, як Linkerd, SMI (Service Mesh Interface) і Kuma (дарэчы, вы таксама задумваліся, чаму ў гэтым спісе няма Istio?..). У чарговы раз спрабуючы прынесці ў DevOps-супольнасць лепшае разуменне ў модны хайп пад назовам "service mesh", ён прыводзіць 16 характэрных магчымасцяў, якія падаюць падобныя рашэнні.
Сёння ― адна з самых гарачых тэм у галіне праграмнай інжынерыі (і па праве!). Я лічу гэтую тэхналогію неверагодна перспектыўнай і мару стаць сведкам яе шырокага распаўсюджвання (вядома, калі гэта мае сэнс). Тым не менш, яна да гэтага часу акружана арэолам таямнічасці для большасці людзей. Пры гэтым нават тыя, хто добра знаёмы з ёй, нярэдка не могуць сфармуляваць яе плюсы і што менавіта яна сабой уяўляе (уключаючы і вашага пакорлівага слугу). У артыкуле я паспрабую выправіць сітуацыю, пералічыўшы розныя сцэнары выкарыстання "сэрвісных сетак"*.
* Заўв. перакл.: тут і далей у артыкуле будзе выкарыстоўвацца менавіта такі пераклад ("сэрвісная сетка") для ўсё яшчэ новага тэрміна service mesh.
Але спачатку хачу зрабіць некалькі заўваг:
- Я ніколі не працаваў з сэрвіснымі сеткамі і не выкарыстоўваў іх па-за праектамі, задуманымі дзеля ўласнай адукацыі. З іншага боку, менавіта я напісаў кучу дакументацыі для ўнутранай service mesh кампаніі Twitter у 2015 годзе (тады яна яшчэ нават не звалася "сэрвіснай сеткай") і ўдзельнічаў у распрацоўцы сайта і дакументацыі для , так што гэта што-небудзь значыць.
- Мой спіс - прыкладны і няпоўны. Цалкам магчымыя невядомыя мне сцэнары выкарыстання, і з часам напэўна ўзнікнуць новыя варыянты, па меры развіцця тэхналогіі і росты яе папулярнасці.
- У той жа час, далёка не кожная існуючая рэалізацыя service mesh падтрымлівае ўсе пералічаныя выпадкі выкарыстання. Таму мае выразы накшталт "service mesh можа…" варта чытаць як "асобныя, а магчыма, і ўсе папулярныя рэалізацыі service mesh могуць…".
- Парадак прыкладаў не мае якога-небудзь значэння.
Кароткі спіс:
- выяўленне сэрвісаў;
- шыфраванне;
- аўтэнтыфікацыя і аўтарызацыя;
- балансіроўка нагрузкі;
- circuit breaking;
- аўтамаштабаванне;
- канарэечныя разгортванні;
- сіне-зялёныя разгортванні;
- праверка здароўя;
- load shedding;
- люстраванне трафіку;
- ізаляцыя;
- абмежаванне частаты запытаў, паўторныя спробы і тайм-аўты;
- тэлеметрыя;
- аўдыт;
- візуалізацыя.
1. Выяўленне сэрвісаў
TL;DR: Падлучайцеся да іншых сэрвісаў у сетцы з дапамогай простых імёнаў.
Сэрвісы павінны мець магчымасць аўтаматычна "знаходзіць" адзін аднаго з дапамогай адэкватных імёнаў ― напрыклад, service.api.production, pets/staging або cassandra. Хмарныя асяроддзі адрозніваюцца сваёй эластычнасцю, і за адным імем можа хавацца мноства асобнікаў сэрвісу. Зразумела, што ў такой сітуацыі фізічна немагчыма захардкадзіць усе IP-адрасы.
Плюс да ўсяго, калі адзін сэрвіс знаходзіць іншы, ён павінен мець магчымасць дасылаць запыты гэтаму сэрвісу, не асцерагаючыся, што яны апынуцца на ўваходзе ў яго непрацуючага асобніка. Іншымі словамі, service mesh павінна сачыць за працаздольнасцю ўсіх асобнікаў сэрвісаў і падтрымліваць спіс хастоў у максімальна актуальным стане.
Кожная служба mesh рэалізуе механізм выяўлення сэрвісаў па-свойму. На дадзены момант самым распаўсюджаным спосабам з'яўляецца дэлегаванне вонкавым працэсам накшталт DNS Kubernetes. У мінулым у Twitter для гэтых мэт мы выкарыстоўвалі сістэму імёнаў . Акрамя таго, тэхналогія service mesh робіць магчымым з'яўленне карыстацкіх механізмаў наймення (хоць я яшчэ не сустракаў ніводнай рэалізацыі SM з такім функцыяналам).
2. Шыфраванне
TL;DR: Пазбаўцеся ад незашыфраванага трафіку паміж сэрвісамі і няхай гэты працэс будзе аўтаматызаваным і маштабуецца.
Прыемна ўсведамляць, што зламыснікі не могуць пракрасціся ў вашу ўнутраную сетку. Сеткавыя экраны выдатна спраўляюцца з гэтым. Але што адбудзецца, калі хакер усё ж пракрадзецца ўнутр? Ён зможа рабіць з унутрысэрвісным трафікам усё, што пажадае? Давайце спадзявацца, што гэтага ўсё ж не адбудзецца. Для таго, каб прадухіліць падобны сцэнар, варта рэалізаваць сетку з нулявым даверам (zero-trust), у якой увесь трафік паміж сэрвісамі зашыфраваны. Большасць сучасных сэрвісных сетак дамагаюцца гэтага з дапамогай узаемнага. (Mutual TLS, mTLS). У некаторых выпадках mTLS працуе ў цэлых аблоках і кластарах (думаю, і міжпланетныя камунікацыі калі-небудзь будуць уладкованыя аналагічна).
Вядома, для mTLS service mesh неабавязкова. Кожны сэрвіс можа сам паклапаціцца аб сваім TLS, але гэта азначае, што трэба будзе знайсці спосаб генераваць сертыфікаты, размяркоўваць іх па хастах сэрвісу, уключаць у дадатак код, які будзе загружаць гэтыя сертыфікаты з файлаў. Так, яшчэ не забудзьцеся аб абнаўленні гэтых сертыфікатаў праз пэўныя прамежкі часу. Сэрвісныя сеткі аўтаматызуюць mTLS з дапамогай сістэм накшталт , якія, у сваю чаргу, аўтаматызуюць працэс выпуску і ратацыі сертыфікатаў.
3. Аўтэнтыфікацыя і аўтарызацыя
TL;DR: Усталёўвайце, хто з'яўляецца ініцыятарам запыту, і вызначайце, што ім дазволена рабіць яшчэ да таго, як запыт дасягне сэрвісу.
Сэрвісы часта хочуць ведаць, хто выконвае запыт (аўтэнтыфікацыя), і, выкарыстоўваючы гэтую інфармацыю, вырашаюць, што гэтаму суб'екту дазволена рабіць (аўтарызацыя). У дадзеным выпадку за займеннікам "хто" могуць хавацца:
- Іншыя сэрвісы. Гэта называецца «аўтэнтыфікацыяй peer'а». Напрыклад, сэрвіс
webхоча атрымаць доступ да сэрвісуdb.Сэрвісныя сеткі звычайна вырашаюць падобныя праблемы з дапамогай mTLS: сертыфікаты ў дадзеным выпадку выступаюць у ролі неабходнага ідэнтыфікатара. - Некаторыя карыстачы-людзі. Гэта называецца «аўтэнтыфікацыяй запыту». Напрыклад, карыстальнік
haxor69жадае набыць новую лямпу. Сэрвісныя сеткі падаюць розныя механізмы, напрыклад, .Многім з нас даводзілася рабіць гэта ў кодзе прыкладання. Прыходзіць запыт, мы праглядаем табліцу
users, знаходзім карыстальніка і параўноўваем пароль, затым правяраем слупокpermissionsі г.д. У выпадку service mesh гэта адбываецца яшчэ да таго, як запыт дасягне сервісу.
Пасля таго, як мы ўстанавілі, ад каго прыйшоў запыт, трэба вызначыць, што гэтаму суб'екту дазволена рабіць. Некаторыя service mesh'і дазваляюць задаваць базавыя палітыкі (пра тое, хто і што можа рабіць) у выглядзе YAML-файлаў ці ў камандным радку, у той час як іншыя прапануюць інтэграцыю з фрэймворкамі накшталт . Канчатковая мэта - дамагчыся таго, каб вашы сэрвісы прымалі любыя запыты, смела мяркуючы, што яны зыходзяць з надзейнай крыніцы. и дзеянне гэта дазволена.
4. Балансіроўка нагрузкі
TL;DR: Размяркоўвайце нагрузку па асобніках сэрвісу па вызначаным шаблоне.
Сэрвіс у складзе сэрвіснай секці вельмі часта складаецца з мноства ідэнтычных асобнікаў. cache складаецца з 5 копій, а заўтра іх колькасць можа ўзрасці да 11. Запыты, якія накіроўваюцца ў cache, павінны размяркоўвацца ў адпаведнасці з пэўнай мэтай. Напрыклад, мінімізаваць затрымку або максымізаваць верагоднасць патрапіць на працаздольны асобнік. Часцей за ўсё выкарыстоўваецца алгарытм кругавога абслугоўвання (Round-robin), але існуе і мноства іншых – напрыклад, метад узважаных (weighted) запытаў (можна выбраць пераважныя мэты), кальцавое (ring) хэшаванне (выкарыстанне ўзгодненага хэшавання для upstream-хастоў) або метад найменшага ліку запытаў (перавага аддаецца асобніку з найменшай колькасцю запытаў).
Класічныя балансавальнікі маюць і іншыя функцыі, такія як кэшаванне HTTP і абарона ад DDoS, але яны не вельмі актуальныя для трафіку тыпу east-west (г.зн. для трафіку, бягучага ў межах датацэнтра ― заўв. перакл.)(тыповая вобласць ужывання service mesh). Вядома, не абавязкова выкарыстоўваць service mesh для балансавання нагрузкі, аднак яна дазваляе задаваць і кантраляваць палітыкі балансавання для кожнага сэрвісу з цэнтралізаванага кіраўніка пласта, тым самым ухіляючы неабходнасць запускаць і наладжваць асобныя балансавальнікі ў сеткавым стэку.
5. Разрыў ланцуга (circuit breaking)
TL;DR: Спыняйце трафік да праблемнага сэрвісу і кантралюйце шкоду пры найгоршых сцэнарах.
Калі па якім-небудзь чынніку сэрвіс не спраўляецца з трафікам, service mesh падае некалькі варыянтаў рашэння гэтай праблемы (аб іншых будзе расказана ў адпаведных раздзелах). Circuit breaking - гэта самы жорсткі варыянт адключэння сэрвісу ад трафіку. Аднак сам па сабе ён не мае сэнсу - неабходны запасны план. Можа прадугледжвацца супрацьціск () на сэрвісы, якія выконваюць запыты (толькі не забудзьцеся наладзіць сваю service mesh для гэтага!), ці, напрыклад, афарбоўванне статус-старонкі ў чырвоны колер і перанакіраванне карыстальнікаў на чарговы варыянт старонкі з "падаючым кітом" ("Twitter is down").
Сэрвісныя сеткі дазваляюць не толькі вызначаць, калі рушыць услед адключэнне і што за гэтым рушыць услед. У дадзеным выпадку "калі" можа ўключаць любую камбінацыю зададзеных параметраў: агульная колькасць запытаў за нейкі перыяд, колькасць паралельных падлучэнняў, pending-запыты, актыўныя паўторныя спробы і г.д.
Вы ці наўрад захочаце марнатравіць circuit breaking'ом, але прыемна ўсведамляць, што ёсць рэзервовы план на крайні выпадак.
6. Аўтамаштабаванне
TL;DR: Павялічвайце ці памяншайце колькасць асобнікаў сэрвісу ў залежнасці ад зададзеных крытэраў.
Service mesh'і ― гэта не планавальнікі, таму яны не ажыццяўляюць маштабаванне самастойна. Аднак яны могуць пастаўляць інфармацыю, на аснове якой планавальнікі будуць прымаць рашэнні. Паколькі service mesh'і маюць доступ да ўсяго трафіку паміж сэрвісамі, яны размяшчаюць шырокай інфармацыяй аб тым, што адбываецца: якія сэрвісы сутыкнуліся з праблемамі, якія загружаны зусім слаба (вылучаныя на іх магутнасці марнуюцца марна) і г.д.
Напрыклад, Kubernetes маштабуе сэрвісы ў залежнасці ад выкарыстання pod'амі CPU і памяці. (гл. наш даклад «» - заўв. перав.), Але калі вы вырашыце праводзіць маштабаванне на аснове любога іншага паказчыка (у нашым выпадку - звязанага з трафікам), спатрэбіцца спецыяльная метрыка. Кіраўніцтва паказвае, як зрабіць гэта з дапамогай , и , Але сам працэс даволі складаны. Мы б жадалася, каб service mesh яго спрасціла, дазволіўшы проста задаваць умовы накшталт «павяліч колькасць асобнікаў сэрвісу. auth, калі колькасць запытаў, якія чакаюць выканання, будзе перавышаць парогавае значэнне на працягу хвіліны».
7. Канарэечныя разгортванні
TL;DR: Выпрабоўвайце новыя функцыі або версіі сэрвісу на падмностве карыстальнікаў.
Скажам, вы распрацоўваеце нейкі SaaS-прадукт і маеце намер выкаціць яго новую крутую версію. Вы пратэставалі яе ў staging, і яна выдатна адпрацавала. Але ўсё ж адольваюць пэўныя асцярогі наконт яе паводзін у рэальных умовах. Іншымі словамі, патрабуецца праверыць новую версію на рэальных задачах, не рызыкуючы пры гэтым даверам карыстальнікаў. Канарэечные разгортванні выдатна падыходзяць для гэтага. Яны дазваляюць прадэманстраваць новую функцыю некатораму падмноству карыстачоў. Гэтае падмноства можа складацца з самых лаяльных карыстачоў ці тых, хто працуе з бясплатнай версіяй прадукта, ці карыстачоў, якія выказалі жаданне пабыць «паддоследнымі трусамі».
Service mesh'і рэалізуюць гэта, дазваляючы паказаць крытэры, якія вызначаюць, хто і якую версію прыкладання ўбачыць, і якая адпавядае выявай маршрутызуючы трафік. Пры гэтым для саміх сэрвісаў нічога не мяняецца. Версія 1.0 сэрвісу лічыць, што ўсе запыты паступаюць ад карыстачоў, якія менавіта яе і павінны ўбачыць, а версія 1.1 тое ж самае мяркуе ў стаўленні сваіх карыстачоў. А вы, тым часам, можаце мяняць працэнт трафіку паміж старой і новай версіяй, перанакіроўваючы расце колькасць карыстальнікаў на новую, калі яна працуе стабільна і вашыя "паддоследныя" даюць дабро.
8. Сіне-зялёныя разгортванні
TL;DR: Выкочвайце новую крутую функцыю, але будзьце гатовыя неадкладна вярнуць усё назад.
Сэнс у тым, каб выкаціць новы "сіні" сэрвіс, запусціўшы яго раўналежна са старым, "зялёным". Калі ўсё пайдзе гладка і новы сэрвіс добра сябе зарэкамендуе, то стары можна будзе паступова адключыць. (Нажаль, калі-небудзь і гэты новы «сіні» сэрвіс паўторыць лёс «зялёнага» і знікне…) Сіне-зялёныя разгортванні адрозніваюцца ад канарэечных тым, што новая функцыя ахоплівае адразу ўсіх карыстальнікаў (а не частка); сэнс тут у тым, каб мець напагатове "запасную гавань", калі раптам нешта пойдзе не так.
Service mesh'і прапануюць вельмі зручны спосаб тэставання «сіняга» сэрвісу і імгненнага пераключэння на працоўны «зялёны» у выпадку непаладак. Не кажучы ўжо пра тое, што адначасна яны даюць масу інфармацыі (гл. пункт "Тэлеметрыя" ніжэй) аб працы "сіняга", якая дапамагае зразумець, ці гатовы той да паўнавартаснай эксплуатацыі.
Заўв. перав.: Больш падрабязна пра розныя стратэгіі разгортвання ў Kubernetes (уключаючы згаданыя canary, blue/green і іншыя) можна пачытаць у .
9. Праверка здароўя
TL;DR: Сачыце за тым, якія асобнікі сэрвісаў працаздольныя, і рэагуйце на тыя з іх, якія такімі быць перастаюць.
Праверка здароўя (health check) дапамагае прыняць рашэнне аб тым, ці гатовы экземпляры сэрвісу прымаць і апрацоўваць трафік. Напрыклад, у выпадку HTTP-сэрвісаў праверка здароўя можа выглядаць як GET-запыт на endpoint /health. Адказ 200 OK будзе азначаць, што экзэмпляр здаровы, любы іншы - што ён не гатовы прымаць трафік.
Такім чынам, праверка здароўя выступае не самастойным сцэнарам выкарыстання, а звычайна выкарыстоўваецца для дасягнення іншых мэт.
10. Перакідванне нагрузкі (load shedding)
TL;DR: Перанакіроўвайце трафік у адказ на часовы ўсплёск у выкарыстанні.
Калі нейкі сэрвіс аказваецца перагружаны трафікам, вы можаце часова перанакіраваць частку гэтага трафіку ў іншае месца (гэта значыць "скінуць", "пераліць") (shed) яго туды). Напрыклад, у рэзервовы сэрвіс або дата-цэнтр, або ў пастаянны topic. У выніку, сэрвіс працягне апрацоўваць частку запытаў замест таго, каб зваліцца і перастаць апрацоўваць наогул усё. Скідванне нагрузкі пераважней, чым парыў ланцуга, але ўсё роўна непажадана марнатравіць ім. Яно дазваляе прадухіліць каскадныя збоі, у выніку якіх падаюць downstream-сэрвісы.
11. Распаралельванне/люстраванне трафіку
TL;DR: Адпраўляйце адзін запыт адразу ў некалькі месцаў.
Часам узнікае неабходнасць адправіць запыт (ці некаторую выбарку запытаў) адразу ў некалькі сэрвісаў. Характэрны прыклад - адпраўка часткі production-трафіку ў staging-сэрвіс. Асноўны вэб-сервер production'а адпраўляе запыт да ніжэйстаячага сэрвісу products.production і толькі да яго. А service mesh інтэлектуальна капіруе гэты запыт і адпраўляе яго на products.staging, пра што вэб-сервер нават не падазрае.
Яшчэ адзін звязаны сцэнар выкарыстання сэрвіснай сеткі, які можна рэалізаваць па-над распаралельваннем трафіку, ― гэта .Яно прадугледжвае адпраўку адных і тых жа запытаў розным версіям сэрвісу і праверку таго, ці паводзяць усе версіі сябе аднолькава. , Але сама ідэя здаецца перспектыўнай.
12. Ізаляцыя
TL;DR: Разбівайце сваю service mesh на міні-сеткі.
Таксама вядомая як сегментацыя, ізаляцыя ― гэта мастацтва падзелу сэрвіснай сеткі на лагічна адасобленыя сегменты, якія нічога не ведаюць сябар пра сябра. Ізаляцыя крыху падобная на стварэнне віртуальных прыватных сетак. Прынцыповая ж розніца складаецца ў тым, што вы па-ранейшаму можаце карыстацца ўсімі перавагамі service mesh (накшталт выяўлення сэрвісаў), але з дадатковай бяспекай. Напрыклад, калі зламыснік здолее пракрасціся ў сэрвіс у адной з падсетак, ён не зможа ўбачыць, якія сэрвісы запушчаныя ў іншых падсетках, ці перахапіць іх трафік.
Акрамя таго, перавагі могуць быць і арганізацыйнымі. Магчыма, вам захочацца разбіць сэрвісы на падсеткі ў залежнасці ад структуры кампаніі і вызваліць распрацоўшчыкаў ад кагнітыўнай нагрузкі, выкліканай неабходнасць трымаць у розуме ўсю service mesh.
13. Абмежаванне частаты запытаў, паўторныя спробы і тайм-аўты
TL;DR: Больш не трэба ўключаць у кодавую базу надзённыя задачы па кіраванні запытамі.
Усе гэтыя рэчы можна было б разглядаць як асобныя выпадкі выкарыстання, але я вырашыў аб'яднаць іх з-за адной агульнай асаблівасці: яны пераймаюць на сябе задачы па кіраванні жыццёвым цыклам запытаў, якія звычайна адпрацоўваюцца бібліятэкамі прыкладанняў. Калі вы распрацоўваеце вэб-сервер на Ruby on Rails (не інтэграваны з service mesh), які выконвае запыты да backend-сэрвісаў праз , Прыкладанне павінна будзе само вырашаць, што рабіць, калі N запытаў завершацца няўдачай. Таксама давядзецца высвятляць, які аб'ём трафіку здольныя будуць апрацаваць гэтыя сэрвісы і за'hardcode'іць гэтыя параметры з дапамогай спецыяльнай бібліятэкі. Плюс да ўсяго, прыкладанне павінна будзе вырашаць, калі пара здацца і дазволіць запыту пратухнуць (па timeout). І для таго, каб змяніць любы з вышэйпералічаных параметраў, вэб-сервер давядзецца спыніць, пераканфігураваць і запусціць нанова.
Перадача гэтых задач сэрвіснай сетцы азначае не толькі тое, што распрацоўнікам сэрвісаў не трэба будзе думаць аб іх, але і тое, што іх можна будзе разглядаць больш глабальным чынам. Калі выкарыстоўваецца складаны ланцужок сэрвісаў, скажам, A -> B -> C -> D -> E, неабходна ўлічваць увесь жыццёвы цыкл запыту. Калі стаіць задача падоўжыць тайм-аўты ў сэрвісе З, лагічна рабіць гэта ўсё зараз, а не па частках: абнавіўшы код сэрвісу і чакаючы, пакуль pull request будзе прыняты і CI-сістэма разгорне абноўлены сэрвіс.
14. Тэлеметрыя
TL;DR: Збірайце ўсю патрэбную (і не зусім) інфармацыю ад сэрвісаў.
Тэлеметрыя - гэта агульны тэрмін, які ўключае ў сябе метрыкі, размеркаваную трасіроўку і логі. Сэрвісныя сеткі прапануюць механізмы для збору і апрацоўкі ўсіх трох тыпаў дадзеных. Тут усё становіцца крыху расплывістым, паколькі колькасць магчымых варыянтаў занадта вялікая. Для збору метрык ёсць і іншыя прылады, для збору логаў можна выкарыстоўваць , , і інш (напрыклад, ClickHouse з нашым для K8s - заўв. перав.), для размеркаванай трасіроўкі ёсць і да т.п. Кожная служба mesh можа падтрымліваць адны прылады і не падтрымліваць іншыя. Цікаўна будзе паглядзець, ці зможа праект забяспечыць некаторую канвергенцыю.
У дадзеным выпадку перавага тэхналогіі service mesh у тым, што sidecar-кантэйнеры могуць, у прынцыпе, сабраць усе вышэйпералічаныя дадзеныя са сваіх сэрвісаў. Іншымі словамі, у сваё распараджэнне вы атрымліваеце адзіную сістэму збору тэлеметрыі, і service mesh можа апрацоўваць усю гэтую інфармацыю рознымі спосабамі. Напрыклад:
- tail'іць логі ад нейкага сэрвісу ў CLI;
- адсочваць аб'ём запытаў з панэлі маніторынгу service mesh;
- збіраць размеркаваныя трасіроўкі і перанакіроўваць іх у сістэму накшталт Jaeger.
Увага, суб'ектыўнае меркаванне: Наогул кажучы, тэлеметрыя - гэта тая вобласць, моцнае ўмяшанне сэрвіснай сеткі ў якую непажадана. Збор базавай інфармацыі і адсочванне на лёце некаторых «залатых метрык» накшталт адсотка паспяховых запытаў і затрымак ― гэта нармальна, але давайце спадзявацца, што мы не станем сведкамі ўзнікнення гэтакіх Франкенштэйн-стэкаў, якія паспрабуюць замяніць спецыялізаваныя сістэмы, некаторыя з якіх ужо выдатна сябе зарэкамендавалі і добра зарэкамендавалі.
15. Аўдыт
TL;DR: Той, хто забывае ўрокі гісторыі, асуджаны іх паўтараць.
Аўдыт ― гэта мастацтва назірання за важнымі падзеямі ў сістэме. У выпадку service mesh гэта можа азначаць адсочванне таго, хто рабіў запыты да пэўных endpoint'аў пэўных сэрвісаў або колькі разоў за апошні месяц адбывалася нейкая падзея, якая мае дачыненне да бяспекі.
Зразумела, што аўдыт вельмі цесна злучаны з тэлеметрыяй. Розніца ж складаецца ў тым, што тэлеметрыя звычайна асацыюецца з такімі рэчамі, як прадукцыйнасць і тэхнічная складнасць, у той час як аўдыт можа мець дачыненне да юрыдычных і іншых пытанняў, якія выходзяць за рамкі строга тэхнічнай сферы (напрыклад, адпаведнасць патрабаванням GDPR - Агульнага рэгламенту ЕС па абароне дадзеных).
16. Папярэдні прагляд
TL;DR: Хай жыве React.js ― невычарпальная крыніца мудрагелістых інтэрфейсаў.
Магчыма, ёсць больш прыдатны тэрмін, але я яго не ведаю. Я проста маю на ўвазе графічнае прадстаўленне service mesh ці яе некаторых кампанентаў. Гэтыя візуалізацыі могуць уключаць індыкатары накшталт сярэдніх затрымак, інфармацыю аб канфігурацыі sidecar-кантэйнераў, вынікі праверак здароўя і абвесткі.
Праца ў сэрвіс-арыентаваным асяроддзі спалучана са значна мацнейшай кагнітыўнай нагрузкай у параўнанні з Яго Вялікасцю Маналітам. Таму кагнітыўны ціск варта змяншаць любым коштам. Банальны графічны інтэрфейс для service mesh з магчымасцю клікнуць на кнопку і атрымаць патрэбны вынік можа мець вырашальнае значэнне для росту папулярнасці гэтай тэхналогіі.
Не былі ўключаны ў спіс
Першапачаткова я меў намер уключыць у спіс яшчэ некалькі сцэнарыяў выкарыстання, але потым вырашыў не рабіць гэтага. Вось яны разам з прычынамі майго рашэння:
- Мульты-датацэнтр.У маім уяўленні гэта не гэтулькі сцэнар выкарыстання, колькі вузкая і пэўная вобласць ужывання сэрвісных сетак або некаторага набору функцый накшталт выяўленні сэрвісаў.
- Ingress і egress. Гэта звязаная вобласць, але я абмежаваў сябе (магчыма, штучна) сцэнарам выкарыстання "трафік east-west". Ingress і egress заслугоўваюць асобнага артыкула.
Заключэнне
На гэтым пакуль усё! Зноў жа, гэты спіс вельмі ўмоўны і, хутчэй за ўсё, не поўны. Калі вам здаецца, што я нешта выпусціў, ці ў нечым памыліўся, звяртайцеся да мяне ў Twitter (). Калі ласка, выконвайце правілы прыстойнасці.
PS ад перакладчыка
У якасці асновы для загалоўнай ілюстрацыі да артыкула ўзята выява з артыкула «»(аўтар - Gregory MacKinnon). На ім паказана, як частка функцыянальнасці з прыкладанняў (зялёным колерам) перайшла да service mesh, якая забяспечвае ўзаемасувязі паміж імі (блакітны колер).
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «.
Крыніца: habr.com
