Оваа статија содржи неколку вообичаени обрасци за да им помогне на инженерите да работат со големи услуги до кои пристапуваат милиони корисници.
Според искуството на авторот, ова не е исцрпна листа, но навистина ефикасен советува. Значи, да започнеме.
Преведено со поддршка .
Ниво на влез
Мерките наведени подолу се релативно едноставни за спроведување, но имаат големо влијание. Ако не сте ги пробале досега, ќе бидете изненадени од значителните подобрувања.
Инфраструктурата како код
Првиот дел од советот е да се имплементира инфраструктурата како код. Ова значи дека мора да имате програмски начин за распоредување на целата инфраструктура. Звучи комплицирано, но всушност зборуваме за следниот код:
Распоредување на 100 виртуелни машини
- со Ubuntu
- 2 GB RAM секој
- тие ќе го имаат следниот код
- со овие параметри
Можете да ги следите промените во вашата инфраструктура и брзо да се вратите на нив користејќи контрола на верзијата.
Модернистот во мене вели дека можете да го користите Kubernetes/Docker за да го направите сето погоре, и тој е во право.
Дополнително, можете да обезбедите автоматизација користејќи готвач, кукла или Terraform.
Континуирана интеграција и испорака
За да креирате скалабилна услуга, важно е да имате цевковод за изградба и тестирање за секое барање за повлекување. Дури и ако тестот е многу едноставен, тој барем ќе осигура дека кодот што го распоредувате се компајлира.
Секој пат во оваа фаза одговарате на прашањето: дали мојот склоп ќе компајлира и ќе помине тестови, дали е валиден? Ова може да изгледа како ниска лента, но решава многу проблеми.
Нема ништо поубаво од гледањето на овие крлежи
За оваа технологија можете да ги оцените Github, CircleCI или Jenkins.
Балансери на оптоварување
Значи, сакаме да извршиме балансер на оптоварување за да го пренасочиме сообраќајот и да обезбедиме еднакво оптоварување на сите јазли или услугата продолжува во случај на неуспех:
Балансерот на оптоварување обично добро го дистрибуира сообраќајот. Најдобрата практика е да се преурамнотежите за да немате ниту една точка на неуспех.
Вообичаено, балансирачите на оптоварување се конфигурирани во облакот што го користите.
RayID, корелација ID или UUID за барања
Дали некогаш сте наишле на грешка во апликацијата со ваква порака: "Нешто тргна наопаку. Зачувајте го овој ID и испратете го до нашиот тим за поддршка"?
Уникатен идентификатор, корелација ID, RayID или која било од варијациите, е единствен идентификатор што ви овозможува да следите барање во текот на неговиот животен циклус. Ова ви овозможува да ја следите целата патека на барање во дневниците.
Корисникот поднесува барање до системот А, потоа А контактира Б, кој контактира со C, го складира во X и потоа барањето се враќа во А
Кога би се поврзале од далечина со виртуелни машини и би се обиделе да ја следите патеката на барањето (и рачно да корелирате кои повици се прават), ќе полудите. Имањето единствен идентификатор го прави животот многу полесен. Ова е една од наједноставните работи што можете да ги направите за да заштедите време додека вашата услуга расте.
Средно ниво
Советите овде се покомплексни од претходните, но вистинските алатки ја олеснуваат задачата, обезбедувајќи поврат на инвестицијата дури и за малите и средни компании.
Централизирано сеча
Секоја чест! Имате распоредено 100 виртуелни машини. Следниот ден доаѓа извршниот директор и се жали на грешка што ја добил додека ја тестирал услугата. Го известува соодветниот проект за кој зборувавме погоре, но ќе треба да ги разгледате дневниците на 100 машини за да ја пронајдете онаа што ја предизвикала несреќата. И треба да се најде пред утрешната презентација.
Иако ова звучи како забавна авантура, најдобро е да бидете сигурни дека имате можност да ги пребарувате сите списанија на едно место. Го решив проблемот со централизирање на дневниците користејќи ја вградената функционалност на стекот ELK: поддржува собирање дневници со можност за пребарување. Ова навистина ќе помогне да се реши проблемот со наоѓање на одредено списание. Како бонус, можете да креирате графикони и други забавни работи како тоа.
Функционалност на стек ELK
Агенти за следење
Сега кога вашата услуга е отворена и работи, треба да бидете сигурни дека таа работи непречено. Најдобар начин да го направите ова е да извршите неколку агенти, кои работат паралелно и проверуваат дали работи и се извршуваат основни операции.
Во овој момент го проверувате тоа конструкцијата за трчање се чувствува добро и работи добро.
За мали и средни проекти, го препорачувам Postman за следење и документирање на API-и. Но, генерално, само сакате да бидете сигурни дека имате начин да знаете кога се случил прекин и да бидете известени навремено.
Автоматско скалирање во зависност од оптоварувањето
Многу е едноставно. Ако имате барања за сервисирање на VM и се приближува до 80% користење на меморијата, можете или да ги зголемите неговите ресурси или да додадете повеќе VM во кластерот. Автоматското извршување на овие операции е одлично за еластични промени на моќноста под оптоварување. Но, секогаш треба да внимавате колку пари трошите и да поставувате разумни граници.
Со повеќето облак услуги, можете да го конфигурирате за автоматско мерење користејќи повеќе сервери или помоќни сервери.
Експеримент систем
Добар начин за безбедно објавување ажурирања е да можете да тестирате нешто за 1% од корисниците за еден час. Вакви механизми, се разбира, сте виделе на дело. На пример, Фејсбук им покажува на делови од публиката со различна боја или ја менува големината на фонтот за да види како корисниците ги перцепираат промените. Ова се нарекува A/B тестирање.
Дури и објавувањето на нова функција може да се започне како експеримент и потоа да се одреди како да се ослободи. Исто така, добивате можност да „запомните“ или да ја промените конфигурацијата во лет врз основа на функцијата што предизвикува деградација во вашата услуга.
Напредно ниво
Еве совети кои се доста тешки за спроведување. Веројатно ќе ви требаат малку повеќе ресурси, па мала или средна компанија ќе има тешко време да се справи со ова.
Сино-зелени распоредувања
Ова е она што јас го нарекувам „Erlang“ начин на расплет. Erlang стана широко користен кога се појавија телефонски компании. Почнаа да се користат меки прекинувачи за насочување на телефонски повици. Главната цел на софтверот на овие прекинувачи беше да не се откажуваат повиците за време на надградбите на системот. Ерланг има убав начин да вчита нов модул без да го сруши претходниот.
Овој чекор зависи од присуството на балансатор на оптоварување. Да замислиме дека ја имате верзијата N на вашиот софтвер, а потоа сакате да ја распоредите верзијата N+1.
Можете би можеле само сопрете ја услугата и искористете ја следната верзија во време што работи за вашите корисници и добијте одредено време на застој. Но, да претпоставиме дека имате навистина строги SLA услови. Значи, SLA 99,99% значи дека можете да одите офлајн само за 52 минути годишно.
Ако навистина сакате да постигнете такви показатели, потребни ви се две распоредувања во исто време:
- онаа што е токму сега (N);
- следната верзија (N+1).
Му кажувате на балансерот на оптоварување да пренасочи процент од сообраќајот кон новата верзија (N+1) додека вие активно следите за регресии.
Овде имаме зелено распоредување N што работи добро. Се обидуваме да преминеме на следната верзија на ова распоредување
Прво испраќаме навистина мал тест за да видиме дали нашето распоредување N+1 работи со мала количина на сообраќај:
Конечно, имаме збир на автоматизирани проверки што на крајот ги извршуваме додека не заврши нашето распоредување. Ако ти многу многу Внимателно, можете да го зачувате и распоредот N засекогаш за брзо враќање во случај на лоша регресија:
Ако сакате да отидете на уште понапредно ниво, дозволете сè што е во сино-зелено распоредување да работи автоматски.
Откривање аномалија и автоматско ублажување
Имајќи предвид дека имате централизирано евидентирање и добро собирање на дневници, веќе можете да поставите повисоки цели. На пример, проактивно предвидете неуспеси. Функциите се следат на мониторите и во дневниците и се градат различни дијаграми - и однапред можете да предвидите што ќе тргне наопаку:
Откако ќе се откријат аномалии, почнувате да испитувате некои од индициите што ги дава услугата. На пример, скок во оптоварувањето на процесорот може да укаже дека хард дискот не функционира, додека скокот во барањата може да укаже дека треба да се зголеми. Овој вид статистички податоци ви овозможуваат да ја направите услугата проактивна.
Со овие сознанија, можете да размерите во која било димензија и проактивно и реактивно да ги менувате карактеристиките на машините, базите на податоци, врските и другите ресурси.
Тоа е се!
Оваа листа на приоритети ќе ве спаси од многу проблеми ако подигате услуга во облак.
Авторот на оригиналната статија ги поканува читателите да ги остават своите коментари и да направат промени. Статијата е дистрибуирана како софтвер со отворен код, повлечете барања од авторот .
Што друго да прочитате на темата:
Извор: www.habr.com