Layanan mikro adalah cara memecah aplikasi besar menjadi modul-modul yang digabungkan secara longgar dan berkomunikasi satu sama lain melalui API sederhana.
Akhir-akhir ini, hanya orang bodoh yang tidak membicarakan layanan mikro. Hal ini menjadi semakin populer. Gaya arsitektur modular tampaknya sangat cocok untuk lingkungan berbasis cloud dan semakin populer. Sebelum kita membahas detailnya, mari kita lihat sekilas semuanya . Oleh karena itu: Layanan mikro adalah cara memecah proyek besar menjadi modul-modul kecil, independen, dan digabungkan secara longgar. Modul independen bertanggung jawab atas tugas-tugas yang jelas dan terpisah serta berkomunikasi satu sama lain melalui API yang sederhana dan dapat diakses. Dengan kata lain, layanan mikro hanyalah gaya arsitektur berbeda untuk merancang aplikasi web yang kompleks. Tapi apa buruknya solusi arsitektur yang ada seperti SOA (Arsitektur Berorientasi Layanan)? Kebanyakan solusi perusahaan modern yang ditulis menggunakan SOA tampaknya bekerja dengan cukup baik. Ini mungkin saat yang tepat untuk membicarakan beberapa tantangan yang dihadapi industri saat ini... Mari kita mulai dengan contoh sederhana. Katakanlah saya perlu menjalankan aplikasi klasik yang ditulis dalam Java. Pertama saya akan mengembangkan User Interface, kemudian lapisan logika bisnis, dengan beberapa komponen yang akan berinteraksi dengan UI, dan terakhir lapisan database, yang akan dapat diakses oleh database persisten. Sekarang sesuai dengan keinginan saya untuk menjalankan aplikasi, saya akan membuat WAR/EAR/JAR dan memasangnya di server (seperti JBoss, Tomcat atau WebLogic). Karena ini dilakukan semua dalam satu, saya mendapatkan aplikasi monolitik, yang berarti semua komponen ada di satu tempat... Contoh pada gambar:
Kemungkinan besar, Anda sudah familiar dengan pendekatan ini dan pernah menggunakannya, namun idenya adalah menggunakan contoh ini untuk menunjukkan tantangan apa yang harus dihadapi pengembang dalam menggunakan solusi arsitektur ini. Penerapan monolitik: menantang tantangan
Seiring pertumbuhan aplikasi, jumlah kode yang ditulis juga meningkat, yang mungkin membebani lingkungan pengembangan setiap kali Anda perlu membukanya. Hal ini jelas mengurangi efisiensi pengembang.
Karena semuanya harus dipasang di satu tempat, hal ini mengarah pada fakta bahwa beralih ke bahasa pemrograman lain atau beralih ke teknologi lain adalah masalah besar. Misalnya, Anda menulis sebuah aplikasi di Java, dan setelah beberapa saat Kotlin keluar dan Anda sangat ingin menulis ulang aplikasi tersebut, karena aplikasi tersebut dipromosikan sebagai lebih keren, lebih baik, lebih cepat. Dengan aplikasi monolitik, bahkan memikirkan tentang refactoring akan menimbulkan kesulitan yang nyata, belum lagi prosesnya sendiri. Saat ini ada banyak aplikasi yang dibuat dengan cara ini dan jumlah baris kodenya sungguh luar biasa.
Jika salah satu komponen berhenti bekerja karena alasan apa pun , seluruh aplikasi juga akan mogok. Bayangkan saja ada aplikasi web yang memiliki modul seperti otorisasi, pembayaran, riwayat, dll. Dan entah kenapa salah satunya rusak. Ini hanyalah sebuah kejutan bagi dunia usaha dan, sebagai dampaknya, bagi para pengembang.
Penskalaan aplikasi monolitik hanya dapat dicapai dengan meningkatkan aplikasi lain yang berjenis sama. Namun bagaimana jika Anda hanya perlu menskalakan satu komponen, dan bukan keseluruhan aplikasi. Berapa banyak sumber daya yang terbuang sia-sia?...
Hal ini dapat berdampak besar pada proses pengembangan dan proses instalasi aplikasi. Semakin besar aplikasi, semakin penting bagi pengembang untuk membagi aplikasi menjadi bagian-bagian kerja yang lebih kecil. Karena semua modul dalam aplikasi monolitik terhubung satu sama lain, pengembang tidak dapat mengerjakan/memasang modul-modul ini secara independen satu sama lain. Karena pengembang bergantung satu sama lain, waktu pengembangan meningkat.
Pada saat yang sama, kami siap untuk mempertimbangkan dan memahami arti layanan mikro, yaitu bagaimana layanan tersebut dapat digunakan untuk memulihkan fleksibilitas yang hilang dengan gaya SOA. Layanan Mikro Tuhan untuk menyelamatkan Salah satu karakteristik terpenting dalam setiap solusi arsitektur adalah skalabilitas. Saat saya mempelajari layanan mikro untuk pertama kalinya, saya melihat semuanya sangat mirip dengan kutipan dari buku “The Art of Scalability”. Ini adalah awal yang baik dan tempat untuk berdiskusi. Buku ini mendefinisikan apa yang disebut model "Kubus Skalabilitas", yang menggambarkan sistem skalabilitas tiga dimensi:
Seperti yang Anda lihat, sumbu X menjelaskan "penskalaan horizontal" (yang telah kita lihat juga tersedia untuk arsitektur monolitik), sumbu Y mewakili penskalaan dalam arti memisahkan komponen layanan yang berbeda . Gagasan sumbu Z dipahami ketika data dibagi dan aplikasi mengirimkan permintaan tepat di mana data tersebut berada. Artinya, mereka tidak semuanya berada di satu tempat. Ide sumbu Y inilah yang akan kita fokuskan lebih detail. Sumbu ini mewakili dekomposisi fungsional . Dalam strategi ini, fungsi-fungsi yang berbeda dapat dianggap sebagai layanan independen. Oleh karena itu, dengan memasang seluruh aplikasi hanya setelah semuanya selesai, pengembang dapat memasang layanan individual secara independen satu sama lain dan tidak menunggu orang lain selesai mengerjakan modul mereka. Hal ini tidak hanya akan meningkatkan waktu pengembangan, namun juga menawarkan fleksibilitas untuk mengubah dan memasang ulang tanpa harus mengkhawatirkan komponen aplikasi lainnya. Mari kita bandingkan diagram ini dengan diagram monolitik sebelumnya:
Layanan Mikro: Manfaat Manfaat layanan mikro tampaknya cukup untuk meyakinkan pengembang perusahaan seperti Amazon, Netflix, Ebay untuk mulai menggunakan pendekatan ini. Tidak seperti aplikasi arsitektur monolitik, layanan mikro:
Meningkatkan isolasi kegagalan komponen: Aplikasi besar dapat terus berjalan secara efisien meskipun satu modul gagal.
Menghilangkan komitmen aplikasi terhadap satu tumpukan teknologi: jika Anda ingin mencoba tumpukan teknologi baru pada beberapa layanan, silakan. Ketergantungan akan jauh lebih ringan dibandingkan dengan ketergantungan monolitik, dan juga akan lebih mudah untuk mengembalikan semuanya. Semakin sedikit kode dalam satu aplikasi, semakin mudah cara kerjanya.
Mempermudah karyawan baru untuk memahami fungsi layanan.
Layanan mikro: fitur pemasangan dan virtualisasi Sekarang kita memahami apa itu layanan mikro. Dan keuntungan terbesarnya adalah ia dipasang oleh lebih dari satu arsip WAR/EAR/JAR. Tapi bagaimana cara menginstalnya? Cara terbaik untuk memasang layanan mikro di dalam container. Kontainer adalah sistem operasi virtual yang dikonfigurasi sepenuhnya dengan lingkungan yang diperlukan dikonfigurasi, yang membantu mengisolasi akses ke sumber daya sistem perangkat keras tempat kontainer diinstal. Solusi paling terkenal di pasaran tentu saja adalah Docker . Mesin virtual dari IaaS (infrastruktur sebagai layanan) seperti AWS juga dapat berfungsi dengan baik untuk memasang layanan mikro, namun layanan mikro yang relatif ringan mungkin tidak menggunakan semua sumber daya yang ada di mesin virtual, sehingga dapat mengurangi profitabilitas penggunaan. Anda juga dapat memasang layanan mikro menggunakan paket OSGI (Open Service Gateway Initiative). Dalam hal ini, semua layanan mikro akan berjalan dalam satu JVM, namun hal ini melibatkan masalah trade-off antara kontrol dan isolasi. Layanan Mikro: Kerugian Hanya karena “ini semua keren” dan “kita belum pernah melihatnya sebelumnya” tidak berarti tidak ada kerugiannya. Di bawah ini adalah daftar kemungkinan area masalah yang ditimbulkan oleh arsitektur layanan mikro:
Mengembangkan sistem terdistribusi bisa jadi sulit. Maksud saya, semua komponen sekarang merupakan layanan independen - Anda harus sangat hati-hati menangani permintaan yang lewat antar modul. Mungkin ada skenario di mana satu modul tidak merespons, sehingga memaksa Anda untuk menulis kode tambahan untuk menghindari kerusakan sistem. Hal ini dapat menjadi lebih sulit jika panggilan jarak jauh sensitif terhadap latensi .
Banyaknya database dan manajemen transaksi bisa sangat menyusahkan.
menguji aplikasi layanan mikro bisa jadi rumit. Dengan menggunakan aplikasi monolitik, kita hanya perlu menjalankan arsip WAR/EAR/JAR di server dan memastikan terhubung ke database. Dan dalam layanan mikro, setiap layanan individual harus dimulai sebelum pengujian dapat dimulai.
Memasang aplikasi bisa jadi rumit. Mereka mungkin memerlukan koordinasi di sekitar beberapa layanan yang mungkin tidak mudah dipasang seperti wadah WAR.
.... Tentu saja, dengan alat dan pendekatan yang tepat, kerugian ini dapat dihindari. Namun mereka sendiri membutuhkan dukungan dan tidak menyelesaikan semua masalah sepenuhnya. Artikel tersebut diterjemahkan dari situs web CloudAcademy . Terjemahan gratis. Setiap orang bebas mengungkapkan semua pemikirannya di kolom komentar. Mereka pasti akan dibaca. Artikel asli akun Github saya
GO TO FULL VERSION