Gaya arsitektur layanan mikro

Layanan mikro adalah gaya arsitektur populer untuk membangun aplikasi yang tangguh, sangat dapat diskalakan, dapat disebarkan secara independen, dan mampu berkembang dengan cepat. Membangun arsitektur layanan mikro yang sukses membutuhkan pergeseran mendasar dalam pola pikir. Ini melampaui penguraian aplikasi menjadi layanan yang lebih kecil. Anda juga harus memikirkan kembali bagaimana sistem dirancang, disebarkan, dan dioperasikan.

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.

Diagram ini mengilustrasikan arsitektur layanan mikro yang disebarkan di Microsoft Azure. Ini diatur ke dalam delapan bagian berlabel yang masing-masing mewakili komponen arsitektur utama. Tata letak mengalir dari kiri ke kanan dan atas ke bawah. Di ujung kiri, ikon berlabel klien mewakili pengguna atau sistem eksternal yang memulai permintaan ke aplikasi. Panah menunjuk dari klien ke gateway API. Permintaan mengalir melalui gateway API dan ke layanan mikro yang sesuai. Panah menunjuk dari gateway API ke kotak berlabel layanan mikro. Kotak ini berisi dua ikon untuk layanan domain, satu ikon untuk layanan komposisi, dan satu ikon untuk layanan. Panah menunjuk dari layanan mikro ke kotak lain yang berlabel database domain. Kotak ini berisi ikon yang mewakili dua database SQL dan database NoSQL. Panah juga menunjuk dari layanan mikro ke kotak berlabel middleware berorientasi pesan. Panah diberi label publikasi atau berlangganan dan kejadian. Diagram ini juga mencakup kotak yang mewakili pengamatan, manajemen dan orkestrasi, dan DevOps.

Apa yang dimaksud dengan layanan mikro?

Layanan mikro adalah komponen kecil, independen, dan digabungkan secara longgar yang dapat ditulis dan dirawat oleh satu tim kecil pengembang. Setiap layanan dikelola sebagai basis kode terpisah, yang memungkinkan tim kecil untuk menanganinya secara efisien. Karena layanan dapat disebarkan secara independen, tim dapat memperbarui layanan yang ada tanpa membangun kembali atau menyebarkan ulang seluruh aplikasi. Tidak seperti model tradisional yang memiliki lapisan data terpusat, layanan mikro bertanggung jawab untuk mempertahankan data atau status eksternal mereka sendiri. Mereka berkomunikasi melalui API yang terdefinisi dengan baik, yang menjaga implementasi internal tetap tersembunyi dari layanan lain. Arsitektur ini juga mendukung pemrograman poliglot, yang berarti bahwa layanan tidak perlu berbagi tumpukan teknologi, pustaka, atau kerangka kerja yang sama.

Komponen

Selain layanan itu sendiri, komponen lain muncul dalam arsitektur layanan mikro yang khas:

• Manajemen atau orkestrasi: Komponen manajemen ini menangani orkestrasi layanan mikro. Ini menjadwalkan dan menyebarkan layanan di seluruh simpul, mendeteksi kegagalan, pulih dari kegagalan, dan memungkinkan penskalakan otomatis berdasarkan permintaan. Platform orkestrasi kontainer seperti Kubernetes biasanya menyediakan fungsionalitas ini. Di lingkungan cloud-native, solusi seperti Azure Container Apps menyediakan orkestrasi terkelola dan penskalakan bawaan. Alat-alat ini mengurangi kompleksitas penyebaran dan overhead operasional.

• Gateway API: Gateway API berfungsi sebagai titik masuk untuk klien. Klien mengirim permintaan ke gateway API alih-alih memanggil layanan secara langsung. Gateway meneruskan permintaan tersebut ke layanan back-end yang sesuai. Ini juga menangani masalah lintas fungsionalitas seperti autentikasi, pencatatan, dan penyeimbangan beban. Dalam arsitektur layanan mikro cloud-native, proksi layanan ringan seperti Envoy dan Nginx mendukung komunikasi layanan ke layanan internal. Jenis lalu lintas internal ini, yang dikenal sebagai lalu lintas east-west, memungkinkan routing canggih dan kontrol lalu lintas.

• Middleware berorientasi pesan: Platform olahpesan seperti Apache Kafka dan Azure Service Bus memungkinkan komunikasi asinkron dalam layanan mikro dengan mempromosikan kopling longgar dan mendukung skalabilitas tinggi. Mereka membentuk fondasi arsitektur berbasis peristiwa. Pendekatan ini memungkinkan layanan untuk bereaksi terhadap peristiwa secara real time dan berkomunikasi melalui olahpesan asinkron.

• Observability: Strategi pengamatan yang efektif membantu tim menjaga keandalan sistem dan menyelesaikan masalah dengan cepat. Pengelogan terpusat mengumpulkan log untuk mendukung diagnostik yang lebih mudah. Pemantauan real time dengan agen dan kerangka kerja pemantauan performa aplikasi seperti OpenTelemetry memberikan visibilitas ke dalam kesehatan dan performa sistem. Pelacakan terdistribusi melacak permintaan di seluruh batas layanan. Ini membantu tim menemukan hambatan dan meningkatkan performa.

• Manajemen data: Arsitektur database yang dirancang dengan baik mendukung otonomi dan skalabilitas. Layanan mikro sering menggunakan persistensi poliglot dengan memilih jenis database yang berbeda, seperti SQL atau NoSQL, berdasarkan kebutuhan spesifik setiap layanan. Pendekatan ini selaras dengan desain berbasis domain (DDD) dan gagasan konteks terikat. Setiap layanan memiliki data dan skemanya. Kepemilikan ini mengurangi dependensi lintas layanan dan memungkinkan layanan berkembang secara independen. Model terdesentralisasi ini meningkatkan fleksibilitas, performa, dan ketahanan sistem.

Keuntungan

• Agilitas: Karena layanan mikro disebarkan secara independen, menjadi lebih mudah untuk mengelola perbaikan bug dan rilis fitur. Anda dapat memperbarui layanan tanpa menyebarkan ulang seluruh aplikasi dan mengembalikan pembaruan jika ada yang salah. Dalam banyak aplikasi tradisional, jika Anda menemukan bug di salah satu bagian aplikasi, itu dapat memblokir seluruh proses rilis. Misalnya, bug dapat menghentikan fitur baru jika perbaikan bug perlu diintegrasikan, diuji, dan diterbitkan.

• Tim kecil yang berfokus: 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 meningkat, dan kelincahan berkurang.

• Basis kode kecil: Dalam aplikasi monolitik, dependensi kode sering menjadi kusut dari waktu ke waktu. Menambahkan fitur baru mungkin memerlukan perubahan di banyak bagian basis kode. Arsitektur layanan mikro menghindari masalah ini dengan tidak berbagi kode atau penyimpanan data. Pendekatan ini meminimalkan dependensi dan membuatnya lebih mudah untuk memperkenalkan fitur baru.

• Campuran teknologi: Tim dapat memilih teknologi yang paling sesuai dengan layanan mereka dengan menggunakan campuran tumpukan teknologi yang sesuai.

• Isolasi kesalahan: Jika suatu layanan mikro individual menjadi tidak tersedia, hal ini tidak 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 dengan menggunakan pola olahpesan asinkron.

• Skalabilitas: Layanan dapat diskalakan secara independen. Pendekatan ini memungkinkan Anda menskalakan subsistem yang memerlukan lebih banyak sumber daya tanpa menskalakan seluruh aplikasi. Gunakan orkestrator seperti Kubernetes untuk menambahkan kepadatan layanan yang lebih tinggi ke satu host, yang memungkinkan penggunaan sumber daya yang lebih efisien.

• Isolasi data: Memperbarui skema lebih sederhana dalam arsitektur layanan mikro karena hanya satu layanan mikro yang terpengaruh. Sebaliknya, aplikasi monolitik dapat mempersulit perubahan skema, karena beberapa komponen sering berinteraksi dengan data yang sama. Akses bersama ini membuat modifikasi apa pun berpotensi berisiko.

Tantangan

Manfaat dari arsitektur microservices disertai dengan keseimbangan antara keuntungan dan kerugian. Pertimbangkan tantangan berikut sebelum Anda membuat 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. Pastikan Anda mempertimbangkan tantangan seperti penemuan layanan, konsistensi data, manajemen transaksi, dan komunikasi antar layanan saat Anda merancang aplikasi Anda.

