Pada tahun 60an dan 70an, arsitektur monolitik disukai untuk mengembangkan aplikasi karena sumber daya komputasi yang terbatas, yang memerlukan penggabungan semua fungsi menjadi satu unit yang kohesif.
Hal ini terjadi hingga akhir tahun 90an dan 2000an, ketika struktur monolitik mulai menjadi terlalu terbatas untuk ukuran dan kompleksitas aplikasi yang terus bertambah, terutama dengan munculnya internet dan sistem terdistribusi.
Hal ini menyebabkan pengembangan pendekatan yang lebih modular, seperti arsitektur berorientasi layanan (SOA) dan, kemudian, arsitektur layanan mikro (MSA), yang akhirnya menjadi menonjol di awal tahun 2010-an.
Meskipun demikian, ini hanyalah penjelasan singkat tentang konsep dasar dan penggunaan layanan mikro. Jadi, mari kita bahas bagaimana layanan mikro menggantikan arsitektur monolitik, cara kerja layanan mikro, dan beberapa contoh layanan mikro. Setelah itu, kita akan membahas aspek-aspek utama penerapan layanan mikro dan apa yang harus dilakukan jika Anda ingin menerapkan layanan mikro.
Apa itu Layanan Mikro? Bagaimana Cara Kerjanya?
Seperti yang saya sebutkan sebelumnya, layanan mikro muncul sebagai solusi untuk meningkatkan kompleksitas dan ukuran aplikasi, sehingga memungkinkan perusahaan untuk memecah fungsi menjadi layanan yang dapat diterapkan secara independen.
Istilah “layanan mikro” dipopulerkan oleh pakar industri seperti Martin Fowler dan James Lewis, yang secara resmi memperkenalkannya dalam sebuah postingan blog pada tahun 2014. Pekerjaan mereka mendefinisikan prinsip dan karakteristik utama, termasuk kebutuhan akan layanan yang dapat diterapkan secara independen, pengelolaan data yang terdesentralisasi, dan agnostisisme teknologi.
Sejak itu, layanan mikro telah menjadi pilihan arsitektur utama, didukung oleh kemajuan dalam bidang ini teknologi kontainerisasi seperti Docker, alat orkestrasi seperti Kubernetes, dan platform komputasi tanpa server. Namun bagaimana cara kerja layanan mikro?
Bagaimana Cara Kerja Layanan Mikro?
Pada intinya, arsitektur layanan mikro memecah aplikasi besar menjadi layanan yang lebih kecil dan berbeda, yang masing-masing bertanggung jawab atas kemampuan bisnis tertentu. Layanan ini berkomunikasi satu sama lain melalui jaringan, sering kali melalui REST API, gRPC, atau broker pesan seperti RabbitMQ atau Apache Kafka.
Berdasarkan definisi Martin Fowler dan James Lewis, semua layanan mikro memiliki empat karakteristik utama sebagai berikut:
- Tanggung Jawab Tunggal: Setiap layanan mikro dirancang untuk melakukan tugas atau fungsi tertentu, memungkinkan spesialisasi dan mengurangi kompleksitas.
- Kemerdekaan: Layanan mikro dapat dikembangkan, diterapkan, dan diskalakan secara independen satu sama lain, sehingga memberikan fleksibilitas dan ketahanan.
- Manajemen Data Terdesentralisasi: Layanan mikro sering kali memiliki database sendiri, sehingga tidak memerlukan database tunggal yang terpusat.
- Agnostisisme Teknologi: Tim dapat memilih teknologi terbaik untuk setiap layanan tanpa terikat dengan pilihan layanan lainnya.
Pendekatan ini kontras dengan arsitektur monolitik tradisional, di mana seluruh komponen aplikasi diintegrasikan secara erat ke dalam satu unit yang kohesif.
Tahapan Penting Penerapan Layanan Mikro
Meskipun arsitektur layanan mikro menawarkan segudang manfaat, seperti skalabilitas tinggi, fleksibilitas, efisiensi, isolasi kesalahan, dll., arsitektur ini memerlukan pengetahuan cara menerapkan layanan mikro secara efektif dan banyak perencanaan agar berhasil.
Itu sebabnya memiliki gagasan komprehensif tentang konsep utama, tahapan, dan praktik terbaik layanan mikro dalam menerapkan layanan mikro sangat penting untuk kesuksesan arsitektur layanan mikro. Jadi, mari kita jelajahi tahapan utama penerapan layanan mikro dan apa saja yang diperlukan dalam setiap tahapan.
Merencanakan dan Mempersiapkan Penerapan Layanan Mikro
Semua hal baik memerlukan perencanaan dan kesabaran, dan agar penerapan layanan mikro berhasil, Anda tentu memerlukan banyak perencanaan dan kesabaran. Itulah mengapa penting untuk mengikuti praktik terbaik layanan mikro dan merencanakan serta menyiapkan semua yang Anda perlukan saat menerapkan layanan mikro.
Seperti yang saya sebutkan sebelumnya, salah satu prinsip dan karakteristik utama layanan mikro adalah Prinsip Tanggung Jawab Tunggal. Dengan tetap setia pada prinsip ini dan memastikan bahwa setiap layanan mikro berfokus pada dan bertanggung jawab pada satu fungsi dan kemampuan, Anda memungkinkan tim Anda untuk mengembangkan, menerapkan, dan menskalakan layanan secara mandiri.
Selanjutnya, subkategori dari prinsip ini adalah prinsip desain kopling longgar. Artinya setiap layanan dapat berfungsi secara independen untuk komunikasi dan minimal bergantung pada layanan lain. Pada gilirannya, hal ini memungkinkan perubahan atau pembaruan pada satu layanan tidak memengaruhi layanan lain, sehingga memungkinkan penskalaan layanan mikro yang independen.
Hal ini mengurangi risiko kegagalan berjenjang, yaitu masalah atau kegagalan pada satu bagian sistem memicu reaksi berantai, yang menyebabkan kegagalan seluruh sistem dan menghentikan seluruh layanan.
Salah satu praktik layanan mikro yang penting adalah memiliki penyimpanan data khusus untuk setiap layanan saat menerapkan layanan mikro sebagai perpanjangan dari prinsip desain kopling longgar, karena hal ini mencegah konflik dan memungkinkan skalabilitas layanan yang lebih baik.
Selain itu, Anda memerlukan pola komunikasi layanan mikro asinkron, seperti perantara pesan, untuk memastikan bahwa setiap layanan dapat berkomunikasi tanpa ketergantungan langsung.
Bagian terakhir dari teka-teki ini adalah penerapan pipeline Continuous Integration and Continuous Delivery (CI/CD) untuk layanan mikro. Saluran pipa ini memungkinkan tim untuk menerapkan fitur atau perbaikan baru Alat CI/CD seperti Jenkins dan GitLab, memungkinkan organisasi menjaga stabilitas sistem sambil terus merilis kemampuan baru.
Sekarang setelah Anda memiliki gambaran menyeluruh tentang perencanaan dan persiapan yang diperlukan untuk penerapan layanan mikro, mari kita bahas tentang strategi penerapan layanan mikro.
Strategi Penerapan Layanan Mikro
Saat Anda menerapkan layanan mikro, pemilihan strategi penerapan bergantung pada fungsi layanan, lalu lintas, penyiapan infrastruktur, keahlian tim, dan pertimbangan biaya. Namun, secara umum, strategi penerapan layanan mikro adalah sebagai berikut:
- Mesin Virtual Layanan per Kontainer: Dalam pendekatan ini, setiap layanan mikro berjalan dalam wadahnya sendiri, menawarkan isolasi yang lebih baik dibandingkan beberapa instans per model host. Kontainer memfasilitasi penskalaan yang mudah dan meningkatkan alokasi sumber daya.
- Mesin Virtual Layanan per Mesin Virtual: Setiap layanan berjalan di mesin virtual (VM) terpisah, memberikan isolasi yang lebih besar dibandingkan container. Meskipun hal ini meningkatkan keamanan dan stabilitas, hal ini biasanya menimbulkan lebih banyak overhead.
- Rilis Bertahap: Awalnya, terapkan versi layanan mikro ke sekelompok kecil pengguna, uji stabilitasnya sebelum peluncuran penuh. Pendekatan ini meminimalkan dampak jika timbul masalah dan memungkinkan rollback cepat untuk menjaga integritas sistem.
- Penerapan Biru-Hijau: Metode ini menggunakan dua lingkungan produksi yang identik, dengan satu lingkungan melayani lalu lintas langsung sementara lingkungan lainnya digunakan untuk menguji rilis berikutnya. Penerapan warna biru-hijau memungkinkan rollback yang mudah dan pembaruan tanpa waktu henti, karena lalu lintas dapat dialihkan dengan mulus di antara kedua lingkungan tersebut.
- Rilis Bertahap: Strategi ini melibatkan peluncuran pembaruan secara bertahap ke berbagai segmen atau lingkungan pengguna. Hal ini sering kali dimulai dengan lingkungan internal sebelum mencapai produksi, membatasi radius ledakan dari setiap potensi masalah dan memungkinkan tim untuk mengatasi masalah secara bertahap.
- Penerapan Tanpa Server: Pendekatan ini memanfaatkan platform tanpa server seperti AWS Fargate dan Google Cloud Run, yang mengotomatiskan pengelolaan infrastruktur dengan menangani penskalaan dan alokasi sumber daya untuk Anda. Dengan penerapan tanpa server, Anda tidak perlu mengelola server yang mendasarinya, sehingga Anda dapat fokus pada layanan mikro Anda sendiri.
Setelah Anda memilih salah satu layanan mikro di atas untuk menerapkan layanan mikro, Anda memerlukan alat orkestrasi layanan mikro.
Orkestrasi Layanan Mikro
Setelah memilih salah satu dari banyak strategi penerapan layanan mikro, Anda memerlukan semacam konduktor untuk orkestrasi layanan mikro. Alat orkestrasi layanan mikro, seperti Kubernet, membantu mengotomatiskan penerapan layanan mikro, penskalaan layanan mikro, pemantauan layanan mikro, dan pengelolaan layanan mikro dalam container.
Airbnb, misalnya, menggunakan Kubernetes, yang memungkinkan para insinyurnya menerapkan ratusan perubahan pada layanan mikro mereka tanpa pengawasan manual. Salah satu fitur penting dari alat orkestrasi layanan mikro seperti Kubernetes adalah penyeimbangan beban bawaan.
Memiliki fitur penyeimbangan beban yang kompeten membantu mendistribusikan lalu lintas masuk ke beberapa contoh layanan mikro. Hal ini mencegah satu kejadian menjadi hambatan dan meningkatkan kemampuan sistem untuk menangani lonjakan permintaan.
Kubernetes memainkan peran penting dalam mengelola layanan mikro melalui kemampuan penyembuhan mandiri, di mana container yang gagal secara otomatis diganti dan dimulai ulang. The New York Times memanfaatkan fitur ini untuk mempertahankan layanan mikronya tanpa memengaruhi pengalaman pengguna dan mengalami waktu henti.
Selain itu, Kubernetes juga meningkatkan keamanan layanan mikro sebagai konfigurasi dan rahasia, seperti kredensial database atau kunci API, menggunakan ConfigMaps dan Secrets. Hal ini sangat penting terutama bagi perusahaan dan layanan, seperti Uber, yang menangani informasi sensitif pelanggan dan pengguna.
Terakhir, alat orkestrasi layanan mikro seperti Kubernetes sangat bermanfaat untuk strategi layanan mikro yang melibatkan pembaruan dan pengembalian berkala, seperti rilis bertahap. Pembaruan berkelanjutan memungkinkan versi layanan mikro baru disebarkan tanpa gangguan layanan dengan menjaga beberapa versi versi lama tetap berjalan.
Setelah menyiapkan alat orkestrasi layanan mikro, Anda perlu membuat dan mengotomatiskannya Saluran pipa CI/CD untuk penerapan layanan mikro.
Pipeline CI/CD untuk Penerapan Layanan Mikro
Seperti yang telah kita bahas sebelumnya, pipeline Continuous Integration dan Continuous Delivery untuk layanan mikro merupakan aspek penting dalam penerapan layanan mikro. Pipeline CD di pipeline CI/CD bertanggung jawab untuk menerapkan perubahan kode secara otomatis ke produksi segera setelah melewati tahap pengujian dan integrasi pipeline CI/CD.
Kemudian, bagian CD dari pipeline CI/CD ikut berperan sehingga setiap kali perubahan kode melewati tahap pengujian dan integrasi, layanan tersebut diterapkan ke alat orkestrasi layanan mikro seperti kluster Kubernetes.
Selain itu, tahap pengujian dan integrasi semuanya dilakukan secara otomatis oleh pipeline CI/CD saat pengujian unit, pengujian integrasi, dan pengujian end-to-end dimasukkan ke dalam pipeline.
Hal ini memungkinkan tim untuk memvalidasi pembaruan di setiap tahap sambil menjaga stabilitas sistem. Selain itu, jika ada masalah dengan perubahan kode, meskipun telah dilakukan berbagai pengujian, rollback otomatis dapat kembali ke versi stabil sebelumnya.
Terakhir, Menerapkan pipeline CI/CD untuk layanan mikro sesuai dengan praktik terbaik layanan mikro membantu organisasi mencapai pengembangan yang lebih cepat, mengurangi kesalahan manual, dan mempertahankan standar kualitas tinggi.
Banyak perusahaan seperti Spotify, Expedia, iRobot, Lufthansa, Pandora, dll., menggunakan pipeline CI/CD untuk layanan mikro melalui alat CI/CD seperti CircleCI, AWS CodePipeline, dan GitLab untuk mengotomatiskan proses penerapan, memastikan kualitas kode yang konsisten, dan menghadirkan fitur-fitur baru dengan cepat sambil menjaga stabilitas sistem.
Pola Komunikasi Layanan Mikro
Cara layanan-layanan mikro berkomunikasi satu sama lain sepenuhnya bergantung pada fungsi, arsitektur keseluruhan, skalabilitas yang diinginkan, dan keandalan layanan-layanan mikro Anda. Secara umum, dua jenis pola komunikasi layanan mikro utama digunakan: sinkronis Dan asinkron pola komunikasi layanan mikro.
Dalam pola komunikasi layanan mikro sinkron, layanan berinteraksi secara real-time, artinya layanan akan mengirimkan permintaan dan menunggu respons sebelum melanjutkan. Pola komunikasi layanan mikro sinkron yang paling umum digunakan adalah API REST (Representational State Transfer)., gRPC (Panggilan Prosedur Jarak Jauh Google), Dan GrafikQL.
Biasanya, pola komunikasi layanan mikro semacam ini digunakan di industri dan perusahaan yang biasanya memerlukan pemrosesan data real-time dan respons segera. Industri seperti keuangan, layanan kesehatan, dan e-commerce sering kali menggunakan pola komunikasi sinkron untuk memastikan bahwa transaksi, pengambilan data, atau interaksi terjadi secara instan, sehingga menjaga pengalaman pengguna yang lancar dan responsif.
Meskipun demikian, meskipun pola komunikasi layanan mikro sinkron menawarkan keuntungan seperti respons real-time dan kesederhanaan, pola tersebut juga memiliki kelemahan tertentu seperti potensi kemacetan karena penggabungannya yang ketat, skalabilitas yang rendah pada beban tinggi, waktu respons yang lambat, dan latensi yang tinggi selama kejadian lalu lintas tinggi.
Di sisi lain, pola komunikasi layanan mikro asinkron biasanya lebih cocok untuk layanan mikro karena didasarkan pada prinsip Kopling Longgar yang telah kita bahas sebelumnya.
Jenis pola komunikasi layanan mikro ini memisahkan layanan dengan mengizinkannya mengirim dan menerima pesan melalui broker seperti Kafka atau RabbitMQ. Dengan mengirimkan pesan ke antrian yang bertindak sebagai buffer, layanan berkomunikasi secara independen daripada menunggu respons seperti dalam pola komunikasi sinkron. Buffer ini memungkinkan layanan lain memproses pesan sesuai kecepatannya sendiri, sehingga pengirim dapat melanjutkan pekerjaannya tanpa menunggu penerima.
Pola komunikasi layanan mikro asinkron tidak hanya menawarkan struktur terpisah untuk penerapan layanan mikro, namun juga menawarkan respons real-time yang sama dengan yang ditawarkan pola komunikasi layanan mikro sinkron.
Hal ini disebabkan oleh arsitektur berbasis peristiwa dari pola komunikasi layanan mikro berbasis peristiwa asinkron, karena layanan berkomunikasi dengan memancarkan peristiwa ketika tindakan tertentu terjadi. Layanan lain dapat berlangganan acara ini dan bereaksi sesuai dengan itu. Hal ini memungkinkan sistem yang sangat responsif bereaksi terhadap perubahan secara real-time tanpa sambungan langsung antar layanan.
Selanjutnya secara asinkron Publikasikan-Berlangganan (Pub/Sub) pola komunikasi layanan mikro, layanan (penerbit) mengirim pesan ke suatu topik, dan layanan lain (pelanggan) mendengarkan topik tersebut untuk menerima pembaruan. Model ini mendukung banyak pelanggan, secara bersamaan menyiarkan pesan ke banyak layanan.
Terakhir, mirip dengan pola berbasis peristiwa, asinkron saga berbasis koreografi pola komunikasi layanan mikro juga menggunakan peristiwa untuk berkomunikasi satu sama lain; namun, dalam pola ini, ada urutan tertentu, yang berarti peristiwa memicu langkah berikutnya dan layanan tertentu untuk diaktifkan.
Perbedaannya di sini adalah bahwa dalam pola berbasis peristiwa, tidak ada urutan atau alur kerja tertentu, dan beberapa layanan dapat bereaksi terhadap suatu peristiwa, bukan proses dan urutan tertentu dalam pola saga berbasis koreografi.
Jenis pola komunikasi layanan mikro asinkron yang Anda gunakan bergantung pada tugas dan fungsi keseluruhan layanan mikro Anda. Antrian pesan seperti RabbitMQ dan Amazon SQS biasanya digunakan untuk penjadwalan tugas, distribusi beban kerja, dan e-commerce untuk pemrosesan pesanan dan sistem notifikasi.
Broker pesan berbasis peristiwa, seperti Apache Kafka dan AWS EventBridge, biasanya digunakan untuk memproses aliran peristiwa berskala besar secara real-time dan perutean peristiwa antar layanan mikro di berbagai bidang seperti layanan keuangan dan lingkungan AWS.
Sedangkan untuk broker pesan Publish-Subscribe (Pub/Sub) seperti Google Cloud Pub/Sub dan Redis Streams, broker pesan ini biasanya digunakan untuk pengiriman pesan yang skalabel di seluruh sistem terdistribusi untuk analisis real-time dan penyerapan peristiwa serta notifikasi dan aplikasi chat real-time.
Terakhir, broker pesan saga berbasis koreografi terutama digunakan untuk pemrosesan pesanan eCommerce, sistem pemesanan perjalanan, dan kasus penggunaan di mana transaksi multi-langkah yang kompleks perlu dikoordinasikan di berbagai layanan tanpa kendali pusat.
Penemuan Layanan Mikro
Setelah Anda menyiapkan dan menerapkan pola komunikasi yang sesuai dengan kebutuhan Anda, Anda harus memastikan bahwa layanan Anda dapat menemukan lokasi satu sama lain. Seperti yang saya sebutkan sebelumnya, alat orkestrasi layanan mikro seperti Kubernetes memainkan peran penting dalam penemuan layanan mikro.
Hal ini dilakukan melalui penemuan layanan bawaan yang disediakan oleh Kubernetes DNS, yang secara dinamis memperbarui alamat IP dan catatan DNS seiring dengan skala layanan atau perubahan lokasi dalam cluster.
Metode penemuan layanan layanan mikro ini disebut penemuan sisi server karena tanggung jawab perutean didelegasikan ke penyeimbang beban, yang kemudian menanyakan registri dan mengarahkan lalu lintas ke instans yang sesuai.
Di sisi lain, kami juga memiliki metode penemuan sisi klien untuk penemuan layanan mikro, di mana layanan atau gateway API menanyakan registri layanan seperti Konsul atau Eureka untuk menemukan instans yang tersedia.
Memilih metode penemuan layanan mana yang terbaik untuk penerapan layanan mikro Anda bergantung pada kebutuhan dan skala sistem.
Dengan penemuan layanan mikro sisi klien, klien memiliki kendali penuh atas instans mana yang berkomunikasi dengannya. Hal ini tidak hanya memungkinkan lebih banyak penyesuaian tetapi juga mengurangi kompleksitas, karena tidak diperlukannya layanan penemuan terpusat.
Misalnya, penerapan layanan mikro Netflix menggunakan penemuan layanan mikro sisi klien dengan Eureka dan Ribbon untuk penyeimbangan beban, sehingga klien dapat memilih instans terbaik berdasarkan kriteria seperti latensi dan beban server.
Namun, penemuan layanan mikro sisi server lebih cocok untuk lingkungan yang lebih besar karena penemuan layanan terpusat dapat meningkatkan efisiensi dan memungkinkan penyeimbangan beban yang konsisten di seluruh sistem terdistribusi.
Solusi penemuan layanan mikro sisi server seperti Kubernetes, AWS Elastic Load Balancing, dan API Gateways (Kong, NGINX, dll.) membantu merutekan lalu lintas secara efisien dan menjaga ketersediaan tinggi serta digunakan oleh perusahaan seperti Airbnb, Pinterest, Expedia, Lyft, dll.
Keamanan Layanan Mikro
Meskipun arsitektur monolitik sebagian besar lebih rendah dibandingkan MSA, salah satu aspek di mana arsitektur monolitik memiliki keunggulan adalah keamanan. Karena layanan mikro dibangun berdasarkan prinsip Loose Coupling dan bersifat terdistribusi, tindakan keamanan umum yang tunggal tidak dapat diterapkan.
Karena setiap layanan harus diamankan secara independen, perlindungan tambahan diperlukan karena permukaan serangan jauh lebih besar pada layanan mikro. Untuk tujuan ini, standar seperti OAuth2 dan JSON Web Tokens (JWT) biasanya digunakan untuk, seperti yang sudah Anda duga, otentikasi dan otorisasi.
Selain itu, gateway API juga sering digunakan untuk mengelola keamanan di seluruh layanan mikro karena menerapkan otentikasi dan otorisasi pada titik masuk. Selain itu, API gateway juga dapat menerapkan pembatasan kecepatan, pencatatan log, dan pemantauan, yang memberikan lapisan keamanan layanan mikro tambahan.
Meskipun ini mengamankan titik masuk utama, diperlukan lebih banyak langkah keamanan layanan mikro untuk mencakup komunikasi antar layanan.
Di sinilah jerat layanan berperan saat mereka menambahkan lapisan keamanan layanan mikro jaringan dan mengenkripsi lalu lintas antar layanan dan menerapkan kebijakan seperti TLS bersama. Jaringan server ini pada dasarnya menyiapkan enkripsi ujung ke ujung yang komprehensif yang secara signifikan meningkatkan keamanan layanan mikro.
Penskalaan Layanan Mikro
Salah satu manfaat terbesar MSA, dan alasan mengapa MSA dikembangkan untuk menggantikan arsitektur monolitik, adalah skalabilitasnya yang tinggi. Biasanya, penskalaan layanan mikro dapat terjadi dalam dua cara: vertikal dan horizontal.
Pada dasarnya, penskalaan layanan mikro vertikal (peningkatan) adalah menambahkan lebih banyak sumber daya, seperti CPU atau memori, ke instance yang ada. Alternatifnya, penskalaan layanan mikro horizontal (scaling out) mendistribusikan beban dan meningkatkan kapasitas.
Dalam hal implementasi, penskalaan layanan mikro vertikal lebih mudah karena yang harus Anda lakukan hanyalah memodifikasi satu instans dengan meningkatkan ke server yang lebih besar, meningkatkan memori atau kekuatan pemrosesan dalam instans cloud, atau menambahkan lebih banyak penyimpanan.
Jenis penskalaan ini biasanya digunakan ketika peningkatan daya RAM atau CPU dapat meningkatkan kinerja kueri dan pemrosesan data, seperti layanan yang bertanggung jawab untuk cache dalam memori.
Meskipun demikian, meskipun penskalaan layanan mikro vertikal lebih mudah dan menawarkan peningkatan kinerja langsung, hal ini juga memiliki kelemahan. Penskalaan vertikal dibatasi oleh kapasitas perangkat keras server, jadi pada titik tertentu, Anda harus beralih ke penskalaan horizontal untuk melanjutkan penskalaan vertikal.
Selain itu, penskalaan vertikal memerlukan biaya yang tinggi karena perangkat keras dan instans yang lebih besar umumnya memiliki label harga yang tinggi. Terakhir, jika instans yang ditingkatkan skalanya gagal, layanan akan mati seluruhnya, karena tidak ada instans tambahan untuk menangani beban tersebut.
Untuk penskalaan layanan mikro horizontal, alih-alih meningkatkan sumber daya satu instans, Anda menerapkan instans baru dari layanan tersebut. Meskipun instans ini bekerja secara independen, instans ini masih menangani layanan dan bagian beban kerja yang sama.
Tidak seperti penskalaan vertikal, penskalaan layanan mikro horizontal tidak terbatas, artinya Anda dapat menambahkan instance sebanyak yang Anda suka untuk menangani peningkatan beban kerja dan lonjakan lalu lintas, sehingga menawarkan skalabilitas yang lebih besar.
Selain itu, karena Anda memiliki beberapa contoh, jika ada yang gagal, Anda tidak menaruh semua telur Anda dalam satu keranjang, karena contoh lain dapat terus menangani permintaan. Terakhir, penskalaan horizontal jauh lebih hemat biaya dalam jangka panjang, karena Anda dapat menggunakan beberapa instans yang lebih kecil dan lebih murah untuk menghasilkan kinerja yang lebih andal dan bertenaga.
Oleh karena itu, penskalaan horizontal dan penambahan lebih banyak instans memerlukan lebih banyak penyeimbang beban, mekanisme penemuan layanan mikro, dan alat orkestrasi layanan mikro, sehingga membuat arsitektur layanan mikro Anda jauh lebih kompleks.
Penskalaan horizontal lebih cocok untuk kasus penggunaan seperti layanan web dan aplikasi seperti e-niaga atau platform media sosial, yang sering kali mengalami fluktuasi lalu lintas dan volume permintaan yang tinggi.
Meskipun demikian, hal ini tidak berlaku untuk salah satu atau kedua jenis penskalaan tersebut, karena kedua jenis penskalaan tersebut didukung dalam layanan mikro dan diperlukan dalam banyak kasus. Biasanya, organisasi kecil menggunakan penskalaan vertikal karena lebih mudah diterapkan dan dikelola, namun seiring berjalannya waktu dan seiring berkembangnya aplikasi, penskalaan horizontal diperkenalkan untuk menangani permintaan yang besar.
Terakhir, platform cloud menawarkan layanan penskalaan otomatis yang secara otomatis menambah atau menghapus instans berdasarkan permintaan real-time, yang secara signifikan membantu organisasi menyeimbangkan penskalaan vertikal dan horizontal.
Pemantauan Layanan Mikro
Pada tahap ini, Anda sudah cukup selesai menerapkan layanan mikro; yang tersisa hanyalah memastikannya bekerja secara konsisten dan andal. Di sinilah alat pemantauan layanan mikro disukai Prometheus dan Grafana masuk.
Alat-alat ini memberikan wawasan real-time mengenai metrik layanan sehingga tim dapat melacak penggunaan sumber daya, latensi, dan tingkat kesalahan. Selain itu, alat ini juga menawarkan penelusuran terdistribusi (Jaeger, Zipkin, dll.), yang membantu memvisualisasikan aliran permintaan di seluruh layanan dan dapat sangat bermanfaat untuk mendiagnosis masalah.
Terakhir, karena kegagalan dapat terjadi di seluruh layanan karena desain layanan mikro yang terdistribusi, agregasi log adalah praktik penting dalam pemantauan layanan mikro. Dengan menggabungkan log ke dalam platform terpusat dan menyiapkan peringatan real-time, Anda akan selalu selangkah lebih maju dari masalah dan dapat meresponsnya secara proaktif sebelum berdampak pada pengguna.
Pikiran Terakhir
Meskipun dunia layanan mikro merupakan dunia yang sulit untuk dipahami, memahami dasar-dasar dan tahapan utama penerapan layanan mikro dapat membuat keseluruhan proses menjadi lebih mudah. Ditambah lagi, seiring berjalannya waktu, semakin banyak alat dengan lebih banyak fitur yang dapat Anda gunakan, membuat penerapan layanan mikro menjadi lebih sederhana dari sebelumnya.
Pertanyaan Umum
Strategi penerapan apa yang biasa digunakan untuk layanan mikro?
Meskipun ada banyak strategi berbeda untuk penerapan layanan mikro, strategi penerapan yang paling umum digunakan mencakup instans layanan per kontainer, rilis bertahap, penerapan biru-hijau, dan penerapan tanpa server, yang masing-masing menawarkan tingkat isolasi, fleksibilitas, dan skalabilitas yang berbeda.
Peran apa yang dimainkan Kubernetes dalam mengatur layanan mikro?
Layanan mikro bergantung pada alat orkestrasi layanan mikro seperti Kubernetes untuk mengotomatiskan penerapan, menskalakan, dan mengelola layanan dalam container, menyediakan kemampuan penyeimbangan beban, penskalaan otomatis, dan penyembuhan mandiri untuk memastikan layanan mikro yang tangguh dan efisien.
Bagaimana cara memastikan keamanan di lingkungan layanan mikro?
Karena sifatnya yang terdistribusi, layanan mikro lebih rumit dalam hal keamanan dibandingkan arsitektur monolitik. Keamanan dalam layanan mikro melibatkan autentikasi dan otorisasi permintaan, enkripsi komunikasi antar layanan, dan penerapan gateway API dan jaringan layanan seperti Istio untuk manajemen keamanan terpusat.
