І зноў добры дзень!.. Напярэдадні старту курса мы падрыхтавалі яшчэ адзін карысны пераклад.
Service Mesh - гэта канфігуруемы інфраструктурны ўзровень з нізкай затрымкай, які патрэбен для апрацоўкі вялікага аб'ёму сеткавых міжпрацэсных камунікацый паміж праграмнымі інтэрфейсамі прыкладання (API). Service Mesh забяспечвае хуткую, надзейную і бяспечную камунікацыю паміж кантэйнерызаваная і часта эфемернымі сэрвісамі інфраструктуры прыкладанняў. Service Mesh дае такія магчымасці, як выяўленне сэрвісаў, балансаванне нагрузкі, шыфраванне, празрыстасць, трасіраванасць, аўтэнтыфікацыю і аўтарызацыю, а таксама падтрымку шаблону аўтаматычнага выключэння (выключальнік).
Service Mesh звычайна рэалізуецца шляхам прадастаўлення кожнаму экзэмпляру сэрвісу экзэмпляра проксі, які называецца Sidecar. Sidecar апрацоўваюць камунікацыі паміж сэрвісамі, вырабляюць маніторынг і ўхіляюць праблемы бяспекі, гэта значыць усё, што можа быць абстрагавана ад асобных сэрвісаў. Такім чынам, распрацоўшчыкі могуць пісаць, падтрымліваць і абслугоўваць код прыкладання ў сэрвісах, а сістэмныя адміністратары могуць працаваць з Service Mesh і запускаць праграму.
Istio ад Google, IBM і Lyft, на дадзены момант з'яўляецца самай вядомай Service Mesh-архітэктурай. А Kubernetes, які першапачаткова распрацоўваўся ў Google, зараз з'яўляецца адзіным фрэймворкам для аркестрацыі кантэйнераў, які падтрымліваецца Istio. Вендары спрабуюць стварыць камерцыйныя падтрымліваемыя версіі Istio. Цікава, што новага яны змогуць прыўнесці ў праект з адчыненым зыходным кодам.
Аднак Istio - гэта не адзіны варыянт, паколькі распрацоўваюцца і іншыя рэалізацыі Service Mesh. Патэрн sidecar proxy з'яўляецца найболей папулярнай рэалізацыяй, як можна судзіць па праектах Buoyant, HashiCorp, Solo.io і іншым. Існуюць і альтэрнатыўныя архітэктуры: тэхналагічны інструментар Netflix - гэта адзін з падыходаў, дзе функцыянал Service Mesh рэалізуецца за кошт бібліятэк Ribbon, Hysterix, Eureka, Archaius, а таксама такіх платформаў, як Azure Service Fabric.
Service Mesh таксама мае сваю ўласную тэрміналогію для кампанентаў-сэрвісаў і функцый:
- Фрэймворк аркестрацыі кантэйнераў. Па меры таго, як усё больш і больш кантэйнераў дадаецца ў інфраструктуру прыкладання, з'яўляецца неабходнасць у асобным інструменце для маніторынгу і кіравання кантэйнерамі - фрэймворка аркестрацыі кантэйнераў. Kubernetes шчыльна заняў гэтую нішу, прычым настолькі, што нават яго асноўныя канкурэнты Docker Swarm і Mesosphere DC/OS прапануюць у якасці альтэрнатывы інтэграцыю з Kubernetes.
- Сэрвісы і экзэмпляры (поды Kubernetes). Асобнік – гэта адзіная запушчаная копія мікрасэрвісу. Часам адзін асобнік - гэта адзін кантэйнер. У Kubernetes асобнік складаецца з невялікай групы незалежных кантэйнераў, які называецца подам. Кліенты рэдка звяртаюцца напрамую да экзэмпляра або поду, часцей яны звяртаюцца да сэрвісу, які ўяўляе сабой набор ідэнтычных маштабуюцца і адмоваўстойлівасць асобнікаў або подаў (рэплік).
- Sidecar Proxy. Sidecar Proxy працуе з адным асобнікам або подам. Сэнс Sidecar Proxy у тым, каб накіроўваць або праксіраваць трафік, які прыходзіць ад кантэйнера, з якім ён працуе, і зваротны трафік. Sidecar ўзаемадзейнічае з іншымі Sidecar Proxy і кіруецца фрэймворкам аркестрацыі. Многія рэалізацыі Service Mesh выкарыстоўваюць Sidecar Proxy для перахопу і кіравання ўсім уваходным і выходным трафікам асобніка або пода.
- Выяўленне сэрвісаў. Калі асобніку трэба ўзаемадзейнічаць з іншым сэрвісам, яму трэба знайсці (выявіць) спраўны і даступны асобнік іншага сэрвісу. Як правіла асобнік выконвае пошук па DNS. Фрэймворк аркестрацыі кантэйнераў захоўвае спіс асобнікаў, якія гатовыя да атрымання запытаў, і дае інтэрфейс для DNS-запытаў.
- Балансіроўка нагрузкі. Большасць фрэймворкаў аркестрацыі кантэйнераў забяспечваюць балансаванне нагрузкі на 4 узроўні (транспартным). Service Mesh рэалізуе больш складанае балансаванне нагрузкі на 7 узроўні (прыкладным), багатую алгарытмамі і больш эфектыўную ў пытанні кіравання трафікам. Параметры балансавання нагрузкі могуць быць зменены з дапамогай API, што дазваляе аркестраваць сіне-зялёнае ці канарэечнае разгортванне.
- шыфраванне. Service Mesh можа зашыфроўваць і расшыфроўваць запыты і адказы, здымаючы гэты цяжар з сэрвісаў. Service Mesh таксама можа павысіць прадукцыйнасць за кошт прыярытэзацыі або перавыкарыстання існуючых пастаянных злучэнняў, што зніжае неабходнасць у дарагіх вылічэннях для стварэння новых злучэнняў. Найбольш распаўсюджанай рэалізацыяй шыфравання трафіку з'яўляецца mutual TLS (mTLS), Дзе інфраструктура адкрытых ключоў (PKI) генеруе і распаўсюджвае сертыфікаты і ключы для выкарыстання іх у Sidecar Proxy.
- Аўтэнтыфікацыя і аўтарызацыя. Service Mesh можа аўтарызоўваць і аўтэнтыфікаваць запыты зробленыя звонку ці знутры прыкладанні, адпраўляючы асобнікам толькі валідаваныя запыты.
- Падтрымка шаблону аўтаматычнага выключэння. Service Mesh падтрымлівае , Які ізалюе нездаровыя экзэмпляры, а затым паступова вяртае іх у пул здаровых асобнікаў пры неабходнасці.
Тая частка прыкладання Service Mesh, якая кіруе сеткавым трафікам паміж асобнікамі называецца Плоскасць дадзеных. Стварэнне і разгортванне канфігурацыі, якая кіруе паводзінамі Плоскасць дадзеных, выконваецца з дапамогай асобнай Плоскасць кіравання. Плоскасць кіравання звычайна ўключае ў сябе або спраектавана такім чынам, каб падключацца да API, CLI або GUI для кіравання дадаткам.
Control Plane у Service Mesh размяркоўвае канфігурацыю паміж Sidecar Proxy і Data Plane.
Часта архітэктура Service Mesh прымяняецца для вырашэння складаных аперацыйных задач з выкарыстаннем кантэйнераў і мікрасэрвісаў. Піянерамі ў вобласці з'яўляюцца такія кампаніі як Lyft, Netflix і Twitter, якія падаюць стабільна якія працуюць сэрвісы мільёнам карыстачоў па ўсім свеце. (). Для меней патрабавальных прыкладных задач хутчэй за ўсё будзе дастаткова прасцейшых архітэктур.
Архітэктура Service Mesh ці наўрад калі-небудзь стане адказам на ўсе пытанні, злучаныя з працай прыкладанняў і іх дастаўкай. Архітэктары і распрацоўшчыкі валодаюць велізарным арсеналам інструментаў, і толькі адзін з іх - малаток, які сярод мноства задач павінен вырашаць толькі адну - забіваць цвікі. , напрыклад, уключае ў сябе некалькі розных мадэляў, якія даюць бесперапынны спектр падыходаў да рашэння задач з дапамогай мікрасэрвісаў.
Элементы, якія аб'ядноўваюцца ў архітэктуры Service Mesh, такія як NGINX, кантэйнеры, Kubernetes і мікрасэрвісы ў якасці архітэктурнага падыходу, могуць быць не менш прадуктыўна выкарыстаны і ў рэалізацыях без Service Mesh. Напрыклад, Istio быў распрацаваны як паўнавартасная архітэктура Service Mesh, але модульнасць кажа аб тым, што распрацоўшчыкі могуць выбіраць і прымяняць толькі неабходныя ім кампаненты тэхналогій. Памятаючы аб гэтым, неабходна сфарміраваць дакладнае разуменне канцэпцыі Service Mesh, нават калі вы не ўпэўненыя ў тым, што зможаце калі-небудзь паўнавартасна яе рэалізаваць у дадатку.
Крыніца: habr.com