Забелешка. превод.: Авторот на оваа статија (Лук Перкинс) е застапник за развивачи во организацијата CNCF, која е дом на проекти со отворен код како Linkerd, SMI (Service Mesh Interface) и Kuma (патем, дали сте се запрашале и зошто Istio е не е на оваа листа? .). Уште еднаш обидувајќи се да ѝ донесе на заедницата DevOps подобро разбирање за трендовската возбуда наречена „сервисна мрежа“, тој наведува 16 карактеристични способности што ги обезбедуваат таквите решенија.
Денес ― една од најжешките теми во областа на софтверското инженерство (и со право!). Мислам дека оваа технологија е неверојатно ветувачка и би сакала да ја видам широко прифатена (кога има смисла, се разбира). Сепак, тој сè уште е опкружен со аура на мистерија за повеќето луѓе. Во исто време, дури и оние кои добро познати со него, често е тешко да се артикулираат неговите предности и што точно е тоа (вклучувајќи ја и вашата навистина). Во оваа статија ќе се обидам да ја поправам ситуацијата со наведување на различни случаи на употреба „сервисни мрежи“*.
* Забелешка превод: овде и понатаму во статијата токму овој превод („сервисна мрежа“) ќе се користи за се уште новиот термин сервисна мрежа.
Но, прво сакам да дадам неколку коментари:
- Никогаш не сум работел со сервисни мрежи или не сум ги користел надвор од проекти започнати за мое образование. Од друга страна, јас бев тој што во 2015 година напиша еден куп документација за интерната мрежа на сервисот на Твитер (тогаш не се ни викаше „сервисна мрежа“) и учествував во изработката на веб-страницата и документацијата за , значи тоа значи нешто.
- Мојот список е приближен и нецелосен. Може да има случаи на употреба непознати за мене, а нови опции најверојатно ќе се појават со текот на времето како што технологијата се развива и нејзината популарност расте.
- Во исто време, не секоја постоечка имплементација на сервисна мрежа ги поддржува сите наведени случаи на употреба. Затоа, моите изјави како „сервисната мрежа може...“ треба да се читаат како „индивидуални, а можеби и сите популарни имплементации на сервисни мрежи можат...“.
- Редоследот на примерите не прави никаква разлика.
Кратка листа:
- откривање на услугата;
- шифрирање;
- автентикација и овластување;
- балансирање на оптоварување;
- прекин на колото;
- автоматско скалирање;
- распоредувања на канари;
- сино-зелени распоредувања;
- здравствен преглед;
- отфрлање на товарот;
- пресликување на сообраќајот;
- изолација;
- ограничување на стапката на барање, повторни обиди и истекувања;
- телеметрија;
- ревизија;
- визуелизација.
1. Откривање на услугата
TL;DR: Поврзете се со други услуги на мрежата користејќи едноставни имиња.
Услугите треба да можат автоматски да се „пронаоѓаат“ едни со други користејќи соодветни имиња - на пример, service.api.production, pets/staging или cassandra. Облачните средини се еластични и едно име може да скрие многу примери на услуга. Јасно е дека во таква ситуација физички е невозможно да се хардкодираат сите IP адреси.
Плус, кога една услуга ќе најде друга, таа треба да може да испраќа барања до таа услуга без страв дека тие ќе завршат на влезот на нејзината скршена инстанца. Со други зборови, сервисната мрежа мора да го следи здравјето на сите примероци на услуги и да ја одржува листата на домаќини што е можно по ажурирана.
Секоја сервисна мрежа различно го имплементира механизмот за откривање услуга. Во моментов, највообичаен начин е да се делегира на надворешни процеси како Kubernetes DNS. Во минатото на Твитер користевме систем за именување за оваа намена . Дополнително, технологијата за сервисна мрежа овозможува да се појават прилагодени механизми за именување (иако сè уште не сум видел никаква имплементација на SM со таква функционалност).
2. Енкрипција
TL;DR: Ослободете се од нешифрираниот сообраќај помеѓу услугите и направете го овој процес автоматизиран и скалабилен.
Убаво е да се знае дека напаѓачите не можат да навлезат во вашата внатрешна мрежа. Заштитните ѕидови прават одлична работа во ова. Но, што се случува ако хакер влезе внатре? Дали ќе може да прави што сака со интер-сервисниот сообраќај? Да се надеваме дека ова сепак нема да се случи. За да го спречите ова сценарио, треба да имплементирате мрежа со нулта доверба во која целиот сообраќај помеѓу услугите е шифриран. Повеќето модерни сервисни мрежи го постигнуваат тоа преку меѓусебно (заемна TLS, mTLS). Во некои случаи, mTLS работи во цели облаци и кластери (мислам дека меѓупланетарните комуникации некогаш ќе бидат распоредени слично).
Се разбира, за mTLS услуга мрежа изборен. Секоја услуга може да се грижи за сопствениот TLS, но тоа значи дека ќе треба да најдете начин да генерирате сертификати, да ги дистрибуирате низ сервисните хостови и да вклучите код во апликацијата што ќе ги вчита овие сертификати од датотеките. Да, не заборавајте да ги обновувате овие сертификати во редовни интервали. Сервисните мрежи го автоматизираат mTLS со системи како , кои, пак, го автоматизираат процесот на издавање и ротирање на сертификати.
3. Автентикација и овластување
TL;DR: Утврдете кој е барателот и дефинирајте што му е дозволено да прават пред барањето да стигне до услугата.
Услугите често сакаат да знаат кој го врши барањето (автентикација), и користејќи ги овие информации, одлучува дека на даден субјект му е дозволено да направи (овластување). Во овој случај, заменката „кој“ може да скрие:
- Други услуги. Ова се нарекува „автентикација“ врсник" На пример, услуга
webсака да пристапи до услугатаdb. Сервисните мрежи обично ги решаваат ваквите проблеми користејќи mTLS: сертификатите во овој случај делуваат како неопходен идентификатор. - Некои човечки корисници. Ова се нарекува „автентикација“ барање" На пример, корисник
haxor69сака да купи нова светилка. Сервисните мрежи обезбедуваат различни механизми, на пр. .Многумина од нас го направија ова во кодот на апликацијата. Влегува барање, гледаме низ табелата
users, најдете го корисникот и споредете ја лозинката, а потоа проверете ја колонатаpermissionsитн. Во случај на сервисна мрежа, ова се случува пред барањето да стигне до услугата.
Откако ќе утврдиме од кого доаѓа барањето, треба да утврдиме што му е дозволено да прави на овој субјект. Некои сервисни мрежи ви дозволуваат да поставите основни политики (за тоа кој може да прави што) како датотеки YAML или на командната линија, додека други нудат интеграција со рамки како . Крајната цел е вашите услуги да прифатат секое барање, безбедно под претпоставка дека доаѓа од доверлив извор и оваа акција е дозволена.
4. Балансирање на товарот
TL;DR: Дистрибуирајте го оптоварувањето низ сервисните примероци според одредена шема.
„Услуга“ во делот за услуги многу често се состои од многу идентични примероци. На пример, денес услугата cache се состои од 5 примероци, а утре нивниот број може да се зголеми на 11. Барањата испратени до cache, мора да се дистрибуира во согласност со одредена цел. На пример, минимизирајте ја латентноста или максимизирајте ја веројатноста да дојдете до работен пример. Најчесто користен алгоритам е Round-robin, но има многу други - на пример, пондериран метод (пондерирана) прашања (можете да изберете претпочитани цели), ѕвони (прстен) хаширање (со користење на конзистентно хаширање низ upstream домаќините) или метод на најмалку барање (предност се дава на примерот со најмалку барања).
Класичните балансери имаат и други функции, како HTTP кеширање и DDoS заштита, но тие не се многу релевантни за сообраќајот исток-запад (т.е. за сообраќај што тече во центарот за податоци - приближно превод) (типичен опсег на мрежа за услуги). Се разбира, не е неопходно да се користи сервисна мрежа за балансирање на оптоварување, но ви овозможува да поставите и контролирате политики за балансирање за секоја услуга од централизиран контролен слој, со што се елиминира потребата да се активираат и конфигурираат одделни балансери на оптоварување во мрежниот оџак .
5. Прекин на колото
TL;DR: Запрете го сообраќајот до проблематичната услуга и контролирајте ја штетата во најлошите сценарија.
Ако поради некоја причина услугата не може да се справи со сообраќајот, сервисната мрежа обезбедува неколку опции за решавање на овој проблем (другите ќе бидат разгледани во соодветните делови). Прекинувањето на колото е најтешката опција за исклучување на услуга од сообраќај. Сепак, само по себе нема смисла - потребен е резервен план. Може да се обезбеди заден притисок () до услугите што поднесуваат барања (само не заборавајте да ја конфигурирате мрежата на вашата услуга за ова!), или, на пример, да ја обоите страницата за статус во црвено и да ги пренасочите корисниците на друга верзија на страницата со „кит што паѓа“ („Твитер е долу“).
Сервисните мрежи не само што ви дозволуваат да дефинирате кога ќе следи исклучување и дека ова ќе следи. Во овој случај, „кога“ може да вклучи која било комбинација на одредени параметри: вкупниот број на барања за одреден период, бројот на паралелни врски, барањата што чекаат, активните повторувања итн.
Веројатно не сакате да го злоупотребувате прекинот на колото, но убаво е да знаете дека имате резервен план во случај на итност.
6. Автоматско скалирање
TL;DR: Зголемете го или намалете го бројот на примероци на услуги во зависност од наведените критериуми.
Сервисните мрежи не се распоредувачи, па затоа не се спроведе скалирање себе. Сепак, тие можат да дадат информации за тоа кои планери ќе ги засноваат своите одлуки. Бидејќи сервисните мрежи имаат пристап до целиот сообраќај помеѓу услугите, тие имаат опширни информации за тоа што се случува: кои услуги се соочуваат со проблеми, кои услуги се многу малку оптоварени (капацитетот што им е доделен се троши) итн.
На пример, Kubernetes ги скалира услугите засновани на процесорот и користењето на меморијата на pods (видете го нашиот извештај““- прибл. превод.), но ако одлучите да скалирате врз основа на која било друга метрика (во нашиот случај поврзана со сообраќајот), ќе ви треба посебна метрика. Управување покажува како се прави тоа со , и , но самиот процес е доста комплициран. Ние би сакале сервисната мрежа да го поедностави ова со тоа што ќе ни овозможи едноставно да поставиме услови како „да го зголемиме бројот на примероци на услуги auth, доколку бројот на нерешени барања го надмине прагот во рок од една минута“.
7. Канарски распоредувања
TL;DR: Тестирајте нови функции или верзии на услуги на подгрупа корисници.
Да речеме дека развивате SaaS производ и имате намера да лансирате кул нова верзија од него. Го тестиравте во постановка и одлично функционираше. Но, сè уште постои одредена загриженост за нејзиното однесување во реални услови. Со други зборови, треба да ја тестирате новата верзија на реални проблеми без да ја ризикувате довербата на корисникот. Распоредувањето на канари се одлични за ова. Тие ви дозволуваат да демонстрирате нова функција на подгрупа корисници. Оваа подгрупа може да се состои од најлојалните корисници или оние кои работат со бесплатната верзија на производот или корисници кои изразиле желба да бидат „заморчиња“.
Сервисните мрежи го имплементираат ова со тоа што ви дозволуваат да одредите критериуми што одредуваат кој ќе ја гледа верзијата на апликацијата и соодветно да го рутирате сообраќајот. Сепак, ништо не се менува за самите услуги. Верзијата 1.0 на услугата верува дека сите барања доаѓаат од корисници кои треба да ја видат, а верзијата 1.1 го верува истото за нејзините корисници. Во меѓувреме, можете да го промените процентот на сообраќај помеѓу старата и новата верзија, пренасочувајќи се поголем број корисници на новата, доколку таа работи стабилно и вашите „заморчиња“ даваат зелено светло.
8. Сино-зелени распоредувања
TL;DR: Воведете нова кул функција, но бидете подготвени веднаш да преземете сè назад.
Значење е да се воведе нова „сина“ услуга, пуштајќи ја паралелно со старата, „зелена“. Ако сè оди без проблеми и новата услуга работи добро, тогаш старата може постепено да се оневозможи. (За жал, еден ден оваа нова „сина“ услуга ќе ја повтори судбината на „зелената“ и ќе исчезне...) Сино-зелените распоредувања се разликуваат од канаринските по тоа што новата функција опфаќа сите одеднаш корисници (не дел); Поентата овде е да имате подготвено „безбедно пристаниште“ во случај нешто да тргне наопаку.
Сервисните мрежи нудат многу удобен начин за тестирање на „сина“ услуга и веднаш префрлување на работна „зелена“ во случај на проблеми. Да не зборуваме за фактот дека на патот тие даваат многу информации (види „Телеметрија“ подолу) за работата на „сините“, што помага да се разбере дали е подготвен за целосна работа.
Забелешка. превод.: Можете да прочитате повеќе за различните стратегии за распоредување во Кубернетес (вклучувајќи ги споменатите канари, сини/зелени и други) во .
9. Здравствена проверка
TL;DR: Следете кои примероци на услуги се функционални и одговарајте на оние што повеќе не се функционални.
Здравствен преглед (здравствен преглед) помага да се одлучи дали инстанците на услугата се подготвени да прифатат и обработуваат сообраќај. На пример, во случај на услуги HTTP, здравствената проверка може да изгледа како барање GET до крајната точка /health... Одговори 200 OK ќе значи дека инстанцата е здрава, која било друга - дека не е подготвена да прима сообраќај. Сервисните мрежи ви овозможуваат да го одредите и начинот на кој ќе се проверува функционалноста и зачестеноста со која ќе се врши оваа проверка. Оваа информација потоа може да се користи за други цели - на пример, за балансирање на оптоварување и прекин на колото.
Така, здравствената проверка не е самостојна употреба, туку обично се користи за постигнување други цели. Исто така, во зависност од резултатите од здравствените проверки, може да бидат потребни дејства надвор од другите цели на сервисната мрежа: на пример, ажурирање на страницата за статус, создавање проблем на GitHub или пополнување на JIRA билет. И сервисната мрежа нуди удобен механизам за автоматизирање на сето ова.
10. Ослободување на товарот
TL;DR: Пренасочете го сообраќајот како одговор на привремено зголемување на употребата.
Ако одредена услуга е преоптоварена со сообраќај, можете привремено да пренасочите дел од овој сообраќај на друга локација (т.е. „депонирање“, „пренесување“ (шупа) него таму). На пример, до услуга за резервна копија или центар за податоци или до постојан тема. Како резултат на тоа, услугата ќе продолжи да обработува некои барања наместо да паѓа и целосно да престане да обработува сè. Се претпочита намалувањето на оптоварувањето отколку прекинувањето на колото, но сепак не е препорачливо да се злоупотребува. Тоа помага да се спречат каскадни неуспеси кои предизвикуваат паѓање на долните услуги.
11. Паралелизирање/прегледување на сообраќајот
TL;DR: Испратете едно барање на неколку места одеднаш.
Понекогаш има потреба да се испрати барање (или одреден избор на барања) до неколку услуги одеднаш. Типичен пример е испраќање на дел од продукцискиот сообраќај до сервис за постановка. Главниот производствен веб-сервер испраќа барање до услугата низводно products.production и само нему. И сервисната мрежа интелигентно го копира ова барање и го испраќа до products.staging, за што веб-серверот не е ни свесен.
Друга поврзана сервисна мрежа за употреба што може да се имплементира на врвот на паралелизацијата на сообраќајот е . Тоа вклучува испраќање исти барања до различни верзии на услугата и проверка дали сите верзии се однесуваат исто. Сè уште не наидов на имплементација на сервисна мрежа со интегриран систем за тестирање на регресија како , но самата идеја изгледа ветувачка.
12. Изолација
TL;DR: Скршете ја мрежата за услуги во мини-мрежи.
Исто така познато како сегментацијаИзолацијата е уметност на поделба на сервисната мрежа на логички различни сегменти кои не знаат ништо еден за друг. Изолацијата е малку како создавање виртуелни приватни мрежи. Фундаменталната разлика е во тоа што сè уште можете да уживате во сите придобивки од мрежата на услуги (како што е откривањето на услугата), но со дополнителна безбедност. На пример, ако напаѓачот успее да навлезе во услуга на една од подмрежите, тој нема да може да види кои услуги работат на други подмрежи или да го пресретне нивниот сообраќај.
Покрај тоа, придобивките може да бидат и организациски. Можеби ќе сакате да ги подмрежите вашите услуги врз основа на структурата на вашата компанија и да ги ослободите програмерите од когнитивното оптоварување поради тоа што треба да ја имаат на ум целата мрежа на услуги.
13. Ограничување на стапката на барање, повторувања и тајмаути
TL;DR: Веќе не треба да ги вклучувате задачите за управување со необични барања во вашата база на кодови.
Сите овие работи може да се сметаат за посебни случаи на употреба, но решив да ги комбинирам поради една заедничка карактеристика: тие ги преземаат задачите за управување со животниот циклус на барањата што вообичаено се справуваат од библиотеките на апликациите. Ако развивате веб-сервер во Ruby on Rails (не интегриран со сервисна мрежа) што испраќа барања за задни услуги преку , апликацијата ќе треба да одлучи што да прави ако N барања не успеат. Исто така, ќе треба да дознаете колку сообраќај овие услуги ќе можат да ги обработат и кодираат овие параметри користејќи специјална библиотека. Плус, апликацијата ќе треба да одлучи кога е време да се откаже и да дозволи барањето да истече (врз основа на тајмаут). И за да се смени некој од горенаведените параметри, веб-серверот ќе треба да се запре, реконфигурира и повторно да се стартува.
Претоварувањето на овие задачи во мрежа на услуги не само што значи дека развивачите на услуги нема да мора да размислуваат за нив, туку и дека може да се гледаат на поглобален начин. Ако се користи сложен синџир на услуги, да речеме A -> B -> C -> D -> E, мора да се земе предвид целиот животен циклус на барањето. Ако задачата е да се пролонгираат временските прекини во услугата C, логично е тоа да се направи одеднаш, а не во делови: со ажурирање на сервисниот код и чекање додека барањето за повлекување не биде прифатено и системот CI ја распореди ажурираната услуга.
14. Телеметрија
TL;DR: Соберете ги сите потребни (и не баш) информации од услугите.
Телеметрија е општ термин кој вклучува метрика, дистрибуирано следење и логови. Сервисните мрежи нудат механизми за собирање и обработка на сите три типа на податоци. Ова е местото каде што работите стануваат малку матни бидејќи бројот на можни опции е преголем. За собирање метрика постои и други алатки кои можат да се користат за собирање трупци , , итн (на пример ClickHouse со нашите за K8s - прибл. превод.), за дистрибуирано трасирање постои и така натаму. Секоја сервисна мрежа може да поддржува некои алатки, а други не. Ќе биде интересно да се види дали проектот може обезбеди одредена конвергенција.
Во овој случај, предноста на технологијата за сервисна мрежа е тоа што контејнерите на страничните кола, во принцип, можат да ги соберат сите горенаведени податоци од нивните услуги. Со други зборови, имате на располагање единствен систем за собирање телеметрија, а сервисната мрежа може да ги обработи сите овие информации на различни начини. На пример:
- опашка логови од одредена услуга во CLI;
- следете го обемот на барања од контролната табла за сервисна мрежа;
- соберете дистрибуирани траги и проследете ги до систем како Јегер.
Внимание, субјективна проценка: Општо земено, телеметријата е област во која силните пречки од сервисната мрежа се непожелни. Собирањето основни информации и следењето на некои златни метрики, како стапката на успех на барањата и латентноста, е во ред, но да се надеваме дека нема да видиме како се појавуваат купишта Франкенштајн кои се обидуваат да ги заменат специјализираните системи, од кои некои се веќе докажани и добро проучени .
15. Ревизија
ТЛ;ДР: Оние кои ги забораваат лекциите од историјата се осудени да ги повторат.
Ревизијата е уметност на набљудување важни настани во системот. Во случај на сервисна мрежа, ова може да значи следење кој поднел барања до одредени крајни точки за одредени услуги или колку пати се случил некој настан поврзан со безбедноста во последниот месец.
Јасно е дека ревизијата е многу тесно поврзана со телеметријата. Разликата е во тоа што телеметријата обично се поврзува со работи како продуктивност и технички интегритет, додека ревизијата може да се однесува на правни и други прашања кои ја надминуваат строго техничката сфера (на пример, усогласеност со GDPR - Општата регулатива на ЕУ за заштита на податоците).
16. Преглед
TL;DR: Да живее React.js - неисцрпен извор на фантастични интерфејси.
Можеби има подобар термин, но не го знам. Едноставно мислам на графички приказ на сервисна мрежа или некои од неговите компоненти. Овие визуелизации може да вклучуваат индикатори како што се просечните доцнења, информации за конфигурацијата на страничната лента, резултатите од здравствената проверка и предупредувањата.
Работата во опкружување ориентирана кон услуги вклучува многу поголемо когнитивно оптоварување во споредба со Неговото Височество Монолитот. Затоа, когнитивниот притисок треба да се намали по секоја цена. Едноставен графички интерфејс за сервисна мрежа со можност за кликнување на копче и добивање на посакуваниот резултат може да биде одлучувачки за растот на популарноста на оваа технологија.
Не беа вклучени во списокот
Првично имав намера да вклучам уште неколку случаи на употреба во списокот, но потоа решив да не. Еве ги, заедно со причините за мојата одлука:
- Центар за повеќе податоци. Според мое мислење, ова не е толку случај на употреба колку тесна и специфична област на примена на сервисни мрежи или некој сет на функции како откривање на услугата.
- Влегување и излегување. Ова е поврзана област, но јас се ограничив (можеби вештачки) на случајот за употреба „сообраќај исток-запад“. Влегувањето и излегувањето заслужуваат посебна статија.
Заклучок
Тоа е се за сега! Повторно, оваа листа е многу произволна и најверојатно нецелосна. Ако мислите дека сум пропуштил нешто или сум згрешил, ве молиме контактирајте ме на Твитер (). Ве молиме почитувајте ги правилата за пристојност.
PS од преведувач
Илустрацијата на насловот за статијата се заснова на слика од статијата “„(од Грегори Мекинон). Покажува како некоја функционалност од апликациите (зелено) се преселила во сервисна мрежа што обезбедува меѓусебни врски меѓу нив (во сино).
Прочитајте и на нашиот блог:
- «";
- «";
- «".
Извор: www.habr.com
