Dengan mengacu pada artikel ini, Anda akan bisa mendapatkan ide yang lebih baik tentang arsitektur Microservice dan kapan menggunakannya. Selanjutnya, artikel ini terdiri dari konten berikut.

◼ Singkatan artikel

◼ Pendahuluan

◼ Ekosistem Layanan Mikro

◼ Arsitektur Monolit vs Arsitektur Layanan Mikro

◼ Tantangan dalam Layanan Mikro

◼ Kapan menggunakan Layanan Mikro

Singkatan

• API : Antarmuka Pemrograman Aplikasi
• MS : Layanan mikro
• NoSQL : Tidak hanya SQL
• RTE : Lingkungan Runtime

Arsitektur layanan mikro adalah pendekatan untuk pengembangan aplikasi di mana aplikasi besar dibangun sebagai rangkaian layanan modular (Ini berarti bahwa (layanan mikro) adalah jenis arsitektur aplikasi di mana aplikasi dikembangkan sebagai kumpulan layanan). Setiap modul mendukung tujuan bisnis tertentu dan menggunakan antarmuka sederhana yang terdefinisi dengan baik untuk berkomunikasi dengan rangkaian layanan lainnya. Selain itu, ada minimal layanan manajemen terpusat, yang dapat ditulis dalam bahasa pemrograman yang berbeda seperti java, python, dll, dan menggunakan teknologi penyimpanan data yang berbeda seperti relasional dan NoSQL dalam arsitektur layanan mikro.

Ada beberapa fitur/karakteristik utama dari layanan mikro sebagai berikut.

• Sangat dapat dipelihara dan diuji
• Digabungkan secara longgar (berkomunikasi melalui antarmuka)
• Dapat diterapkan secara mandiri
• Diatur di sekitar kemampuan bisnis
• Dimiliki oleh tim kecil (tim lintas fungsi)

Secara umum, Sistem Layanan Mikro berisi entitas yang terdaftar berikut ini. Beberapa entitas ini adalah fase dalam pengembangan perangkat lunak standar dan beberapa di antaranya adalah proses khusus Layanan Mikro yang akan menyediakan tulang punggung untuk sistem layanan mikro yang efisien.

Penyeimbang Beban

Tanggung jawab utama penyeimbang beban adalah mendistribusikan beban yang masuk di antara banyak contoh layanan mikro. Terutama ada 2 jenis penyeimbang beban yang disebut penemuan klien (penyeimbang beban sisi klien) dan penemuan server (penyeimbang beban sisi server). Dalam penemuan klien, klien berbicara ke registri layanan dan melakukan penyeimbangan muatan. Karena itu klien perlu mengetahui registri layanan. Dalam penemuan server, klien berbicara dengan penyeimbang beban dan penyeimbang beban berbicara dengan registri layanan. Oleh karena itu, layanan klien tidak perlu mengetahui registri layanan. Dengan melihat diagram berikut, Anda dapat lebih memahami 2 jenis penyeimbang beban ini.

Server Penemuan Layanan

Fungsionalitas penemuan layanan memungkinkan layanan mikro untuk mendaftar sendiri saat startup alih-alih secara manual melacak layanan mikro apa yang saat ini digunakan dan host serta port apa yang kami butuhkan. Oleh karena itu, Jika MS1 ingin berbicara dengan MS2, pertama-tama, MS1 mendapatkan detail dari layanan registri yang dimiliki lanskap dan kemudian berbicara dengan MS2. Selain itu, ketika ada MS lain bernama MS3 yang telah naik atau turun di lanskap yang sama, layanan registri akan diperbarui secara otomatis.

Gerbang API

API Gateway adalah server. Ini adalah titik masuk tunggal ke dalam sistem. API Gateway merangkum arsitektur sistem internal. Ini menyediakan API yang disesuaikan untuk setiap klien. Ia juga memiliki tanggung jawab lain seperti otentikasi, pemantauan, penyeimbangan muatan, caching, pembentukan dan manajemen permintaan, dan penanganan respons statis. API Gateway juga bertanggung jawab atas perutean permintaan, komposisi, dan terjemahan protokol. Semua permintaan yang dibuat oleh klien melalui API Gateway. Setelah itu, API Gateway merutekan permintaan ke layanan mikro yang sesuai.

