Сервисна мрежа: Што секој софтверски инженер треба да знае за најжешката технологија

Забелешка. превод.: Сервисната мрежа е феномен што сè уште нема стабилен превод на руски (пред повеќе од 2 години ја понудивме опцијата „мрежа за услуги“, а малку подоцна, некои колеги почнаа активно да ја промовираат комбинацијата „сервисно сито“) . Постојаниот разговор за оваа технологија доведе до ситуација во која маркетинг и техничките компоненти се премногу тесно испреплетени. Овој прекрасен материјал од еден од авторите на оригиналниот термин има за цел да им донесе јасност на инженерите, а не само.

Стрип од Себастијан Касерес

Вовед

Ако сте софтверски инженер кој работи некаде во областа на задни системи, терминот „сервисна мрежа“ веројатно веќе стана цврсто вкоренет во вашиот ум во последните неколку години. Благодарение на чудна случајност, оваа фраза се повеќе ја зазема индустријата, а возбудата и поврзаните промотивни понуди растат како снежна топка, летаат по ридот и не покажуваат знаци на забавување.

Сервисната мрежа е родена во матните, тенденциозни води на родниот екосистем на облакот. За жал, ова значи дека голем дел од контроверзите околу него се движат од „нискокалорични муабети“ до - да го користам техничкиот термин - бесрамни срања. Но, ако ја филтрирате целата бучава, можете да откриете дека сервисната мрежа има многу реална, дефинитивна и важна функција.

Во овој пост, ќе се обидам да го направам токму тоа: да дадам искрен, продлабочен, инженерски ориентиран водич за сервисната мрежа. Ќе одговорам повеќе од само прашањето: "Што е тоа?", - но, исто така "Зошто?"И „Зошто сега?. Конечно, ќе се обидам да наведам зошто (според мое мислење) оваа конкретна технологија предизвика толку луда возбуда, што само по себе е интересна приказна.

Кој сум јас

