Ескерту. аударма: Осы мақаланың авторы (Люк Перкинс) Linkerd, SMI (Service Mesh Interface) және Kuma сияқты ашық бастапқы жобалардың үйі болып табылатын CNCF ұйымындағы әзірлеушілердің адвокаты (айтпақшы, сіз Istio неліктен екенін ойладыңыз ба? бұл тізімде жоқ па?). DevOps қауымдастығына «қызмет торы» деп аталатын сәнді хайпты жақсырақ түсінуге тырысып, ол мұндай шешімдер ұсынатын 16 сипаттамалық мүмкіндіктерді тізімдейді.
Бүгін ― бағдарламалық қамтамасыз ету саласындағы ең өзекті тақырыптардың бірі (және солай!). Менің ойымша, бұл технология керемет перспективалы және оны кеңінен қолдануды қалаймын (әрине мағынасы бар кезде). Дегенмен, ол әлі де көптеген адамдар үшін жұмбақ аурамен қоршалған. Сонымен қатар, тіпті кім жақсы белгілі онымен бірге оның артықшылықтарын және оның нақты не екенін (соның ішінде сіздікі) тұжырымдау жиі қиын. Бұл мақалада мен әртүрлі тізімдер арқылы жағдайды түзетуге тырысамын қолдану жағдайлары "қызмет торлары"*.
* Ескерту аудар.: осы жерде және әрі қарай мақалада дәл осы аударма («қызмет торы») әлі жаңа қызмет торы термині үшін пайдаланылады.
Бірақ алдымен мен бірнеше түсініктеме айтқым келеді:
- Мен ешқашан қызмет көрсету торларымен жұмыс істеген емеспін немесе оларды жеке білім алу үшін басталған жобалардан тыс пайдаланған емеспін. Екінші жағынан, мен 2015 жылы Twitter-дің ішкі сервистік торы үшін көптеген құжаттамаларды жазған адам болдым (ол кезде ол тіпті «қызметтік тор» деп те аталмаған) және веб-сайт пен құжаттаманы дамытуға үлес қостым. , сондықтан бұл бір нәрсені білдіреді.
- Менің тізімім шамамен және толық емес. Маған белгісіз пайдалану жағдайлары әбден мүмкін және технология дамып, оның танымалдылығы артқан сайын жаңа опциялар пайда болуы мүмкін.
- Сонымен қатар, әрбір бар қызмет торын іске асыру тізімде көрсетілген пайдалану жағдайларының барлығын қолдамайды. Сондықтан, менің «қызмет торы...» сияқты мәлімдемелерімді «жеке, мүмкін, барлық танымал сервис торын іске асырулары мүмкін...» деп оқу керек.
- Мысалдардың реті ешқандай айырмашылық жасамайды.
Қысқа тізім:
- қызметті ашу;
- шифрлау;
- аутентификация және авторизация;
- жүктемені теңестіру;
- тізбекті үзу;
- автомасштабтау;
- канарларды орналастыру;
- көк-жасыл орналастырулар;
- денсаулықты тексеру;
- жүкті түсіру;
- трафикті шағылыстыру;
- оқшаулау;
- сұраныс жылдамдығын шектеу, қайталау және күту уақыты;
- телеметрия;
- аудит;
- визуализация.
1. Қызметті табу
TL;DR: қарапайым атауларды пайдаланып желідегі басқа қызметтерге қосылыңыз.
Қызметтер сәйкес атауларды пайдаланып бір-бірін автоматты түрде «табу» мүмкіндігі болуы керек, мысалы, service.api.production, pets/staging немесе cassandra. Бұлтты орталар серпімді және бір атау қызметтің көптеген даналарын жасыра алады. Мұндай жағдайда барлық IP мекенжайларын қатаң кодтау физикалық мүмкін емес екені анық.
Сонымен қатар, бір қызмет екіншісін тапқан кезде, ол бұзылған данасы кірісінде аяқталады деп қорықпай сол қызметке сұрауларды жібере алуы керек. Басқаша айтқанда, қызмет торы барлық қызмет даналарының денсаулығын бақылап, хосттар тізімін мүмкіндігінше жаңартып отыруы керек.
Әрбір қызмет торы қызметті табу механизмін басқаша жүзеге асырады. Қазіргі уақытта ең көп таралған әдіс - Kubernetes DNS сияқты сыртқы процестерге өкілдік ету. Бұрын Twitter-де осы мақсат үшін атау жүйесін қолдандық . Сонымен қатар, сервистік тор технологиясы теңшелетін атау механизмдерінің пайда болуына мүмкіндік береді (бірақ мен мұндай функционалдығы бар SM іске асыруды әлі көрмедім).
2. Шифрлау
TL; DR: қызметтер арасындағы шифрланбаған трафиктен құтылыңыз және бұл процесті автоматтандырылған және масштабталатын етіңіз.
Шабуылдаушылардың ішкі желіңізге еніп кете алмайтынын білу жақсы. Брандмауэрлер бұл жұмысты жақсы атқарады. Бірақ хакер ішке кірсе не болады? Қызметішілік трафикпен ол қалағанын жасай ала ма? Бұл бәрібір болмайды деп үміттенейік. Бұл сценарийді болдырмау үшін қызметтер арасындағы барлық трафик шифрланған нөлдік сенімді желіні енгізу керек. Көптеген заманауи қызмет көрсету торлары бұған өзара әрекеттесу арқылы қол жеткізеді (өзара TLS, mTLS). Кейбір жағдайларда mTLS тұтас бұлттар мен кластерлерде жұмыс істейді (менің ойымша, планетааралық байланыс бір күні осылай ұйымдастырылады).
Әрине, mTLS қызмет көрсету торы үшін міндетті емес. Әрбір қызмет өзінің TLS-і туралы қамқорлық жасай алады, бірақ бұл сізге сертификаттарды жасау, оларды қызмет хосттары бойынша тарату және осы сертификаттарды файлдардан жүктейтін бағдарламаға код қосу жолын табу керек дегенді білдіреді. Иә, бұл сертификаттарды жүйелі түрде жаңартуды ұмытпаңыз. Сервис торлары mTLS сияқты жүйелермен автоматтандырады , бұл өз кезегінде сертификаттарды беру және айналдыру процесін автоматтандырады.
3. Аутентификация және авторизация
TL; DR: Сұраныс берушінің кім екенін анықтаңыз және сұрау қызметке жеткенге дейін оларға не істеуге рұқсат етілгенін анықтаңыз.
Қызметтер жиі білгісі келеді кім сұрауды (аутентификацияны) орындайды және осы ақпаратты пайдалана отырып, шешім қабылдайды сол берілген субъектіге (авторизация) рұқсат етіледі. Бұл жағдайда «кім» есімдігі жасыра алады:
- Басқа қызметтер. Бұл «аутентификация» деп аталады құрдас" Мысалы, қызмет көрсету
webқызметке қол жеткізгісі келедіdb. Қызметтік торлар әдетте mTLS көмегімен осындай мәселелерді шешеді: бұл жағдайда сертификаттар қажетті идентификатор ретінде әрекет етеді. - Кейбір адам пайдаланушылар. Бұл «аутентификация» деп аталады сұрау" Мысалы, пайдаланушы
haxor69жаңа шам сатып алғысы келеді. Қызмет көрсету торлары әртүрлі механизмдерді қамтамасыз етеді, мысалы. .Көпшілігіміз мұны қолданбалы кодта жасадық. Сұраныс келеді, кестені ақтарамыз
users, пайдаланушыны тауып, құпия сөзді салыстырыңыз, содан кейін бағанды тексеріңізpermissionsжәне т.б. Қызмет көрсету торы жағдайында бұл сұрау тіпті қызметке жеткенге дейін орын алады.
Сұрау кімнен келгенін анықтағаннан кейін, бұл ұйымның не істеуге рұқсат етілгенін анықтауымыз керек. Кейбір қызмет торлары YAML файлдары ретінде немесе пәрмен жолында негізгі саясаттарды (кім не істей алатыны туралы) орнатуға мүмкіндік береді, ал басқалары сияқты құрылымдармен біріктіруді ұсынады. . Түпкілікті мақсат – сіздің қызметтеріңіздің кез келген сұрауды сенімді көзден келетінін болжаған жағдайда қабылдауы и бұл әрекетке рұқсат етіледі.
4. Жүктемені теңестіру
TL;DR: белгілі бір үлгіге сәйкес қызмет даналары бойынша жүктемені таратыңыз.
Қызмет бөліміндегі «Қызмет» көбінесе көптеген бірдей даналардан тұрады. Мысалы, бүгінгі күні қызмет cache 5 данадан тұрады, ертең олардың саны 11-ге дейін артуы мүмкін cache, белгілі бір мақсатқа сәйкес таратылуы керек. Мысалы, кідірісті азайтыңыз немесе жұмыс данасына жету ықтималдығын арттырыңыз. Ең жиі қолданылатын алгоритм - Round-robin, бірақ басқалары көп - мысалы, салмақты әдіс (салмақталған) сұраулар (қалаулы мақсаттарды таңдауға болады), қоңырау шалу (сақина) хэштеу (жоғары ағынды хосттар бойынша дәйекті хэштеуді пайдалану) немесе ең аз сұрау әдісі (ең аз сұраулары бар данаға артықшылық беріледі).
Классикалық теңгергіштерде HTTP кэштеу және DDoS қорғау сияқты басқа да функциялар бар, бірақ олар шығыс-батыс трафик үшін (яғни, деректер орталығының ішінде ағып жатқан трафик үшін – шамамен аударма) аса маңызды емес (қызмет торының әдеттегі ауқымы). Әрине, жүктемені теңестіру үшін сервистік торды пайдалану қажет емес, бірақ ол орталықтандырылған басқару деңгейінен әрбір қызмет үшін теңдестіру саясатын орнатуға және басқаруға мүмкіндік береді, осылайша желі стекіндегі бөлек жүктеме теңестірушілерін іске қосу және конфигурациялау қажеттілігін жояды. .
5. Тізбекті үзу
TL; DR: проблемалық қызметке трафикті тоқтатыңыз және ең нашар сценарийлердегі зақымдарды басқарыңыз.
Егер қандай да бір себептермен қызмет трафикті жеңе алмаса, қызмет торы бұл мәселені шешудің бірнеше нұсқасын ұсынады (басқалары тиісті бөлімдерде талқыланады). Тізбекті үзу – қызметті трафиктен ажыратудың ең қиын нұсқасы. Дегенмен, бұл өздігінен мағынасыз - резервтік жоспар қажет. Кері қысым қамтамасыз етілуі мүмкін () сұраулар жасайтын қызметтерге (бұл үшін қызмет көрсету торын конфигурациялауды ұмытпаңыз!) немесе, мысалы, күй бетін қызыл түске бояңыз және пайдаланушыларды «құлап бара жатқан кит» бар беттің басқа нұсқасына қайта бағыттаңыз («Twitter - бұл төмен»).
Қызметтік торлар тек анықтауға мүмкіндік бермейді кезде кейін өшіру және сол осыдан кейін болады. Бұл жағдайда «қашан» көрсетілген параметрлердің кез келген комбинациясын қамтуы мүмкін: белгілі бір кезеңдегі сұраулардың жалпы саны, параллель қосылымдар саны, күтудегі сұраулар, белсенді қайталаулар және т.б.
Сіз электр тізбегін бұзуды теріс пайдаланғыңыз келмейтін шығар, бірақ төтенше жағдайда резервтік жоспарыңыз бар екенін білу жақсы.
6. Автомасштабтау
TL;DR: Көрсетілген критерийлерге байланысты қызмет даналарының санын көбейтіңіз немесе азайтыңыз.
Қызмет торлары жоспарлаушы емес, сондықтан олар жоқ жүзеге асыру өзіңізді масштабтау. Дегенмен, олар қандай жоспарлаушылар шешімдерін негізге алатыны туралы ақпаратты бере алады. Сервистік торлар қызметтер арасындағы барлық трафикке қол жеткізе алатындықтан, оларда не болып жатқаны туралы кең ақпарат бар: қандай қызметтерде ақаулар бар, қандай қызметтер өте аз жүктеледі (оларға бөлінген сыйымдылық босқа кетеді) және т.б.
Мысалы, Kubernetes қызметтерді процессордың процессоры мен жадты пайдалануына негізделген қызметтерді масштабтайды (біздің есепті қараңыз»" - шамамен. аудар.), бірақ кез келген басқа көрсеткішке негізделген масштабтауды шешсеңіз (біздің жағдайда трафикке қатысты), сізге арнайы көрсеткіш қажет болады. Басқару мұны қалай жасау керектігін көрсетеді , и , бірақ процестің өзі өте күрделі. Біз сервистік тордың «қызмет көрсету даналарының санын көбейту» сияқты жай шарттарды орнатуға мүмкіндік беру арқылы оны жеңілдетуді қалаймыз. 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: пайдаланудың уақытша өсуіне жауап ретінде трафикті қайта бағыттаңыз.
Белгілі бір қызмет трафикпен шамадан тыс жүктелсе, сіз осы трафиктің бір бөлігін басқа орынға уақытша қайта бағыттай аласыз (яғни, «қоқыс», «тасымалдау»). (сарай) ол сонда). Мысалы, сақтық көшірме қызметіне немесе деректер орталығына немесе тұрақты Тақырып. Нәтижесінде, қызмет бұзылып, барлығын өңдеуді толығымен тоқтатудың орнына кейбір сұрауларды өңдеуді жалғастырады. Тізбекті бұзғаннан гөрі жүктемені түсіру жақсырақ, бірақ оны әлі де теріс пайдалану ұсынылмайды. Бұл төмен ағындық қызметтердің бұзылуына әкелетін каскадты сәтсіздіктерді болдырмауға көмектеседі.
11. Трафикті параллелизациялау/айналау
TL; DR: бір сұрауды бірден бірнеше жерге жіберу.
Кейде сұранысты (немесе сұраныстардың белгілі бір таңдауын) бірден бірнеше қызметтерге жіберу қажеттілігі туындайды. Типтік мысал өндірістік трафиктің бір бөлігін кезеңдік қызметке жіберу болып табылады. Негізгі өндірістік веб-сервер төмен ағындық қызметке сұраныс жібереді products.production және тек оған. Ал қызмет торы бұл сұрауды ақылды түрде көшіріп, оны жібереді products.staging, бұл туралы веб-сервер тіпті білмейді.
Трафикті параллелизациялаудың жоғарғы жағында жүзеге асырылуы мүмкін басқа сәйкес қызмет торын пайдалану жағдайы . Бұл қызметтің әртүрлі нұсқаларына бірдей сұрауларды жіберуді және барлық нұсқалардың бірдей әрекет ететінін тексеруді қамтиды. Мен регрессиялық тестілеудің интеграцияланған жүйесі бар сервистік торды енгізуді әлі кездестірген жоқпын , бірақ идеяның өзі перспективалы болып көрінеді.
12. Оқшаулау
TL;DR: қызмет көрсету торын шағын желілерге бөліңіз.
ретінде де белгілі сегменттеуОқшаулау - бұл қызмет торын бір-бірі туралы ештеңе білмейтін логикалық тұрғыдан бөлек сегменттерге бөлу өнері. Оқшаулау виртуалды жеке желілерді құру сияқты. Негізгі айырмашылық - сіз әлі де қосымша қауіпсіздікпен қызмет көрсету торының барлық артықшылықтарын (қызметтерді табу сияқты) пайдалана аласыз. Мысалы, егер шабуылдаушы бір ішкі желідегі қызметке еніп кетсе, ол басқа ішкі желілерде қандай қызметтер жұмыс істеп тұрғанын көре алмайды немесе олардың трафигін ұстай алмайды.
Сонымен қатар, артықшылықтар ұйымдастырушылық болуы мүмкін. Компания құрылымына негізделген қызметтеріңізді ішкі желіге қосқыңыз келуі мүмкін және әзірлеушілерді бүкіл қызмет торын есте сақтау қажеттілігінен когнитивтік жүктемеден босатқыңыз келуі мүмкін.
13. Сұраныс жылдамдығын шектеу, қайталау және күту уақыты
TL; DR: Сізге код базасына күрделі сұрауларды басқару тапсырмаларын қосу қажет емес.
Осы заттардың барлығын бөлек пайдалану жағдайлары деп санауға болады, бірақ мен оларды бір ортақ мүмкіндікке байланысты біріктіруді шештім: олар әдетте қолданба кітапханалары өңдейтін сұраудың өмірлік циклін басқару тапсырмаларын қабылдайды. Егер сіз Ruby on Rails жүйесінде веб-серверді әзірлеп жатсаңыз (қызмет торымен біріктірілмеген), ол серверлік қызметтерге сұраулар жібереді. , қолданба N сұрау сәтсіз болған жағдайда не істеу керектігін шешуі керек. Сондай-ақ, бұл қызметтер арнайы кітапхананың көмегімен осы параметрлерді өңдеуге және кодтауға қаншалықты трафиктің болатынын білуіңіз керек. Сонымен қатар, қолданба қашан бас тарту керек екенін және сұраудың қабылданбауына мүмкіндік беруі керек (күту уақыты негізінде). Және жоғарыда аталған параметрлердің кез келгенін өзгерту үшін веб-серверді тоқтатып, қайта конфигурациялап, қайта іске қосу керек болады.
Бұл тапсырмаларды қызмет торына түсіру қызмет әзірлеушілеріне олар туралы ойланудың қажеті болмайтынын ғана емес, сонымен қатар оларды жаһандық түрде көруге болатынын білдіреді. Қызметтердің күрделі тізбегі пайдаланылса, айталық, A -> B -> C -> D -> E, сұраудың бүкіл өмірлік циклі ескерілуі керек. Егер тапсырма C қызметіндегі күту уақытын ұзарту болса, мұны бөліктермен емес, бір уақытта орындау қисынды: қызмет кодын жаңарту және тарту сұрауы қабылданғанша және CI жүйесі жаңартылған қызметті қолданғанша күту арқылы.
14. Телеметрия
TL; DR: қызметтерден барлық қажетті (және толық емес) ақпаратты жинаңыз.
Телеметрия – бұл көрсеткіштерді, бөлінген бақылауды және журналдарды қамтитын жалпы термин. Қызметтік торлар деректердің барлық үш түрін жинау және өңдеу механизмдерін ұсынады. Мүмкін опциялардың саны тым көп болғандықтан, бұл жерде нәрселер аздап бұлыңғыр болады. Көрсеткіштерді жинау үшін бар және журналдарды жинау үшін пайдалануға болатын басқа құралдар , , және басқалар. (мысалы, ClickHouse біздің K8s үшін - шамамен. аудар.), таратылған бақылау үшін бар және т.б. Әрбір қызмет көрсету торы кейбір құралдарды қолдауы мүмкін, ал басқаларына қолдау көрсетпейді. Жоба мүмкін бе, соны білу қызықты болады кейбір конвергенцияны қамтамасыз етеді.
Бұл жағдайда сервистік тор технологиясының артықшылығы - бүйірлік контейнерлер, негізінен, жоғарыда аталған барлық деректерді өз қызметтерінен жинай алады. Басқаша айтқанда, сізде жалғыз телеметрия жинау жүйесі бар және қызмет торы осы ақпаратты әртүрлі жолдармен өңдей алады. Мысалы:
- CLI-дағы белгілі бір қызметтен алынған құйрық журналдары;
- қызмет көрсету торының бақылау тақтасынан сұраныстардың көлемін бақылау;
- бөлінген іздерді жинап, оларды Jaeger сияқты жүйеге жіберіңіз.
Назар аударыңыз, субъективті пайымдау: Жалпы айтқанда, телеметрия - бұл қызмет көрсету торынан күшті кедергілер қажет емес аймақ. Негізгі ақпаратты жинау және сұраудың сәттілігі мен кідірістері сияқты кейбір алтын көрсеткіштерді бақылау өте жақсы, бірақ кейбіреулері өзін дәлелдеген және жақсы зерттелген арнайы жүйелерді ауыстыруға тырысатын Франкенштейн стектерінің пайда болуын көрмейміз деп үміттенейік. .
15. Аудит
TL;DR: Тарих сабақтарын ұмытқандар оларды қайталауға мәжбүр.
Аудит – жүйедегі маңызды оқиғаларды бақылау өнері. Қызметтік тор жағдайында бұл нақты қызметтер үшін нақты соңғы нүктелерге кім сұрау салғанын немесе соңғы айда қауіпсіздікке қатысты оқиғаның қанша рет орын алғанын бақылауды білдіруі мүмкін.
Аудит телеметриямен өте тығыз байланысты екені анық. Айырмашылығы мынада, телеметрия әдетте өнімділік және техникалық тұтастық сияқты нәрселермен байланысты, ал аудит қатаң техникалық саладан тыс құқықтық және басқа мәселелерге қатысты болуы мүмкін (мысалы, GDPR сәйкестігі - деректерді қорғау туралы ЕО жалпы ережесі).
16. Көрнекілік
TL;DR: ұзақ өмір сүріңіз React.js – сәнді интерфейстердің сарқылмас көзі.
Жақсырақ термин болуы мүмкін, бірақ мен оны білмеймін. Мен жай ғана қызмет көрсету торының немесе оның кейбір компоненттерінің графикалық көрінісін айтамын. Бұл көрнекіліктер орташа кідіріс уақыттары, бүйірлік вагон конфигурациясы туралы ақпарат, денсаулықты тексеру нәтижелері және ескертулер сияқты көрсеткіштерді қамтуы мүмкін.
Қызмет көрсетуге бағытталған ортада жұмыс істеу Мәртебелі Монолитпен салыстырғанда әлдеқайда жоғары когнитивтік жүктемені қамтиды. Сондықтан когнитивті қысымды кез келген жағдайда азайту керек. Түймені басу және қажетті нәтиже алу мүмкіндігі бар сервистік тордың қарапайым графикалық интерфейсі осы технологияның танымалдылығының өсуі үшін шешуші болуы мүмкін.
Тізімге енбеген
Бастапқыда мен тізімге тағы бірнеше пайдалану жағдайларын қосуды жоспарладым, бірақ кейіннен бас тарттым. Міне, олар менің шешімімнің себептерімен бірге:
- Көп деректер орталығы. Менің ойымша, бұл қызмет көрсету торларын қолданудың тар және нақты аймағы немесе қызметті табу сияқты кейбір функциялар жиынтығы сияқты пайдалану жағдайы емес.
- Кіру және шығу. Бұл байланысты аймақ, бірақ мен өзімді (мүмкін жасанды түрде) «шығыс-батыс қозғалысы» пайдалану жағдайымен шектедім. Кіру және шығу бөлек мақалаға лайық.
қорытынды
Әзірге бәрі осы! Тағы да, бұл тізім өте ерікті және толық емес. Егер мені бірдеңені жіберіп алдым немесе бірдеңе дұрыс емес деп ойласаңыз, Twitter арқылы маған хабарласыңыз (). Әдептілік ережелерін құрметтеңіз.
Аудармашыдан PS
Мақаланың тақырыптық иллюстрациясы мақаладағы суретке негізделген ««(Грегори МакКиннон бойынша). Ол қолданбалардың кейбір функцияларының (жасыл түспен) олардың арасындағы өзара байланысты қамтамасыз ететін қызмет торына қалай ауысқанын көрсетеді (көк түспен).
Біздің блогта да оқыңыз:
- ««;
- ««;
- ««.
Ақпарат көзі: www.habr.com
