Ringkasan laporan “Apa yang kita ketahui tentang layanan mikro” (HL2018, Avito, Vadim Madison)

Hai% nama pengguna%!

Baru-baru ini, konferensi Highload ++ berakhir (sekali lagi terima kasih kepada seluruh tim penyelenggara dan olegbunin . Itu sangat keren!).

Menjelang konferensi, Alexey fisher mengusulkan untuk membuat kelompok inisiatif “penguntit” di konferensi. Selama laporan, kami menulis catatan kecil yang kami tukarkan. Beberapa catatan ternyata cukup detail dan terperinci.

Komunitas di jejaring sosial secara positif mengevaluasi format ini, jadi saya (dengan izin) memutuskan untuk menerbitkan sinopsis laporan pertama. Jika format ini menarik, maka saya dapat menyiapkan beberapa artikel lagi.

Berkendara

Avito memiliki banyak layanan dan banyak koneksi di antara mereka. Ini menyebabkan masalah:

• Banyak repositori. Sulit untuk mengubah kode di mana saja sekaligus
• Tim dibatasi oleh konteksnya. Tumpang tindih maksimum sedikit dan tidak semua
• Fragmentasi data ditambahkan.

Sejumlah besar elemen infrastruktur:

• Penebangan
• Permintaan Jejak (Jaeger)
• Agregasi Kesalahan (Penjaga)
• Status / Pesan / Acara dari Kubernetes
• Batas ras / Pemutus Arus (Hystrix)
• Konektivitas Layanan (Istio)
• Pengawasan (Grafana)
• Majelis (Teamcity)
• Komunikasi
• Pelacak tugas
• Dokumentasi
• ...

Ada beberapa lapisan, laporan hanya menjelaskan satu (PaaS).

Platform ini memiliki 3 bagian utama:

• Generator dikontrol oleh cli
• Aggregator (pengumpul), yang dikendalikan melalui dashboard
• Penyimpanan dengan pemicu untuk tindakan tertentu.

Pipa Pengembangan Layanan Mikro Standar

CLI-push -> CI -> Bake -> Deploy -> Test -> Canary -> Produksi

CLI-push

Untuk waktu yang lama diajarkan untuk melakukan pengembang yang tepat. Semua sama, itu tetap merupakan titik lemah.

Otomatis melalui utilitas cli yang membantu menciptakan dasar untuk layanan-mikro:

1. Membuat layanan templat (templat untuk sejumlah PL didukung).
2. Secara otomatis menyebarkan infrastruktur untuk pengembangan lokal
3. Menghubungkan database (tidak memerlukan konfigurasi, pengembang tidak memikirkan akses ke database apa pun).
4. Membangun langsung
5. Pembuatan disk autotest.

Konfigurasi dijelaskan dalam file toml.

File contoh:

Validasi

Pemeriksaan validasi dasar:

• Ketersediaan Dockerfile
• app.toml
• Ketersediaan dokumentasi
• Ketergantungan
• Aturan lansiran untuk pemantauan (ditetapkan oleh pemilik layanan)

Dokumentasi

Setiap orang harus memiliki dokumentasi, tetapi hampir tidak ada yang memilikinya

Dokumentasi harus mencakup:

• Deskripsi layanan (pendek)
• Tautan ke diagram arsitektur
• Runbook
• Faq
• Deskripsi API Endpoint
• Label (mengikat produk, fungsionalitas, divisi struktural)
• Pemilik layanan (mungkin ada beberapa, dalam banyak kasus dapat ditentukan secara otomatis).

Dokumentasi perlu ditinjau.

Persiapan pipa

• Repositori memasak
• Membuat saluran pipa di TeamCity
• Kami menetapkan hak
• Kami mencari pemilik (dua, satu tidak dapat diandalkan)
• Daftarkan layanan di Atlas (produk internal)
• Periksa migrasi.

Panggang

• Membangun aplikasi dalam gambar buruh pelabuhan.
• Pembuatan grafik helm untuk layanan itu sendiri dan sumber daya terkait (DB, cache)
• Tiket dibuat untuk administrator untuk membuka port, memori dan pembatasan cpu diperhitungkan.
• Jalankan tes unit. Cakupan kode dipertahankan. Jika di bawah tertentu, maka penyebaran akan berakhir. Jika jangkauan tidak berkembang, notifikasi didorong.

Pencarian pemilik ditentukan oleh dorongan (jumlah dorongan dan jumlah kode di dalamnya).

Jika ada potensi migrasi berbahaya (alter), maka pelatuknya terdaftar di Atlas dan layanannya dikarantina.

Karantina diselesaikan melalui dorongan ke pemilik (dalam mode manual?)

Pemeriksaan Konvensi

Kami memeriksa:

• Titik akhir layanan
• Korespondensi jawaban untuk skema
• Format log
• Pengaturan header (termasuk X-Source-ID saat mengirim pesan ke bus untuk melacak konektivitas melalui bus)

Tes

Pengujian dilakukan dalam loop tertutup (misalnya, hoverfly.io) - beban tipikal dicatat. Kemudian ditiru dalam loop tertutup.

Korespondensi konsumsi sumber daya diperiksa (kami melihat secara terpisah pada kasus-kasus ekstrem - sumber daya terlalu sedikit), terpotong oleh rps.

Pengujian beban juga menunjukkan delta kinerja antar versi.

Tes kenari

Kami memulai peluncuran pada sejumlah kecil pengguna (<0,1%).

Beban minimum 5 menit. 2 jam utama. Kemudian volume pengguna meningkat jika semuanya baik-baik saja.

Kami melihat:

• Metrik produk (pertama-tama) - ada banyak dari mereka (100500)
• Kesalahan Sentry
• Status respons,
• Waktu responden - waktu respons tepat dan rata-rata
• Latensi
• Pengecualian (diproses dan tidak diproses)
• Lebih spesifik untuk bahasa metrik (mis. Pekerja php-fpm)

Tes pemerasan

Pengujian ekstrusi.

Kami memuat pengguna nyata 1 contoh ke titik kegagalan. Kami melihat langit-langitnya. Selanjutnya, tambahkan contoh lain dan muat. Kami melihat langit-langit berikutnya. Kami melihat regresi. Kami memperkaya atau mengganti data dari pengujian beban di Atlas.

Scaling

Hanya cpu yang buruk, Anda perlu menambahkan metrik produk.

Skema terakhir:

• CPU + RAM
• Jumlah permintaan
• Waktu respon
• Ramalan Sejarah

Saat melakukan penskalaan, jangan lupa untuk melihat dependensi layanan. Ingat kaskade penskalaan (level +1). Kami melihat data historis dari layanan inisialisasi.

Opsional

• Penanganan pemicu - migrasi jika tidak ada versi di bawah X yang tersisa
• Layanan belum diperbarui untuk waktu yang lama
• Karantina
• Pembaruan aman

Dasbor

Kami melihat segala sesuatu dari atas dalam bentuk agregat dan menarik kesimpulan.

• Penyaringan layanan dan label
• Integrasi dengan penelusuran, pencatatan, pemantauan
• Dokumentasi layanan titik tunggal
• Satu titik tampilan semua acara layanan

Contoh: