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

(Жана ушул макаланын аягында мен микросервис архитектурасы боюнча эксперт Крис Ричардсондун үч күндүк семинарына катышуу мүмкүнчүлүгү жөнүндө сүйлөшөм).

Микросервистерге кантип келдик

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

Биз бир нече жылдан бери микросервис архитектурасын куруп жатабыз. Кантип так - майда-чүйдөсүнө чейин биздин кесиптештер айтып биздин RIT++ 2017 бөлүмүндө. CodeFest 2017де (караңыз. видео), Сергей Орлов жана Михаил Прокопчук эмне үчүн микросервистерге өтүү керектигин жана Кубернетес бул жерде кандай роль ойногондугун кеңири түшүндүрүштү. Эми биз мындай архитектурага мүнөздүү болгон масштабдуу чыгымдарды азайтуу үчүн бардыгын жасап жатабыз.

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

Эми PaaS CLI утилитасында бир буйрук менен жаңы кызмат түзүлөт жана дагы экөөсү менен жаңы маалымат базасы кошулуп, Этапка орнотулат.

"Микросервистин фрагментациясынын" доорун кантип жеңсе болот

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

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

• жыгачтарды даярдоо;
• суроо-талапты издөө (Jaeger);
• каталарды топтоо (Sentry);
• Kubernetes'тен статустар, билдирүүлөр, окуялар (Окуя агымын иштетүү);
• жарыш чеги / автоматтык өчүргүч (сиз Hystrix колдоно аласыз);
• кызмат байланышын көзөмөлдөө (биз Netramesh колдонобуз);
• мониторинг (Графана);
• ассамблея (TeamCity);
• байланыш жана кабарлоо (Slack, электрондук почта);
• тапшырмага көз салуу; (Джира)
• документтерди даярдоо.

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

Микросервистерди кантип башкарабыз

Көптөгөн Avito микросервистеринин арасында бирдиктүү "партиялык саясатты" ишке ашырууга төмөнкү жардам берет:

• инфраструктураны катмарларга бөлүү;
• Platform as a Service (PaaS) концепциясы;
• микросервистер менен болгон бардык нерсени көзөмөлдөө.

Инфраструктуранын абстракциялык катмарлары үч катмарды камтыйт. Жогортон ылдый карай кетели.

A. Top - тейлөө тор. Башында биз Istio'ну сынап көрдүк, бирок ал өтө көп ресурстарды колдонот, бул биздин көлөмдөр үчүн өтө кымбат. Ошондуктан, архитектура тобунун улук инженери Александр Лукьянченко өз алдынча чечим иштеп чыккан - Netramesh (Ачык булакта бар), биз азыр өндүрүштө колдонуп жатабыз жана Istioго караганда бир нече эсе аз ресурстарды керектейт (бирок Istio мактана турган нерселердин баарын жасай бербейт).
B. Орто - Kubernetes. Биз ага микросервистерди орнотуп, иштетебиз.
C. Асты - жылаңач металл. Биз булуттарды же OpenStack сыяктуу нерселерди колдонбойбуз, бирок толугу менен жылаңач металлга таянабыз.

Бардык катмарлар PaaS менен бириктирилген. Ал эми бул платформа өз кезегинде үч бөлүктөн турат.

I. Генераторлор, CLI утилитасы аркылуу башкарылат. Ал иштеп чыгуучуга микросервисти туура жол менен жана минималдуу күч менен түзүүгө жардам берет.

II. Консолидацияланган коллектор жалпы башкаруу тактасы аркылуу бардык куралдарды башкаруу менен.

III. Сактагыч. Маанилүү аракеттер үчүн триггерлерди автоматтык түрдө орнотуучу пландаштыруучулар менен туташат. Мындай системанын аркасында кимдир бирөө Jiraда тапшырма коюуну унутуп калгандыктан, бир дагы тапшырма аткарылбай калат. Бул үчүн биз Atlas деп аталган ички куралды колдонобуз.

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

