Hello! Jenengku Vadim Madison, aku mimpin pangembangan Platform Sistem Avito. Wis ngandika luwih saka sapisan carane kita ing perusahaan obah saka arsitektur monolithic kanggo microservices. Iku wektu kanggo nuduhake carane kita wis rubah prasarana kita kanggo entuk paling metu saka microservices lan nyegah awake dhewe saka ilang ing. Kepiye PaaS mbantu kita ing kene, kepiye nyederhanakake penyebaran lan nyuda nggawe layanan mikro dadi siji klik - maca terus. Ora kabeh sing dakcritakake ing ngisor iki ditindakake kanthi lengkap ing Avito, sawetara yaiku cara ngembangake platform kita.

(Lan ing pungkasan artikel iki, aku bakal ngomong babagan kesempatan kanggo rawuh ing seminar telung dina saka ahli arsitektur microservice Chris Richardson).

Carane kita teka menyang microservices

Avito minangka salah sawijining situs klasifikasi paling gedhe ing donya; luwih saka 15 yuta iklan anyar diterbitake saben dina. Backend kita nampa luwih saka 20 ewu panjalukan saben detik. Saiki kita duwe sawetara atus layanan mikro.

Kita wis mbangun arsitektur microservice kanggo sawetara taun saiki. Carane persis - kolega kita ing rinci marang ing bagean kita ing RIT ++ 2017. Ing CodeFest 2017 (ndeleng. видео), Sergey Orlov lan Mikhail Prokopchuk nerangake kanthi rinci kenapa kita butuh transisi menyang layanan mikro lan peran apa sing dimainake Kubernetes ing kene. Saiki, kita nindakake kabeh kanggo nyuda biaya skala sing ana ing arsitektur kasebut.

Kaping pisanan, kita ora nggawe ekosistem sing bakal mbantu kita ngembangake lan ngluncurake layanan mikro kanthi lengkap. Dheweke mung ngumpulake solusi sumber terbuka sing wicaksana, diluncurake ing omah lan ngajak pangembang kanggo ngatasi. Akibaté, dheweke lunga menyang rolas panggonan (dashboard, layanan internal), banjur dadi kuwat ing kepinginan kanggo Cut kode cara lawas, ing monolith a. Werna ijo ing diagram ing ngisor iki nuduhake apa sing ditindakake pangembang kanthi cara siji utawa liyane nganggo tangane dhewe, lan warna kuning nuduhake otomatisasi.

Saiki ing utilitas PaaS CLI, layanan anyar digawe kanthi siji printah, lan database anyar ditambahake karo loro liyane lan disebarake menyang Stage.

Kepiye cara ngatasi jaman "fragmentasi layanan mikro"

Kanthi arsitektur monolitik, kanggo konsistensi owah-owahan ing prodhuk, pangembang dipeksa ngerteni apa sing kedadeyan karo tanggane. Nalika nggarap arsitektur anyar, konteks layanan ora gumantung maneh.

Kajaba iku, supaya arsitektur layanan mikro bisa efektif, akeh proses sing kudu ditindakake, yaiku:

• logging;
• panjalukan nelusuri (Jaeger);
• panggabungan kesalahan (Sentry);
• status, pesen, acara saka Kubernetes (Proses Aliran Acara);
• watesan balapan / pemutus sirkuit (sampeyan bisa nggunakake Hystrix);
• kontrol panyambungan layanan (kita nggunakake Netramesh);
• ngawasi (Grafana);
• perakitan (TeamCity);
• komunikasi lan kabar (Slack, email);
• nelusuri tugas; (Jira)
• preparation saka dokumentasi.

Kanggo mesthekake yen sistem ora ilang integritas lan tetep efektif minangka timbangan, kita rethought organisasi microservices ing Avito.

Carane kita ngatur microservices

Bantuan ing ngisor iki kanggo ngetrapake "kabijakan partai" sing manunggal ing antarane akeh layanan mikro Avito:

• mbagi infrastruktur dadi lapisan;
• Konsep Platform minangka Layanan (PaaS);
• ngawasi kabeh sing kedadeyan karo microservices.

