19 September di Moskow pertemuan tematik pertama HUG (Highload++ User Group), yang didedikasikan untuk layanan mikro. Ada presentasi “Mengoperasikan Layanan Mikro: Ukuran Penting, Bahkan Jika Anda Memiliki Kubernetes,” di mana kami berbagi pengalaman luas Flant dalam mengoperasikan proyek dengan arsitektur layanan mikro. Pertama-tama, ini akan berguna bagi semua pengembang yang berpikir untuk menggunakan pendekatan ini dalam proyek mereka saat ini atau di masa depan.
Memperkenalkan (50 menit, jauh lebih informatif daripada artikel), serta kutipan utama dalam bentuk teks.
NB: Video dan presentasi juga tersedia di akhir postingan ini.
pengenalan
Biasanya cerita yang bagus mempunyai awal, alur utama, dan resolusi. Laporan ini lebih seperti pendahuluan, dan juga tragis. Penting juga untuk dicatat bahwa ini memberikan pandangan orang luar tentang layanan mikro. Operasi.
Saya akan mulai dengan grafik ini, yang penulisnya (pada tahun 2015) Martin Fowler:
Hal ini menunjukkan bagaimana, dalam kasus penerapan monolitik yang mencapai nilai tertentu, produktivitas mulai menurun. Layanan mikro berbeda karena produktivitas awalnya lebih rendah, tetapi seiring dengan meningkatnya kompleksitas, penurunan efisiensi tidak begitu terlihat bagi layanan tersebut.
Saya akan menambahkan grafik ini untuk kasus penggunaan Kubernetes:
Mengapa aplikasi dengan layanan mikro lebih baik? Karena arsitektur seperti itu mengedepankan persyaratan serius pada arsitektur, yang pada gilirannya tercakup secara sempurna oleh kemampuan Kubernetes. Di sisi lain, beberapa fungsi ini akan berguna untuk monolit, terutama karena monolit yang umum saat ini bukanlah monolit (detailnya akan dijelaskan nanti di laporan).
Seperti yang Anda lihat, grafik akhir (saat aplikasi monolitik dan layanan mikro berada dalam infrastruktur Kubernetes) tidak jauh berbeda dari grafik aslinya. Selanjutnya kita akan membahas tentang aplikasi yang dioperasikan menggunakan Kubernetes.
Layanan mikro yang berguna dan berbahaya
Dan inilah gagasan utamanya:
apa normal arsitektur layanan mikro? Ini akan memberi Anda manfaat nyata, meningkatkan efisiensi kerja Anda. Jika kita kembali ke grafiknya, ini dia:
Jika Anda meneleponnya berguna, maka di sisi lain grafik akan ada berbahaya layanan mikro (mengganggu pekerjaan):
Kembali ke “gagasan utama”: haruskah saya memercayai pengalaman saya? Sejak awal tahun ini saya sudah mencarinya 85 proyek. Tidak semuanya merupakan layanan mikro (sekitar sepertiga hingga setengahnya memiliki arsitektur seperti itu), namun jumlahnya masih besar. Kami (perusahaan Flat) sebagai agen outsourcing berhasil melihat berbagai macam aplikasi yang dikembangkan baik di perusahaan kecil (dengan 5 pengembang) dan di perusahaan besar (~500 pengembang). Manfaat tambahannya adalah kami melihat aplikasi ini hidup dan berkembang selama bertahun-tahun.
Mengapa layanan mikro?
Untuk pertanyaan tentang manfaat layanan mikro, ada dari Martin Fowler yang telah disebutkan:
- batasan modularitas yang jelas;
- penyebaran independen;
- kebebasan memilih teknologi.
Saya telah berbicara banyak dengan arsitek dan pengembang perangkat lunak dan bertanya mengapa mereka memerlukan layanan mikro. Dan saya membuat daftar harapan mereka. Inilah yang terjadi:
Jika kita mendeskripsikan beberapa poin “dalam sensasi”, maka:
- batasan modul yang jelas: di sini kita memiliki monolit yang mengerikan, dan sekarang semuanya akan tertata rapi di repositori Git, di mana semuanya ada "di rak", yang hangat dan yang lembut tidak tercampur;
- kemandirian penerapan: kami akan dapat meluncurkan layanan secara mandiri sehingga pengembangan berjalan lebih cepat (memublikasikan fitur-fitur baru secara paralel);
- kemandirian pengembangan: kami dapat memberikan layanan mikro ini kepada satu tim/pengembang, dan layanan mikro tersebut kepada tim/pengembang lainnya, sehingga kami dapat berkembang lebih cepat;
- боkeandalan yang lebih besar: jika terjadi degradasi sebagian (satu dari 20 layanan mikro gagal), maka hanya satu tombol yang akan berhenti bekerja, dan sistem secara keseluruhan akan terus berfungsi.
Arsitektur layanan mikro yang khas (berbahaya).
Untuk menjelaskan mengapa kenyataan tidak seperti yang kita harapkan, saya akan sampaikan kolektif gambar arsitektur layanan mikro berdasarkan pengalaman dari banyak proyek berbeda.
Contohnya adalah toko online abstrak yang akan bersaing dengan Amazon atau setidaknya OZON. Arsitektur layanan mikronya terlihat seperti ini:
Karena berbagai alasan, layanan mikro ini ditulis pada platform berbeda:
Karena setiap layanan mikro harus memiliki otonomi, banyak dari layanan tersebut memerlukan database dan cache sendiri. Arsitektur akhirnya adalah sebagai berikut:
Apa konsekuensinya?
Fowler juga memilikinya — tentang “pembayaran” untuk menggunakan layanan mikro:
Dan kita akan melihat apakah harapan kami terpenuhi.
Batasan modul yang jelas...
Tetapi berapa banyak layanan mikro yang sebenarnya perlu kita perbaiki?untuk meluncurkan perubahan? Bisakah kita mengetahui cara kerja semuanya tanpa pelacak terdistribusi (bagaimanapun juga, permintaan apa pun diproses oleh setengah dari layanan mikro)?
Ada pola"“, dan di sini ternyata ada segumpal tanah yang tersebar. Untuk mengonfirmasi hal ini, berikut adalah ilustrasi perkiraan bagaimana permintaan berjalan:
Kemandirian penerapan...
Secara teknis, hal ini telah tercapai: kami dapat meluncurkan setiap layanan mikro secara terpisah. Namun dalam praktiknya, Anda perlu memperhitungkan bahwa hal itu selalu diluncurkan banyak layanan mikro, dan kita perlu memperhitungkannya urutan peluncurannya. Dalam cara yang baik, kita biasanya perlu menguji di sirkuit terpisah apakah kita meluncurkan rilis dalam urutan yang benar.
Kebebasan memilih teknologi...
Dia adalah. Ingatlah bahwa kebebasan sering kali berbatasan dengan pelanggaran hukum. Sangat penting di sini untuk tidak memilih teknologi hanya untuk “bermain” dengannya.
Kemandirian pembangunan...
Bagaimana cara membuat test loop untuk seluruh aplikasi (dengan begitu banyak komponen)? Namun Anda tetap harus selalu memperbaruinya. Semua ini mengarah pada fakta bahwa jumlah sebenarnya dari rangkaian uji, yang pada prinsipnya dapat kami tampung, ternyata minim.
Bagaimana kalau menyebarkan semua ini secara lokal?.. Ternyata seringkali developer melakukan pekerjaannya secara mandiri, namun “acak”, karena terpaksa menunggu hingga sirkuit bebas untuk pengujian.
Penskalaan terpisah...
Ya, tetapi terbatas pada area DBMS yang digunakan. Dalam contoh arsitektur yang diberikan, Cassandra tidak akan mengalami masalah, tetapi MySQL dan PostgreSQL akan mengalaminya.
Боkeandalan yang lebih besar...
Kegagalan satu layanan mikro pada kenyataannya tidak hanya sering kali mengganggu berfungsinya seluruh sistem, tetapi juga terdapat masalah baru: membuat setiap layanan mikro toleran terhadap kesalahan sangatlah sulit. Karena layanan mikro menggunakan teknologi yang berbeda (memcache, Redis, dll.), untuk masing-masing layanan tersebut Anda perlu memikirkan semuanya dan mengimplementasikannya, yang tentu saja mungkin dilakukan, tetapi membutuhkan sumber daya yang besar.
Keterukuran beban...
Ini sangat bagus.
"Ringan" layanan mikro...
Kami tidak hanya punya yang besar overhead jaringan (permintaan DNS bertambah banyak, dll.), tetapi juga karena banyaknya subkueri yang kami mulai mereplikasi data (menyimpan cache), yang menyebabkan sejumlah besar penyimpanan.
Dan inilah hasil memenuhi harapan kami:
Tapi itu tidak semua!
Karena:
- Kemungkinan besar kita membutuhkan bus pesan.
- Bagaimana cara membuat cadangan yang konsisten pada waktu yang tepat? Satu satunya nyata pilihannya adalah mematikan lalu lintas untuk ini. Tapi bagaimana cara melakukan ini dalam produksi?
- Jika kita berbicara tentang mendukung beberapa daerah, maka pengorganisasian keberlanjutan di masing-masing daerah adalah tugas yang sangat padat karya.
- Masalah dalam membuat perubahan terpusat muncul. Misalnya, jika kita perlu memperbarui versi PHP, kita perlu berkomitmen pada setiap repositori (dan jumlahnya ada lusinan).
- Pertumbuhan kompleksitas operasional bersifat eksponensial.
Apa yang harus dilakukan dengan semua ini?
Mulailah dengan aplikasi monolitik. pengalaman Fowler bahwa hampir semua aplikasi layanan mikro yang sukses dimulai dari sebuah monolit yang menjadi terlalu besar dan kemudian rusak. Pada saat yang sama, hampir semua sistem yang dibangun sebagai layanan mikro sejak awal cepat atau lambat akan mengalami masalah yang serius.
Pemikiran berharga lainnya adalah agar proyek dengan arsitektur layanan mikro dapat berhasil, Anda harus mengetahuinya dengan baik dan bidang subjek, dan cara membuat layanan mikro. Dan cara terbaik untuk mempelajari suatu mata pelajaran adalah dengan membuat monolit.
Namun bagaimana jika kita sudah berada dalam situasi tersebut?
Langkah pertama untuk memecahkan masalah apa pun adalah menyetujuinya dan memahami bahwa itu adalah sebuah masalah, bahwa kita tidak ingin menderita lagi.
Jika, dalam kasus monolit yang tumbuh terlalu besar (ketika kita kehabisan kesempatan untuk membeli sumber daya tambahan untuk itu), kita memotongnya, maka dalam kasus ini cerita sebaliknya akan muncul: ketika layanan mikro yang berlebihan tidak lagi membantu, tetapi menghambat - potong kelebihannya dan perbesar!
Misalnya, untuk citra kolektif yang dibahas di atas...
Singkirkan layanan mikro yang paling dipertanyakan:
Gabungkan semua layanan mikro yang bertanggung jawab untuk pembuatan frontend:
... menjadi satu layanan mikro, ditulis dalam satu bahasa/kerangka (modern dan normal, seperti yang Anda pikirkan):
Ini akan memiliki satu ORM (satu DBMS) dan beberapa aplikasi pertama:
... tetapi secara umum Anda dapat mentransfer lebih banyak lagi ke sana, mendapatkan hasil sebagai berikut:
Selain itu, di Kubernetes kami menjalankan semua ini dalam instance terpisah, yang berarti kami masih dapat mengukur beban dan menskalakannya secara terpisah.
Meringkas
Lihatlah gambaran yang lebih besar. Seringkali, semua masalah dengan layanan mikro ini muncul karena seseorang mengambil tugasnya, tetapi ingin “bermain dengan layanan mikro”.
Dalam kata "layanan mikro", bagian "mikro" adalah mubazir.. Mereka disebut “mikro” hanya karena lebih kecil dari monolit besar. Tapi jangan menganggapnya sebagai sesuatu yang kecil.
Dan untuk pemikiran terakhir, mari kembali ke grafik awal:
Sebuah catatan tertulis di atasnya (kanan atas) bermuara pada fakta bahwa keterampilan tim yang membuat proyek Anda selalu menjadi yang utama — mereka akan memainkan peran penting dalam pilihan Anda antara layanan mikro dan monolit. Jika tim tidak memiliki keterampilan yang cukup, tetapi mulai membuat layanan mikro, ceritanya pasti berakibat fatal.
Video dan slide
Video dari pidatonya (~50 menit; sayangnya, tidak menyampaikan berbagai emosi pengunjung, yang sangat menentukan suasana laporan, tapi begitulah adanya):
Penyajian laporan:
PS
Laporan lain di blog kami:
- «» (Dmitry Stolyarov; 28 Mei 2018 di RootConf);
- «» (Dmitry Stolyarov; 7 November 2017 di HighLoad++);
- «» (Dmitry Stolyarov; 6 Juni 2017 di RootConf);
- «» (Dmitry Stolyarov; 8 November 2016 di HighLoad++);
- «» (Dmitry Stolyarov; 31 Mei 2016 di RootConf).
Anda mungkin juga tertarik dengan publikasi berikut:
- «»;
- «»;
- «'.
Sumber: www.habr.com