Стандарттык микросервисти өнүктүрүү түтүгү кантип иштейт?

Жалпысынан алганда, микросервис түзүү чынжыр төмөнкүдөй көрүнөт:

CLI-түртүү → Үзгүлтүксүз интеграция → Бышыруу → Жайгаштыруу → Жасалма сыноолор → Канар сыноолору → Сыгып сыноо → Өндүрүш → Тейлөө.

Келгиле, аны так ушул тартипте карап көрөлү.

CLI-түртүү

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

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

— Кызматты калыпка ылайык түзөт — этап-этабы менен, «устаз» режиминде. Бизде Avito серверинде негизги программалоо тилдери үчүн шаблондор бар: PHP, Golang жана Python.

- Бир убакта бир буйрук белгилүү бир машинада жергиликтүү өнүгүү үчүн чөйрөнү жайылтат - Minikube ишке киргизилет, Helm диаграммалары автоматтык түрдө түзүлөт жана жергиликтүү кубернеттерде ишке киргизилет.

— Керектүү маалымат базасын бириктирет. Иштеп чыгуучу өзүнө керектүү маалымат базасына жетүү үчүн IP, логин жана сырсөздү билиши керек эмес - ал жергиликтүү, этапта же өндүрүштө. Мындан тышкары, маалымат базасы катага чыдамдуу конфигурацияда жана тең салмактуулук менен дароо жайгаштырылат.

— Ал түз жыйынды өзү аткарат. Иштеп чыгуучу IDE аркылуу микросервисте бир нерсени оңдоду дейли. Утилита файл тутумундагы өзгөрүүлөрдү көрөт жана алардын негизинде тиркемени кайра түзөт (Голанг үчүн) жана кайра иштетет. PHP үчүн, биз жөн гана кубдун ичиндеги каталогду жөнөтөбүз жана ал жерден "автоматтык түрдө" жандуу кайра жүктөө алынат.

— Автотесттерди түзөт. бланк түрүндө, бирок колдонуу үчүн абдан ылайыктуу.

• Микросервисти жайылтуу.

Микросервисти жайылтуу биз үчүн бир аз түйшүк болчу. Төмөнкүлөр талап кылынган:

I. Dockerfile.

II. Конфигурация.
III. Руль диаграммасы, ал өзү оор жана төмөнкүлөрдү камтыйт:

- диаграммалар өздөрү;
— шаблондор;
- ар кандай чөйрөнү эске алуу менен белгилүү бир баалуулуктар.

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

Ооба, жана app.toml өзүндө бир мүнөттө кыла турган эч нерсе жок. Кызматтын кайда жана канча нускасын көтөрө турганыбызды (иштеп чыгуучу серверде, сахнада, өндүрүштө) тактап, анын көз карандылыгын көрсөтөбүз. [кыймылдаткыч] блогунда сызык өлчөмү = "кичинекей" экенин байкаңыз. Бул Kubernetes аркылуу кызматка бөлүнгөн чек.

Андан кийин, конфигурациянын негизинде, бардык керектүү Helm диаграммалары автоматтык түрдө түзүлөт жана маалымат базаларына байланыштар түзүлөт.

• Негизги валидация. Мындай текшерүүлөр да автоматташтырылган.
Көз салуу керек:
— Докер файлы барбы;
— app.toml барбы;
— Документтер барбы?
— көз карандылык туурабы?
— эскертүү эрежелери коюлганбы.
Акыркы пунктка: кызматтын ээси кайсы продукттун көрсөткүчтөрүн көзөмөлдөөнү өзү аныктайт.

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

I. Кызматтын кыскача баяндамасы. Ал эмне кылат жана эмне үчүн керектиги жөнүндө бир нече сүйлөмдөр.

II. Архитектура диаграммасы шилтемеси. Маанилүү нерсе, аны тез карап көрүү менен, мисалы, Redisди кэштөө үчүн колдонуп жатасызбы же туруктуу режимде негизги маалымат сактагычы катары түшүнүү оңой. Азыр Avitoдо бул Confluence шилтемеси.

