Artikel ini mengandungi beberapa corak biasa untuk membantu jurutera bekerja dengan perkhidmatan berskala besar yang diakses oleh berjuta-juta pengguna.
Mengikut pengalaman penulis, ini bukanlah senarai yang lengkap, tetapi sememangnya berkesan nasihat. Jadi, mari kita mulakan.
Diterjemah dengan sokongan .
Tahap pertama
Langkah-langkah yang disenaraikan di bawah adalah agak mudah untuk dilaksanakan tetapi mempunyai impak yang tinggi. Jika anda belum mencubanya sebelum ini, anda akan terkejut dengan peningkatan yang ketara.
Infrastruktur sebagai kod
Bahagian pertama nasihat adalah untuk melaksanakan infrastruktur sebagai kod. Ini bermakna anda mesti mempunyai cara terprogram untuk menggunakan keseluruhan infrastruktur. Kedengarannya rumit, tetapi kita sebenarnya bercakap tentang kod berikut:
Penggunaan 100 mesin maya
- dengan Ubuntu
- 2 GB RAM setiap satu
- mereka akan mempunyai kod berikut
- dengan parameter ini
Anda boleh menjejaki perubahan pada infrastruktur anda dan kembali kepada perubahan tersebut dengan cepat menggunakan kawalan versi.
Orang moden dalam diri saya berkata anda boleh menggunakan Kubernetes/Docker untuk melakukan semua perkara di atas, dan dia betul.
Selain itu, anda boleh menyediakan automasi menggunakan Chef, Puppet atau Terraform.
Integrasi dan Penyampaian Berterusan
Untuk mencipta perkhidmatan berskala, adalah penting untuk mempunyai saluran paip binaan dan ujian untuk setiap permintaan tarik. Walaupun ujian itu sangat mudah, ia sekurang-kurangnya akan memastikan kod yang anda gunakan disusun.
Setiap kali pada peringkat ini anda menjawab soalan: adakah perhimpunan saya akan menyusun dan lulus ujian, adakah ia sah? Ini mungkin kelihatan seperti bar rendah, tetapi ia menyelesaikan banyak masalah.
Tiada yang lebih indah daripada melihat kutu ini
Untuk teknologi ini, anda boleh menilai Github, CircleCI atau Jenkins.
Pengimbang Beban
Jadi, kami ingin menjalankan pengimbang beban untuk mengubah hala lalu lintas dan memastikan beban yang sama pada semua nod atau perkhidmatan diteruskan sekiranya berlaku kegagalan:
Pengimbang beban biasanya berfungsi dengan baik untuk mengagihkan trafik. Amalan terbaik adalah mengimbangi terlebih dahulu supaya anda tidak mengalami satu pun titik kegagalan.
Biasanya, pengimbang beban dikonfigurasikan dalam awan yang anda gunakan.
RayID, ID korelasi atau UUID untuk permintaan
Pernahkah anda mengalami ralat aplikasi dengan mesej seperti ini: βSesuatu telah berlaku. Simpan id ini dan hantar kepada pasukan sokongan kami"?
Pengecam unik, ID korelasi, RayID atau mana-mana variasi, ialah pengecam unik yang membolehkan anda menjejak permintaan sepanjang kitaran hayatnya. Ini membolehkan anda menjejaki keseluruhan laluan permintaan dalam log.
Pengguna membuat permintaan kepada sistem A, kemudian A menghubungi B, yang menghubungi C, menyimpannya dalam X, dan kemudian permintaan itu dikembalikan kepada A
Jika anda menyambung dari jauh ke mesin maya dan cuba menjejaki laluan permintaan (dan mengaitkan secara manual panggilan yang sedang dibuat), anda akan menjadi gila. Mempunyai pengecam unik menjadikan hidup lebih mudah. Ini adalah salah satu perkara paling mudah yang boleh anda lakukan untuk menjimatkan masa apabila perkhidmatan anda berkembang.
Tahap pertengahan
Nasihat di sini adalah lebih kompleks daripada yang sebelumnya, tetapi alat yang betul menjadikan tugas lebih mudah, memberikan pulangan pelaburan walaupun untuk syarikat kecil dan sederhana.
Pembalakan berpusat
tahniah! Anda telah menggunakan 100 mesin maya. Keesokan harinya, Ketua Pegawai Eksekutif datang dan mengadu tentang kesilapan yang dia terima semasa menguji perkhidmatan. Ia melaporkan ID sepadan yang kami bincangkan di atas, tetapi anda perlu menyemak log 100 mesin untuk mencari mesin yang menyebabkan ranap. Dan ia perlu dicari sebelum pembentangan esok.
Walaupun ini kelihatan seperti pengembaraan yang menyeronokkan, sebaiknya pastikan anda mempunyai keupayaan untuk mencari semua majalah di satu tempat. Saya menyelesaikan masalah pemusatan log menggunakan fungsi terbina dalam timbunan ELK: ia menyokong koleksi log boleh dicari. Ini benar-benar akan membantu menyelesaikan masalah mencari jurnal tertentu. Sebagai bonus, anda boleh membuat carta dan perkara menyeronokkan lain seperti itu.
Fungsi tindanan ELK
Ejen pemantauan
Memandangkan perkhidmatan anda telah beroperasi dan berjalan, anda perlu memastikan ia berjalan dengan lancar. Cara terbaik untuk melakukan ini ialah menjalankan beberapa ejen, yang berfungsi selari dan pastikan ia berfungsi dan operasi asas dilakukan.
Pada ketika ini anda menyemaknya binaan berjalan terasa baik dan berfungsi dengan baik.
Untuk projek kecil hingga sederhana, saya mengesyorkan Posman untuk memantau dan mendokumentasikan API. Tetapi secara umum, anda hanya ingin memastikan anda mempunyai cara untuk mengetahui apabila gangguan telah berlaku dan dimaklumkan tepat pada masanya.
Autoscaling bergantung pada beban
Ia sangat mudah. Jika anda mempunyai permintaan servis VM dan ia menghampiri 80% penggunaan memori, anda boleh sama ada meningkatkan sumbernya atau menambah lebih banyak VM pada kluster. Pelaksanaan automatik operasi ini sangat baik untuk perubahan kuasa anjal di bawah beban. Tetapi anda harus sentiasa berhati-hati tentang jumlah wang yang anda belanjakan dan tetapkan had yang munasabah.
Dengan kebanyakan perkhidmatan awan, anda boleh mengkonfigurasinya untuk autoscale menggunakan lebih banyak pelayan atau pelayan yang lebih berkuasa.
Sistem eksperimen
Cara yang baik untuk melancarkan kemas kini dengan selamat ialah dapat menguji sesuatu untuk 1% pengguna selama sejam. Sudah tentu, anda telah melihat mekanisme sedemikian dalam tindakan. Sebagai contoh, Facebook menunjukkan bahagian penonton dengan warna yang berbeza atau menukar saiz fon untuk melihat cara pengguna melihat perubahan tersebut. Ini dipanggil ujian A/B.
Malah mengeluarkan ciri baharu boleh dimulakan sebagai percubaan dan kemudian menentukan cara mengeluarkannya. Anda juga mendapat keupayaan untuk "mengingat" atau menukar konfigurasi dengan pantas berdasarkan fungsi yang menyebabkan kemerosotan dalam perkhidmatan anda.
Tahap lanjutan
Berikut adalah petua yang agak sukar untuk dilaksanakan. Anda mungkin memerlukan lebih sedikit sumber, jadi syarikat kecil atau sederhana akan menghadapi kesukaran untuk menguruskan perkara ini.
Kerahan biru-hijau
Inilah yang saya panggil cara "Erlang" terungkap. Erlang digunakan secara meluas apabila syarikat telefon muncul. Suis lembut mula digunakan untuk menghalakan panggilan telefon. Tujuan utama perisian pada suis ini adalah untuk tidak menggugurkan panggilan semasa naik taraf sistem. Erlang mempunyai cara yang bagus untuk memuatkan modul baharu tanpa merosakkan modul sebelumnya.
Langkah ini bergantung pada kehadiran pengimbang beban. Mari bayangkan anda mempunyai versi N perisian anda, dan kemudian anda mahu menggunakan versi N+1.
Anda kita boleh hentikan sahaja perkhidmatan dan lancarkan versi seterusnya pada masa yang sesuai untuk pengguna anda dan dapatkan sedikit masa berhenti. Tetapi andaikan anda mempunyai benar-benar syarat SLA yang ketat. Jadi, SLA 99,99% bermakna anda boleh pergi ke luar talian sahaja sebanyak 52 minit setahun.
Jika anda benar-benar ingin mencapai penunjuk sedemikian, anda memerlukan dua penempatan pada masa yang sama:
- yang ada sekarang (N);
- versi seterusnya (N+1).
Anda memberitahu pengimbang beban untuk mengubah hala peratusan trafik ke versi baharu (N+1) semasa anda memantau regresi secara aktif.
Di sini kami mempunyai penggunaan N hijau yang berfungsi dengan baik. Kami cuba beralih ke versi seterusnya bagi penggunaan ini
Mula-mula kami menghantar ujian yang sangat kecil untuk melihat sama ada penggunaan N+1 kami berfungsi dengan jumlah trafik yang kecil:
Akhir sekali, kami mempunyai satu set semakan automatik yang akhirnya kami jalankan sehingga penggunaan kami selesai. Jika awak sangat sangat berhati-hati, anda juga boleh menyimpan penggunaan N anda selama-lamanya untuk pemulangan semula yang cepat sekiranya berlaku regresi yang buruk:
Jika anda ingin pergi ke tahap yang lebih maju, biarkan segala-galanya dalam penggunaan biru-hijau berjalan secara automatik.
Pengesanan anomali dan mitigasi automatik
Memandangkan anda mempunyai pembalakan berpusat dan pengumpulan log yang baik, anda sudah boleh menetapkan matlamat yang lebih tinggi. Sebagai contoh, proaktif meramalkan kegagalan. Fungsi dikesan pada monitor dan dalam log dan pelbagai gambar rajah dibina - dan anda boleh meramalkan terlebih dahulu perkara yang akan berlaku:
Setelah anomali dikesan, anda mula memeriksa beberapa petunjuk yang disediakan oleh perkhidmatan tersebut. Sebagai contoh, lonjakan dalam beban CPU mungkin menunjukkan bahawa cakera keras gagal, manakala lonjakan permintaan mungkin menunjukkan bahawa anda perlu meningkatkan skala. Data perangkaan jenis ini membolehkan anda menjadikan perkhidmatan proaktif.
Dengan cerapan ini, anda boleh membuat skala dalam mana-mana dimensi dan secara proaktif dan reaktif menukar ciri mesin, pangkalan data, sambungan dan sumber lain.
Itu sahaja!
Senarai keutamaan ini akan menjimatkan banyak masalah jika anda meningkatkan perkhidmatan awan.
Pengarang artikel asal menjemput pembaca untuk meninggalkan komen mereka dan membuat perubahan. Artikel itu diedarkan sebagai sumber terbuka, permintaan tarik oleh pengarang .
Apa lagi yang perlu dibaca mengenai topik:
Sumber: www.habr.com