• 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 dirancang untuk bekerja dengan dependensi layanan. Refaktorisasi lintas batas layanan bisa sulit. Ini 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 mengakibatkan masalah. Anda mungkin berakhir dengan begitu banyak bahasa dan kerangka kerja yang berbeda sehingga aplikasi menjadi sulit untuk dipertahankan. Mungkin berguna untuk menerapkan beberapa standar di seluruh proyek, tanpa terlalu membatasi fleksibilitas tim. Metode ini terutama berlaku untuk fungsionalitas lintas seperti pencatatan.

• Kemacetan dan latensi jaringan: Penggunaan banyak layanan kecil dan terperinci dapat mengakibatkan lebih banyak komunikasi antar layanan. Selain itu, jika rantai dependensi layanan terlalu panjang (layanan A memanggil B, yang memanggil C...), latensi ekstra 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 polaQueue-Based Load Leveling.

• Integritas data: Setiap layanan mikro bertanggung jawab atas penyimpanan 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 data baru atau yang diubah, tidak mungkin perubahan data lengkap dapat dianggap sebagai transaksi atom, konsisten, terisolasi, dan tahan lama (ACID). Sebaliknya, teknik ini lebih selaras dengan Basically Available, Soft State, Eventual Consistency (BASE). Sambut keselarasan yang berangsur-angsur jika memungkinkan.

• Direksi: Arsitektur layanan mikro yang sukses membutuhkan budaya DevOps yang matang. Pencatatan log yang berkorelasi di seluruh layanan bisa menantang. Biasanya, pencatatan perlu menghubungkan beberapa panggilan layanan untuk satu operasi pengguna.

• Penerapan versi: Pembaruan pada layanan tidak boleh memutus 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. Gunakan DDD untuk mengidentifikasi konteks terikat dan menentukan batas layanan yang jelas. Hindari membuat layanan yang terlalu terperinci, yang dapat meningkatkan kompleksitas dan mengurangi performa.

• Desentralisasi semuanya. Tim individu bertanggung jawab untuk merancang dan membangun layanan secara menyeluring. Hindari berbagi kode atau skema data.

• Standarkan pilihan teknologi Anda dengan membatasi jumlah bahasa dan kerangka kerja yang Anda gunakan. Tetapkan standar di seluruh platform untuk pengelogan, pemantauan, dan penyebaran.

• Penyimpanan data harus bersifat pribadi untuk layanan yang memiliki data. 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 kopling antar layanan. Penyebab kopling termasuk skema database bersama dan protokol komunikasi yang kaku.

• Gunakan kerangka kerja olahpesan untuk komunikasi asinkron. Mengadopsi alat seperti MassTransit atau NServiceBus untuk menangani perutean, coba ulang, ketahanan, dan pola kerja alur alih-alih membangun logika pesan kustom. Kerangka kerja membantu mengurangi kompleksitas sistem terdistribusi, meningkatkan keandalan, dan menghindari jebakan umum saat menerapkan layanan mikro berbasis pesan.

• Tingkatkan keamanan dengan menggunakan Keamanan Lapisan Transportasi bersama (mTLS) untuk enkripsi layanan-ke-layanan. Terapkan kontrol akses berbasis peran dan gunakan gateway API untuk menerapkan kebijakan.

• Alihkan kepentingan lintas aspek, seperti autentikasi dan penanganan penghentian SSL, ke gateway. Jaringan layanan dan kerangka kerja seperti Dapr juga dapat membantu dengan masalah umum yang melintasi berbagai aspek seperti autentikasi dan ketahanan mTLS.

• Jauhkan pengetahuan domain dari gateway. Gateway harus menangani dan merutekan permintaan klien tanpa mengetahui aturan bisnis atau logika domain. Jika tidak, gateway menjadi dependensi dan dapat menyebabkan kopling antar layanan.

• Layanan harus memiliki kopling longgar dan kohesi fungsional tinggi. Fungsi yang kemungkinan akan berubah bersama-sama harus dipaketkan dan disebarkan bersama-sama. Jika mereka berada di layanan terpisah, layanan tersebut akhirnya digabungkan dengan erat, karena perubahan dalam satu layanan memerlukan pembaruan layanan lain. Komunikasi yang terlalu cerewet antara dua layanan mungkin merupakan gejala kopling ketat dan kohesi rendah.

• Gunakan alur integrasi berkelanjutan dan penyebaran berkelanjutan (CI/CD) untuk mengotomatiskan pengujian dan penyebaran. Mengimplementasikan layanan secara independen dan memantau status kesehatan peluncuran.