III. Runbook. Кызматты баштоо жана аны иштетүүнүн татаалдыктары боюнча кыскача колдонмо.

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

V. API үчүн акыркы чекиттердин сүрөттөлүшү. Эгер күтүлбөгөн жерден сиз көздөгөн жерлерди көрсөтпөсөңүз, микросервистери сиздикине тиешелүү болгон кесиптештер бул үчүн сөзсүз түрдө төлөшөт. Эми биз Swaggerди колдонобуз жана бул үчүн кыскача чечимибиз.

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

VII. Кызматтын ээси же ээлери. Көпчүлүк учурларда, ал же аларды PaaS аркылуу автоматтык түрдө аныктоого болот, бирок коопсуз тарапта болуу үчүн биз иштеп чыгуучудан аларды кол менен көрсөтүүнү талап кылабыз.

Акыр-аягы, кодду карап чыгууга окшош документтерди карап чыгуу жакшы практика.

үзгүлтүксүз Integration

• Репозиторийлерди даярдоо.
• TeamCityде конвейерди түзүү.
• Укуктарды орнотуу.
• Кызмат ээлерин издөө. Бул жерде гибриддик схема бар - кол менен белгилөө жана PaaSдан минималдуу автоматташтыруу. Кызматтар башка иштеп чыгуу тобуна колдоо үчүн өткөрүлүп берилгенде же, мисалы, кызматты иштеп чыгуучу иштен чыкса, толук автоматтык схема иштебей калат.
• Атласта кызматты каттоо (жогоруда кара). Анын бардык ээлери жана көз карандылыгы менен.
• Миграцияларды текшерүү. Алардын кайсынысы кооптуу экенин текшеребиз. Мисалы, алардын биринде өзгөртүү таблицасы же башка бир нерсе пайда болот, бул кызматтын ар кандай версияларынын ортосундагы маалымат схемасынын шайкештигин бузушу мүмкүн. Андан кийин көчүрүү жүргүзүлбөйт, бирок жазылууга жайгаштырылат - PaaS кызматтын ээсине аны колдонуу коопсуз болгондо сигнал бериши керек.

бышыруу

Кийинки этап - жайылтуудан мурун пакеттөө кызматтары.

• Колдонмону түзүү. Классика боюнча - Докер сүрөтүндө.
• Кызматтын өзү жана ага тиешелүү ресурстар үчүн Helm диаграммаларын түзүү. Анын ичинде маалымат базалары жана кэш үчүн. Алар CLI-түртүү баскычында түзүлгөн app.toml конфигурациясына ылайык автоматтык түрдө түзүлөт.
• Портторду ачуу үчүн администраторлор үчүн билеттерди түзүү (зарыл болгондо).
• Бирдиктин тесттерин жүргүзүү жана коддун камтылышын эсептөө. Эгерде коддун камтуусу көрсөтүлгөн чектен төмөн болсо, анда кызмат андан ары барбайт - жайылтууга. Эгерде ал алгылыктуу чегинде болсо, анда кызматка "пессимизирлөө" коэффициенти ыйгарылат: андан кийин, убакыттын өтүшү менен көрсөткүчтүн жакшыруусу болбосо, иштеп чыгуучу тесттер боюнча эч кандай жылыш жок деген билдирүү алат ( жана бул боюнча бир нерсе кылуу керек).
• Эстутум жана CPU чектөөлөрүн эсепке алуу. Биз негизинен Голангда микросервистерди жазып, аларды Kubernetesте иштетебиз. Демек, Голанг тилинин өзгөчөлүгү менен байланышкан бир кылдаттык: демейки боюнча, баштоодо, машинадагы бардык өзөктөр колдонулат, эгерде сиз GOMAXPROCS өзгөрмөсүн ачык койбосоңуз жана бир эле машинада бир нече ушундай кызматтар ишке киргизилгенде, алар башталат. бири-бирине кийлигишип, ресурстар үчүн атаандашууга. Төмөнкү графиктер тиркемени талашсыз жана ресурстар үчүн жарышта иштетсеңиз, аткаруу убактысы кандай өзгөрөрүн көрсөтүп турат. (Графиктердин булагы болуп саналат бул жерде).

Аткаруу убактысы азыраак болсо жакшы. Максималдуу: 643 мс, минималдуу: 42 мс. Сүрөт чыкылдатса болот.

Операцияга убакыт азыраак, жакшыраак. Максималдуу: 14091 нс, минималдуу: 151 нс. Сүрөт чыкылдатса болот.

Жыйынды даярдоо баскычында сиз бул өзгөрмөнү ачык орното аласыз же китепкананы колдоно аласыз automaxprocs Uberдин жигиттеринен.

Жайгаштыруу

• Конвенцияларды текшерүү. Кызмат жыйындарын өзүңүздүн чөйрөңүзгө жеткирүүдөн мурун, төмөнкүлөрдү текшеришиңиз керек:
- API акыркы чекиттери.
— API акыркы чекиттеринин жоопторунун схемага ылайык келиши.
— Журнал форматы.
— Кызматка суроо-талаптар үчүн аталыштарды коюу (учурда бул Netramesh тарабынан жасалат)
— Окуя автобусуна билдирүүлөрдү жөнөтүүдө ээсинин белгисин коюу. Бул автобустагы кызматтардын байланышын көзөмөлдөө үчүн керек. Сиз автобуска идемпотенттик маалыматтарды да жөнөтө аласыз, бул кызматтардын туташуулугун арттырбайт (бул жакшы), жана кызматтардын байланышын күчөткөн бизнес-даалыматтарды (бул абдан жаман!). Ал эми бул туташуу көйгөйгө айланган учурда, автобусту ким жазганын жана окуганын түшүнүү кызматтарды туура бөлүштүрүүгө жардам берет.

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

Синтетикалык тесттер

• Жабык цикл тести. Бул үчүн биз азыр ачык булакты колдонуп жатабыз Hoverfly.io. Биринчиден, ал кызматтын реалдуу жүгүн жазат, андан кийин - жөн гана жабык циклде - аны туурайт.

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

Жүктөлгөн тестирлөө учурунда биз ресурсту керектөө белгиленген чектерге жооп берерин текшеребиз. Ал эми биз биринчи кезекте экстремалдык нерселерге басым жасайбыз.

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

б) Биз RPS боюнча кесүүнү карайбыз.
Бул жерде биз учурдагы версия менен мурунку жана жалпы санынын ортосундагы айырманы карап көрөлү. Мисалы, эгерде кызмат 100 rps өндүрсө, анда ал начар жазылган, же бул анын өзгөчөлүгү, бирок кандай болгон күндө да, бул кызматка өтө кылдаттык менен кароого негиз болуп саналат.
Эгерде, тескерисинче, RPS өтө көп болсо, анда кандайдыр бир ката бар жана кээ бир акыркы чекиттер пайдалуу жүктү аткарууну токтоткон, ал эми башкасы жөн эле иштетилген болушу мүмкүн. return true;

Канар тесттери

Синтетикалык тесттерден өткөндөн кийин биз микросервисти аз сандагы колдонуучуларга сынайбыз. Биз кылдаттык менен баштайбыз, кызматтын арналган аудиториясынын бир аз үлүшү - 0,1% дан аз. Бул этапта, алар мүмкүн болушунча тезирээк кызмат көйгөйдү көрсөтүү үчүн, туура техникалык жана продукт көрсөткүчтөрү мониторинг киргизилген абдан маанилүү болуп саналат. Канар тестинин минималдуу убактысы 5 мүнөт, негизгиси 2 саат. Татаал кызматтар үчүн биз убакытты кол менен орнотобуз.
талдап көрөлү:
— тилге тиешелүү метрика, атап айтканда, php-fpm кызматкерлери;
— Сентридеги каталар;
— жооп статустары;
— жооп берүү убактысы, так жана орточо;
- кечигүү;
— иштетилген жана иштетилбеген өзгөчөлүктөр;
- продукт көрсөткүчтөрү.

Squeeze Testing

Кысып тестирлөө "кысуу" тести деп да аталат. Техниканын аты Netflixке киргизилген. Анын маңызы – адегенде биз бир инстанцияны ишке ашпай калганга чейин реалдуу трафик менен толтурабыз жана ошону менен анын чегин белгилейбиз. Андан кийин биз дагы бир мисалды кошуп, бул жупту жүктөйбүз - кайрадан максималдуу; биз алардын шыпты жана дельтасын биринчи "кысылуу" менен көрөбүз. Ошентип, биз бир эле учурда бир инстанцияны бириктирип, өзгөрүүлөрдүн үлгүсүн эсептейбиз.
"Кысуу" аркылуу сыноо маалыматтары да жалпы метрикалык маалымат базасына агып кетет, анда биз алар менен жасалма жүктөөнүн натыйжаларын байытабыз, ал тургай "синтетиканы" алар менен алмаштырабыз.

Өндүрүш

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

Натыйжада, масштабдоодо биз талдайбыз:
- CPU жана RAM көрсөткүчтөрү,
- кезектеги суроо-талаптардын саны,
- жооп убактысы,
— топтолгон тарыхый маалыматтардын негизинде болжолдоо.

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

кызмат

Микросервис ишке киргизилгенден кийин, биз ага триггерлерди кошо алабыз.

Бул жерде триггерлер пайда болгон типтүү кырдаалдар.
— Потенциалдуу кооптуу миграциялар аныкталды.
— Коопсуздук жаңыртуулары чыгарылды.
— Кызматтын өзү көптөн бери жаңылана элек.
— Кызматтын жүктөмү байкаларлык азайып кетти же анын кээ бир продукциясынын көрсөткүчтөрү нормалдуу диапазондон тышкары.
— Кызмат мындан ары жаңы платформа талаптарына жооп бербейт.

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

Куралдар тактасы

Кыскача айтканда, башкаруу панели биздин бүт PaaS башкаруу панели болуп саналат.

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

жалпы

PaaSти киргизүүдөн мурун, жаңы иштеп чыгуучу өндүрүштө микросервисти ишке киргизүү үчүн зарыл болгон бардык куралдарды түшүнүүгө бир нече жума сарпташы мүмкүн: Kubernetes, Helm, биздин ички TeamCity өзгөчөлүктөрү, маалымат базаларына жана кэштерге катага чыдамдуу туташууларды орнотуу ж.б.у.с. Ыкчам баштоону окуу жана кызматтын өзүн түзүү үчүн бир нече саат талап кылынат.

Мен HighLoad++ 2018 үчүн бул тема боюнча отчет бердим, аны көрө аласыз видео и презентация.

Аягына чейин окугандар үчүн бонустук трек

Авитодо биз иштеп чыгуучулар үчүн үч күндүк ички тренинг уюштуруп жатабыз Крис Ричардсон, микросервис архитектурасы боюнча эксперт. Биз бул посттун окурмандарынын бирине катышуу мүмкүнчүлүгүн бергибиз келет. бул Тренинг программасы жарыяланды.

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

Сиз катышуу үчүн арыз бере аласыз бул Google формасында. Сизден - эмне үчүн тренингге барышыңыз керек деген суроого жооп жана сиз менен кантип байланышуу керектиги тууралуу маалымат. Англисче жооп бериңиз, анткени тренингге катыша турган катышуучуну Крис өзү тандайт.
Биз тренингдин катышуучусунун атын ушул посттун жаңыртуусунда жана Avito социалдык тармактарында иштеп чыгуучулар үчүн жарыялайбыз (AvitoTech in Facebook, VKontakte, Twitter) 19-июлдан кечиктирбестен.

Source: www.habr.com