На интернет куп статии о сервисна мрежа (сервисна мрежа), а еве уште една. Ура! Но зошто? Потоа, сакам да го изразам моето мислење дека ќе беше подобро ако сервисните мрежи се појавија пред 10 години, пред појавата на контејнерските платформи како што се Docker и Kubernetes. Не велам дека мојата гледна точка е подобра или полоша од другите, но бидејќи сервисните мрежи се прилично сложени животни, повеќекратните гледишта ќе помогнат подобро да се разберат.

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

Историја на dotCloud

Пишував за историјата на dotCloud и за избор на архитектура за оваа платформа, но не зборував многу за мрежниот слој. Ако не сакате да се нурнете во читањето последната статија за dotCloud, еве ја суштината накратко: тоа е PaaS платформа-како-услуга која им овозможува на клиентите да извршуваат широк спектар на апликации (Java, PHP, Python...), со поддршка за широк опсег на податоци услуги (MongoDB, MySQL, Redis...) и работен тек како Heroku: го поставувате вашиот код на платформата, таа создава слики од контејнери и ги распоредува.

Ќе ви кажам како сообраќајот беше насочен кон платформата dotCloud. Не затоа што беше особено кул (иако системот работеше добро во своето време!), туку првенствено затоа што со современи алатки таквиот дизајн може лесно да се имплементира за кратко време од скромен тим, доколку им треба начин да го насочат сообраќајот помеѓу куп на микросервиси или еден куп апликации. На овој начин, можете да ги споредите опциите: што ќе се случи ако развиете сè сами или користите постоечка мрежа за услуги. Стандарден избор е да го направите сами или да го купите.

Рутирање на сообраќај за хостирани апликации

Апликациите на dotCloud можат да ги изложат HTTP и TCP крајните точки.

HTTP крајни точки динамички додаден во конфигурацијата на кластерот за балансирање на оптоварување Хипаче. Ова е слично на она што го прават ресурсите денес Целосно во Kubernetes и load balancer како Траефик.

Клиентите се поврзуваат со HTTP крајните точки преку соодветни домени, под услов името на доменот да укажува на балансери на оптоварување dotCloud. Ништо посебно.

TCP крајни точки поврзан со број на порта, кој потоа се пренесува до сите контејнери во тој оџак преку променливите на околината.

Клиентите можат да се поврзат со крајните точки на TCP користејќи соодветно име на домаќин (нешто како gateway-X.dotcloud.com) и број на порта.

Ова име на домаќин се решава во кластерот на сервери „nats“ (не е поврзан со НАТС), што ќе ги насочи дојдовните TCP конекции до правилниот контејнер (или, во случај на услуги балансирани со оптоварување, до правилните контејнери).

Ако сте запознаени со Kubernetes, ова веројатно ќе ве потсети на Services NodePort.

Немаше еквивалентни услуги на платформата dotCloud ClusterIP: За едноставност, до услугите се пристапуваше на ист начин и од внатре и од надвор од платформата.

Сè беше организирано прилично едноставно: првичните имплементации на HTTP и TCP рутирачките мрежи беа веројатно само неколку стотици линии на Python секоја. Едноставни (би рекла наивни) алгоритми кои се усовршуваа како што растеше платформата и се појавуваа дополнителни барања.

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

Како ова се разликува од модерната сервисна мрежа?

Ограничени видливост. Воопшто немавме метрика за TCP рутирачката мрежа. Кога станува збор за рутирање HTTP, подоцнежните верзии воведоа детални HTTP метрика со кодови за грешки и време на одговор, но модерните сервисни мрежи одат уште подалеку, обезбедувајќи интеграција со системи за собирање метрика како што е Prometheus, на пример.

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

Ефикасност на рутирање е исто така ограничен. Во мрежата за рутирање dotCloud, целиот сообраќај мораше да помине низ кластер на посветени рутирачки јазли. Ова значеше потенцијално преминување на повеќе граници AZ (зона на достапност) и значително зголемување на латентноста. Се сеќавам на код за смена на проблеми што правеше над сто SQL барања по страница и отвораше нова врска со SQL серверот за секое барање. Кога работи локално, страницата се вчитува веднаш, но во dotCloud потребни се неколку секунди за да се вчита бидејќи секоја TCP конекција (и последователно SQL барање) трае десетици милисекунди. Во овој конкретен случај, постојаните врски го решија проблемот.

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

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

