🥇Кызматтын тор колдонуу учурлары

Эскертүү. котормо.: Бул макаланын автору (Люк Перкинс) Linkerd, SMI (Service Mesh Interface) жана Кума сыяктуу ачык булактуу долбоорлордун мекени болгон CNCF уюмунун иштеп чыгуучу жактоочусу (Баса, сиз дагы Istio эмне үчүн деп ойлодуңуз беле? бул тизмеде жок?) DevOps коомчулугуна "кызматтык тор" деп аталган модалуу хайпты жакшыраак түшүнүүгө дагы бир жолу аракет кылып, ал мындай чечимдер камсыз кылган 16 мүнөздүү мүмкүнчүлүктөрдү тизмектеди.

бүгүн тейлөө тору ― программалык камсыздоо тармагындагы эң кызуу темалардын бири (жана туура!). Менимче, бул технология укмуштуудай келечектүү жана анын кеңири колдонулушун көргүм келет (албетте, мааниси болгондо). Бирок, ал дагы эле көпчүлүк адамдар үчүн сырдуу аура менен курчалган. Ошол эле учурда, ал тургай, ким жакшы белгилүү аны менен, анын артыкчылыктарын жана ал эмне экенин (анын ичинде чындап эле) айтуу кыйын. Бул макалада мен ар кандай тизмектөө менен кырдаалды оңдоого аракет кылам колдонуу учурлары «кызмат торлору»*.

* Эскертүү котормосу: бул жерде жана андан ары макалада дал ушул котормо («кызматтык тор») дагы жаңы термин кызматтык тор үчүн колдонулат.

Бирок адегенде мен бир нече комментарий айткым келет:

Мен эч качан кызматтык торлор менен иштеген эмесмин же аларды өзүмдүн билимим үчүн башталган долбоорлордон тышкары колдонгон эмесмин. Башка жагынан алып караганда, мен 2015-жылы Twitterдин ички тейлөө тармагына бир топ документтерди жазган адам болчумун (ал кезде ал "кызматтык тор" деп да аталчу эмес) жана веб-сайтты жана документтерди иштеп чыгууга катышканмын. Linkerd, демек, бул бир нерсени билдирет.
Менин тизмем болжолдуу жана толук эмес. Мага белгисиз колдонуу учурлары болушу мүмкүн жана технология өнүккөн сайын жана анын популярдуулугу өскөн сайын жаңы варианттар пайда болушу мүмкүн.
Ошол эле учурда, ар бир эле учурдагы тейлөө тармагын ишке ашыруу саналып өткөн бардык колдонуу учурларын колдой бербейт. Ошондуктан, "кызмат торчо болот ..." сыяктуу менин билдирүүлөр "жеке, жана, балким, бардык популярдуу кызмат тор ишке ашыруу мүмкүн ..." деп окуу керек.
Мисалдардын ирети эч кандай айырмачылык кылбайт.

Кыска тизме:

кызмат табуу;
шифрлөө;
аутентификация жана авторизация;
жүк балансы;
чынжыр үзүү;
autoscaling;
канарларды жайгаштыруу;
көк-жашыл жайылтуулар;
ден соолукту текшерүү;
жүк түшүрүү;
трафикти чагылдыруу;
жылуулоо;
суроо-талаптын ылдамдыгын чектөө, кайра аракет кылуу жана күтүү мөөнөтү;
телеметрия;
аудит;
визуализация.

1. Кызматтын ачылышы

TL; DR: Жөнөкөй аттарды колдонуу менен тармактагы башка кызматтарга туташуу.

Кызматтар адекваттуу аттарды колдонуу менен бири-бирин автоматтык түрдө "таба" алышы керек - мисалы, service.api.production, pets/staging же cassandra. Булут чөйрөлөрү ийкемдүү жана бир ат кызматтын көптөгөн учурларын жашыра алат. Мындай кырдаалда бардык IP даректерди коддоо физикалык жактан мүмкүн эмес экени түшүнүктүү.

Мындан тышкары, бир кызмат башкасын тапканда, ал ошол кызматка суроо-талаптарды жөнөтө алышы керек, алар анын бузулган инстанциясына кирип калат деп коркпостон. Башкача айтканда, тейлөө торчосу бардык тейлөө инстанцияларынын ден соолугуна көз салып, хосттордун тизмесин мүмкүн болушунча жаңыртып турушу керек.

Ар бир тейлөө торчосу кызматты табуу механизмин башкача ишке ашырат. Азыркы учурда, эң кеңири таралган жол - Kubernetes DNS сыяктуу тышкы процесстерге өткөрүп берүү. Мурда Твиттерде бул максатта ат коюу системасын колдондук Finagle. Кошумчалай кетсек, сервис тор технологиясы ыңгайлаштырылган аталыш механизмдерин пайда кылууга мүмкүндүк берет (бирок мен мындай функция менен эч кандай SM ишке ашырууну көрө элекмин).

2. Шифрлөө

TL; DR: Кызматтар ортосундагы шифрленбеген трафиктен арылыңыз жана бул процессти автоматташтырылган жана масштабдуу кылыңыз.

Чабуулчулар сиздин ички тармагыңызга кире албай турганын билүү жагымдуу. Firewalls бул үчүн абдан жакшы иш. Бирок хакер ичине кирип кетсе эмне болот? Кызмат ичиндеги трафик менен ал каалаганын кыла алабы? Акыры мындай болбойт деп үмүт кылалы. Бул сценарийди алдын алуу үчүн, сиз кызматтардын ортосундагы бардык трафик шифрленген ишенимсиз тармакты ишке ашырууңуз керек. Көпчүлүк заманбап тейлөө торлору буга өз ара аркылуу жетишет TLS (өз ара TLS, mTLS). Кээ бир учурларда, mTLS бүтүндөй булуттарда жана кластерлерде иштейт (менин оюмча, планеталар аралык байланыш качандыр бир убакта ушундай уюштурулат).

Албетте, mTLS кызмат сетка үчүн кошумча. Ар бир кызмат өзүнүн TLSине кам көрө алат, бирок бул сиз тастыктамаларды түзүүнүн жолун таап, аларды тейлөө хостторуна бөлүштүрүшүңүз жана бул сертификаттарды файлдардан жүктөй турган кодду тиркемеге киргизишиңиз керек дегенди билдирет. Ооба, бул сертификаттарды мезгил-мезгили менен жаңыртып турууну унутпаңыз. Кызмат торлору сыяктуу системалар менен mTLS автоматташтырылган SPIFFE, бул өз кезегинде күбөлүктөрдү берүү жана ротациялоо процессин автоматташтырат.

3. Аутентификация жана авторизация

TL; DR: Сурамчы ким экенин аныктаңыз жана сурам кызматка жеткенге чейин аларга эмне кылууга уруксат берилгенин аныктаңыз.

Кызматтар көбүнчө билгиси келет ким суроо-талапты (аныктыгын текшерүү) аткарат жана бул маалыматты колдонуу менен чечим кабыл алат ошол берилген субъекттин жасоосуна уруксат берилет (уруксат). Бул учурда, ат атооч "ким" жашыра алат:

Башка кызматтар. Бул "аутентификация" деп аталат теңтуш" Мисалы, кызмат web кызматка кирүүнү каалайт db. Кызмат торлору, адатта, mTLS аркылуу мындай көйгөйлөрдү чечет: сертификаттар бул учурда керектүү идентификатордун ролун аткарышат.
Кээ бир адам колдонуучулар. Бул "аутентификация" деп аталат өтүнүч" Мисалы, колдонуучу haxor69 жаңы лампа сатып алууну каалайт. Тейлөө торлору ар кандай механизмдерди, мис. JSON Желе Токендери.
Көптөрүбүз муну колдонмо кодунда жасаганбыз. Сураныч келет, үстөлдү карап чыгабыз users, колдонуучуну таап, сырсөздү салыштырыңыз, анан тилкени текшериңиз permissions жана башкалар. Кызмат тармагында, бул суроо-талап кызматка жеткенге чейин болот.

Сурам кимден келгенин аныктагандан кийин, бул уюмга эмне кылууга уруксат берилгенин аныкташыбыз керек. Кээ бир тейлөө торлору YAML файлдары катары же буйрук сабында негизги саясаттарды (ким эмне кыла ала тургандыгы жөнүндө) коюуга мүмкүндүк берет, ал эми башкалары сыяктуу алкактар менен интеграцияны сунуштайт. Ачык саясат агенти. Түпкү максат – бул ишенимдүү булактан келген болсо, сиздин кызматтарыңыз каалаган суроону кабыл алуу и бул аракетке уруксат берилет.

4. Жүктүн тең салмактуулугу

TL; DR: Белгилүү бир калыпка ылайык жүктү тейлөө инстанциялары боюнча бөлүштүрүңүз.

Кызмат бөлүмүндөгү "Кызмат" көбүнчө көптөгөн окшош инстанциялардан турат. Мисалы, бүгүнкү күндө кызмат cache 5 нускадан турат, эртең алардын саны 11ге чейин көбөйүшү мүмкүн cache, белгилүү бир максатка ылайык бөлүштүрүлүшү керек. Мисалы, күтүү убактысын азайтуу же жумушчу инстанцияга жетүү ыктымалдыгын жогорулатуу. Эң көп колдонулган алгоритм Round-robin, бирок көптөгөн башкалары бар - мисалы, салмактуу ыкма (салмактуу) суроо (каалаган максаттарды тандай аласыз), шакек (шакек) хэшинг (жогорку агымдагы хосттор боюнча ырааттуу хэширлөө аркылуу) же эң аз суроо-талап ыкмасы (эң аз сурамдары бар инстанцияга артыкчылык берилет).

Классикалык баланстоочу башка функцияларды аткарат, мисалы, HTTP кэштөө жана DDoS коргоо, бирок алар чыгыштан-батыштагы трафик үчүн (башкача айтканда, маалымат борборунун ичинде агып жаткан трафик үчүн - болжол менен котормо) (тейлөө торунун типтүү чөйрөсү) өтө актуалдуу эмес. Албетте, жүктү теңдөө үчүн кызматтык торду колдонуунун кажети жок, бирок ал борборлоштурулган башкаруу катмарынан ар бир кызмат үчүн тең салмактуулук саясаттарын коюуга жана көзөмөлдөөгө мүмкүндүк берет, ошону менен тармактын стекинде өзүнчө жүк баланстоочуларды иштетүү жана конфигурациялоо зарылдыгын жок кылат. .

5. Электр чынжырын үзүү

TL; DR: Көйгөйлүү кызматка трафикти токтотуп, эң начар сценарийлерде зыянды көзөмөлдөңүз.

