Pada 19 September, metap tematik pertama HUG (Highload ++ User Group)
diadakan di Moskow, yang didedikasikan untuk layanan microser. Laporan "Pengoperasian layanan microser: ukuran sangat penting bahkan jika Anda memiliki Kubernet" disampaikan di mana kami berbagi pengalaman luas Flant dalam proyek pengoperasian dengan arsitektur layanan microser. Pertama-tama, ini akan bermanfaat bagi semua pengembang yang berpikir untuk menerapkan pendekatan ini dalam proyek mereka saat ini atau masa depan.
Kami menyajikan
video dengan laporan (50 menit, jauh lebih informatif daripada artikel), serta ekstrak utama dari itu dalam bentuk teks.
NB: Video dan presentasi juga tersedia di akhir publikasi ini. Pendahuluan
Biasanya cerita yang bagus memiliki plot, plot utama dan denouement. Laporan ini lebih seperti plot, dan tragis. Penting juga untuk dicatat bahwa ini menyediakan tampilan pada
operasi layanan microser.
Saya akan mulai dengan jadwal seperti itu, yang penulisnya (pada 2015)
adalah Martin Fowler:
Ini menunjukkan bagaimana dalam kasus aplikasi monolitik yang telah mencapai nilai tertentu, produktivitas pekerjaan mulai menurun. Layanan Microsoft berbeda karena produktivitas awal dengan mereka lebih rendah, namun, seiring dengan meningkatnya kompleksitas, penurunan efisiensi bagi mereka tidak begitu terlihat.
Saya akan melengkapi grafik ini untuk kasus menggunakan Kubernetes:
Mengapa aplikasi microservice menjadi lebih baik? Karena arsitektur seperti itu mengedepankan persyaratan arsitektur yang serius, yang pada gilirannya tercakup dengan sempurna oleh kemampuan Kubernetes. Di sisi lain, bagian dari fungsi ini juga akan berguna untuk monolit, terutama karena alasan bahwa monolit yang khas saat ini bukanlah monolit (detail akan lebih jauh dalam laporan).
Seperti yang Anda lihat, jadwal akhir (ketika aplikasi monolitik dan microservice dalam infrastruktur dengan Kubernetes) tidak jauh berbeda dari aslinya. Selanjutnya, kita akan berbicara tentang aplikasi yang berjalan menggunakan Kubernetes.
Layanan microser yang berguna dan berbahaya
Dan inilah ide utamanya:
Apa itu arsitektur microservice
normal ? Seharusnya memberi Anda manfaat nyata, meningkatkan efisiensi kerja. Jika Anda kembali ke grafik, ini dia:
Jika Anda menyebutnya
bermanfaat , maka di sisi lain dari grafik akan ada microservice
berbahaya (mengganggu pekerjaan):
Kembali ke "ide utama": apakah layak untuk memercayai pengalaman saya sama sekali? Sejak awal tahun ini, saya telah melihat
85 proyek . Tidak semua dari mereka adalah layanan mikro (sekitar sepertiga hingga setengah dari mereka memiliki arsitektur seperti itu), tetapi ini masih banyak. Kami (perusahaan Flant) sebagai agen outsourcing mengelola untuk melihat berbagai aplikasi yang dikembangkan baik di perusahaan kecil (dengan 5 pengembang) dan yang besar (~ 500 pengembang). Kelebihan lainnya adalah kita melihat bagaimana aplikasi ini hidup dan berkembang selama bertahun-tahun.
Mengapa layanan microser?
Untuk pertanyaan tentang manfaat layanan mikro, Martin Fowler yang telah disebutkan memiliki
jawaban yang sangat spesifik :
- batas modularitas yang jelas;
- penyebaran independen;
- kebebasan memilih teknologi.
Saya banyak berbicara dengan arsitek dan pengembang perangkat lunak dan bertanya mengapa mereka membutuhkan layanan microser. Dan menyusun daftar harapan mereka. Inilah yang terjadi:
Jika Anda menggambarkan "dalam sensasi" beberapa poin, maka:
- batas-batas modul yang jelas: di sini kita memiliki monolit yang mengerikan, dan sekarang semuanya akan ditata dengan rapi di repositori Git, di mana semuanya berada "di rak", tidak dicampur dengan hangat dan lunak;
- Kemandirian penerapan: kami akan dapat meluncurkan layanan secara mandiri, sehingga pengembangan berjalan lebih cepat (mempublikasikan fitur baru secara paralel);
- independensi pengembangan: kami dapat memberikan layanan mikro ini kepada tim / pengembang tersebut, dan yang lainnya, sehingga kami dapat berkembang lebih cepat;
- keandalan yang lebih besar: jika terjadi degradasi parsial (satu microservice dari 20 jatuh), maka hanya satu tombol yang akan berhenti bekerja, dan sistem secara keseluruhan akan terus berfungsi.
Arsitektur layanan mikro yang khas (berbahaya)
Untuk menjelaskan mengapa pada kenyataannya semuanya tidak seperti yang kita harapkan, saya akan menyajikan gambar
kolektif arsitektur layanan mikro berdasarkan pengalaman dari banyak proyek yang berbeda.
Contohnya adalah toko online abstrak yang akan bersaing dengan Amazon atau setidaknya OZON. Arsitektur microservice-nya terlihat seperti ini:
Untuk kombinasi alasan, layanan microser ini ditulis pada platform berbeda:
Karena setiap layanan mikro harus memiliki otonomi, banyak dari mereka memerlukan basis data dan cache mereka sendiri. Arsitektur terakhir adalah sebagai berikut:
Apa konsekuensinya?
Fowler
memiliki artikel tentang hal ini - tentang "pengembalian" untuk menggunakan layanan Microsoft:
Dan kita akan melihat apakah harapan kita terpenuhi.
Hapus batas modul ...
Tetapi
berapa banyak layanan microser yang benar-benar perlu kita perbaiki untuk meluncurkan perubahan? Bisakah kita mencari tahu bagaimana semuanya bekerja tanpa pelacak terdistribusi (setelah semua, setiap permintaan diproses oleh setengah dari layanan microser)?
Ada pola “
benjolan besar lumpur ”, tetapi di sini kita mendapatkan benjolan lumpur yang didistribusikan. Untuk mendukung ini, berikut adalah contoh ilustrasi tentang bagaimana pertanyaan berjalan:
Penerapan Kemerdekaan ...
Secara teknis, ini telah dicapai: kita dapat menggulung masing-masing layanan microser secara terpisah. Namun dalam praktiknya, Anda perlu mempertimbangkan bahwa
banyak layanan microsoft selalu diluncurkan, dan kami harus memperhitungkan
urutan peluncurannya . Dengan cara yang baik, kita umumnya perlu menguji di sirkuit terpisah apakah kita meluncurkan rilis dalam urutan yang benar.
Kebebasan untuk memilih teknologi ...
Dia disana. Patut diingat bahwa seringkali kebebasan berbatasan dengan pelanggaran hukum. Sangat penting di sini untuk tidak memilih teknologi hanya untuk "bermain" dengan mereka.
Kemerdekaan Pembangunan ...
Bagaimana cara membuat rangkaian uji untuk seluruh aplikasi (dari begitu banyak komponen)? Tetapi Anda masih harus mempertahankannya tetap terbaru. Semua ini mengarah pada fakta bahwa
jumlah sebenarnya dari loop tes , yang kita, pada prinsipnya, dapat mengandung,
adalah minimal .
Tetapi untuk menyebarkan semua ini secara lokal? .. Ternyata sering pengembang melakukan pekerjaannya secara independen, tetapi secara acak, karena ia harus menunggu sampai sirkuit untuk pengujian dirilis.
Penskalaan terpisah ...
Ya, tetapi terbatas pada area DBMS yang digunakan. Dalam contoh arsitektur yang diberikan, Cassandra tidak akan memiliki masalah, tetapi MySQL dan PostgreSQL akan memilikinya.
Keandalan lebih ...
Tidak hanya itu, pada kenyataannya, kegagalan satu microservice sering merusak fungsi yang benar dari seluruh sistem, ada juga masalah baru:
sangat sulit untuk membuat setiap kesalahan microservice toleran . Karena layanan microser menggunakan teknologi yang berbeda (memcache, Redis, dll.), Semua orang perlu memikirkan dan mengimplementasikan segalanya, yang tentu saja mungkin, tetapi membutuhkan sumber daya yang besar.
Pengukuran beban ...
Semuanya sangat baik dengan ini.
Ringannya layanan ...
Kami tidak hanya memiliki
overhead jaringan yang besar (kueri DNS, dll.), Tetapi juga karena banyaknya subkueri, kami mulai
mereplikasi data (cache penyimpanan), yang menyebabkan sejumlah besar penyimpanan.
Dan inilah hasil dari memenuhi harapan kita:
Tapi bukan itu saja!
Karena:
- Kemungkinan besar kita membutuhkan bus pesan.
- Bagaimana cara membuat cadangan yang konsisten pada waktu yang tepat? Satu-satunya pilihan nyata adalah mematikan lalu lintas untuk ini. Tetapi bagaimana melakukannya pada produksi?
- Jika kita berbicara tentang mendukung beberapa daerah, maka mengatur keberlanjutan di masing-masing daerah adalah tugas yang sangat memakan waktu.
- Ada masalah membuat perubahan terpusat. Sebagai contoh, jika kita perlu memperbarui versi PHP, maka kita perlu komit ke setiap repositori (dan ada puluhan).
- Peningkatan kompleksitas operasional begitu saja eksponensial.
Apa yang harus dilakukan dengan semua ini?
Mulai dengan aplikasi monolitik . Pengalaman Fowler
menunjukkan bahwa hampir semua aplikasi microservice yang sukses dimulai dengan monolith, yang menjadi terlalu besar, setelah itu rusak. Pada saat yang sama, hampir semua sistem yang dibangun sebagai microservice dari awal mengalami masalah serius cepat atau lambat.
Pemikiran lain yang berharga adalah agar proyek dengan arsitektur microservice berhasil, Anda harus tahu betul
bidang subjek dan cara membuat layanan microser . Dan cara terbaik untuk mengetahui bidang subjek adalah membuat monolit.
Tetapi bagaimana jika kita sudah berada dalam situasi ini?
Langkah pertama untuk menyelesaikan masalah adalah dengan menyetujuinya dan memahami bahwa itu adalah masalah, bahwa kita tidak lagi ingin menderita.
Jika dalam kasus monolit yang terlalu banyak (ketika kita kehabisan kesempatan untuk membeli sumber daya untuk itu), kita memotongnya, maka dalam kasus ini kita mendapatkan cerita yang berlawanan: ketika layanan mikro yang berlebihan tidak membantu lagi, tetapi mengganggu -
memotong kelebihan dan memperbesar !
Misalnya, untuk gambar kolektif yang dibahas di atas ...
Singkirkan microservices yang paling meragukan:
Gabungkan semua layanan microser yang bertanggung jawab untuk menghasilkan frontend:
... dalam satu microservice, ditulis dalam satu bahasa / kerangka kerja (modern dan normal, seperti yang Anda pikirkan):
Ini akan memiliki satu ORM (satu DBMS) dan beberapa aplikasi pertama:
... secara umum, lebih banyak yang dapat ditransfer di sana, setelah memperoleh hasil sebagai berikut:
Selain itu, di Kubernetes kami menjalankan semua ini dalam contoh terpisah, yang berarti bahwa kami masih dapat mengukur beban dan skala secara terpisah.
Meringkas
Lihatlah gambar yang lebih luas. Sangat sering, semua masalah dengan layanan microser ini muncul karena fakta bahwa seseorang mengambil tugas mereka, tetapi ingin "memainkan layanan microser."
Dalam kata "microservices" bagian "mikro" tidak perlu . Mereka "mikro" hanya karena mereka lebih kecil dari monolit besar. Tetapi jangan menganggap mereka sebagai sesuatu yang kecil.
Dan untuk pemikiran terakhir, kembali ke jadwal semula:
Catatan yang ditulis kepadanya
(kanan atas) bermuara pada kenyataan bahwa
keterampilan tim yang membuat proyek Anda selalu utama - mereka akan memainkan peran kunci dalam pilihan Anda antara layanan mikro dan monolit. Jika tim tidak memiliki keterampilan yang cukup, tetapi mulai membuat layanan mikro, ceritanya pasti akan berakibat fatal.
Video dan slide
Video dari pidato (~ 50 menit; sayangnya, tidak menyampaikan banyak emosi pengunjung, yang sebagian besar menentukan suasana hati laporan, tetapi sebagaimana adanya):
Penyajian laporan:
PS
Laporan lain di blog kami:
Anda mungkin juga tertarik dengan publikasi berikut: