Layanan mikro adalah gaya arsitektur populer untuk membangun aplikasi yang tangguh, sangat dapat diskalakan, dapat disebarkan secara independen, dan mampu berkembang dengan cepat. Tetapi arsitektur layanan mikro yang sukses memerlukan pendekatan yang berbeda untuk merancang dan membangun aplikasi.
Sebuah arsitektur layanan mikro terdiri dari kumpulan kecil, layanan otonom. Setiap layanan mandiri dan harus menerapkan kemampuan bisnis tunggal dalam konteks terbatas. Konteks terikat adalah divisi alami dalam bisnis dan memberikan batas eksplisit di mana model domain berada.
Apa yang dimaksud dengan layanan mikro?
Layanan mikro kecil, independen, dan digabungkan secara longgar. Satu tim kecil pengembang dapat menulis dan memelihara layanan.
Setiap layanan adalah basis kode terpisah, yang dapat dikelola oleh tim pengembangan kecil.
Layanan dapat digunakan secara mandiri. Sebuah tim dapat memperbarui layanan yang ada tanpa membangun kembali dan menerapkan ulang seluruh aplikasi.
Layanan bertanggung jawab untuk mempertahankan data mereka sendiri atau status eksternal. Ini berbeda dari model tradisional, di mana lapisan data terpisah menangani persistensi data.
Layanan berkomunikasi satu sama lain dengan menggunakan API yang terdefinisi dengan baik. Detail implementasi internal dari setiap layanan disembunyikan dari layanan lain.
Mendukung pemrograman poliglot. Misalnya, layanan tidak perlu berbagi tumpukan teknologi, pustaka, atau kerangka kerja yang sama.
Selain untuk layanan itu sendiri, beberapa komponen lain muncul dalam arsitektur layanan mikro yang khas:
Pengelolaan/orkestrasi. Komponen ini bertanggung jawab untuk menempatkan layanan pada node, mengidentifikasi kegagalan, menyeimbangkan layanan di seluruh node, dan sebagainya. Biasanya komponen ini adalah teknologi siap pakai seperti Kubernetes, bukan sesuatu yang dibuat khusus.
Gateway API. Gateway API adalah titik masuk untuk klien. Sebagai ganti memanggil layanan secara langsung, klien memanggil gateway API, yang meneruskan panggilan ke layanan yang sesuai di bagian belakang.
Keuntungan menggunakan gateway API meliputi:
Ini memisahkan klien dari layanan. Layanan dapat diversi atau di-refaktor tanpa perlu memperbarui semua klien.
Layanan dapat menggunakan protokol pesan yang tidak ramah web, seperti AMQP.
API Gateway dapat melakukan fungsi lintas sektoral lainnya seperti autentikasi, pencatatan log, penghentian SSL, dan penyeimbangan beban.
Kebijakan unik, seperti untuk pembatasan, penembolokan, transformasi, atau validasi.
Keuntungan
Ketangkasan. Karena layanan mikro digunakan secara independen, lebih mudah untuk mengelola perbaikan bug dan rilis fitur. Anda dapat memperbarui layanan tanpa menerapkan ulang seluruh aplikasi, dan mengembalikan pembaruan jika terjadi kesalahan. Dalam banyak aplikasi tradisional, jika bug ditemukan di salah satu bagian aplikasi, bug dapat memblokir seluruh proses rilis. Fitur baru mungkin tertahan menunggu perbaikan bug diintegrasikan, diuji, dan diterbitkan.
Tim yang kecil dan terfokus. Layanan mikro harus cukup kecil sehingga satu tim fitur dapat membangun, menguji, dan menyebarkannya. Ukuran tim yang kecil mendorong kelincahan yang lebih besar. Tim besar cenderung kurang produktif, karena komunikasi lebih lambat, overhead manajemen naik, dan kelincahan berkurang.
Basis kode kecil. Dalam aplikasi monolitik, ada kecenderungan dari waktu ke waktu untuk dependensi kode menjadi kusut. Menambahkan fitur baru memerlukan sentuhan kode di banyak tempat. Dengan tidak berbagi kode atau penyimpanan data, arsitektur layanan mikro meminimalkan ketergantungan, dan itu mempermudah penambahan fitur baru.
Campuran teknologi. Tim dapat memilih teknologi yang paling sesuai dengan layanan mereka, menggunakan campuran tumpukan teknologi yang sesuai.
Isolasi kesalahan. Jika layanan mikro individu menjadi tidak tersedia, layanan mikro tidak akan mengganggu seluruh aplikasi, selama layanan mikro hulu dirancang untuk menangani kesalahan dengan benar. Misalnya, Anda dapat menerapkan pola Circuit Breaker, atau Anda dapat merancang solusi Anda sehingga layanan mikro berkomunikasi satu sama lain menggunakan pola olahpesan asinkron.
Skalabilitas. Layanan dapat diskalakan secara independen, memungkinkan Anda menskalakan subsistem yang membutuhkan lebih banyak sumber daya, tanpa menskalakan seluruh aplikasi. Dengan menggunakan orkestrator seperti Kubernetes, Anda dapat mengemas kepadatan layanan yang lebih tinggi ke satu host, yang memungkinkan pemanfaatan sumber daya yang lebih efisien.
Isolasi data. Jauh lebih mudah untuk melakukan pembaruan skema, karena hanya satu layanan mikro yang terpengaruh. Dalam aplikasi monolitik, pembaruan skema dapat menjadi sangat menantang, karena berbagai bagian aplikasi mungkin semua menyentuh data yang sama, membuat perubahan apa pun pada skema berisiko.
Tantangan
Manfaat layanan mikro tidak gratis. Berikut adalah beberapa tantangan yang perlu dipertimbangkan sebelum memulai arsitektur layanan mikro.
Kompleksitas. Aplikasi layanan mikro memiliki bagian yang lebih bergerak daripada aplikasi monolitik yang setara. Setiap layanan lebih sederhana, tetapi seluruh sistem secara keseluruhan lebih kompleks.
Pengembangan dan pengujian. Menulis layanan kecil yang bergantung pada layanan dependen lainnya memerlukan pendekatan yang berbeda dari menulis aplikasi monolitik atau berlapis tradisional. Alat yang ada tidak selalu didesain untuk bekerja dengan dependensi layanan. Refactoring di seluruh batas layanan dapat jadi sulit. Juga menantang untuk menguji dependensi layanan, terutama ketika aplikasi berkembang dengan cepat.
Kurangnya tata kelola. Pendekatan terdesentralisasi untuk membangun layanan mikro memiliki keuntungan, tetapi juga dapat menyebabkan masalah. Anda mungkin berakhir dengan begitu banyak bahasa dan kerangka kerja yang berbeda sehingga aplikasi menjadi sulit untuk dipertahankan. Mungkin berguna untuk menempatkan beberapa standar di seluruh proyek, tanpa terlalu membatasi fleksibilitas tim. Ini terutama berlaku untuk fungsionalitas lintas sektoral seperti pengelogan.
Kemacetan dan latensi jaringan. Penggunaan banyak layanan kecil dan terperinci dapat menghasilkan komunikasi yang lebih interservice. Juga, jika rantai ketergantungan layanan menjadi terlalu panjang (layanan A memanggil B, yang memanggil C...), latensi tambahan dapat menjadi masalah. Anda perlu merancang API dengan hati-hati. Hindari API yang terlalu cerewet, pikirkan format serialisasi, dan cari tempat untuk menggunakan pola komunikasi asinkron seperti perataan beban berbasis antrean.
Integritas data. Dengan setiap layanan mikro bertanggung jawab atas persistensi datanya sendiri. Akibatnya, konsistensi data dapat menjadi tantangan tersendiri. Rangkullah konsistensi akhirnya jika memungkinkan.
Manajemen. Agar berhasil dengan layanan mikro, diperlukan budaya DevOps yang matang. Pencatatan berkorelasi di seluruh layanan dapat menjadi tantangan. Biasanya, pencatatan harus menghubungkan beberapa panggilan layanan untuk satu operasi pengguna.
Penerapan versi. Pembaruan pada layanan tidak boleh merusak layanan yang bergantung padanya. Beberapa layanan dapat diperbarui pada waktu tertentu, jadi tanpa desain yang cermat, Anda mungkin mengalami masalah dengan kompatibilitas mundur atau maju.
Set keterampilan. Layanan mikro adalah sistem yang sangat terdistribusi. Evaluasi dengan cermat apakah tim memiliki keterampilan dan pengalaman untuk menjadi sukses.
Proses untuk membangun arsitektur layanan mikro
Artikel yang tercantum di sini menyajikan pendekatan terstruktur untuk merancang, membangun, dan mengoperasikan arsitektur layanan mikro.
Analisis domain. Untuk menghindari beberapa jebakan umum saat merancang layanan mikro, gunakan analisis domain untuk menentukan batas layanan mikro Anda. Ikuti langkah-langkah ini:
- Gunakan analisis domain untuk memodelkan layanan mikro.
- Gunakan DDD taktis untuk merancang layanan mikro.
- Identifikasi batasan layanan mikro.
Desain layanan. Layanan mikro memerlukan pendekatan berbeda untuk merancang dan membangun aplikasi. Untuk informasi selengkapnya, lihat Mendesain arsitektur layanan mikro.
Beroperasi dalam produksi. Karena arsitektur layanan mikro didistribusikan, Anda harus memiliki operasi yang kuat untuk penyebaran dan pemantauan.
- CI/CD untuk arsitektur layanan mikro
- Membangun alur CI/CD untuk layanan mikro di Kubernetes
- Memantau layanan mikro yang berjalan di Azure Kubernetes Service (AKS)