Эгерде кандайдыр бир себептерден улам кызмат трафикти көтөрө албаса, анда кызматтык тор бул көйгөйдү чечүү үчүн бир нече варианттарды сунуш кылат (башкалары тиешелүү бөлүмдөрдө каралат). Ажыратуу - бул кызматты трафиктен ажыратуунун эң оор варианты. Бирок, өзүнөн өзү мааниси жок - резервдик план керек. Артка басым камсыз кылынышы мүмкүн (арткы басым) суроо-талаптарды жасаган кызматтарга (бул үчүн кызматтык торуңузду конфигурациялоону унутпаңыз!) же, мисалы, статус барагын кызыл түскө боёп, колдонуучуларды "жыгылган кит" менен барактын башка версиясына багыттоо ("Twitter" ылдый").

Кызмат торлору сизди аныктоого гана мүмкүнчүлүк бербейт качан өчүрүү жана андан кийин болот ошол бул ээрчийт. Бул учурда, "качан" көрсөтүлгөн параметрлердин каалаган комбинациясын камтышы мүмкүн: белгилүү бир мезгил үчүн суроо-талаптардын жалпы саны, параллелдүү туташуулардын саны, күтүлүп жаткан суроо-талаптар, активдүү кайра аракет ж.б.у.с.

Сиз электр линиясын өчүрүүнү кыянаттык менен колдонгуңуз келбей жатышы мүмкүн, бирок өзгөчө кырдаалдарда резервдик планыңыз бар экенин билүү жагымдуу.

6. Автомасштабтоо

TL; DR: Көрсөтүлгөн критерийлерге жараша тейлөө инстанцияларынын санын көбөйтүү же азайтуу.

Кызмат торлору пландоочу эмес, андыктан андай эмес көтөрүп чыгып өзүңүздү масштабдоо. Бирок алар кандай пландоочулар өз чечимдерин негиздей тургандыгы тууралуу маалымат бере алышат. Кызмат торлору кызматтардын ортосундагы бардык трафикке кирүү мүмкүнчүлүгүнө ээ болгондуктан, алар эмне болуп жаткандыгы жөнүндө кеңири маалыматка ээ: кайсы кызматтарда көйгөйлөр бар, кайсы кызматтар өтө жеңил жүктөлөт (аларга бөлүнгөн кубаттуулук текке кетет) ж.б.

Мисалы, Kubernetes кызматтардын масштабын поддондордун CPU жана эстутумунун колдонулушуна негиздейт (биздин отчетту караңыз "Kubernetes'те автомасштабтоо жана ресурстарды башкаруу"- болжол менен. котормо.), бирок сиз кандайдыр бир башка метрикага (биздин учурда трафикке байланыштуу) негизинде масштабдоону чечсеңиз, сизге атайын метрика керек болот. Менеджмент Бул сыяктуу менен муну кантип жасоону көрсөтөт өкүлү, Istio и Prometheus, бирок процесстин өзү абдан татаал. Тейлөө торунун муну жөнөкөйлөштүрүшүн каалайбыз, бул бизге жөн гана шарттарды коюуга мүмкүндүк берет "тейлөө инстанцияларынын санын көбөйтүү" auth, эгерде күтүлбөгөн суроо-талаптардын саны бир мүнөттүн ичинде босогодон ашса."

7. Канарияларды жайгаштыруу

TL; DR: Колдонуучулардын бир бөлүгүндө жаңы функцияларды же кызмат версияларын сынап көрүңүз.

Келгиле, сиз SaaS продуктуну иштеп жатасыз жана анын жаңы сонун версиясын чыгарууну көздөп жатасыз дейли. Сиз аны сахналаштырууда сынап көрдүңүз жана ал сонун болду. Бирок реалдуу шарттарда анын жүрүм-туруму боюнча дагы эле белгилүү бир кооптонуулар бар. Башкача айтканда, жаңы версияны колдонуучунун ишенимине шек келтирбестен реалдуу көйгөйлөр боюнча сынап көрүү керек. Канарияларды жайгаштыруу бул үчүн сонун. Алар колдонуучулардын бир бөлүгүнө жаңы функцияны көрсөтүүгө мүмкүндүк берет. Бул топтом эң ишенимдүү колдонуучулардан же буюмдун акысыз версиясы менен иштегендерден же "гвинея чочколору" болгусу келген колдонуучулардан турушу мүмкүн.

Кызмат торлору муну колдонмонун кайсы версиясын ким көрөрүн аныктоочу критерийлерди аныктоого жана трафикти ошого жараша багыттоого мүмкүндүк берүү менен ишке ашырат. Бирок, кызматтардын өздөрү үчүн эч нерсе өзгөрбөйт. Кызматтын 1.0 версиясы бардык суроо-талаптар аны көрүүгө тийиш болгон колдонуучулардан келет деп эсептейт, ал эми 1.1 версиясы анын колдонуучулары үчүн ушундай деп эсептейт. Ошол эле учурда, сиз эски жана жаңы версиялардын ортосундагы трафиктин пайызын өзгөртө аласыз, эгер ал туруктуу иштеп, "гвинея чочколору" алдыга жылса, өсүп жаткан колдонуучулардын санын жаңысына багыттай аласыз.

8. Көк-жашыл жайгаштыруу

TL; DR: Жаңы сонун функцияны чыгарыңыз, бирок баарын дароо кайтарып алууга даяр болуңуз.

маани көк-жашыл жайгаштыруу жаңы "көк" кызматты жайылтуу болуп саналат, аны эски, "жашыл" менен катарлаш ишке киргизүү. Эгер баары ойдогудай болуп, жаңы кызмат жакшы иштесе, анда эскисин акырындык менен өчүрүүгө болот. (Аттиң, качандыр бир күнү бул жаңы “көк” кызмат “жашылдын” тагдырын кайталап, жок болуп кетет...) Көк-жашыл жайылтуулар канариялыктардан жаңы функцияны камтыганы менен айырмаланат. баары бир убакта колдонуучулар (бөлүгү эмес); Бул жерде бир нерсе туура эмес болуп кетсе, "коопсуз порт" даяр болушу керек.

Кызмат торлору "көк" кызматты сынап көрүүнүн жана көйгөйлөр пайда болгон учурда дароо иштеп жаткан "жашылга" өтүүнүн абдан ыңгайлуу жолун сунуштайт. Жолдо алар «көктүн» иши жөнүндө көптөгөн маалыматтарды (төмөндө «Телеметрияны» караңыз) берип жатканын айтпаганда да, анын толук иштөөгө даяр экендигин түшүнүүгө жардам берет.

Эскертүү. котормо.: Сиз Kubernetes ар кандай жайгаштыруу стратегиялары жөнүндө көбүрөөк окуй аласыз (анын ичинде айтылган канар, көк/жашыл жана башкалар) бул макалада.

9. Ден соолукту текшерүү

TL; DR: Кайсы кызмат инстанциялары иштей тургандыгына көз салып туруңуз жана иштебей калгандарына жооп бериңиз.

Ден соолук текшерүү (ден соолукту текшерүү) тейлөө инстанциялары трафикти кабыл алууга жана иштетүүгө даяр экендигин чечүүгө жардам берет. Мисалы, HTTP кызматтарында ден соолукту текшерүү акыркы чекитке GET сурамы сыяктуу көрүнүшү мүмкүн /health. Жооп 200 OK инстанциянын дени сак, башкасы - трафикти кабыл алууга даяр эмес экенин билдирет. Кызматтык торлор сизге функциянын кандай жол менен текшерилерин жана бул текшерүүнүн жыштыгын аныктоого мүмкүндүк берет. Бул маалымат андан кийин башка максаттар үчүн колдонулушу мүмкүн - мисалы, жүктөрдү тең салмактоо жана чынжырларды үзүү.

Ошентип, ден соолукту текшерүү өз алдынча колдонуу учуру эмес, бирок, адатта, башка максаттарга жетүү үчүн колдонулат. Ошондой эле, ден соолук текшерүүлөрүнүн жыйынтыгына жараша, башка кызматтык тор максаттарынан тышкары иш-аракеттер талап кылынышы мүмкүн: мисалы, статус барагын жаңыртуу, GitHubда маселе түзүү же JIRA билетин толтуруу. Ал эми сервис торчо мунун баарын автоматташтыруу үчүн ыңгайлуу механизмди сунуштайт.

10. Жүк таштоо

TL; DR: Колдонуунун убактылуу өсүшүнө жооп катары трафикти багыттоо.

Эгер белгилүү бир кызмат трафик менен ашыкча жүктөлсө, сиз бул трафиктин бир бөлүгүн убактылуу башка жерге багыттай аласыз (б.а. "төкмө", "өткөрүү" (төкмө) аны ошол жерде). Мисалы, резервдик кызматка же маалымат борборуна же туруктуу Pulsar тема. Натыйжада, кызмат бузулуп, бардыгын толугу менен иштетүүнү токтотуунун ордуна кээ бир суроо-талаптарды иштеп чыгууну улантат. Жүгүн төгүү чынжырды бузуудан артык, бирок аны кыянаттык менен пайдалануу дагы эле туура эмес. Бул ылдый агымдагы кызматтардын бузулушуна алып келген каскаддык каталарды алдын алууга жардам берет.

11. Трафиктин параллелизациясы/күзгүсү

TL; DR: Бир эле учурда бир нече жерге бир суроо жөнөтүңүз.

Кээде бир эле учурда бир нече кызматтарга суроо-талапты (же суроо-талаптардын белгилүү бир тандоосун) жөнөтүү зарылчылыгы келип чыгат. Кадимки мисал - өндүрүш трафигинин бир бөлүгүн коюу кызматына жөнөтүү. Негизги өндүрүш веб-сервери ылдыйкы кызматка суроо-талап жөнөтөт products.production жана ага гана. Ал эми кызмат сетка акылдуу түрдө бул өтүнүчтү көчүрүп жана жөнөтөт products.staging, бул жөнүндө веб-сервер да билбейт.

Трафиктин параллелизациясынын үстүнө ишке ашырылышы мүмкүн болгон дагы бир тиешелүү кызматтык тор колдонуу учуру регрессиялык тест. Бул кызматтын ар кандай версияларына бир эле суроо-талаптарды жөнөтүүнү жана бардык версиялар бирдей иш алып барарын текшерүүнү камтыйт. Мен азырынча интеграцияланган регрессиялык тестирлөө системасы менен кызматтык торду ишке ашыра элекмин Diffy, бирок идеянын өзү келечектүү көрүнөт.

12. жылуулоо

TL; DR: Кызмат торуңузду мини-тармактарга бөлүңүз.

катары да белгилүү сегменттөөИзоляция - бул кызматтык торду бири-бири жөнүндө эч нерсе билбеген логикалык жактан айырмаланган сегменттерге бөлүү искусствосу. Изоляция виртуалдык жеке тармактарды түзүү сыяктуу бир аз. Негизги айырмачылык, сиз дагы эле тейлөө тармагынын бардык артыкчылыктарынан ырахат ала аласыз (кызматтын ачылышы сыяктуу), бирок кошумча коопсуздук менен. Мисалы, эгер чабуулчу подсеттердин бириндеги кызматка кире алса, ал башка ички тармактарда кандай кызматтар иштеп жатканын көрө албайт же алардын трафигин токтото албайт.

Мындан тышкары, пайда да уюштуруу болушу мүмкүн. Сиз компанияңыздын түзүмүнүн негизинде кызматтарыңыздын субнетинесин кааласаңыз жана иштеп чыгуучуларды когнитивдик жүктөн арылтууну кааласаңыз, бүт кызматтык торду эстен чыгарбашыңыз керек.

13. Сурамдын ылдамдыгын чектөө, кайталоо жана күтүү мөөнөтү

TL; DR: Мындан ары код базасына майда-чүйдөсүнө чейин суроо-талаптарды башкаруу тапшырмаларын кошуунун кереги жок.

Булардын бардыгын өзүнчө колдонуу учурлары катары кароого болот, бирок мен аларды бир жалпы өзгөчөлүктөн улам айкалыштырууну чечтим: алар адатта тиркеме китепканалары тарабынан аткарылуучу суроо-талаптын жашоо циклин башкаруу тапшырмаларын аткарышат. Эгер сиз Ruby on Rails веб-серверин иштеп жатсаңыз (кызматтык тор менен интеграцияланбаган), ал сервердик кызматтарга суроо-талаптарды жөнөтөт. gRPC, колдонмо N сурамдары аткарылбай калса, эмне кылууну чечиши керек болот. Ошондой эле, бул кызматтар атайын китепкананын жардамы менен бул параметрлерди иштеп чыгууга жана коддоштурууга мүмкүнчүлүк бере турган трафикти билишиңиз керек. Мындан тышкары, өтүнмө качан баш тартууга убакыт келгенин чечиши керек жана өтүнүчтүн аткарылбай калышына жол бериши керек (тайм-ауттун негизинде). Жана жогорудагы параметрлердин кайсынысын болбосун өзгөртүү үчүн веб-серверди токтотуп, кайра конфигурациялап, кайра иштетүү керек болот.

Бул тапшырмаларды тейлөө тармагына түшүрүү кызматты иштеп чыгуучуларга алар жөнүндө ойлонбоону гана билдирбестен, аларды глобалдуу түрдө көрүүгө болот. Кызматтардын татаал тизмеги колдонулса, A -> B -> C -> D -> E деп айтсаңыз, суроо-талаптын бүткүл жашоо цикли эске алынышы керек. Эгерде тапшырма С кызматындагы күтүү убактысын узартуу болсо, муну бөлүк-бөлүк эмес, бир эле учурда жасоо логикалык жактан туура болот: кызмат кодун жаңыртуу жана тартуу сурамы кабыл алынганга чейин жана CI системасы жаңыланган кызматты жайылтканга чейин күтүү менен.

14. Телеметрия

TL; DR: Кызматтардан бардык керектүү (жана толук эмес) маалыматты чогултуңуз.

Телеметрия – бул көрсөткүчтөрдү, бөлүштүрүлгөн байкоону жана журналдарды камтыган жалпы термин. Кызмат торлору маалыматтардын бардык үч түрүн чогултуу жана иштетүү механизмдерин сунуштайт. Бул жерде нерселер бир аз бүдөмүк болуп калат, анткени мүмкүн болгон варианттардын саны өтө көп. метрикаларды чогултуу үчүн бар Prometheus жана журналдарды чогултуу үчүн колдонула турган башка куралдар эркин, чонойгондо, оору жана башка. (мисалы ClickHouse менен биздин жыгач үй K8s үчүн - болжол менен. котормо.), бөлүштүрүлгөн байкоо үчүн бар Джагер жана башка. Ар бир тейлөө торлору кээ бир инструменттерди колдошу мүмкүн, башкаларды колдобойт. Долбоордун мүмкүнбү же жокпу, көрүү кызыктуу болот Ачык телеметрия кээ бир конвергенцияны камсыз кылуу.

Мында сервистик тор технологиясынын артыкчылыгы каптал контейнерлери, негизинен, өз кызматтарынан жогорудагы маалыматтардын баарын чогулта алат. Башкача айтканда, сиздин карамагыңызда бирдиктүү телеметриялык чогултуу системасы бар жана кызматтык тор бул маалыматтын баарын ар кандай жолдор менен иштете алат. Мисалы:

CLIдеги белгилүү бир кызматтын куйрук журналдары;
тейлөө тармагынын панелинен суроо-талаптардын көлөмүн көзөмөлдөө;
бөлүштүрүлгөн издерди чогултуу жана Jaeger сыяктуу системага жөнөтүү.

Көңүл буруу, субъективдүү өкүм: Жалпысынан алганда, телеметрия - бул кызматтык тордон күчтүү кийлигишүү жагымсыз болгон аймак. Негизги маалыматты чогултуу жана сурамдын ийгилиги жана күтүү мөөнөтү сыяктуу алтын көрсөткүчтөргө көз салуу жакшы нерсе, бирок биз Frankenstein стектеринин пайда болгон адистештирилген системаларды алмаштырууга аракет кылганын көрбөйбүз деп үмүттөнөлү, алардын айрымдары өздөрүн далилдеген жана жакшы изилденген. .

15. Аудит

ТЛ;ДР: Тарыхтын сабактарын унуткандар аларды кайталап коюуга милдеттуу.

Аудит – бул системадагы маанилүү окуяларга байкоо жүргүзүү искусствосу. Тейлөө тармагында, бул конкреттүү кызматтар үчүн конкреттүү акыркы чекиттерге ким суроо-талаптарды жасаганын же акыркы айда коопсуздукка байланыштуу окуя канча жолу болгонун байкоону билдирет.

Аудит телеметрия менен абдан тыгыз байланышта экени түшүнүктүү. Айырмачылыгы телеметрия, адатта, өндүрүмдүүлүк жана техникалык бүтүндүк сыяктуу нерселер менен байланышкан, ал эми аудит катуу техникалык чөйрөдөн тышкары юридикалык жана башка маселелерге тиешелүү болушу мүмкүн (мисалы, GDPR менен шайкештик - маалыматтарды коргоо боюнча ЕБ Башкы жобосу).

16. Алдын ала көрүү

TL;DR: Жашасын React.js - кооз интерфейстердин түгөнгүс булагы.

Жакшыраак термин болушу мүмкүн, бирок мен аны билбейм. Мен жөн гана кызматтык тордун же анын айрым компоненттеринин графикалык көрүнүшүн айтып жатам. Бул визуализациялар орточо күтүү убакыттары, каптал конфигурациясынын маалыматы, ден соолукту текшерүү натыйжалары жана эскертүүлөр сыяктуу көрсөткүчтөрдү камтышы мүмкүн.

Кызматка багытталган чөйрөдө иштөө Улуу Даражалуу Монолитке салыштырмалуу бир топ жогору когнитивдик жүктү камтыйт. Ошондуктан, таанып-билүү басымы бардык чыгымдарды азайтуу керек. Бул технологиянын популярдуулугунун өсүшү үчүн баскычты чыкылдатуу жана каалаган натыйжаны алуу мүмкүнчүлүгү менен тейлөө тармагынын жөнөкөй графикалык интерфейси чечүүчү болушу мүмкүн.

Тизмеге кирген эмес

Мен башында тизмеге дагы бир нече колдонуу учурларын кошууну көздөгөн элем, бирок андан кийин баш тартууну чечтим. Бул жерде алар менин чечимимдин себептери менен бирге:

Көп маалымат борбору. Менин оюмча, бул кызматтык торлорду колдонуунун тар жана конкреттүү чөйрөсү же кызматтын ачылышы сыяктуу айрым функциялардын жыйындысы эмес.
Кирүү жана чыгуу. Бул тиешелүү аймак, бирок мен өзүмдү (балким, жасалма түрдө) "чыгыш-батыш кыймылы" колдонуу учуру менен чектеп койдум. Кирүү жана чыгуу өзүнчө макалага татыктуу.

жыйынтыктоо

Азырынча баары ушул! Дагы, бул тизме абдан эркин жана толук эмес. Эгер мен бир нерсени өткөрүп жибердим деп ойлосоңуз же туура эмес болуп калдым деп ойлосоңуз, мени менен Twitter аркылуу байланышыңыз (@luckerkins). Сураныч, адептүүлүк эрежелерин сыйлаңыз.

Котормочудан PS

Макаланын аталышындагы иллюстрация макаладагы сүрөткө негизделген "Кызматтык тор деген эмне (жана аны качан колдонуу керек)?"(Грегори МакКиннон тарабынан). Ал тиркемелердеги айрым функциялардын (жашыл түстө) алардын ортосундагы байланышты камсыз кылган кызматтык торчого кантип өткөнүн көрсөтөт (көк түстө).

Биздин блогдон дагы окуңуз:

Source: www.habr.com