Белешка. трансл.: Сервисна мрежа је феномен који још нема стабилан превод на руски (пре више од 2 године понудили смо опцију „мрежа за услуге“, а нешто касније неке колеге су почеле да активно промовишу комбинацију „услужно сито“) . Стални разговори о овој технологији довели су до ситуације у којој су маркетиншке и техничке компоненте исувише блиско испреплетене. Овај дивни материјал једног од аутора оригиналног термина има за циљ да унесе јасноћу инжењерима и не само.
Стрип из
Увод
Ако сте софтверски инжењер који ради негде у области позадинских система, термин „сервисна мрежа“ је вероватно већ постао чврсто укорењен у вашем уму у последњих неколико година. Захваљујући чудној коинциденцији, ова фраза све више преузима индустрију, а хипе и повезане промотивне понуде расту као грудва снега, лете низ брдо и не показују знаке успоравања.
Сервисна мрежа је рођена у мутним, тенденциозним водама природног екосистема облака. Нажалост, то значи да се велики део контроверзи око тога креће од „нискокалоричних чаврљања” до – да употребимо технички израз – очигледног срања. Али ако филтрирате сву буку, открићете да сервисна мрежа има веома стварну, дефинитивну и важну функцију.
У овом посту покушаћу да урадим управо то: пружим искрен, дубински, инжењерски оријентисан водич за сервисну мрежу. Одговорићу не само на питање: "Шта је то?", - али и "Зашто?"И "Зашто сада?". На крају, покушаћу да опишем зашто је (по мом мишљењу) ова технологија изазвала тако луду помпу, што је само по себи занимљива прича.
Кто а?
Здраво свима! Моје име је . Ја сам један од креатора - први сервисни месх пројекат и пројекат који је крив за појаву термина сервисна мрежа као такав (извините момци!). (Ноте трансл.: Иначе, у зору појаве овог појма, пре више од 2,5 године, већ смо превели рани материјал истог аутора под називом „".) И ја глава је стартуп који прави цоол сервисне мреже као што су Линкерд и .
Вероватно можете да претпоставите да имам веома пристрасно и субјективно мишљење о овом питању. Међутим, покушаћу да сведу пристрасност на минимум (са изузетком једног одељка: „Зашто се толико прича о мрежи услуга?“, - у којој ћу ипак поделити своје унапред створене идеје). Такође ћу се потрудити да овај водич буде што објективнији. У конкретним примерима, углавном ћу се ослањати на искуство Линкерда, указујући на разлике (ако их има) за које знам у имплементацији других типова сервисне мреже.
У реду, време је да пређемо на посластице.
Шта је сервисна мрежа?
Упркос свом узбуђењу, сервисна мрежа је структурно прилично једноставна. То је само гомила проксија корисничког простора који се налази „поред” услуга (о „близу” ћемо мало касније), плус скуп контролних процеса. Заступници се заједнички називају раван података, а контролни процеси се зову управљачка раван. Раван података пресреће позиве између услуга и ради „све врсте различитих ствари“ са њима; контролна раван, односно, координира понашање проксија и обезбеђује приступ за вас, тј. оператера, до АПИ-ја, омогућавајући да се мрежом манипулише и мери као целина.
Шта је ово проки? Ово је ТЦП прокси из категорије "Лаиер 7-аваре". (тј. „узимајући у обзир“ слој 7 ОСИ модела) као што су ХАПроки и НГИНКС. Можете одабрати прокси по свом укусу; Линкерд користи Руст проки, једноставно назван . Саставили смо га посебно за сервисну мрежу. Друге мреже преферирају друге проксије (Енвои је уобичајен избор). Међутим, избор проксија је само ствар имплементације.
Шта раде ови прокси сервери? Очигледно, они проксију позиве ка услугама и са њих (строго говорећи, они делују као проксији и обрнути проксији, обрађујући и долазне и одлазне позиве). И имплементирају скуп функција који се фокусира на позиве између услуге. Овај фокус на саобраћај између услуга је оно што разликује сервисни месх проки од, рецимо, АПИ приступних пролаза или улазних проксија (потоњи се фокусирају на позиве који долазе у кластер из спољашњег света). (Белешка. трансл.: За поређење постојећих Ингресс контролера за Кубернетес, од којих многи користе већ поменути Енвои, погледајте .)
Дакле, схватили смо раван података. Контролна раван је једноставнија: то је скуп компоненти које обезбеђују сву механику која је потребна да би раван података радио на координисан начин, укључујући откривање услуге, издавање ТЛС сертификата, агрегацију метрика, итд. Раван података обавештава контролну раван о његово понашање; заузврат, контролна раван обезбеђује АПИ који вам омогућава да промените и пратите понашање равни података у целини.
Испод је дијаграм контролне равни и равни података у Линкерду. Као што видите, контролна раван укључује неколико различитих компоненти, укључујући Прометхеус инстанцу која прикупља метрику са прокси сервера, као и друге компоненте као што су destination (откривање услуге), identity (цертификацијски орган, ЦА) и public-api (крајње тачке за веб и ЦЛИ). Насупрот томе, раван података је једноставан линкерд-проки поред инстанце апликације. Ово је само логички дијаграм; у примени у стварном свету, можда имате три реплике сваке компоненте контролне равни и стотине или хиљаде проксија у равни података.
(Плави оквири на овом дијаграму представљају границе Кубернетес подова. Можете видети да су контејнери са линкерд-проки-ом у истом под као и контејнери апликације. Ова шема је позната као контејнер за приколицу.)
Архитектура сервисне мреже има неколико важних импликација. Прво, пошто је посао проксија да пресреће позиве између услуга, мрежа услуга има смисла само ако је ваша апликација направљена за скуп услуга. месх може се користити са монолитима, али ово је очигледно сувишно због једног проксија, и мало је вероватно да ће његова функционалност бити тражена.
Друга важна последица је да сервисна мрежа захтева огроман број пуномоћника. У ствари, Линкерд повезује линкерд-проки са сваком инстанцом сваког сервиса (друге имплементације додају проки за сваки хост/хост/ВМ. То је ионако много). Таква активна употреба проксија сама по себи носи низ додатних компликација:
- Прокси у равни података треба да буду брзо, јер за сваки позив постоји неколико позива проксију: један на страни клијента, један на страни сервера.
- Такође, пуномоћници морају бити мали и лагана. Сваки ће трошити меморијске и ЦПУ ресурсе, а ова потрошња ће расти линеарно са апликацијом.
- Биће вам потребан механизам за постављање и ажурирање великог броја проксија. Да то урадите ручно није опција.
Уопштено гледано, сервисна мрежа изгледа овако (барем из птичје перспективе): постављате гомилу проксија корисничког простора који „раде нешто“ са интерним, међусервисним саобраћајем, и користите контролну раван за надгледање и управљање њима.
Време је за питање "Зашто?"
Чему служи сервисна мрежа?
Онима који су се први пут сусрели са идејом сервисне мреже могло би се опростити што су се осећали мало уплашено. Дизајн сервисне мреже значи да не само да ће повећати кашњење у апликацији, већ ће и повећати конзумирати ресурсе и ће додати гомила нових механизама у инфраструктури. Прво поставите сервисну мрежу, а онда одједном осетите потребу да опслужујете стотине (ако не и хиљаде) проксија. Питање је ко ће се за ово добровољно пријавити?
Одговор на ово питање има два дела. Прво, трошкови трансакције повезани са применом ових проксија могу бити значајно смањени због неких промена које се дешавају у екосистему (више о томе касније).
Друго, такав уређај је заправо одличан начин да се унесе додатна логика у систем. И не само зато што се много нових функција може додати помоћу мреже услуга, већ и зато што се то може урадити без мешања у екосистем. У ствари, цео модел сервисне мреже је заснован на овом постулату: у мултисервисном систему, без обзира на све направити појединачне услуге, саобраћај између њих је идеална тачка за додавање функционалности.
На пример, у Линкерду (као у већини мрежа) функционалност је фокусирана првенствено на ХТТП позиве, укључујући ХТТП/2 и гРПЦ*. Функционалност је прилично богата - може се поделити у три класе:
- Карактеристике везане за поузданост. Поновљени захтеви, тајмаути, канарски приступ (подела саобраћаја/преусмеравање) итд.
- Карактеристике везане за праћење. Обједињавање стопа успеха, кашњења и обима захтева за сваку услугу или појединачне правце; израда тополошких карата услуга и др.
- Карактеристике везане за сигурност. Узајамни ТЛС, контрола приступа итд.
* Са Линкердове тачке гледишта, гРПЦ се практично не разликује од ХТТП/2: он само користи протобуф у корисном учитавању. Са становишта програмера, ове две ствари су, наравно, различите.
Многи од ових механизама раде на нивоу захтева (отуда „Л7 проки“). На пример, ако услуга Фоо упути ХТТП позив сервису Бар, линкерд-проки на страни Фоо-а може интелигентно да балансира оптерећење и усмерава позиве од Фоо до Бар инстанци на основу уоченог кашњења; може поновити захтев ако је потребно (и ако је идемпотентан); он може да сними код одговора и временско ограничење, и тако даље. Слично, линкерд-проки на страни Бар може одбити захтев ако није дозвољен или ако је ограничење захтева прекорачено; може поправити кашњење са своје стране, итд.
Прокси могу да „учине нешто“ и на нивоу везе. На пример, линкерд-проки на страни Фоо-а може да покрене ТЛС везу, а линкерд-проки на страни Бар може да је прекине, а обе стране могу да верификују међусобне ТЛС сертификате*. Ово обезбеђује не само шифровање између услуга, већ и криптографски сигуран начин за идентификацију услуга: Фоо и Бар могу да „докажу“ да су они за које кажу да јесу.
* „Пријатељ пријатеља“ значи да је сертификат клијента такође верификован (мутуал ТЛС). У „класичном“ ТЛС-у, на пример, између претраживача и сервера обично се верификује сертификат само једне стране (сервера).
Без обзира да ли раде на нивоу захтева или везе, важно је нагласити да су све карактеристике сервисне мреже оперативни карактера. Линкерд није у стању да трансформише семантику корисног оптерећења – на пример, додавањем поља у ЈСОН фрагмент или уношењем промена у протобуф. О овој важној особини ћемо говорити касније када будемо говорили о ЕСБ-у и међуверату.
Ово је скуп функција које нуди сервисна мрежа. Поставља се питање: зашто их не имплементирати директно у апликацију? И зашто се уопште петљати са проксијем?
Зашто је сервисна мрежа добра идеја
Иако су могућности сервисне мреже задивљујуће, њена главна вредност заправо не лежи у карактеристикама. На крају ми Моћи имплементирајте их директно у апликацију (касније ћемо видети да је ово порекло сервисне мреже). Да то кажем у једној реченици, вредност сервисне мреже је: пружа функције критичне за покретање модерног серверског софтвера на конзистентан начин у целом стеку и независно од кода апликације.
Хајде да анализирамо овај предлог.
«Функције кључне за покретање модерног серверског софтвера„. Ако правите трансакциону серверску апликацију повезану са јавним интернетом која прихвата захтеве из спољашњег света и одговара на њих у кратком времену – на пример, веб апликацију, АПИ сервер и огромну већину других модерних апликација – и ако га имплементирате као скуп сервиса који синхроно интерагују једни са другима, и ако стално надограђујете овај софтвер, додајете нове функције и ако сте принуђени да одржавате овај систем у радном стању током процеса модификације – у овом случају, честитамо, креирате модеран серверски софтвер. И све те сјајне карактеристике које су горе наведене заправо су кључне за вас. Апликација мора бити поуздана, безбедна и морате бити у могућности да видите шта ради. Управо ова питања помаже у решавању сервисне мреже.
(У реду, моје уверење да је овај приступ модеран начин за прављење серверског софтвера се увукло у претходни пасус. Други више воле да развијају монолите, „реактивне микросервисе“ и друге ствари које не потпадају под горе дату дефиницију. Ови људи вероватно имају мишљење које се разликује од мог, а заузврат верујем да су "погрешни" - иако им у сваком случају сервисна мрежа није од велике користи).
«Униформа за цео стог„. Карактеристике које пружа сервисна мрежа нису само критичне. Примењују се на све сервисе у апликацији, без обзира на томе на ком језику су написани, који оквир користе, ко их је написао, како су распоређени и све друге суптилности њиховог развоја и употребе.
«Независан код апликације„. Коначно, сервисна мрежа не само да пружа доследну функционалност у целом стеку, већ то чини на начин који не захтева уређивање апликације. Основна основа функционалности сервисне мреже, укључујући задатке конфигурисања, ажурирања, рада, одржавања, итд., је чисто на нивоу платформе и независна је од апликације. Апликација се може променити без утицаја на сервисну мрежу. Заузврат, сервисна мрежа се може променити без икаквог учешћа апликације.
Укратко, сервисна мрежа не само да пружа виталну функционалност, већ то чини на глобалан, униформан и независан начин од апликација. И тако, док се функционалност сервисне мреже може имплементирати у сервисни код (на пример, као библиотека укључена у сваки сервис), овај приступ неће обезбедити униформност и независност који су толико вредни у случају сервисне мреже. .
И све што треба да урадите је да додате гомилу проксија! Обећавам, врло брзо ћемо размотрити оперативне трошкове повезане са додавањем ових проксија. Али прво, хајде да застанемо и погледамо ову идеју независности из перспективе разних људи.
Коме помаже сервисна мрежа?
Колико год то било незгодно, да би технологија постала важан део екосистема, људи морају да је прихвате. Дакле, ко је заинтересован за сервисну мрежу? Ко има користи од његове употребе?
Ако развијате модеран серверски софтвер, можете отприлике замислити свој тим као групу власници услугакоји заједно развијају и имплементирају пословну логику, и власници платформиукључени у развој интерне платформе на којој ове услуге раде. У малим организацијама то могу бити исти људи, али како компанија расте, ове улоге имају тенденцију да постану израженије и чак подељене на под-улоге... (Овде има много тога да се каже о променљивој природи девопса, организациони утицај микросервиса итд.) н. Али за сада узмимо ове описе као дате).
Са ове тачке гледишта, јасни корисници сервисне мреже су власници платформе. На крају крајева, крајњи циљ платформског тима је стварање интерне платформе на којој власници услуга могу имплементирати пословну логику и то на начин који им гарантује максималну независност од мрачних детаља њеног рада. Сервисна мрежа не само да нуди могућности кључне за постизање овог циља, већ то чини на начин који, заузврат, не намеће никакве зависности од власника услуга.
Власници услуга такође имају користи, иако на индиректнији начин. Циљ власника сервиса је да буде што продуктивнији у спровођењу логике пословног процеса, и што мање мора да брине о оперативним питањима, то боље. Уместо да се баве применом, рецимо, политика поновног покушаја или ТЛС-а, они могу да се усредсреде само на пословне циљеве и надају се да ће се платформа побринути за остало. Ово је за њих велика предност.
Организациона вредност такве поделе између власника платформи и услуга не може се преценити. Мислим да она доприноси главни допринос вредности сервисне мреже.
Научили смо ову лекцију када нам је један рани фан Линкерда рекао зашто су изабрали сервисну мрежу: јер им је то омогућило да „причају на минимуму“. Ево неких детаља: момци из једне велике компаније су мигрирали своју платформу на Кубернетес. Пошто је апликација радила са осетљивим информацијама, желели су да шифрују све комуникације у кластерима. Међутим, ситуација је била компликована присуством стотина услуга и стотина развојних тимова. Могућност да контактирају све и убеде их да укључе подршку за ТЛС у своје планове уопште им се није допала. Инсталирањем Линкерда, они су мигрирали одговорност од програмера (са чије тачке гледишта је то била непотребна мука) до платформера, којима је ово био приоритет највишег нивоа. Другим речима, Линкерд је за њих решавао не толико технички колико организациони проблем.
Укратко, сервисна мрежа није техничко решење, већ друштвено-техничких Проблеми. (Хвала вам за увођење овог појма.
Да ли ће сервисна мрежа решити све моје проблеме?
Да. Мислим, не!
Гледајући три класе карактеристика које су горе наведене – поузданост, сигурност и уочљивост – постаје јасно да сервисна мрежа није потпуно решење ни за један од ових проблема. Иако Линкерд може да шаље поновљене захтеве (ако зна да су идемпотентни), није у позицији да доноси одлуке о томе шта да врати кориснику ако услуга коначно нестане – такве одлуке мора да донесе апликација. Линкерд може да води статистику о успешним захтевима, али није у могућности да погледа у услугу и обезбеди њене интерне метрике - апликација би требало да има такав комплет алата. И док Линкерд може да хостује мТЛС, пуноправна безбедносна решења захтевају много више.
Подскуп карактеристика у овим областима које нуди мрежа услуга је повезан са карактеристике платформе. Под овим мислим на функције које:
- Независно од пословне логике. Начин на који се конструишу хистограми позива између Фоо и Бар је потпуно независан од тога да ли зашто Фоо зове Бар.
- Тешко је правилно применити. У Линкерду, поновни покушаји се параметризују са свим врстама фенси ствари као што су буџети за поновни покушај (поново покушајте са буџетима), будући да ће простодушан приступ спровођењу оваквих ствари сигурно довести до појаве такозване „лавине захтева“ (поновни покушај олује) и други проблеми специфични за дистрибуиране системе.
- Најефикаснији када се примењује доследно. ТЛС механизам има смисла само ако се примењује свуда.
Пошто су ове карактеристике имплементиране на прокси слоју (а не на слоју апликације), сервисна мрежа их излаже на платформе, а не апликације. Дакле, није битно на ком су језику сервиси написани, који оквир користе, ко их је написао и зашто. Проксији раде изван свих ових детаља, а основна основа ове функционалности, укључујући задатке конфигурисања, ажурирања, рада, одржавања, итд., лежи искључиво на нивоу платформе.
Примери могућности сервисне мреже
Укратко, сервисна мрежа није комплетно решење за поузданост, уочљивост или безбедност. Обим ових области подразумева обавезно учешће власника услуга, Опс/СРЕ тимова и других заинтересованих страна компаније. Сервисна мрежа обезбеђује само „срез“ на нивоу платформе за сваку од ових области.
Зашто је сервисна мрежа постала популарна управо сада?
Вероватно се тренутно питате: ОК, ако је сервисна мрежа тако добра, зашто нисмо почели да примењујемо милионе проксија на стеку пре десет година?
На ово питање постоји баналан одговор: пре десет година сви су градили монолите, а сервисна мрежа никоме није била потребна. То је тачно, али по мом мишљењу, овај одговор промашује поенту. Чак и пре десет година, концепт микросервиса као обећавајућег начина за креирање система великих размера био је нашироко разматран и примењиван у компанијама као што су Твитер, Фејсбук, Гугл и Нетфликс. Општа перцепција - барем у деловима индустрије са којима сам био у контакту - била је да су микросервисе "прави начин" за изградњу великих система, чак и ако је то било проклето тешко.
Наравно, иако су постојале компаније које су користиле микросервисе пре десет година, оне нису стављале прокси свуда где су могле да формирају мрежу услуга. Међутим, ако боље погледате, урадили су нешто слично: многе од ових компанија су захтевале коришћење посебне интерне библиотеке за умрежавање (понекад се назива библиотека дебелих клијената, библиотека дебелих клијената).
Нетфлик је имао Хистерик, Гугл је имао Стубби, Твиттер је имао библиотеку Финагле. Финагле је, на пример, био обавезан за сваку нову услугу на Твитеру. Обрађивао је и клијентску и серверску страну веза, дозвољавао је поновљене захтеве, подржавао рутирање захтева, балансирање оптерећења и мерење. Обезбедио је доследан ниво поузданости и уочљивости у целом Твиттер групи, без обзира на то шта је услуга радила. Наравно, радио је само за ЈВМ језике и био је заснован на моделу програмирања који је морао да се користи за целу апликацију. Међутим, његова функционалност је била скоро иста као и сервисне мреже. (У ствари, прва верзија Линкерда била је једноставно Финагле умотана у проки форму.)
Дакле, пре десет година нису постојале само микросервисе, већ и специјалне прото-сервице-месх библиотеке које су решавале исте проблеме које сервисна мрежа решава данас. Међутим, сама сервисна мрежа тада није постојала. Морала је бити још једна смена пре него што се појавила.
И ту лежи дубљи одговор, скривен у још једној промени која се догодила у последњих 10 година: цена примене микросервиса је драматично опала. Горе поменуте компаније које су користиле микросервисе пре десет година — Твитер, Нетфликс, Фејсбук, Гугл — биле су компаније огромног обима и огромних ресурса. Не само да су имали потребу, већ су имали и могућност да изграде, имплементирају и раде велике апликације засноване на микроуслугама. Енергија и напор који су Твиттер инжењери уложили у прелазак са монолитног на приступ микросервисима је невероватан. (Искрено, као и чињеница да је функционисало.) Овакво инфраструктурно маневрисање тада је било немогуће за мање компаније.
Пређимо у садашњост. Данас постоје стартапови у којима је однос микросервиса и програмера 5:1 (или чак ), и штавише, успешно се носе са њима! Ако стартап од 5 особа може лако да управља са 50 микроуслуга, онда је нешто очигледно смањило трошкове њихове имплементације.
1500 микросервиса у Монцу; свака линија је прописано мрежно правило које дозвољава саобраћај
Драматично смањење трошкова оперативних микроуслуга је резултат једног процеса: растућа популарност контејнера и оркестратори. Управо је ово дубок одговор на питање шта је допринело настанку сервисне мреже. Иста технологија учинила је и сервисну мрежу и микросервисе атрактивним: Кубернетес и Доцкер.
Зашто? Па, Доцкер решава један велики проблем - проблем паковања. Паковањем апликације и њених (немрежних) зависности времена извођења у контејнер, Доцкер претвара апликацију у заменљиву јединицу која се може хостовати и покретати било где. Истовремено, то у великој мери поједностављује рад. вишејезичне стек: Пошто је контејнер атомска јединица извршења, није важно шта је унутра, да ли је то ЈВМ, Ноде, Го, Питхон или Руби апликација, за примену и оперативне сврхе. Само га покренеш и то је то.
Кубернетес све подиже на виши ниво. Сада када постоје тоне „ствари за покретање“ и тоне машина на којима се могу покренути, постоји потреба за алатом који може да их повеже једно са другим. У ширем смислу, дајете Кубернетес-у много контејнера и много машина, и он их међусобно усклађује (наравно, ово је динамичан процес који се стално мења: нови контејнери се крећу по систему, машине се покрећу и заустављају, итд. Међутим, Кубернетес све ово узима у обзир).
Када се Кубернетес постави, време које је потребно за примену и рад једне услуге се не разликује много од трошкова за примену и управљање десет услуга (у ствари, скоро је исто за 100 услуга). Додајте овом контејнеру као механизам за паковање који подстиче вишејезичну примену, и имаћете гомилу нових апликација имплементираних као микросервисе написане на више језика, управо такво окружење за које је сервисна мрежа тако добро прилагођена.
Дакле, долазимо до одговора на питање зашто је идеја о сервисној мрежи постала популарна управо сада: униформност коју Кубернетес пружа за услуге је директно применљива на оперативне задатке са којима се сервисна мрежа суочава. Пакујете проксије у контејнере, дајете Кубернетесу задатак да их залепи где год је то могуће, и воила! На излазу добијате сервисну мрежу, док Кубернетес контролише сву механику њеног постављања. (Бар из птичје перспективе. Наравно, постоји много нијанси у овом процесу.)
Да сумирамо: разлог зашто је сервисна мрежа постала популарна сада, а не пре десет година је тај што су Кубернетес и Доцкер не само значајно порасли требати у њему, поједностављујући имплементацију апликација као скупова вишејезичних микросервиса, али и значајно смањене трошкови за њен рад обезбеђивањем механизама за постављање и одржавање прокси паркова бочних приколица.
Зашто се толико прича о сервисној мрежи?
Упозорење: У овом одељку прибегавам свакојаким претпоставкама, нагађањима, измишљотинама и инсајдерским информацијама.
Потрага за "сервисном мрежом" ће открити гомилу рециклираног, нискокалоријског садржаја, чудних пројеката и калеидоскопа изобличења достојног ехо коморе. Свака модерна нова технологија има ово, али у случају сервисне мреже, проблем је посебно акутан. Зашто?
Па, део је и моја кривица. Напорно сам радио да промовишем Линкерд и мрежу услуга при свакој прилици коју добијем кроз безброј постова на блогу и чланака попут овог. Али нисам толико моћан. Да бисмо заиста одговорили на ово питање, морамо мало да разговарамо о укупној ситуацији. А о томе је немогуће говорити без помињања једног пројекта: је мрежна мрежа отвореног кода коју су заједнички развили Гоогле, ИБМ и Лифт.
(Те три компаније имају веома различите улоге: чини се да је учешће Лифт-а ограничено само на име; они су аутори Енвои-а, али не користе или су укључени у развој Истио-а. ИБМ је укључен у развој Истио-а и користи га. Гоогле је у великој мери укључен у развој Истио-а, али колико могу да кажем, заправо га не користи.)
Пројекат Истио је познат по две ствари. Прво, то је огроман маркетиншки напор који Гоогле, посебно, улаже у своју промоцију. Процењујем да је већина људи који су тренутно упознати са концептом сервисне мреже први пут сазнали за њега захваљујући Истио-у. Друга карактеристика је колико је Истио лоше примљен. По овом питању, ја сам, очигледно, заинтересована страна, али покушавајући да останем што објективнији, ипак не могу да не , није баш специфично (иако није јединствено: системд ми пада на памет, ...) за пројекат отвореног кода.
(У пракси, чини се да Истио има проблема не само са сложеношћу и корисничким доживљајем, већ и са перформансама. На пример, током које је спровела трећа страна, стручњаци су пронашли ситуације у којима је Истио-ово кашњење репа било 100 пута веће од Линкердовог, као и ситуације са недостатком ресурса, када је Линкерд наставио да функционише успешно, а Истио је потпуно престао да ради.)
Остављајући по страни моје теорије о томе зашто се то догодило, верујем да је ван скале помпе око мреже услуга последица умешаности Гугла. Наиме, комбинација следећа три фактора:
- опсесивна промоција Истио-а од стране Гоогле-а;
- одговарајући неодобравајући, критички однос према пројекту;
- недавна велика популарност Кубернетеса, чије је сећање још увек свеже.
Заједно, ови фактори се спајају у неку врсту опојне, аноксичне средине у којој је способност рационалног расуђивања ослабљена, а остаје само дивна разноликост. .
Са Линкердове тачке гледишта, ово је... описао бих то као помешани благослов. Мислим, сјајно је што је сервисна мрежа ушла у мејнстрим – што није био случај 2016. године када се Линкерд први пут појавио и било је заиста тешко привући пажњу људи на пројекат. Сада нема таквог проблема! Али лоша вест је да је ситуација са сервисном мрежом данас толико збуњујућа да је готово немогуће открити који пројекти заиста припадају категорији сервисне мреже (а камоли открити који је најбољи за одређени случај употребе). Ово свакако свима смета (а дефинитивно је у неким случајевима Истио или неки други пројекат бољи од Линкерда, пошто ово друго није решење за све).
Са Линкердове стране, наша стратегија је била да игноришемо буку, наставимо да се фокусирамо на решавање стварних проблема у заједници и у суштини сачекамо да хипе утихне. На крају ће се гужва спласнути и можемо да наставимо да радимо у миру.
До тада, сви ћемо морати да будемо стрпљиви.
Да ли ће сервисна мрежа бити од користи мени, скромном софтверском инжењеру?
Следећи упитник ће вам помоћи да одговорите на ово питање:
Бавите ли се искључиво имплементацијом пословне логике? У овом случају, сервисна мрежа вам неће бити од користи. То је, наравно, можда ће вас то занимати, али у идеалном случају сервисна мрежа не би требало директно да утиче на било шта у вашем окружењу. Наставите да радите на ономе за шта сте плаћени.
Да ли одржавате платформу у компанији која користи Кубернетес? Да, у овом случају вам је потребна сервисна мрежа (наравно, ако не користите К8с само за покретање монолитне или групне обраде - али онда бих желео да питам зашто вам треба К8с). Највероватније ћете се наћи у ситуацији са много микросервиса које су написали различити људи. Сви су у интеракцији једни са другима и повезани су у сплет зависности времена извршавања, а ви морате пронаћи начин да се носите са свим овим. Употреба Кубернетеса вам омогућава да изаберете сервисну мрежу "за себе". Да бисте то урадили, упознајте се са њиховим могућностима и карактеристикама и одговорите на питање да ли вам неки од доступних пројеката уопште одговара (препоручујем да своје истраживање започнете са Линкердом).
Да ли користите платформу за компанију која НЕ користи Кубернетес, али користи микросервисе? У овом случају, сервисна мрежа ће вам бити корисна, али њена употреба неће бити тривијална. Наравно да можете имитирати сервице месх хостовањем гомиле проксија, али важна предност Кубернетеса је управо модел примене: ручно одржавање ових проксија захтева много више времена, труда и трошкова.
Да ли сте задужени за платформу у компанији која ради са монолитима? У овом случају, вероватно вам не треба сервисна мрежа. Ако радите са монолитима (или чак скуповима монолита) који имају добро дефинисане и ретко променљиве обрасце интеракције, онда сервисна мрежа нема много тога да вам понуди. Дакле, можете га једноставно игнорисати и надати се да ће нестати као ружан сан...
Закључак
Вероватно, сервисну мрежу још увек не би требало називати „најнаглашенијом технологијом на свету“ - ова сумњива част вероватно припада биткоину или вештачкој интелигенцији. Можда је у првих пет. Али ако се пробијете кроз слојеве буке и галаме, постаје јасно да сервисна мрежа доноси стварне предности онима који креирају апликације у Кубернетесу.
Волео бих да испробате Линкерд - инсталирате га у Кубернетес кластер (или чак Миникубе на лаптопу) и сами видите о чему говорим.
FAQ
- Ако занемарим сервисну мрежу, да ли ће она нестати?
— Морам да вас разочарам: сервисна мрежа је код нас дуго времена.
— Али НЕ ЖЕЛИМ да користим сервисну мрежу!
- Па није потребно! Само прочитајте мој упитник изнад да видите да ли би требало да се барем упознате са његовим основама.
— Није ли то стари добри ЕСБ/миддлеваре са новим сосом?
- Сервисна мрежа се бави оперативном логиком, а не семантичком. пословни аутобус за услуге (). Одржавање овог раздвајања помаже сервисној мрежи да избегне исту судбину.
- По чему се сервисна мрежа разликује од АПИ мрежних пролаза?
Постоји милион чланака на ову тему. Само гуглај.
Да ли је Енвои сервисна мрежа?
- Не, Енвои није сервисна мрежа, то је прокси сервер. Може се користити за организовање сервисне мреже (и још много тога - то је прокси за општу намену). Али само по себи, то није сервисна мрежа.
— Нетворк Сервице Месх је сервисна мрежа?
- Не. Упркос имену, ово није сервисна мрежа (како вам се свиђају чуда маркетинга?).
- Да ли ће сервисна мрежа помоћи мом реактивном асинхроном систему заснованом на реду порука?
- Не, сервисна мрежа ти неће помоћи.
- Коју сервисну мрежу да користим?
- , прост.
- Чланак је срање! / Аутор - на сапун!
— Молимо вас да поделите везу са свим својим пријатељима како би могли да је виде!
Захвалнице
Као што можете претпоставити из наслова, овај чланак је инспирисан фантастичном расправом Џеја Крепса "„. Упознала сам Џеја пре десет година док сам радила интервју на Линкед Ину и од тада ми је био инспирација.
Иако волим да себе називам „Линкард програмер“, реалност је да сам више одржавалац датотеке РЕАДМЕ.мд у пројекту. Радим на Линкерду данас , , људи, а овај пројекат се не би догодио без учешћа дивне заједнице сарадника и корисника.
И на крају, посебно хвала креатору Линкерда, (Примус интер парес), који је, заједно са мном пре много година, безглаво заронио у сву ову гужву са сервисном мрежом.
ПС од преводиоца
Прочитајте и на нашем блогу:
- «";
- «";
- «";
- «";
- «'.
Извор: ввв.хабр.цом