Здраво на сите! Моето име е Вилијам Морган. Јас сум еден од креаторите Линкерд - првиот сервисен мрежен проект и проектот кој е виновен за појавата на терминот сервисна мрежа како таков (извинете момци!). (Забелешка превод.: Инаку, во зората на појавувањето на овој термин, пред повеќе од 2,5 години, веќе го преведовме раниот материјал на истиот автор наречен „Што е сервисна мрежа и зошто ми е потребна [за облак апликација со микросервиси]?".) Водам и јас Пловидбена е стартап кој создава кул сервисни мрежи како Linkerd и Нуркач.

Веројатно можете да претпоставите дека имам многу пристрасно и субјективно мислење за ова прашање. Сепак, ќе се обидам да ја задржам пристрасноста на минимум (со исклучок на еден дел: „Зошто толку многу се зборува за сервисната мрежа?, - во која сепак ќе ги споделам моите однапред смислени идеи). Исто така, ќе дадам се од себе за да го направам овој водич што е можно пообјективен. Во конкретни примери, главно ќе се потпрам на искуството на Linkerd, притоа истакнувајќи ги разликите (доколку ги има) за кои знам во имплементацијата на други видови сервисни мрежи.

Добро, време е да се префрлиме на задоволствата.

Што е сервисна мрежа?

И покрај сета возбуда, сервисната мрежа е структурно прилично едноставна. Тоа е само еден куп прокси за кориснички простор лоцирани „до“ услугите (подоцна ќе зборуваме малку за „близу“), плус збир на контролни процеси. Полномошниците се колективно повикани податочна рамнина, и се нарекуваат контролните процеси контролна рамнина. Податочната рамнина пресретнува повици помеѓу услугите и прави „се што е различно“ со нив; контролната рамнина, соодветно, го координира однесувањето на прокси и обезбедува пристап за вас, т.е. оператор, на API, овозможувајќи мрежата да се манипулира и мери како целина.

Што е овој прокси? Ова е TCP-прокси од категоријата „Свесен за слој 7“. (т.е. „земајќи го предвид“ седмиот слој на моделот OSI) како HAProxy и NGINX. Можете да изберете прокси по ваш вкус; Linkerd користи Rust прокси, некомплицирано именуван поврзувач-прокси. Го составивме специјално за сервисната мрежа. Другите мрежи претпочитаат други прокси (Envoy е вообичаен избор). Сепак, изборот на прокси е само прашање на имплементација.

Што прават овие прокси-сервери? Очигледно, тие ги испраќаат повиците до и од услугите (строго кажано, тие дејствуваат како прокси и обратни прокси, справувајќи се со дојдовните и појдовните повици). И тие имплементираат сет на функции што се фокусира на повиците меѓу услуги. Овој фокус на сообраќајот помеѓу услугите е она што го разликува сервисниот мрежен прокси од, да речеме, портите на API или проксите за влез (вторите се фокусираат на повиците кои доаѓаат во кластерот од надворешниот свет). (Забелешка. превод.: За споредба на постоечките контролори на Kubernetes Ingress, од кои многумина го користат веќе споменатиот Пратеник, види овој напис.)

Значи, ја сфативме рамнината на податоци. Контролната рамнина е поедноставна: тоа е збир на компоненти кои ја обезбедуваат целата механика што му е потребна на податочната рамнина за да работи на координиран начин, вклучувајќи откривање услуга, издавање сертификат TLS, агрегација на метрика, итн. неговото однесување; за возврат, контролната рамнина обезбедува API што ви овозможува да го промените и следите однесувањето на рамнината на податоци како целина.

Подолу е дијаграм на контролната рамнина и рамнината на податоци во Линкерд. Како што можете да видите, контролната рамнина вклучува неколку различни компоненти, вклучително и пример на Prometheus кој собира метрика од прокси-сервери, како и други компоненти како што се destination (откривање на услугата), identity (орган за издавање сертификати, CA) и public-api (крајни точки за веб и CLI). Спротивно на тоа, податочната рамнина е едноставно поврзувачко-прокси веднаш до примерот на апликацијата. Ова е само логички дијаграм; при распоредување во реален свет, може да имате три копии на секоја компонента на контролната рамнина и стотици или илјадници прокси во податочната рамнина.

(Сините полиња на овој дијаграм ги претставуваат границите на Kubernetes pods. Можете да видите дека контејнерите со linkerd-proxy се во истиот дел како и контејнерите на апликацијата. Оваа шема е позната како контејнер за странична кола.)

Архитектурата на сервисната мрежа има неколку важни импликации. Прво, бидејќи работата на прокси е да пресретнува повици помеѓу услугите, сервисната мрежа има смисла само ако вашата апликација е изградена за сет на услуги. мрежа некој може да користете со монолити, но ова е јасно излишно за доброто на еден прокси, а неговата функционалност веројатно нема да биде на побарувачката.

Друга важна последица е што бара сервисната мрежа огромен број на полномошници. Всушност, Linkerd поврзува поврзувач-прокси за секој пример од секоја услуга (другите имплементации додаваат прокси на секој јазол/домаќин/ВМ. Тоа е сепак многу). Таквата активна употреба на прокси сама по себе носи голем број дополнителни компликации:

1. Прокси во податочната рамнина треба да бидат брзо, бидејќи за секој повик има неколку повици до прокси: еден од клиентската страна, еден од страната на серверот.
2. Исто така, прокси мора да бидат мали и лесен. Секој ќе троши меморија и ресурси на процесорот, а оваа потрошувачка ќе расте линеарно со апликацијата.
3. Ќе ви треба механизам за распоредување и ажурирање на голем број прокси. Рачно правење не е опција.

Општо земено, мрежата за услуги изгледа вака (барем од птичја перспектива): распоредувате еден куп прокси за кориснички простор што „прават нешто“ со внатрешниот сообраќај меѓу услугите и ја користите контролната рамнина за следење и управување со нив.

Време е за прашањето „Зошто?

За што служи сервисната мрежа?

За оние кои првпат се сретнаа со идејата за сервисна мрежа, простливо е да се биде малку во страв. Дизајнот на сервисната мрежа значи дека не само што ќе ја зголеми доцнењето на апликацијата, туку и ќе ја зголеми консумираат ресурси и ќе додаде еден куп нови механизми во инфраструктурата. Прво поставувате сервисна мрежа, а потоа одеднаш се наоѓате дека треба да опслужувате стотици (ако не и илјадници) прокси. Прашањето е кој ќе волонтира за ова?

Одговорот на ова прашање има два дела. Прво, трансакциските трошоци поврзани со распоредувањето на овие прокси може значително да се намалат поради некои промени што се случуваат во екосистемот (повеќе за ова подоцна).

Второ, таков уред е всушност одличен начин за воведување дополнителна логика во системот. И не само затоа што може да се додадат многу нови функции со помош на сервисната мрежа, туку и затоа што тоа може да се направи без да се меша со екосистемот. Всушност, целиот модел на сервисна мрежа се заснова на овој постулат: во мултисервисен систем, без разлика на се направи индивидуални услуги, сообраќај помеѓу нив е идеална точка за додавање функционалност.

На пример, во Linkerd (како и во повеќето мрежи) функционалноста е фокусирана првенствено на HTTP повици, вклучувајќи HTTP/2 и gRPC*. Функционалноста е доста богата - може да се подели во три класи:

1. Поврзани карактеристики доверливост. Обидете се повторно со барања, тајмаути, канарински пристап (поделба/пренасочување на сообраќајот) итн.
2. Поврзани карактеристики следење. Агрегација на стапки на успех, одложувања и обем на барања за секоја услуга или поединечни дестинации; градење тополошки карти на услуги и сл.
3. Поврзани карактеристики безбедност. Заемна TLS, контрола на пристап, итн.

* Од гледна точка на Linkerd, gRPC практично не се разликува од HTTP/2: тој само користи протобуф во товарот. Од гледна точка на развивач, овие две работи се, се разбира, различни.

Многу од овие механизми работат на ниво на барање (оттука и „L7 прокси“). На пример, ако услугата Foo упати HTTP повик до лентата за услуги, поврзувачот-прокси од страната на Foo може интелигентно да вчита-балансира и да насочува повици од примероци од Foo до Bar врз основа на набљудуваната латентност; може да го повтори барањето доколку е потребно (и ако е идемпотентно); тој може да го сними кодот за одговор и истекот на времето, и така натаму. Слично на тоа, поврзувачот-прокси од страната на лентата може да одбие барање ако тоа не е дозволено или ако е надминато ограничувањето на барањето; може да го поправи доцнењето од своја страна, итн.

Проксите можат да „направат нешто“ и на ниво на врска. На пример, поврзувачот-прокси од страната Foo може да иницира TLS-врска, а поврзаниот-прокси од страната на лентата може да го прекине, и двете страни можат да ги потврдат меѓусебните TLS сертификати*. Ова обезбедува не само шифрирање помеѓу услугите, туку и криптографски безбеден начин за идентификување на услугите: Фу и Бар можат да „докажат“ дека се тие што велат дека се.

* „Пријател на пријател“ значи дека сертификатот на клиентот е исто така потврден (заемно TLS). Во „класичниот“ TLS, на пример, помеѓу прелистувачот и серверот, обично се потврдува сертификатот на само едната страна (серверот).

Без разлика дали тие работат на ниво на барање или поврзување, важно е да се нагласи дека сите карактеристики на мрежата за услуги се оперативни карактер. Linkerd не може да ја трансформира семантиката на товарот, како што е додавање полиња на фрагмент JSON или правење промени во протобуф. Ќе зборуваме за оваа важна карактеристика подоцна кога ќе зборуваме за ESB и Middleware.

Ова е збир на функции што ги нуди сервисната мрежа. Се поставува прашањето: зошто да не ги имплементирате директно во апликацијата? И зошто воопшто да се плеткаш со прокси?

Зошто сервисната мрежа е добра идеја

Иако можностите на сервисната мрежа се волшебни, нејзината главна вредност всушност не лежи во карактеристиките. На крајот ние Може имплементирајте ги директно во апликацијата (подоцна ќе видиме дека ова е потеклото на сервисната мрежа). Да се ​​стави во една реченица, вредноста на сервисната мрежа е: обезбедува функционалност од клучно значење за водење на модерен софтвер за сервери на конзистентен, агностички начин за апликациски код..

Ајде да го анализираме овој предлог.

«Функциите се клучни за водење модерен софтвер за сервери“. Ако градите апликација за трансакциски сервер поврзан на јавен интернет што прифаќа барања од надворешниот свет и одговара на нив за кратко време - на пример, веб-апликација, API-сервер и огромно мнозинство други современи апликации - и ако го имплементирате како збир на услуги кои синхроно комуницираат едни со други, и ако постојано го надградувате овој софтвер, додавате нови функции и ако сте принудени да го одржувате овој систем во работна состојба за време на модификацијата - во овој случај, честитки , создавате модерен серверски софтвер . И сите тие одлични карактеристики наведени погоре, всушност се покажаа како критични за вас. Апликацијата мора да биде сигурна, безбедна и мора да можете да видите што прави. Токму овие прашања помага да се решат сервисната мрежа.

(Во ред, моето убедување дека овој пристап е модерен начин за градење серверски софтвер се навлезе во претходниот пасус. Други претпочитаат да развиваат монолити, „реактивни микросервиси“ и други работи што не спаѓаат во горната дефиниција. Овие луѓе веројатно имаат мислење тоа се разликува од моето, а пак верувам дека „грешат“ - иако во секој случај сервисната мрежа не им е многу корисна).

«Униформа за целиот оџак“. Карактеристиките што ги обезбедува сервисната мрежа не се само критични. Тие се однесуваат на сите услуги во апликацијата, без разлика на кој јазик се напишани, каква рамка користат, кој ги напишал, како се распоредени и сите други суптилности на нивниот развој и употреба.

«Независен код на апликацијата“. Конечно, сервисната мрежа не само што обезбедува конзистентна функционалност низ целиот куп, туку тоа го прави на начин што не бара уредување на апликацијата. Основната основа на функционалноста на сервисната мрежа, вклучувајќи ги задачите за конфигурирање, ажурирање, работење, одржување итн., е чисто на ниво на платформа и е независна од апликацијата. Апликацијата може да се промени без да влијае на сервисната мрежа. За возврат, сервисната мрежа може да се промени без каква било интервенција на апликацијата.

Накратко, сервисната мрежа не само што обезбедува витална функционалност, туку тоа го прави на глобален, униформен и независен начин од апликацијата. И така, додека функционалноста на сервисната мрежа може да се имплементира во услужниот код (на пример, како библиотека вклучена со секоја услуга), овој пристап нема да обезбеди униформност и независност што е толку вредна во случај на сервисна мрежа .

И се што треба да направите е да додадете еден куп прокси! Ветувам, наскоро ќе ги разгледаме оперативните трошоци поврзани со додавањето на овие прокси. Но, прво, да застанеме и да ја разгледаме оваа идеја за независност од перспектива на различни од луѓе.

Кому му помага сервисната мрежа?

Колку и да е незгодно, за да може една технологија да стане важен дел од екосистемот, таа мора да биде прифатена од луѓето. Значи, кој е заинтересиран за сервисна мрежа? Кој има корист од неговата употреба?

Ако развивате модерен софтвер за сервери, отприлика можете да го замислите вашиот тим како група сопственици на услугикои заедно ја развиваат и спроведуваат деловната логика, и сопственици на платформавклучени во развојот на внатрешната платформа на која работат овие услуги. Во малите организации, тоа може да бидат истите луѓе, но како што расте компанијата, овие улоги имаат тенденција да стануваат поизразени, па дури и поделени на под-улоги... (Тука има многу да се каже за променливата природа на devops, организациското влијание на микросервисите итн.) n. Но засега, да ги земеме овие описи здраво за готово).