Lapisan abstraksi infrastruktur kalebu telung lapisan. Ayo pindhah saka ndhuwur menyang ngisor.

A. Top - bolong layanan. Ing wiwitan, kita nyoba Istio, nanging ternyata nggunakake sumber daya sing akeh banget, sing larang banget kanggo volume kita. Mulane, insinyur senior ing tim arsitektur Alexander Lukyanchenko ngembangake solusi dhewe - Netramesh (kasedhiya ing Open Source), sing saiki digunakake ing produksi lan nggunakake sumber daya kaping pirang-pirang kurang saka Istio (nanging ora nindakake kabeh sing bisa dibanggakake Istio).
B. Sedheng - Kubernetes. Kita nyebar lan ngoperasikake layanan mikro.
C. Ngisor - logam gundhul. Kita ora nggunakake mega utawa barang kaya OpenStack, nanging gumantung ing logam kosong.

Kabeh lapisan digabungake dening PaaS. Lan platform iki, ing siji, kasusun saka telung bagean.

I. Generator, dikontrol liwat sarana CLI. Dheweke sing mbantu pangembang nggawe layanan mikro kanthi cara sing bener lan kanthi minimal gaweyan.

II. Kolektor gabungan kanthi kontrol kabeh alat liwat dashboard umum.

III. Lumbung. Nyambung karo panjadwal sing kanthi otomatis nyetel pemicu kanggo tumindak sing penting. Thanks kanggo sistem kasebut, ora ana tugas sing ora kejawab mung amarga ana sing lali nyetel tugas ing Jira. Kita nggunakake alat internal sing disebut Atlas kanggo iki.

Implementasi layanan mikro ing Avito uga ditindakake miturut skema siji, sing nyederhanakake kontrol ing saben tahap pangembangan lan rilis.

Kepiye cara kerja pipa pangembangan microservice standar?

Umumé, chain nggawe microservice katon kaya iki:

CLI-push → Integrasi Terus-terusan → Panggang → Deploy → Tes buatan → Tes Canary → Tes Squeeze → Produksi → Maintenance.

Ayo dadi liwat persis ing urutan iki.

CLI-push

• Nggawe microservice.
Kita berjuang nganti suwe kanggo ngajari saben pangembang carane nindakake layanan mikro. Iki kalebu nulis instruksi rinci ing Confluence. Nanging skema kasebut diganti lan ditambah. Asil kasebut yaiku ana bottleneck ing wiwitan perjalanan: butuh wektu luwih akeh kanggo miwiti layanan mikro, lan isih ana masalah nalika nggawe.

Pungkasane, kita nggawe sarana CLI sing prasaja sing ngotomatisasi langkah-langkah dhasar nalika nggawe layanan mikro. Nyatane, iki ngganti push git pisanan. Mangkene apa sing ditindakake dheweke.

- Nggawe layanan miturut cithakan - langkah demi langkah, ing mode "wisaya". Kita duwe template kanggo basa pamrograman utama ing mburi Avito: PHP, Golang lan Python.

- Siji printah ing wektu deploys lingkungan kanggo pangembangan lokal ing mesin tartamtu - Minikube dibukak, denah Helm kanthi otomatis digawe lan dibukak ing kubernetes lokal.

- Nyambungake database sing dibutuhake. Pangembang ora perlu ngerti IP, login lan sandhi kanggo entuk akses menyang database sing dibutuhake - dadi lokal, ing Stage, utawa ing produksi. Menapa malih, database disebarake langsung ing konfigurasi fault-tolerant lan kanthi imbangan.

- Iku performs manggon Déwan dhewe. Ayo dadi pangembang mbenerake soko ing microservice liwat IDE kang. Utilitas ndeleng owah-owahan ing sistem file lan, adhedhasar, mbangun maneh aplikasi (kanggo Golang) lan miwiti maneh. Kanggo PHP, kita mung nerusake direktori ing jero kubus lan ana live-reload dijupuk "otomatis".