API Gateway menangani permintaan dengan salah satu dari dua cara berikut:

• Itu merutekan atau memproksi permintaan ke layanan yang sesuai.
• Menyebarkan (menyebarkan) permintaan ke beberapa layanan.

Sekarang kita tahu ada banyak layanan mikro yang berjalan pada node berbeda dalam ekosistem yang sama. Oleh karena itu, kita perlu memantaunya bersama dalam satu sistem sangat penting. Dasbor Hystrix dan dasbor admin boot Spring adalah beberapa contoh alat pemantauan. Ada lima prinsip pemantauan microservices sebagai berikut:

• Pantau wadah dan apa yang ada di dalamnya.
• Waspada pada kinerja layanan.
• Pantau layanan yang elastis dan multi-lokasi.
• Pantau API.
• Memantau struktur organisasi

Saat kami mengimplementasikan layanan mikro, mereka berjalan di RTE yang berbeda seperti JRE dan Node.js karena implementasi layanan mikro dapat dilakukan dengan menggunakan teknologi yang berbeda. Juga, Anda tahu bahwa layanan mikro ini diterapkan dengan cara poliglot. Oleh karena itu, node tidak mengetahui RTE dari layanan mikro yang diterapkan dan kami perlu menginstalnya secara manual di setiap node. Namun terkait Containerisasi, kami mengemas RTE kami dengan layanan mikro kami. Oleh karena itu kami dapat menjalankan layanan mikro di mana saja tanpa mempertimbangkan RTE dan kami dapat mengelola dan memperbarui layanan ini dengan mudah.

Pemutus arus

Ini adalah entitas yang sangat penting dalam ekosistem layanan mikro. Sebagian besar waktu ini didefinisikan sebagai pola. Untuk tujuan pemahaman, ini sangat mirip dengan pemutus sirkuit rumah Anda. Ini melindungi Anda dari bencana dan menghentikan penyebaran masalah yang muncul. Skenario yang sama terjadi di sini (pemutus sirkuit di MS) sehubungan dengan layanan mikro. Mari kita asumsikan bahwa klien mengirim permintaan ke layanan mikro pemasok dan saat respons datang, ada masalah koneksi. Karena itu klien menunggu respon untuk waktu yang lama dan mungkin mempengaruhi layanan lain juga. Karena arsitektur pemutus sirkuit, saluran bermasalah dibuang dan masalah menunggu sebelumnya diselesaikan. Selain itu, ada tiga Keadaan berbeda dari Pemutus Sirkuit yang disebut Tertutup, Terbuka dan Setengah Terbuka.

Arsitektur Monolit vs Arsitektur Layanan Mikro

Harga

• Monolitik : Lebih tinggi setelah skala proyek
• Microservce : Lebih tinggi pada tahap pengembangan pertama

• Monolitik : Basis kode dan basis data terpadu untuk seluruh produk
• Microservce : Beberapa file kode; setiap layanan menangani basis dan penyimpanan data

• Monolitik : Seluruh basis kode perlu diterapkan
• Microservce : Setiap layanan mikro dikerahkan secara individual

• Monolitik : Tumpukan kode yang sama
• Microservce : Tumpukan berbeda (bahasa, lingkungan runtime, dll.)

Ada beberapa tantangan ketika kita berhadapan dengan microservices sebagai berikut.

• Komunikasi antar proses (melalui jaringan)
• Transaksi terdistribusi
• Sejumlah besar layanan
• Membutuhkan lebih banyak otomatisasi

Sekarang kami memiliki pemahaman yang baik tentang layanan mikro dan tantangannya. Mari kita lihat skenario mana yang cocok untuk digunakan dengan layanan mikro.

• Perusahaan ingin segera membuat kode yang bersih dan dapat dibaca serta menghindari hutang teknis
• Perusahaan memiliki sumber daya manusia untuk pengembangan layanan mikro
• Perusahaan memprioritaskan keuntungan jangka panjang daripada keuntungan jangka pendek
• Tim pengembang menggunakan tumpukan dan alat teknologi yang berbeda
• Platform harus sangat terukur dan berkembang ke pasar yang berbeda