На Интернету (сервисна мрежа), а ево још једне. Ура! Али зашто? Затим, желим да изразим своје мишљење да би било боље да су се сервисне мреже појавиле пре 10 година, пре појаве контејнерских платформи као што су Доцкер и Кубернетес. Не кажем да је моје гледиште боље или лошије од других, али пошто су сервисне мреже прилично сложене животиње, више тачака гледишта ће помоћи да их боље разумемо.
Говорићу о платформи дотЦлоуд, која је изграђена на преко стотину микросервиса и подржава хиљаде контејнерских апликација. Објаснићу изазове са којима смо се суочили приликом његовог развоја и покретања, и како би сервисне мреже могле (или нису могле) помоћи.
Историја дотЦлоуд-а
Писао сам о историји дотЦлоуд-а и избору архитектуре за ову платформу, али нисам много говорио о мрежном слоју. Ако не желите да зароните у читање о дотЦлоуд-у, ево суштине укратко: то је ПааС платформа-као-услуга која омогућава корисницима да покрећу широк спектар апликација (Јава, ПХП, Питхон...), уз подршку за широк спектар података услуге (МонгоДБ, МиСКЛ, Редис...) и радни ток као што је Хероку: Учитавате свој код на платформу, он прави слике контејнера и примењује их.
Рећи ћу вам како је саобраћај усмерен на дотЦлоуд платформу. Не зато што је био посебно кул (иако је систем добро функционисао за своје време!), већ првенствено зато што са савременим алатима такав дизајн може лако да имплементира скроман тим за кратко време ако им је потребан начин да усмере саобраћај између гомиле микросервиса или гомиле апликација. На овај начин можете упоредити опције: шта се дешава ако све сами развијете или користите постојећу мрежу услуга. Стандардни избор је да га направите сами или купите.
Усмеравање саобраћаја за хостоване апликације
Апликације на дотЦлоуд-у могу открити ХТТП и ТЦП крајње тачке.
ХТТП крајње тачке динамички додато у конфигурацију кластера балансера оптерећења . Ово је слично ономе што ресурси раде данас у Кубернетесу и балансеру оптерећења попут .
Клијенти се повезују на ХТТП крајње тачке преко одговарајућих домена, под условом да име домена указује на дотЦлоуд балансере оптерећења. Ништа посебно.
ТЦП крајње тачке повезан са бројем порта, који се затим прослеђује свим контејнерима у том стеку преко променљивих окружења.
Клијенти се могу повезати на ТЦП крајње тачке користећи одговарајуће име хоста (нешто попут гатеваи-Кс.дотцлоуд.цом) и број порта.
Ово име хоста се решава у кластер сервера „натс“ (није повезано са ), који ће усмеравати долазне ТЦП везе у исправан контејнер (или, у случају услуга са балансирањем оптерећења, у исправне контејнере).
Ако сте упознати са Кубернетес-ом, ово ће вас вероватно подсетити на Услуге .
Није било еквивалентних услуга на дотЦлоуд платформи : Ради једноставности, услугама се приступало на исти начин и изнутра и изван платформе.
Све је било организовано прилично једноставно: почетне имплементације ХТТП и ТЦП мрежа за рутирање су вероватно биле само неколико стотина линија Питхон-а свака. Једноставни (рекао бих наивни) алгоритми који су се усавршавали како је платформа расла и појавили су се додатни захтеви.
Није било потребно опсежно рефакторисање постојећег кода. Нарочито, може директно да користи адресу добијену преко променљивих окружења.
По чему се ово разликује од модерне сервисне мреже?
Ограничен видљивост. Уопште нисмо имали никакве метрике за ТЦП мрежу рутирања. Када је у питању ХТТП рутирање, касније верзије су увеле детаљне ХТТП метрике са кодовима грешака и временом одговора, али модерне мреже услуга иду још даље, обезбеђујући интеграцију са системима за прикупљање метрика као што је Прометхеус, на пример.
Видљивост је важна не само из оперативне перспективе (за помоћ у решавању проблема), већ и када се пуштају нове функције. Ради се о сигурном и .
Ефикасност рутирања такође је ограничен. У дотЦлоуд мрежи за рутирање, сав саобраћај је морао да прође кроз кластер наменских чворова за рутирање. То је значило потенцијално прелазак вишеструких граница АЗ (Зона доступности) и значајно повећање латенције. Сећам се кода за решавање проблема који је правио преко стотину СКЛ упита по страници и отварао нову везу са СКЛ сервером за сваки упит. Када се покреће локално, страница се учитава тренутно, али у дотЦлоуд-у је потребно неколико секунди да се учита јер свака ТЦП веза (и каснији СКЛ упит) траје десетине милисекунди. У овом конкретном случају, упорне везе су решиле проблем.
Савремене сервисне мреже боље се носе са таквим проблемима. Пре свега, проверавају да ли су везе рутиране у извору. Логички ток је исти: клиент → меш → сервис, али сада мрежа ради локално а не на удаљеним чворовима, тако да је веза клиент → меш је локална и веома брза (микросекунде уместо милисекунди).
Модерне сервисне мреже такође имплементирају паметније алгоритме за балансирање оптерећења. Праћењем здравља позадинских система, они могу да пошаљу више саобраћаја на брже позадине, што резултира побољшаним укупним перформансама.
безбедност боље такође. ДотЦлоуд мрежа за рутирање је у потпуности радила на ЕЦ2 Цлассиц и није шифровала саобраћај (на основу претпоставке да ако је неко успео да стави њушкало на ЕЦ2 мрежни саобраћај, већ сте били у великој невољи). Савремене мреже услуга транспарентно штите сав наш саобраћај, на пример, уз међусобну ТЛС аутентификацију и накнадну енкрипцију.
Рутирање саобраћаја за услуге платформе
У реду, разговарали смо о саобраћају између апликација, али шта је са самом дотЦлоуд платформом?
Сама платформа се састојала од стотинак микросервиса одговорних за различите функције. Неки су прихватали захтеве других, а неки су били радници у позадини који су се повезивали са другим сервисима, али нису сами прихватали везе. У сваком случају, свака услуга мора знати крајње тачке адреса на које треба да се повеже.
Многе услуге високог нивоа могу да користе мрежу за рутирање описану горе. У ствари, многе од више од стотину микросервиса дотЦлоуд-а су распоређене као редовне апликације на самој дотЦлоуд платформи. Али малом броју сервиса ниског нивоа (нарочито оних који имплементирају ову мрежу рутирања) је било потребно нешто једноставније, са мање зависности (пошто нису могли да зависе од себе да раде – стари добри проблем са кокошком и јајима).
Ове услуге ниског нивоа, критичне за мисију, биле су распоређене покретањем контејнера директно на неколико кључних чворова. У овом случају нису коришћене стандардне платформске услуге: линкер, планер и руннер. Ако желите да упоредите са модерним контејнерским платформама, то је као да покрећете контролни авион docker run директно на чворове, уместо да делегира задатак Кубернетесу. Прилично је сличан концепту , који користи или приликом покретања самосталног кластера.
Ове услуге су биле изложене на једноставан и груб начин: ИАМЛ фајл је навео њихова имена и адресе; и сваки клијент је морао да узме копију ове ИАМЛ датотеке за примену.
С једне стране, изузетно је поуздан јер не захтева подршку екстерног складишта кључева/вредности као што је Зоокеепер (запамтите, етцд или Цонсул у то време нису постојали). С друге стране, то је отежавало премештање услуга. Сваки пут када се направи потез, сви клијенти би добили ажурирану ИАМЛ датотеку (и потенцијално се поново покренули). Није баш удобно!
Након тога, почели смо да имплементирамо нову шему, где се сваки клијент повезује на локални прокси сервер. Уместо адресе и порта, потребно је само да зна број порта услуге и да се повеже преко localhost. Локални прокси управља овом везом и прослеђује је стварном серверу. Сада, када премештате позадину на другу машину или скалирате, уместо да ажурирате све клијенте, потребно је само да ажурирате све ове локалне проксије; и поновно покретање више није потребно.
(Такође је планирано да се инкапсулира саобраћај у ТЛС конекција и стави други прокси сервер на страну примаоца, као и да се верификују ТЛС сертификати без учешћа сервиса примаоца, који је конфигурисан да прихвата везе само на localhost. Више о овоме касније).
Ово је веома слично од Аирбнб-а, али значајна разлика је у томе што је СмартСтацк имплементиран и распоређен у производњу, док је унутрашњи систем рутирања дотЦлоуд-а одбачен када је дотЦлоуд постао Доцкер.
Ја лично сматрам да је СмартСтацк један од претходника система као што су Истио, Линкерд и Цонсул Цоннецт јер сви прате исти образац:
- Покрените проки на сваком чвору.
- Клијенти се повезују на проки.
- Контролна раван ажурира конфигурацију проксија када се бацкендови промене.
- ... Профит!
Савремена имплементација сервисне мреже
Ако бисмо морали да имплементирамо сличну мрежу данас, могли бисмо да користимо сличне принципе. На пример, конфигуришите интерну ДНС зону тако што ћете мапирати имена услуга у адресе у простору 127.0.0.0/8. Затим покрените ХАПроки на сваком чвору у кластеру, прихватајући везе на свакој адреси услуге (у тој подмрежи 127.0.0.0/8) и преусмеравање/балансирање оптерећења на одговарајуће позадине. ХАПроки конфигурација се може контролисати , што вам омогућава да чувате позадинске информације у етцд или Цонсул и аутоматски прослеђујете ажурирану конфигурацију на ХАПроки када је то потребно.
Ово је отприлике начин на који Истио функционише! Али са неким разликама:
- Користи уместо ХАПроки.
- Чува позадинску конфигурацију преко Кубернетес АПИ-ја уместо етцд-а или Цонсул-а.
- Сервисима се додељују адресе на интерној подмрежи (ИП адресе Кубернетес кластера) уместо 127.0.0.0/8.
- Има додатну компоненту (Цитадел) за додавање међусобне ТЛС аутентификације између клијента и сервера.
- Подржава нове функције као што су прекид струјног кола, дистрибуирано праћење, примена канаринца итд.
Хајде да на брзину погледамо неке од разлика.
Прокси изасланик
Енвои Проки је написао Лифт [Уберов конкурент на такси тржишту - прибл. трака]. На много начина је сличан другим проксијима (нпр. ХАПроки, Нгинк, Траефик...), али је Лифт написао њихов јер су им биле потребне функције које су недостајале другим проксијима, и чинило се да је паметније направити нови, а не проширити постојећи.
Енвои се може користити самостално. Ако имам одређену услугу која треба да се повеже са другим услугама, могу да је конфигуришем да се повеже на Енвои, а затим да динамички конфигуришем и поново конфигуришем Енвои са локацијом других услуга, док добијам много сјајних додатних функција, као што је видљивост. Уместо прилагођене клијентске библиотеке или убацивања трагова позива у код, шаљемо саобраћај у Енвои, а он прикупља метрику за нас.
Али Енвои је такође способан да ради као раван података (раван података) за сервисну мрежу. То значи да је Енвои сада конфигурисан за ову сервисну мрежу контролни авион (контролни авион).
Контролни авион
За контролну раван, Истио се ослања на Кубернетес АПИ. Ово се не разликује много од коришћења цонфд-а, који се ослања на етцд или Цонсул за преглед скупа кључева у складишту података. Истио користи Кубернетес АПИ за преглед скупа Кубернетес ресурса.
Између овога и тада: Лично сам ово сматрао корисним који гласи:
Кубернетес АПИ сервер је „глуп сервер“ који нуди складиштење, верзионисање, валидацију, ажурирање и семантику за АПИ ресурсе.
Истио је дизајниран да ради са Кубернетес-ом; а ако желите да га користите ван Кубернетеса, онда морате да покренете инстанцу Кубернетес АПИ сервера (и етцд помоћну услугу).
Сервисне адресе
Истио се ослања на ЦлустерИП адресе које Кубернетес додељује, тако да Истио услуге добијају интерну адресу (није у опсегу 127.0.0.0/8).
Саобраћај до ЦлустерИП адресе за одређену услугу у Кубернетес кластеру без Истио-а пресреће кубе-проки и шаље на позадину тог проксија. Ако сте заинтересовани за техничке детаље, кубе-проки поставља иптаблес правила (или ИПВС балансере оптерећења, у зависности од тога како је конфигурисан) да препише одредишне ИП адресе веза које иду на ЦлустерИП адресу.
Једном када се Истио инсталира на Кубернетес кластер, ништа се не мења док се експлицитно не омогући за датог корисника, или чак за цео именски простор, увођењем контејнера sidecar у прилагођене махуне. Овај контејнер ће покренути инстанцу Енвои-а и поставити скуп иптаблес правила за пресретање саобраћаја који иде на друге услуге и преусмеравање тог саобраћаја на Енвои.
Када је интегрисан са Кубернетес ДНС-ом, то значи да се наш код може повезати према називу услуге и све „једноставно ради“. Другим речима, наш код издаје упите попут http://api/v1/users/4242онда api реши захтев за 10.97.105.48, иптаблес правила ће пресрести везе од 10.97.105.48 и проследити их локалном проксију Енвои, а тај локални прокси ће проследити захтев стварном позадинском АПИ-ју. Фуј!
Додатни украси
Истио такође обезбеђује енд-то-енд енкрипцију и аутентификацију путем мТЛС-а (мутуал ТЛС). Компонента тзв Цитадела.
Постоји и компонента миксер, што изасланик може затражити сваки захтевајте да се донесе посебна одлука о том захтеву у зависности од различитих фактора као што су заглавља, оптерећење позадинског дела, итд... (не брините: постоји много начина да Микер остане у раду, па чак и ако се сруши, Енвои ће наставити да ради у реду као пуномоћник) .
И, наравно, поменули смо видљивост: Енвои прикупља огромну количину метрике док обезбеђује дистрибуирано праћење. У архитектури микросервиса, ако један АПИ захтев мора да прође кроз микроуслуге А, Б, Ц и Д, тада ће по пријави дистрибуирано праћење додати јединствени идентификатор захтеву и похранити овај идентификатор кроз подзахтеве за све ове микросервисе, омогућавајући сви повезани позиви које треба ухватити, кашњења итд.
Развијте или купите
Истио има репутацију комплексног. Насупрот томе, изградња мреже за рутирање коју сам описао на почетку овог поста је релативно једноставна коришћењем постојећих алата. Дакле, да ли има смисла креирати сопствену мрежу услуга?
Ако имамо скромне потребе (не треба нам видљивост, прекидач и друге суптилности), онда размишљамо о развоју сопственог алата. Али ако користимо Кубернетес, можда неће ни бити потребан јер Кубернетес већ пружа основне алате за откривање услуга и балансирање оптерећења.
Али ако имамо напредне захтеве, онда се чини да је „куповина“ сервисне мреже много боља опција. (Ово није увек „куповина“ јер је Истио отворени код, али и даље морамо да уложимо инжењерско време да бисмо га разумели, применили и управљали њиме.)
Да ли да изаберем Истио, Линкерд или Цонсул Цоннецт?
До сада смо говорили само о Истио-у, али ово није једина мрежа сервиса. Популарна алтернатива - , и има још тога .
Шта одабрати?
Искрено, не знам. Тренутно се не сматрам довољно компетентним да одговорим на ово питање. Има их неколико уз поређење ових алата и чак .
Један обећавајући приступ је употреба алата као што је . Он имплементира слој апстракције да поједностави и обједини АПИ-је изложене сервисним мрежама. Уместо да учимо специфичне (и, по мом мишљењу, релативно сложене) АПИ-је различитих сервисних мрежа, можемо да користимо једноставније конструкције СуперГлоо-а - и лако се пребацујемо са једне на другу, као да имамо средњи конфигурациони формат који описује ХТТП интерфејсе и позадинске мреже способне генерисања стварне конфигурације за Нгинк, ХАПроки, Траефик, Апацхе...
Мало сам се бавио Истио-ом и СуперГлоо-ом, а у следећем чланку желим да покажем како да додате Истио или Линкерд у постојећи кластер користећи СуперГлоо, и како овај други обавља посао, односно омогућава вам да пређете са једна сервисна мрежа у другу без преписивања конфигурација.
Извор: ввв.хабр.цом