- Ngasilake tes otomatis. Ing wangun kosong, nanging cukup cocok kanggo nggunakake.

• panyebaran layanan mikro.

Nyebarake layanan mikro biyen dadi tugas kanggo kita. Ing ngisor iki dibutuhake:

I. Dockerfile.

II. Konfigurasi.
III. Bagan helm, sing dhewe rumit lan kalebu:

- denah dhewe;
- cithakan;
- nilai tartamtu sing njupuk menyang akun lingkungan beda.

Kita wis ngilangi rasa lara saka ngolah ulang manifes Kubernetes supaya saiki digawe kanthi otomatis. Nanging sing paling penting, dheweke nyederhanakake penyebaran nganti watesan. Wiwit saiki kita duwe Dockerfile, lan pangembang nulis kabeh konfigurasi ing siji file app.toml singkat.

Ya, lan ing app.toml dhewe ora ana sing kudu ditindakake sajrone sedina. Kita nemtokake ngendi lan carane akeh salinan layanan kanggo mundhakaken (ing server dev, ing pementasan, ing produksi), lan nunjukaké dependensi. Wigati ukuran baris = "cilik" ing blok [mesin]. Iki minangka watesan sing bakal diwenehake menyang layanan liwat Kubernetes.

Banjur, adhedhasar konfigurasi, kabeh denah Helm sing dibutuhake digawe kanthi otomatis lan sambungan menyang database digawe.

• Validasi dhasar. Pemeriksaan kasebut uga otomatis.
Perlu kanggo nglacak:
- ana Dockerfile;
- ana app.toml;
- ana dokumentasi kasedhiya?
- apa gumantung ing urutan?
- apa aturan tandha wis disetel.
Kanggo titik pungkasan: pemilik layanan kasebut dhewe nemtokake metrik produk sing kudu dipantau.

• Preparation saka dokumentasi.
Isih wilayah masalah. Iku misale jek sing paling ketok, nanging ing wektu sing padha uga rekaman "asring lali", lan mulane link ngrugekke ing chain.
Perlu ana dokumentasi kanggo saben layanan mikro. Iku kalebu pamblokiran ing ngisor iki.

I. gambaran Brief saka layanan. Secara harfiah sawetara ukara babagan apa sing ditindakake lan kenapa dibutuhake.

II. Link diagram arsitektur. Penting, kanthi cepet, gampang dingerteni, umpamane, apa sampeyan nggunakake Redis kanggo caching utawa minangka nyimpen data utama ing mode terus-terusan. Ing Avito saiki iki minangka link menyang Confluence.

III. Runbook. Pandhuan singkat babagan miwiti layanan lan kerumitan nangani.

IV. FAQ, ing ngendi iku bakal apik kanggo antisipasi masalah sing kolega bisa nemokke nalika nggarap layanan.

V. Katrangan endpoints kanggo API. Yen dumadakan sampeyan ora nemtokake tujuan, kolega sing layanan mikro sing ana gandhengane karo sampeyan mesthi bakal mbayar. Saiki kita nggunakake Swagger lan solusi sing diarani ringkes kanggo iki.

VI. Label. Utawa spidol sing nuduhake produk, fungsi, utawa divisi struktural saka perusahaan layanan kasebut. Dheweke mbantu sampeyan ngerti kanthi cepet, contone, apa sampeyan ngethok fungsi sing diluncurake kolega kanggo unit bisnis sing padha seminggu kepungkur.

VII. Pamilik utawa pamilik layanan. Umume kasus, iku - utawa wong-wong mau - bisa ditemtokake kanthi otomatis nggunakake PaaS, nanging supaya aman, kita mbutuhake pangembang kanggo nemtokake kanthi manual.

Pungkasan, praktik sing apik kanggo mriksa dokumentasi, padha karo review kode.

Integrasi Integrasi