Од оваа гледна точка, јасните корисници на сервисната мрежа се сопствениците на платформата. На крајот на краиштата, крајната цел на тимот на платформата е да создаде внатрешна платформа на која сопствениците на услуги ќе можат да ја имплементираат деловната логика и да го прават тоа на начин што ќе ја гарантира нивната максимална независност од мрачните детали за нејзиното работење. Сервисната мрежа не само што нуди способности клучни за постигнување на оваа цел, туку тоа го прави на начин што, пак, не наметнува никаква зависност од сопствениците на услугите.

Сопствениците на услуги исто така имаат корист, иако на поиндиректен начин. Целта на сопственикот на услугата е да биде што е можно попродуктивен во спроведувањето на логиката на деловниот процес и колку помалку треба да се грижи за оперативните прашања, толку подобро. Наместо да спроведуваат, да речеме, политики за повторно обиди или TLS, тие можат да се фокусираат исклучиво на бизнисот и да се надеваат дека платформата ќе се грижи за останатото. За нив ова е голема предност.

Организациската вредност на таквата поделба помеѓу сопствениците на платформи и услуги не може да се прецени. Мислам дека таа придонесува главната придонес кон вредноста на сервисната мрежа.

Оваа лекција ја научивме кога еден ран фан на Линкерд ни кажа зошто ја избрале сервисната мрежа: затоа што тоа им овозможило „да продолжат да зборуваат на минимум“. Еве неколку детали: момците од една голема компанија ја префрлија својата платформа во Кубернетес. Бидејќи апликацијата работеше со чувствителни информации, тие сакаа да ги шифрираат сите комуникации во кластерите. Сепак, ситуацијата беше комплицирана од присуството на стотици услуги и стотици развојни тимови. Изгледите да стапат во контакт со сите и да ги убедат да вклучат поддршка за TLS во нивните планови воопшто не ги задоволи. Со инсталирање на Linkerd, тие мигрираа одговорност од програмери (од чија гледна точка тоа беше непотребна неволја) до платформери, за кои ова беше приоритет на највисоко ниво. Со други зборови, Линкерд им решаваше не толку технички проблем колку организациски.

