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. Setiap layanan mikro yang bertanggung jawab atas persistensi datanya sendiri. Akibatnya, konsistensi data di beberapa layanan dapat menjadi tantangan. Layanan yang berbeda mempertahankan data pada waktu yang berbeda, menggunakan teknologi yang berbeda, dan dengan tingkat keberhasilan yang berpotensi berbeda. Ketika lebih dari satu layanan mikro terlibat dalam mempertahankan tanggal baru atau berubah, tidak mungkin perubahan data lengkap dapat dianggap sebagai transaksi ACID. Sebaliknya, teknik ini lebih selaras dengan BASE (Pada dasarnya Tersedia, Status lunak, dan Akhirnya konsisten). 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.
Praktik terbaik
Layanan model di sekitar domain bisnis.
Desentralisasi segalanya. Setiap tim bertanggung jawab untuk merancang dan membangun layanan. Hindari berbagi kode atau skema data.
Penyimpanan data harus bersifat pribadi untuk layanan yang memiliki data tersebut. Gunakan penyimpanan terbaik untuk setiap layanan dan jenis data.
Layanan berkomunikasi melalui API yang dirancang dengan baik. Hindari membocorkan detail implementasi. API harus memodelkan domain, bukan implementasi internal layanan.
Hindari penggabungan antar layanan. Penyebab kopling termasuk skema database bersama dan protokol komunikasi yang kaku.
Offload masalah lintas sektoral, seperti autentikasi dan penghentian SSL, ke gateway.
Jauhkan pengetahuan domain dari gateway. Gateway harus menangani dan merutekan permintaan klien tanpa pengetahuan tentang aturan bisnis atau logika domain. Jika tidak, gateway menjadi ketergantungan dan dapat menyebabkan kopling antar layanan.
Layanan harus memiliki koneksi yang longgar dan kohesi fungsional yang tinggi. Fungsic yang kemungkinan besar akan berubah bersama-sama harus dipaketkan dan disebarkan bersama-sama. Jika mereka berada di layanan yang terpisah, layanan tersebut akhirnya digabungkan secara erat, karena perubahan dalam satu layanan akan memerlukan pembaruan layanan lainnya. Komunikasi yang terlalu intensif antara dua layanan mungkin merupakan gejala dari hubungan yang erat dan kohesi yang rendah.
Mengisolasi kegagalan. Gunakan strategi ketahanan untuk mencegah kegagalan dalam layanan dari cascading. Lihat Pola ketahanan dan Merancang aplikasi yang andal.
Langkah berikutnya
Untuk panduan mendetail tentang membangun arsitektur layanan mikro di Azure, lihat Merancang, membangun, dan mengoperasikan layanan mikro di Azure.