• Nyiapake repositori.
• Nggawe pipa ing TeamCity.
• Nyetel hak.
• Telusuri pamilik layanan. Ana skema hibrida ing kene - menehi tandha manual lan otomatisasi minimal saka PaaS. Skema otomatis gagal nalika layanan ditransfer kanggo dhukungan menyang tim pangembangan liyane utawa, contone, yen pangembang layanan mandheg.
• Ndhaptar layanan ing Atlas (ndeleng ndhuwur). Kanthi kabeh sing nduweni lan dependensi.
• Priksa migrasi. Kita mriksa manawa ana sing bisa mbebayani. Contone, ing salah siji saka wong-wong mau, tabel alter utawa liyane muncul sing bisa ngilangi kompatibilitas skema data ing antarane versi layanan sing beda-beda. Banjur migrasi ora dileksanakake, nanging diselehake ing langganan - PaaS kudu menehi tandha marang pemilik layanan nalika aman kanggo nggunakake.

Panggang

Tahap sabanjure yaiku layanan kemasan sadurunge penyebaran.

• Nggawe aplikasi. Miturut klasik - ing gambar Docker.
• Generasi grafik Helm kanggo layanan kasebut lan sumber daya sing ana gandhengane. Kalebu kanggo database lan cache. Padha digawe kanthi otomatis miturut app.toml config sing digawe ing tataran CLI-push.
• Nggawe tiket kanggo admin kanggo mbukak port (yen dibutuhake).
• Nglakokake tes unit lan ngitung jangkoan kode. Yen jangkoan kode ana ing sangisore ambang sing ditemtokake, kemungkinan layanan kasebut ora bakal luwih maju - kanggo panyebaran. Yen ana ing ambang sing bisa ditampa, layanan kasebut bakal diwenehi koefisien "pessimizing": banjur, yen ora ana perbaikan ing indikator sajrone wektu, pangembang bakal nampa kabar yen ora ana kemajuan babagan tes ( lan ana sing kudu ditindakake).
• Akuntansi kanggo watesan memori lan CPU. Kita utamane nulis layanan mikro ing Golang lan mbukak ing Kubernetes. Mula, siji subtlety sing ana gandhengane karo keanehan basa Golang: kanthi standar, nalika miwiti, kabeh intine ing mesin digunakake, yen sampeyan ora nyetel variabel GOMAXPROCS kanthi jelas, lan nalika sawetara layanan kasebut diluncurake ing mesin sing padha, mula bakal diwiwiti. kanggo saingan kanggo sumber daya, interfering karo saben liyane. Grafik ing ngisor iki nuduhake carane owah-owahan wektu eksekusi yen sampeyan mbukak aplikasi tanpa pratelan lan ing lomba kanggo mode sumber daya. (Sumber grafik yaiku kene).

Wektu eksekusi, kurang luwih apik. Maksimum: 643ms, minimal: 42ms. Foto kasebut bisa diklik.

Wektu kanggo operasi, kurang luwih apik. Maksimum: 14091 ns, minimal: 151 ns. Foto kasebut bisa diklik.

Ing tahap persiapan perakitan, sampeyan bisa nyetel variabel iki kanthi tegas utawa sampeyan bisa nggunakake perpustakaan automaxprocs saka wong lanang saka Uber.

nyebarake

• Konvensi mriksa. Sadurunge miwiti ngirim rakitan layanan menyang lingkungan sing dikarepake, sampeyan kudu mriksa ing ngisor iki:
- titik pungkasan API.
- Selaras karo respon titik pungkasan API karo skema.
- Format log.
- Nyetel header kanggo panjaluk menyang layanan (saiki ditindakake dening netramesh)
- Nyetel token pemilik nalika ngirim pesen menyang bis acara. Iki dibutuhake kanggo nglacak konektivitas layanan ing bus. Sampeyan bisa ngirim data idempotent menyang bis, sing ora nambah konektivitas layanan (sing apik), lan data bisnis sing nguatake konektivitas layanan (sing ala banget!). Lan nalika konektivitas iki dadi masalah, pangerten sing nulis lan maca bis mbantu misahake layanan kanthi bener.

Ora akeh konvensi ing Avito, nanging kolam renang saya tambah akeh. Persetujuan sing luwih akeh kasedhiya ing wangun sing bisa dingerteni lan dingerteni tim, luwih gampang kanggo njaga konsistensi ing antarane layanan mikro.