Накратко, сервисната мрежа не е техничко решение, туку социо-технички Проблеми. (Ви благодарам Синди Сридхаран за воведување на овој термин.

Дали сервисната мрежа ќе ги реши сите мои проблеми?

Да. Мислам, не!

Гледајќи ги трите класи на карактеристики наведени погоре - доверливост, безбедност и набљудување - станува јасно дека сервисната мрежа не е целосно решение за ниту еден од овие проблеми. Иако Linkerd може да испраќа повторени барања (ако знае дека се немоќни), тој не е во позиција да донесува одлуки за тоа што да му врати на корисникот ако услугата конечно исчезна - таквите одлуки мора да ги донесе апликацијата. Linkerd може да води статистика за успешни барања, но не може да ја разгледа услугата и да ги обезбеди нејзините внатрешни метрики - апликацијата треба да има таков пакет со алатки. И додека Linkerd е способен да хостира mTLS, полноправните безбедносни решенија бараат многу повеќе.

Подмножество од карактеристиките во овие области што ги нуди сервисната мрежа се поврзани со карактеристики на платформата. Под ова мислам на функции кои:

1. Независно од деловната логика. Начинот на кој се конструираат хистограмите за повици помеѓу Foo и Bar е целосно независен од тоа дали зошто Foo повикува Бар.
2. Тешко е да се спроведе правилно. Во Linkerd, повторувањата се параметризирани со секакви фантастични работи како буџети за повторно обиди. (повторно обидете се со буџетите), бидејќи простодушниот пристап кон спроведувањето на таквите работи сигурно ќе доведе до појава на таканаречената „лавина од барања“ (обидете се со бура) и други проблеми специфични за дистрибуираните системи.
3. Најефективен кога се применува постојано. Механизмот TLS има смисла само ако се применува насекаде.

Бидејќи овие карактеристики се имплементирани на прокси слојот (а не на слојот на апликацијата), сервисната мрежа ги изложува на платформи, не апликации. Така, не е важно на кој јазик се напишани услугите, каква рамка користат, кој ги напишал и зошто. Проксите работат надвор од сите овие детали, а основната основа на оваа функционалност, вклучувајќи ги задачите за конфигурирање, ажурирање, работење, одржување итн., лежи исклучиво на ниво на платформа.

Примери на можности за сервисна мрежа

Накратко, сервисната мрежа не е целосно решение за доверливост, набљудување или безбедност. Опсегот на овие области подразбира задолжително учество на сопствениците на услугите, тимовите на Ops/SRE и другите засегнати страни на компанијата. Сервисната мрежа обезбедува само „парче“ на ниво на платформа за секоја од овие области.

Зошто сервисната мрежа стана популарна токму сега?

Веројатно се прашувате во моментов: Добро, ако мрежата за услуги е толку добра, зошто не почнавме да распоредуваме милиони прокси на оџакот пред десет години?

Има банален одговор на ова прашање: пред десет години сите изградија монолити, а никому не му требаше сервисна мрежа. Ова е точно, но според мое мислење, овој одговор ја промашува поентата. Дури и пред десет години, концептот на микросервисите како ветувачки начин за создавање системи од големи размери беше широко дискутиран и применет во компании како Twitter, Facebook, Google и Netflix. Општата перцепција - барем во деловите од индустријата со кои сум бил во контакт - беше дека микросервисите се „вистинскиот начин“ за изградба на големи системи, дури и ако тоа беше проклето тешко.

Се разбира, иако пред десет години имаше компании кои ги искористуваа микроуслугите, тие не лепеа прокси секаде каде што можеа за да формираат сервисна мрежа. Меѓутоа, ако погледнете внимателно, тие направија нешто слично: многу од овие компании наложија употреба на специјална внатрешна библиотека за вмрежување (понекогаш наречена библиотека со дебел клиент, дебели клиенти библиотека).

Netflix имаше Hysterix, Google имаше Stubby, Twitter ја имаше библиотеката Finagle. Finagle, на пример, беше задолжителен за секоја нова услуга на Твитер. Се справуваше и со клиентот и од страната на серверот на конекциите, дозволуваше повторени барања, поддржуваше рутирање на барања, балансирање на оптоварување и мерење. Тој обезбеди конзистентен слој на доверливост и набљудување низ целиот куп на Твитер, без разлика што прави услугата. Се разбира, тој работеше само за јазиците на JVM и беше заснован на програмски модел што требаше да се користи за целата апликација. Сепак, неговата функционалност беше речиси иста како онаа на сервисната мрежа. (Всушност, првата верзија на Linkerd беше само Finagle завиткана во форма на прокси.)

Така, пред десет години не постоеја само микросервиси, туку и специјални прото-сервисни-мрежести библиотеки кои ги решаваа истите проблеми што ги решава сервисната мрежа денес. Сепак, самата сервисна мрежа тогаш не постоеше. Мораше да има уште една смена пред таа да се појави.

И тука лежи подлабокиот одговор, скриен во уште една промена што се случи во изминатите 10 години: имаше нагло намалување на трошоците за распоредување на микроуслуги. Компаниите споменати погоре кои користеа микроуслуги пред една деценија - Твитер, Нетфликс, Фејсбук, Гугл - беа компании од огромни размери и огромни ресурси. Тие не само што имаа потреба, туку и можност за градење, распоредување и управување со големи апликации базирани на микросервиси. Енергијата и напорот што инженерите на Твитер ги вложија за да преминат од монолитен кон микросервис пристап се неверојатни. (Искрено, како што беше фактот дека тоа функционираше.) Овој вид инфраструктурно маневрирање тогаш беше невозможно за помалите компании.

Да преминеме во сегашноста. Денес постојат стартапи каде што соодносот на микросервисите и програмерите е 5:1 (или дури 10:1), а згора на тоа, успешно се справуваат со нив! Ако стартап од 5 луѓе е способен да управува со 50 микросервиси без оптоварување, тогаш нешто јасно ги намали трошоците за нивната имплементација.

1500 микросервиси во Монцо; секоја линија е пропишано мрежно правило кое дозволува сообраќај

Драматичното намалување на трошоците за оперативни микроуслуги е резултат на еден процес: зголемена популарност на контејнерите и оркестратори. Ова е токму длабокиот одговор на прашањето што придонесе за појавата на сервисната мрежа. Истата технологија ги направи привлечни и сервисната мрежа и микросервисите: Kubernetes и Docker.

Зошто? Па, Докер решава еден голем проблем - проблемот со пакувањето. Со пакување на апликацијата и нејзините (не-мрежни) зависности за време на траење во контејнер, Docker ја претвора апликацијата во заменлива единица која може да се хостира и да работи насекаде. Во исто време, во голема мера го поедноставува работењето. повеќејазичен стек: Бидејќи контејнерот е атомска единица за извршување, не е важно што има внатре, без разлика дали е JVM, Node, Go, Python или Ruby апликација, за распоредување и оперативни цели. Едноставно водете го и тоа е тоа.

Кубернетес носи сè на следното ниво. Сега, кога има еден куп „извршливи работи“ и многу машини на кои може да се работи, има потреба од алатка која може да ги совпадне една со друга. Во широка смисла, на Kubernetes му давате многу контејнери и многу машини, и тоа ги совпаѓа едни со други (се разбира, ова е динамичен и постојано променлив процес: нови контејнери се движат низ системот, машините почнуваат и запираат, итн. Kubernetes го зема сето ова предвид).

Откако ќе се постави Kubernetes, времето потребно за распоредување и управување со една услуга не се разликува многу од трошоците за распоредување и управување со десет услуги (всушност, тоа е речиси исто за 100 услуги). Додајте во ова контејнери како механизам за пакување што поттикнува повеќејазична имплементација, и ќе имате еден тон нови апликации имплементирани како микросервиси напишани на повеќе јазици, токму онаква средина на којашто е толку добро прилагодена мрежата за услуги.

Значи, доаѓаме до одговорот на прашањето зошто идејата за сервисна мрежа стана популарна токму сега: униформноста што Кубернетес ја обезбедува за услугите е директно применлива за оперативните задачи со кои се соочува сервисната мрежа. Вие пакувате прокси во контејнери, му давате на Кубернетс задача да ги залепат секаде каде што е можно, и Voila! Како резултат на тоа, добивате сервисна мрежа, додека Kubernetes ја контролира целата механика на неговото распоредување. (Барем од птичја перспектива. Се разбира, има многу нијанси во овој процес.)

Да резимираме: причината поради која сервисната мрежа стана популарна сега, а не пред десет години е тоа што Kubernetes и Docker не само што значително се зголемија потреба во него, поедноставување на имплементацијата на апликациите како множества на повеќејазични микросервиси, но и значително намалена трошоците за негово функционирање преку обезбедување механизми за распоредување и одржување на прокси паркови на страничната кара.

Зошто толку многу се зборува за сервисната мрежа?

Предупредување: Во овој дел прибегнувам кон секакви претпоставки, претпоставки, измислици и внатрешни информации.

Во потрага по „сервисна мрежа“ ќе се појави куп рециклирана, нискокалорична содржина, чудни проекти и калеидоскоп за изобличување достоен за ехо комора. Секоја трендовска нова технологија го има ова, но во случајот со сервисната мрежа, проблемот е особено акутен. Зошто?

Па, тоа е делумно моја вина. Дадов се од себе за да го промовирам Linkerd и сервисната мрежа во секоја прилика, преку безброј објави на блогови и написи како оваа. Но, јас не сум толку моќен. За вистински да одговориме на ова прашање, треба малку да зборуваме за општата ситуација. И невозможно е да се зборува за тоа без да се спомене еден проект: Истио е мрежа за услуги со отворен код развиена заеднички од Google, IBM и Lyft.

(Тие три компании имаат многу различни улоги: се чини дека учеството на Lyft е ограничено само на името; тие се автор на Envoy, но не го користат или се вклучени во развојот на Istio. IBM е вклучен во развојот на Istio и го користи. Google е во голема мера вклучен во развојот на Istio, но колку што можам да кажам, всушност не го користи.)

Проектот Истио е познат по две работи. Прво, тоа е огромниот маркетинг напор што Google, особено, го вложува во својата промоција. Проценувам дека повеќето луѓе кои моментално се свесни за концептот на сервисна мрежа првпат дознале за него благодарение на Истио. Втората карактеристика е колку лошо беше примен Истио. Во оваа работа, јас, очигледно, сум заинтересирана страна, но обидувајќи се да останам што е можно пообјективен, сепак не можам да не марка сосема негативен став, не многу специфично (иако не единствено: systemd ми доаѓа на ум, споредба беше спроведена веќе постојано...) за проект со отворен код.

(Во пракса, Istio се чини дека има проблеми не само со сложеноста и UX, туку и со перформансите. На пример, за време на Оценки на перформансите на линкериспроведено од трето лице, експертите открија ситуации во кои латентноста на опашката на Истио беше 100 пати поголема од онаа на Линкерд, како и ситуации со недостаток на ресурси, кога Линкерд продолжи да функционира успешно, а Истио целосно престана да работи.)

Оставајќи ги настрана моите теории за тоа зошто се случи ова, верувам дека ненадејната возбуда околу сервисната мрежа се должи на вмешаноста на Google. Имено, комбинација од следните три фактори:

1. опсесивна промоција на Istio од Google;
2. соодветен неодобрувачки, критички став кон проектот;
3. неодамнешната вртоглава популарност на Кубернетес, чие сеќавање е сè уште свежо.

Заедно, овие фактори се спојуваат во еден вид опојна, аноксична средина во која способноста за рационално расудување е ослабена, а останува само прекрасна разновидност. лале манија.

Од гледна точка на Линкерд, ова е… Јас би го опишал како мешан благослов. Мислам, одлично е што сервисната мрежа влезе во мејнстримот - што не беше случај во 2016 година кога првпат се појави Linkerd и беше навистина тешко да се привлече вниманието на луѓето на проектот. Сега нема таков проблем! Но, лошата вест е дека ситуацијата со сервисната мрежа денес е толку збунувачка што е речиси невозможно да се открие кои проекти навистина припаѓаат во категоријата на сервисната мрежа (а камоли да се открие кој е најдобар за одреден случај на употреба). Ова секако им пречи на сите (и дефинитивно во некои случаи Istio или некој друг проект е подобар од Linkerd, бидејќи вториот не е едно решение за сите).

Од страната на Линкерд, нашата стратегија беше да ја игнорираме вревата, да продолжиме да се фокусираме на решавање на вистинските проблеми во заедницата и во суштина да чекаме возбудата да згасне. На крајот возбудата ќе стивне и можеме да продолжиме да работиме во мир.

Дотогаш, сите ќе треба да бидеме трпеливи.

Дали сервисната мрежа ќе ми биде корисна за мене, скромен софтверски инженер?

Следниот прашалник ќе помогне да се одговори на ова прашање:

Дали се занимавате исклучиво со имплементација на деловната логика? Во овој случај, сервисната мрежа нема да ви биде корисна. Тоа е, се разбира, можеби ќе ве интересира, но идеално, сервисната мрежа не треба директно да влијае на ништо во вашата околина. Продолжете да работите на она за што сте платени.

Дали одржувате платформа во компанија која користи Kubernetes? Да, во овој случај ви треба сервисна мрежа (се разбира, ако не користите K8 само за да извршите монолит или сериска обработка - но тогаш би сакал да прашам зошто ви се потребни K8s). Најверојатно, ќе се најдете во ситуација со многу микросервиси напишани од различни луѓе. Сите тие се во интеракција едни со други и се врзани во метеж од зависности од траење, а вие треба да најдете начин да се справите со сето ова. Употребата на Kubernetes ви овозможува да изберете сервисна мрежа „за себе“. За да го направите ова, запознајте се со нивните можности и карактеристики и одговорете на прашањето дали некој од достапните проекти воопшто ви одговара (препорачувам да го започнете вашето истражување со Linkerd).

Дали водите платформа за компанија која НЕ користи Kubernetes туку користи микросервис? Во овој случај, сервисната мрежа ќе ви биде корисна, но нејзината употреба ќе биде нетривијална. Секако дека можеш имитираат сервисна мрежа со хостирање на куп прокси, но важна предност на Kubernetes е токму моделот на распоредување: рачното одржување на овие прокси ќе бара многу повеќе време, напор и трошоци.

Дали сте одговорни за платформата во компанија која работи со монолити? Во овој случај, веројатно не ви треба сервисна мрежа. Ако работите со монолити (или дури и колекции на монолити) кои имаат добро дефинирани и ретко променливи модели на интеракција, тогаш мрежата за услуги има малку да ви понуди. Така, можете едноставно да го игнорирате и да се надевате дека ќе исчезне како лош сон...

Заклучок

Веројатно, сервисната мрежа сè уште не треба да се нарекува „најпопуларната технологија во светот“ - оваа сомнителна чест веројатно му припаѓа на биткоинот или на вештачката интелигенција. Можеби таа е во првите пет. Но, ако ги пробиете слоевите на бучава и бучава, станува јасно дека сервисната мрежа носи вистински придобивки за оние кои создаваат апликации во Кубернет.

Би сакал да го пробате Linkerd - инсталирајќи го во кластерот Kubernetes (или дури и Minikube на лаптоп) трае околу 60 секундии можеш да видиш за што зборувам.

Често поставувани прашања

- Ако ја игнорирам сервисната мрежа, дали ќе исчезне?
- Морам да ве разочарам: сервисната мрежа е кај нас долго време.

— Но, НЕ САКАМ да користам сервисна мрежа!
- Па, не е потребно! Само прочитајте го мојот прашалник погоре за да видите дали треба барем да се запознаете со неговите основи.

— Да не е добар стар ESB/среден уред со нов сос?
- Сервисната мрежа се занимава со оперативна логика, а не со семантичка. Ова беше главниот недостаток автобус на претпријатието (ЕСБ). Задржувањето на оваа разделба и помага на сервисната мрежа да ја избегне истата судбина.

- Како се разликува сервисната мрежа од портите на API?
Има милион статии на оваа тема. Само прогуглај.

Дали Envoy е сервисна мрежа?
- Не, Envoy не е сервисна мрежа, тоа е прокси-сервер. Може да се користи за организирање на сервисна мрежа (и многу повеќе - тоа е прокси за општа намена). Но, само по себе, тоа не е сервисна мрежа.

- Network Service Mesh - дали е сервисна мрежа?
- Не. И покрај името, ова не е сервисна мрежа (како ви се допаѓаат чудата на маркетингот?).

- Дали сервисната мрежа ќе помогне со мојот реактивен асинхрон систем заснован на редот за пораки?
- Не, сервисната мрежа нема да ви помогне.

- Која сервисна мрежа треба да ја користам?
- Линкерд, без паметен човек.

- Статијата е смрдлива! / Авторот - на сапун!
— Ве молиме споделете ја врската до неа со сите ваши пријатели за да се уверат во тоа!

Благодарници

Како што може да претпоставите од насловот, оваа статија е инспирирана од фантастичната расправа на Џеј Крепс "Дневник: Што треба да знае секој софтверски инженер за обединувачката апстракција на податоците во реално време“. Го запознав Џеј пред десет години додека правев интервју на Linked In и оттогаш тој ми е инспирација.

Иако сакам да се нарекувам себеси „развивач на Linkerd“, реалноста е дека јас сум повеќе одржувач на датотеката README.md во проект. Денес се работи на Linkerd многу, многу, многу много луѓе, и овој проект не би бил возможен без неверојатната заедница на соработници и корисници.

И конечно, посебна благодарност до креаторот на Linkerd, Оливер Гулд (primus inter pares), кој заедно со мене пред многу години главоглаво нурна во сета оваа гужва со сервисната мрежа.

PS од преведувач

Прочитајте и на нашиот блог:

• «Што е сервисна мрежа и зошто ми е потребна [за облак апликација со микросервиси]?";
• «Traefik 2.0: ажурирање на сервисната мрежа со поддршка за TCP и нов веб-интерфејс";
• «Maesh - нова едноставна сервисна мрежа за Kubernetes од авторите на Traefik";
• «Назад на микросервисите со Istio. Дел 1";
• «Проводник - лесна сервисна мрежа за Kubernetes".

Извор: www.habr.com