безбедност подобро исто така. Решетката за рутирање dotCloud целосно работеше на EC2 Classic и не го шифрираше сообраќајот (врз основа на претпоставката дека ако некој успее да стави трагач на сообраќајот на мрежата EC2, веќе сте биле во голема неволја). Современите сервисни мрежи транспарентно го штитат целиот наш сообраќај, на пример, со меѓусебна TLS автентикација и последователно шифрирање.

Рутирање на сообраќајот за услуги на платформата

Добро, разговаравме за сообраќајот помеѓу апликациите, но што е со самата платформа dotCloud?

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

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

Овие услуги на ниско ниво, клучни за мисијата, беа распоредени со пуштање контејнери директно на неколку клучни јазли. Во овој случај, стандардните платформски услуги не беа користени: поврзувач, распоредувач и тркач. Ако сакате да се споредите со модерни платформи за контејнери, тоа е како да управувате со контролен авион docker run директно на јазлите, наместо задачата да се делегира на Kubernetes. Прилично е сличен по концепт статични модули (подови), што го користи kubeadm или bootkube при подигнување на самостоен кластер.

Овие услуги беа изложени на едноставен и груб начин: датотеката YAML ги наведе нивните имиња и адреси; и секој клиент мораше да земе копија од оваа датотека YAML за распоредување.

Од една страна, тој е исклучително сигурен бидејќи не бара поддршка од надворешна продавница за клучеви/вредности како што е Zookeeper (запомнете, итн. или Конзул не постоеше во тоа време). Од друга страна, го отежнуваше преместувањето на услугите. Секој пат кога ќе се премести, сите клиенти добиваат ажурирана датотека YAML (и потенцијално се рестартира). Не многу удобно!

Последователно, почнавме да имплементираме нова шема, каде што секој клиент се поврзуваше со локален прокси-сервер. Наместо адреса и порта, треба само да го знае бројот на портата на услугата и да се поврзе преку localhost. Локалниот прокси се справува со оваа врска и ја препраќа до вистинскиот сервер. Сега, при преместување на заднината на друга машина или скалирање, наместо да ги ажурирате сите клиенти, треба само да ги ажурирате сите овие локални прокси; и повеќе не е потребно рестартирање.

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

Ова е многу слично на SmartStack од Airbnb, но значајната разлика е во тоа што SmartStack е имплементиран и распореден на производство, додека внатрешниот систем за рутирање на dotCloud беше ставен на полица кога dotCloud стана Docker.

Јас лично сметам дека SmartStack е еден од претходниците на системите како Istio, Linkerd и Consul Connect бидејќи сите тие ја следат истата шема:

• Стартувај прокси на секој јазол.
• Клиентите се поврзуваат со прокси.
• Контролната рамнина ја ажурира конфигурацијата на прокси кога се менуваат позадините.
• ... Профит!

Модерна имплементација на сервисна мрежа

Ако требаше да имплементираме слична мрежа денес, би можеле да користиме слични принципи. На пример, конфигурирајте внатрешна DNS зона со мапирање на имињата на услугите на адресите во просторот 127.0.0.0/8. Потоа извршете HAProxy на секој јазол во кластерот, прифаќајќи врски на секоја адреса на услуга (во таа подмрежа 127.0.0.0/8) и пренасочување/балансирање на оптоварувањето до соодветните задни делови. Конфигурацијата на HAProxy може да се контролира конфд, овозможувајќи ви да складирате информации за заднината во etcd или Consul и автоматски да ја туркате ажурираната конфигурација на HAProxy кога е потребно.

Ова е речиси како функционира Istio! Но, со некои разлики:

• Користи Полномошник на пратеник наместо HAProxy.
• Ја складира конфигурацијата на задниот дел преку Kubernetes API наместо etcd или Consul.
• Услугите се доделени адреси на внатрешната подмрежа (Kubernetes ClusterIP адреси) наместо 127.0.0.0/8.
• Има дополнителна компонента (Цитадела) за додавање взаемна TLS автентикација помеѓу клиентот и серверите.
• Поддржува нови функции како што се прекинување на колото, дистрибуирано следење, распоредување на канари итн.