Tes sintetik

• Pengujian loop tertutup. Kanggo iki kita saiki nggunakake open source Hoverfly.io. Kaping pisanan, nyathet beban nyata ing layanan kasebut, banjur - mung ing daur ulang sing ditutup - niru.

• Stress Testing. Kita nyoba kanggo nggawa kabeh layanan kanggo kinerja optimal. Lan kabeh versi saben layanan kudu tundhuk testing mbukak - kanthi cara iki kita bisa ngerti kinerja layanan saiki lan prabédan karo versi sadurungé saka layanan padha. Yen, sawise nganyari layanan, kinerja mudhun siji lan setengah kaping, iki minangka sinyal sing jelas kanggo sing nduweni: sampeyan kudu digali menyang kode lan mbenerake kahanan.
Kita nggunakake data sing diklumpukake, umpamane, kanggo ngetrapake skala otomatis kanthi bener lan, ing pungkasan, umume ngerti kepiye skala layanan kasebut.

Sajrone testing beban, kita mriksa apa konsumsi sumber daya ketemu watesan sing disetel. Lan kita fokus utamane ing ekstrem.

a) Kita ndeleng total beban.
- Cilik banget - paling kamungkinan ana sing ora bisa digunakake yen beban tiba-tiba mudhun kaping pirang-pirang.
- Gedhe banget - optimasi dibutuhake.

b) Kita ndeleng cutoff miturut RPS.
Ing kene kita ndeleng prabédan antarane versi saiki lan sing sadurunge lan jumlah total. Contone, yen layanan mrodhuksi 100 rps, iku salah siji sing ditulis kurang apik, utawa iki specificity, nanging ing kasus, iku alesan kanggo katon ing layanan banget rapet.
Yen, ing nalisir, ana akeh banget RPS, banjur mbok menawa ana sawetara jenis bug lan sawetara endpoints wis mandheg nglakokaké payload, lan sawetara liyane mung micu. return true;

Tes kenari

Sawise lulus tes sintetik, kita nyoba layanan mikro ing sawetara pangguna. Kita miwiti kanthi ati-ati, kanthi bagean cilik saka pamirsa sing dituju layanan - kurang saka 0,1%. Ing tahap iki, penting banget yen metrik teknis lan produk sing bener kalebu ing pemantauan supaya bisa nuduhake masalah ing layanan kanthi cepet. Wektu minimal kanggo tes kenari yaiku 5 menit, sing utama yaiku 2 jam. Kanggo layanan rumit, kita nyetel wektu kanthi manual.
Kita nganalisa:
- metrik khusus basa, utamane, buruh php-fpm;
- kasalahan ing Sentry;
- status respon;
- wektu nanggepi, pas lan rata-rata;
- latensi;
- pangecualian, diproses lan ora ditangani;
- metrik produk.

Tes Squeeze

Tes Squeeze uga diarani tes "squeezing". Jeneng teknik kasebut dikenalake menyang Netflix. Intine yaiku pisanan kita ngisi siji conto kanthi lalu lintas nyata nganti titik kegagalan lan kanthi mangkono nyetel watesan. Banjur kita nambah conto liyane lan mbukak pasangan iki - maneh maksimal; kita ndeleng langit-langit lan delta karo pisanan "meremet". Dadi, kita nyambungake siji-sijine lan ngitung pola owah-owahan.
Data test liwat "squeezing" uga mili menyang database metrik umum, ngendi kita salah siji enrich asil mbukak gawean karo wong-wong mau, utawa malah ngganti "sintetik" karo wong-wong mau.

Produksi

• Skala. Nalika kita muter metu layanan kanggo produksi, kita ngawasi carane timbangan. Ing pengalaman kita, ngawasi mung indikator CPU ora efektif. Skala otomatis kanthi benchmarking RPS ing wangun murni, nanging mung kanggo layanan tartamtu, kayata streaming online. Dadi kita katon dhisik ing metrik produk khusus aplikasi.

