Hi, saya Stanislav Yablonskiy, Pemaju Server Utama di Pixonic (MY.GAMES). dan hari ini, mari kita membahas microservices. Microservices adalah pendekatan untuk pengembangan perangkat lunak (terutama pengembangan backend) di mana fungsionalitas dibagi menjadi komponen terkecil yang mungkin, masing-masing beroperasi secara independen. Microservices sangat populer saat ini, tetapi penggunaan mereka memperkenalkan overhead yang signifikan dalam hal jaringan, memori, dan CPU. Setiap panggilan berubah menjadi kebutuhan untuk serialisasi, mengirim, dan menerima data melalui jaringan.Selain itu, tidak lagi mungkin untuk menggunakan transaksi database klasik, yang mengarah ke transaksi yang didistribusikan atau konsistensi akhirnya. Transaksi yang didistribusikan lambat dan mahal, sementara konsistensi yang mungkin berarti bahwa hasil operasi mungkin tidak muncul segera, dan data mungkin sementara tidak konsisten. Menggunakan microservices memaksa pengembang untuk menulis lebih banyak kode dalam setiap layanan individu karena kesulitan mengakses logika yang sudah ditulis dari layanan lain. terkadang, sulit untuk menggunakan ulang kode yang ada, atau Anda mungkin bahkan tidak tahu bahwa itu ada – karena orang lain mungkin bekerja pada proyek yang berbeda. Microservices’ Overheads Debug Overhead Debugging menjadi jauh lebih sulit dengan microservices. debugger reguler hampir tidak berguna dalam kondisi seperti itu karena Anda tidak dapat debug semua layanan sekaligus. Ini berarti Anda membutuhkan lingkungan khusus di mana tidak hanya layanan yang sedang debugging berjalan, tetapi juga semua ketergantungan (layanan lain, database, baris, dll.). Menggunakan HTTP Overhead Protokol HTTP memiliki banyak fungsionalitas built-in. mendukung berbagai rute, metode parameter-passing, kode tanggapan, dan didukung oleh banyak layanan siap pakai (termasuk proxy). tetapi itu tidak ringan - itu memaksa setiap layanan untuk menerapkan banyak kode yang tidak begitu efisien untuk menganalisa dan menghasilkan jalur, header, dan sebagainya. Protobuf di atas kepala Serialisasi untuk komunikasi jaringan dan deserialisasi saat menerima pesan diperlukan. Ketika menggunakan protobuf untuk pertukaran pesan, Anda perlu: untuk menciptakan objek, Mengubahnya menjadi aliran aliran, dan membuangnya segera setelah digunakan. Ini menciptakan banyak pekerjaan tambahan untuk pengumpulan sampah atau manajer memori dinamis. Jaringan Overhead Transmisi data melalui jaringan meningkatkan waktu tanggapan layanan, meningkatkan konsumsi memori dan CPU, bahkan jika microservices berjalan pada host yang sama. Memori Overhead Mengirim dan menerima pesan membutuhkan pemeliharaan struktur data tambahan, menggunakan thread terpisah, dan menyinkronkan mereka.Setiap proses terpisah, terutama yang berjalan dalam wadah, mengkonsumsi jumlah memori yang signifikan hanya karena ada. CPU di atas Tentu saja, semua komunikasi antara proses dan antara kontainer ini membutuhkan sumber daya komputasi. Database Overhead Transaksi normal tidak mungkin ketika operasi meliputi beberapa microservices. transaksi yang didistribusikan jauh lebih lambat dan membutuhkan koordinasi yang kompleks – seringkali manual. Jaringan Disk Overhead Kontainer microservice sering berjalan pada disk yang dipasang di jaringan. ini meningkatkan latensi, mengurangi kinerja (IOPS), dan membuatnya tidak dapat diprediksi. Proyek Perbatasan Overhead Desain dan pengembangan microservices membawa kesulitan dalam mengembangkan dan merefleksikan sebuah proyek. Tidak mudah untuk mengubah zona tanggung jawab layanan. Anda tidak bisa hanya mengganti nama atau menghapus sesuatu. Anda tidak bisa hanya memindahkan kode dari satu layanan ke layanan lain. Ini biasanya membutuhkan: banyak waktu dan usaha, Beberapa versi api, dan migrasi kompleks sebelum fungsionalitas dapat didistribusikan kembali antara layanan. Selain itu, jika Anda ingin memperbarui atau mengganti pustaka, Anda harus melakukannya di semua proyek, bukan hanya satu. Infrastruktur Overhead Anda tidak bisa hanya “melakukan microservices.” Anda akan membutuhkan infrastruktur – tidak, INFRASTRUKTUR: kontainer (masing-masing berisi salinan perpustakaan bersama), dengan kubernya, Layanan cloud, Tanda-tanda Tanda Tanda Tanda Tanda Tanda Tanda Tanda Tanda Tanda Tanda Tanda Tanda Tanda Tanda Tanda alat sinkronisasi konfigurasi (Zookeeper, Etcd, Consul), dan sebagainya. Semua ini membutuhkan sumber daya besar dari kedua mesin dan orang. Penempatan independen Overhead Mendukung penyebaran independen berarti: Setiap layanan harus dapat diimplementasikan secara terpisah, Masing-masing harus memiliki pipa CI / CD sendiri, dan bagian yang paling sulit - API versi. Setiap layanan harus mendukung beberapa versi API secara bersamaan. dan pemanggil harus melacak versi ini dan memperbarui panggilan mereka tepat waktu. Pertunjukan Ball of Mud Alih-alih microservices bersih, Anda akan berakhir dengan bola lumpur yang didistribusikan – di mana fungsionalitas didistribusikan dengan buruk, panggilan eksternal memicu seluruh rantai panggilan layanan internal, dan semuanya sangat lambat. Apakah Monolit itu benar-benar menakutkan? Modul Monolit Monolit modular memungkinkan Anda untuk menghindari sebagian besar overhead microservice - sementara masih menyediakan pemisahan yang dapat digunakan nanti jika diperlukan. Pendekatan ini melibatkan menulis aplikasi (terutama backend) sebagai satu layanan dibagi menjadi modul individu dengan: batas-batas yang jelas dan hubungan yang minimal. Ini memungkinkan untuk membagi mereka menjadi layanan jika skala benar-benar membutuhkannya. Tunggu, apakah Anda bisa melakukannya? Banyak manfaat yang dikaitkan dengan arsitektur microservice dapat dicapai dalam monolit: Modularitas dapat diimplementasikan dengan fitur bahasa: kelas, namespaces, proyek, dan assemblies; Berbagai database – mungkin, jika benar-benar diperlukan; Berbagai bahasa – juga mungkin, misalnya, menggabungkan C/C++/C#/Java dengan bahasa skrip seperti JavaScript, Python, atau Erlang untuk pengembangan tingkat yang lebih tinggi; Interop – banyak platform mendukung panggilan C/C++ dari Java, C#, Python, JavaScript, atau Erlang; Barisan pesan – hanya gunakan struktur data yang tepat. Dan ketika Anda ingin debug — satu keypress, dan seluruh aplikasi berada di ujung jari Anda. Aktor Kerangka Kerja Actor frameworks memungkinkan Anda untuk membangun microservices – tanpa microservices. Semua logika dibagi menjadi kelas (aktor) yang berkomunikasi hanya melalui bus pesan (kewarganegaraan). Aktor ini bisa: ada dalam satu proses, atau disebarkan melalui berbagai proses. Dengan cara ini, Anda mendapatkan model pemrograman microservice, tetapi sebagian besar infrastruktur ditangani oleh kerangka kerja itu sendiri. Conclusion Kesimpulan Arsitektur harus dipilih berdasarkan: persyaratan proyek, sumber daya yang tersedia, dan keahlian tim. Microservices bukanlah peluru perak. mereka berguna untuk proyek-proyek besar dan tim - tetapi monolit tidak usang dan bukan hutang teknis secara default. Yang paling penting adalah keseimbangan antara fleksibilitas dan kompleksitas, skalabilitas dan pemeliharaan - sehingga sistem yang Anda bangun efektif dan berkelanjutan.