Ајде брзо да погледнеме некои од разликите.

Полномошник на пратеник

Envoy Proxy го напиша Lyft [конкурентот на Uber на такси пазарот - прибл. лента]. Слично е на многу начини со другите прокси (на пр. HAProxy, Nginx, Traefik...), но Lyft ги напиша нивните затоа што им требаа карактеристики што им недостигаа на другите прокси, и се чинеше попаметно да се направи нов наместо да се прошири постојниот.

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

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

Контролен авион

За контролната рамнина, Istio се потпира на Kubernetes API. Ова не е многу различно од користењето на confd, кој се потпира на etcd или Consul за да го прегледа множеството клучеви во продавницата за податоци. Istio го користи Kubernetes API за да прегледа збир на ресурси на Kubernetes.

Помеѓу ова и тогаш: Ова лично ми беше корисно Опис на Kubernetes APIкој гласи:

Серверот Kubernetes API е „глуп сервер“ кој нуди складирање, верзии, валидација, ажурирање и семантика за ресурсите на API.

Istio е дизајниран да работи со Kubernetes; и ако сакате да го користите надвор од Kubernetes, тогаш треба да извршите пример од серверот Kubernetes API (и помошната услуга etcd).

Адреси на услугата

Istio се потпира на ClusterIP адресите што Kubernetes ги доделува, така што услугите на Istio добиваат внатрешна адреса (не во опсегот 127.0.0.0/8).

Сообраќајот до адресата ClusterIP за одредена услуга во кластерот Kubernetes без Istio е пресретнат од kube-прокси и се испраќа до задниот дел на тој прокси. Ако ве интересираат техничките детали, kube-proxy поставува правила за iptables (или IPVS load balancers, во зависност од тоа како е конфигуриран) за да ги препише дестинациските IP адреси на конекциите што одат на адресата ClusterIP.

Штом Istio ќе се инсталира на кластерот Kubernetes, ништо не се менува додека не се овозможи експлицитно за даден потрошувач, па дури и за целиот именски простор, со воведување контејнер sidecar во сопствени мешунки. Овој контејнер ќе сврти примерок од Envoy и ќе постави збир на правила за iptables за да го пресретне сообраќајот што оди до други услуги и да го пренасочи тој сообраќај кон Envoy.

Кога е интегриран со Kubernetes DNS, тоа значи дека нашиот код може да се поврзе по име на услугата и сè „само работи“. Со други зборови, нашиот код поставува прашања како http://api/v1/users/4242тогаш api реши барање за 10.97.105.48, правилата iptables ќе ги пресретнат врските од 10.97.105.48 и ќе ги проследат до локалниот прокси Envoy, а тој локален прокси ќе го препрати барањето до вистинскиот заден API. Пуф!

Дополнителни важничене

Istio, исто така, обезбедува шифрирање и автентикација од крај до крај преку mTLS (заемно TLS). Компонента наречена Цитаделата.

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

И, се разбира, ја споменавме видливоста: Envoy собира огромна количина на метрика додека обезбедува дистрибуирано следење. Во архитектурата на микроуслуги, ако едно барање за API мора да помине низ микросервисите A, B, C и D, тогаш по најавувањето, дистрибуираното следење ќе додаде единствен идентификатор на барањето и ќе го складира овој идентификатор преку подбарања на сите овие микросервиси, овозможувајќи сите поврзани повици да се фатат.одложувања итн.

Развијте или купете

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

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

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

Дали треба да изберам Istio, Linkerd или Consul Connect?

Досега зборувавме само за Истио, но ова не е единствената сервисна мрежа. Популарна алтернатива - Линкерд, и има повеќе Конзул Поврзете.

Што да одбереш?

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

Еден ветувачки пристап е да се користи алатка како СуперГлу. Имплементира слој на апстракција за да ги поедностави и обедини API-ите изложени од сервисните мрежи. Наместо да ги учиме специфичните (и, според мое мислење, релативно сложени) API-и на различни сервисни мрежи, можеме да ги користиме поедноставните конструкции на SuperGloo - и лесно да се префрламе од еден на друг, како да имаме среден конфигурациски формат кој опишува HTTP интерфејси и позадини способни за генерирање на вистинската конфигурација за Nginx, HAProxy, Traefik, Apache...

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

Извор: www.habr.com