Akibaté, nalika skala kita nganalisa:
- Indikator CPU lan RAM,
- jumlah panjalukan ing antrian,
- wektu nanggepi,
- ramalan adhedhasar data historis akumulasi.

Nalika skala layanan, iku uga penting kanggo ngawasi dependensi supaya kita ora skala layanan pisanan ing chain, lan sing diakses gagal ing mbukak. Kanggo netepake beban sing bisa ditampa kanggo kabeh layanan, kita ndeleng data historis layanan gumantung "paling cedhak" (adhedhasar kombinasi indikator CPU lan RAM, ditambah karo metrik khusus aplikasi) lan mbandhingake karo data historis. saka layanan wiwitan, lan sateruse ing saindhenging "rantai ketergantungan" ", saka ndhuwur nganti ngisor.

Layanan

Sawise microservice dileksanakake, kita bisa masang pemicu.

Ing ngisor iki kahanan khas sing nyebabake pemicu.
- Migrasi sing bisa mbebayani dideteksi.
- Nganyari keamanan wis dirilis.
- Layanan kasebut dhewe wis suwe ora dianyari.
- Beban ing layanan wis suda utawa sawetara metrik produk ing njaba kisaran normal.
- Layanan kasebut ora nyukupi syarat platform anyar.

Sawetara pemicu tanggung jawab kanggo stabilitas operasi, sawetara - minangka fungsi pangopènan sistem - umpamane, sawetara layanan wis suwe ora diluncurake lan gambar dhasar wis mandheg ngliwati pemeriksaan keamanan.

Dashboard

Ing cendhak, dashboard minangka panel kontrol kabeh PaaS kita.

• Titik siji informasi babagan layanan kasebut, kanthi data babagan jangkoan tes, jumlah gambar, jumlah salinan produksi, versi, lsp.
• Alat kanggo nyaring data miturut layanan lan label (penanda saka unit bisnis, fungsi produk, lsp.)
• Alat kanggo integrasi karo alat infrastruktur kanggo nelusuri, logging, lan ngawasi.
• Siji titik dokumentasi layanan.
• Sudut pandang siji saka kabeh acara ing layanan.

Total

Sadurunge ngenalake PaaS, pangembang anyar bisa nglampahi sawetara minggu kanggo mangerteni kabeh alat sing dibutuhake kanggo ngluncurake layanan mikro ing produksi: Kubernetes, Helm, fitur TeamCity internal kita, nyetel sambungan menyang database lan cache kanthi cara toleran kesalahan, lsp. njupuk sawetara jam kanggo maca wiwitan cepet lan nggawe layanan dhewe.

Aku menehi laporan babagan topik iki kanggo HighLoad ++ 2018, sampeyan bisa nonton видео и presentasi.

Bonus trek kanggo sing maca kanggo mburi

Kita ing Avito ngatur latihan internal telung dina kanggo pangembang saka Chris Richardson, pakar ing arsitektur microservice. Kita pengin menehi kesempatan kanggo melu ing salah sawijining pembaca postingan iki. iku Program latihan wis dikirim.

Latihan kasebut bakal ditindakake wiwit 5 nganti 7 Agustus ing Moskow. Iki minangka dina kerja sing bakal dikuwasani kanthi lengkap. Nedha awan lan latihan bakal ana ing kantor kita, lan peserta sing dipilih bakal mbayar lelungan lan akomodasi dhewe.

Sampeyan bisa nglamar kanggo partisipasi ing formulir google iki. Saka sampeyan - jawaban kanggo pitakonan kenapa sampeyan kudu melu latihan lan informasi babagan cara ngubungi sampeyan. Wangsulane nganggo basa Inggris, amarga Chris bakal milih peserta sing bakal melu latihan dhewe.
Kita bakal ngumumake jeneng peserta latihan ing nganyari kirim iki lan ing jaringan sosial Avito kanggo pangembang (AvitoTech ing Facebook, Вконтакте, Twitter) ora luwih saka 19 Juli.

Source: www.habr.com