• Mengisolasi kegagalan. Gunakan strategi ketahanan untuk mencegah kegagalan dalam layanan berkala. Untuk informasi selengkapnya, lihat Pola ketahanan dan Mendesain aplikasi yang andal.

• Gunakan rekayasa chaos untuk menguji ketahanan arsitektur layanan mikro Anda dan dependensinya. Mengevaluasi dan meningkatkan cara sistem menangani kegagalan parsial.

• Terapkan pengelogan terpusat, pelacakan terdistribusi (OpenTelemetry), dan pengumpulan metrik untuk memastikan pengamatan.

Pola antipola untuk layanan mikro

Ketika Anda merancang dan mengimplementasikan layanan mikro, perangkap tertentu sering terjadi yang dapat merusak manfaat gaya arsitektur ini. Mengenali antipattern ini membantu tim menghindari kesalahan yang mahal dan membangun sistem yang lebih tangguh dan dapat dipertahankan. Hindari antipattern berikut:

• Menerapkan layanan mikro tanpa pemahaman mendalam tentang domain bisnis menghasilkan batas layanan yang kurang selaras dan merusak manfaat yang dimaksudkan.

• Merancang event yang bergantung pada event di masa lalu atau di masa mendatang melanggar prinsip pesan yang bersifat atomik dan mandiri. Dependensi ini memaksa konsumen untuk menunggu dan mengurangi keandalan sistem.

• Menggunakan entitas database sebagai peristiwa mengekspos rincian layanan internal dan sering gagal menyampaikan niat bisnis yang benar, menyebabkan integrasi yang erat dan tidak jelas.

• Menghindari duplikasi data dengan segala cara adalah antipola. Menggunakan pola seperti tampilan materialisasi untuk mempertahankan salinan lokal meningkatkan otonomi layanan dan mengurangi dependensi lintas layanan.

• Menggunakan peristiwa generik memaksa konsumen untuk menafsirkan dan memfilter pesan. Pendekatan ini menambahkan kompleksitas yang tidak perlu dan mengurangi kejelasan dalam komunikasi berbasis peristiwa.

• Berbagi pustaka atau dependensi umum antara layanan mikro menciptakan kopling yang erat sehingga perubahan menjadi berisiko dan meluas serta bertentangan dengan prinsip layanan yang terpisah.

• Mengekspos layanan mikro langsung ke konsumen menghasilkan kopling yang ketat, masalah skalabilitas, dan risiko keamanan. Menggunakan gateway API menyediakan titik masuk yang bersih, dapat dikelola, dan aman.

• Menjaga nilai konfigurasi di dalam layanan mikro menggabungkannya dengan erat ke lingkungan tertentu, yang membuat penyebaran lebih sulit. Namun, konfigurasi eksternalisasi mempromosikan fleksibilitas dan portabilitas lingkungan.

• Menyematkan logika keamanan seperti validasi token langsung di dalam layanan mikro mempersulit kode dan pemeliharaannya. Atau, memindahkan keamanan ke komponen khusus memastikan layanan tetap fokus dan teratur.

• Gagal mengabstraksi tugas layanan mikro umum menghasilkan kode berulang yang rawan kesalahan dan membatasi fleksibilitas. Atau, menggunakan kerangka kerja abstraksi seperti Dapr menyederhanakan pengembangan dengan memisahkan logika bisnis dari masalah infrastruktur.

Membangun arsitektur layanan mikro

Artikel berikut menyajikan pendekatan terstruktur untuk merancang, membangun, dan mengoperasikan arsitektur layanan mikro.

Gunakan analisis domain: Untuk menghindari jebakan umum saat Anda merancang layanan mikro, gunakan analisis domain untuk menentukan batas layanan mikro Anda. Lakukan langkah-langkah berikut:

1. Gunakan analisis domain untuk memodelkan layanan mikro.
2. Gunakan DDD taktis untuk merancang layanan mikro.
3. Identifikasi batasan layanan mikro.

Merancang layanan: Layanan mikro memerlukan pendekatan terdesentralisasi dan gesit 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.

Sumber daya terkait

• Membangun alur CI/CD untuk layanan mikro di Kubernetes
• CI/CD untuk arsitektur layanan mikro
• Arsitektur layanan mikro di Azure Kubernetes Service (AKS)