Arsitektur Microservice:
Dari saya , Anda pasti sudah memiliki pemahaman dasar tentang Arsitektur Layanan Mikro.Tapi, menjadi seorang profesional dengan akan membutuhkan lebih dari sekedar dasar. Di blog ini, Anda akan mendalami konsep arsitektur dan mengimplementasikannya menggunakan studi kasus UBER.
Di blog ini, Anda akan belajar tentang hal-hal berikut:
- Definisi Arsitektur Microservice
- Konsep Utama Arsitektur Microservice
- Pro Dan Kontra Dari Arsitektur Microservice
- UBER - Studi Kasus
Anda dapat merujuk ke , untuk memahami dasar-dasar dan manfaat Microservices.
Ini hanya akan adil jika saya memberikan definisi dari Microservices.
Definisi Layanan Mikro
Dengan demikian, tidak ada definisi yang tepat tentang Layanan Mikro alias Arsitektur Layanan Mikro, tetapi Anda dapat mengatakan bahwa ini adalah kerangka kerja yang terdiri dari layanan kecil yang dapat diterapkan secara individual yang melakukan operasi berbeda.
Layanan mikro berfokus pada satu domain bisnis yang dapat diimplementasikan sebagai layanan yang dapat diterapkan sepenuhnya independen dan menerapkannya pada tumpukan teknologi yang berbeda.
Gambar 1: Perbedaan Antara Arsitektur Monolitik dan Microservice - Arsitektur Microservice
Lihat diagram di atas untuk memahami perbedaan antara arsitektur monolitik dan layanan mikro.Untuk lebih memahami perbedaan antara kedua arsitektur tersebut, Anda dapat merujuk ke blog saya sebelumnya
Untuk membuat Anda lebih memahami, izinkan saya memberi tahu Anda beberapa konsep utama arsitektur layanan mikro.
Konsep Utama Arsitektur Microservice
Sebelum Anda mulai membangun aplikasi Anda sendiri menggunakan layanan mikro, Anda harus memahami ruang lingkup, dan fungsi aplikasi Anda dengan jelas.
Berikut adalah beberapa pedoman yang harus diikuti saat membahas layanan mikro.
apa fungsi overloading di c ++
Panduan Saat Mendesain Layanan Mikro
- Sebagai pengembang, ketika Anda memutuskan untuk membangun aplikasi, pisahkan domain dan jelaskan fungsinya.
- Setiap layanan mikro yang Anda rancang harus berkonsentrasi hanya pada satu layanan aplikasi.
- Pastikan Anda telah mendesain aplikasi sedemikian rupa sehingga setiap layanan dapat diterapkan satu per satu.
- Pastikan komunikasi antar layanan mikro dilakukan melalui server tanpa negara.
- Setiap layanan dapat dikembangkan kembali menjadi layanan yang lebih kecil, memiliki layanan mikro sendiri.
Sekarang, setelah Anda membaca seluruh pedoman dasar saat merancang layanan mikro, mari kita pahami arsitektur layanan mikro.
Bagaimana Arsitektur Microservice Bekerja?
Arsitektur Microservice (MSA) tipikal harus terdiri dari komponen-komponen berikut:
- Klien
- Penyedia Identitas
- Gateway API
- Format Pesan
- Database
- Konten Statis
- Pengelolaan
- Penemuan Layanan
Lihat diagram di bawah ini.
Gambar 2: Arsitektur Layanan Mikro - Arsitektur Layanan Mikro
Saya tahu arsitekturnya terlihat agak rumit, tetapi biarkansayasederhanakan untuk Anda.
1. Klien
Arsitektur dimulai dengan berbagai jenis klien, dari perangkat berbeda yang mencoba melakukan berbagai kemampuan manajemen seperti pencarian, pembuatan, konfigurasi, dll.
2. Penyedia Identitas
Permintaan ini dari klien kemudian diteruskan ke penyedia identitas yang mengotentikasi permintaan klien dan mengkomunikasikan permintaan tersebut ke API Gateway. Permintaan tersebut kemudian dikomunikasikan ke layanan internal melalui API Gateway yang ditentukan dengan baik.
3. Gerbang API
Karena klien tidak memanggil layanan secara langsung, API Gateway bertindak sebagai titik masuk bagi klien untuk meneruskan permintaan ke layanan mikro yang sesuai.
Keuntungan menggunakan API gateway meliputi:
- Semua layanan dapat diperbarui tanpa sepengetahuan klien.
- Layanan juga dapat menggunakan protokol perpesanan yang tidak ramah web.
- API Gateway dapat melakukan fungsi lintas sektor seperti memberikan keamanan, penyeimbangan beban, dll.
Setelah menerima permintaan klien, arsitektur internal terdiri dari layanan mikro yang berkomunikasi satu sama lain melalui pesan untuk menangani permintaan klien.
4. Format Pesan
Ada dua jenis pesan yang digunakan untuk berkomunikasi:
- Pesan Sinkron: Dalam situasi di mana klien menunggu tanggapan dari suatu layanan, Microservices biasanya cenderung menggunakan REST (Transfer Negara Perwakilan) karena bergantung pada stateless, client-server, dan Protokol HTTP . Protokol ini digunakan karena merupakan lingkungan terdistribusi masing-masing dan setiap fungsi diwakili dengan sumber daya untuk menjalankan operasi
- Pesan Asinkron: Dalam situasi di mana klien tidak menunggu respon dari suatu layanan, Microservices biasanya cenderung menggunakan protokol seperti AMQP, STOMP, MQTT . Protokol ini digunakan dalam jenis komunikasi ini karena sifat pesan ditentukan dan pesan ini harus dapat dioperasikan antar implementasi.
Pertanyaan selanjutnya yang mungkin muncul di benak Anda adalah bagaimana aplikasi yang menggunakan Microservices menangani datanya?
5. Penanganan Data
Nah, setiap Microservice memiliki database pribadi untuk menangkap datanya dan menerapkan fungsionalitas bisnis masing-masing. Juga, database Microservice diperbarui hanya melalui API layanan mereka. Lihat diagram di bawah ini:
Gambar 3: Representasi Data Penanganan Layanan Mikro - Arsitektur Layanan Mikro
Layanan yang disediakan oleh Microservices diteruskan ke layanan jarak jauh apa pun yang mendukung komunikasi antar-proses untuk tumpukan teknologi yang berbeda.
6. Konten Statis
Setelah Microservices berkomunikasi di dalam dirinya sendiri, mereka menyebarkan konten statis ke layanan penyimpanan berbasis cloud yang dapat mengirimkannya langsung ke klien melalui Jaringan Pengiriman Konten (CDN) .
apa itu big data dan hadoop
Terlepas dari komponen di atas, ada beberapa komponen lain yang muncul dalam Arsitektur Layanan Mikro yang khas:
7. Manajemen
Komponen ini bertanggung jawab untuk menyeimbangkan layanan pada node dan mengidentifikasi kegagalan.
8. Penemuan Layanan
Bertindak sebagai panduan untuk Microservices untuk menemukan rute komunikasi di antara mereka karena ia menyimpan daftar layanan tempat node berada.
Berlangganan saluran youtube kami untuk mendapatkan pembaruan baru ..!
Sekarang, mari kita lihat pro dan kontra dari arsitektur ini untuk mendapatkan pemahaman yang lebih baik tentang kapan harus menggunakan arsitektur ini.
Pro dan Kontra Arsitektur Microservice
Lihat tabel di bawah ini.
| Kelebihan Arsitektur Microservice | Kontra Dari Microservice Arsitektur |
| Kebebasan untuk menggunakan teknologi yang berbeda | Meningkatkan tantangan pemecahan masalah |
| Setiap layanan mikro berfokus pada kemampuan bisnis tunggal | Meningkatkan penundaan karena panggilan jarak jauh |
| Mendukung unit individu yang dapat diterapkan | Peningkatan upaya untuk konfigurasi dan operasi lainnya |
| Memungkinkan rilis perangkat lunak yang sering | Sulit untuk menjaga keamanan transaksi |
| Menjamin keamanan setiap layanan | Sulit untuk melacak data di berbagai batasan layanan |
| Berbagai layanan dikembangkan dan diterapkan secara paralel | Sulit untuk memindahkan kode antar layanan |
Mari kita memahami lebih lanjut tentang Layanan Mikro dengan membandingkan arsitektur UBER sebelumnya dengan yang sekarang.
STUDI KASUS UBER
Arsitektur UBER Sebelumnya
Seperti banyak perusahaan rintisan, UBER memulai perjalanannya dengan arsitektur monolitik yang dibangun untuk satu penawaran di satu kota. Memiliki satu basis kode tampaknya dibersihkan pada saat itu, dan memecahkan masalah bisnis inti UBER. Namun, saat UBER mulai berkembang di seluruh dunia, mereka menghadapi berbagai masalah dengan ketat terkait skalabilitas dan integrasi berkelanjutan.
Gambar 4: Arsitektur Monolitik UBER - Arsitektur Microservice
Diagram di atas menggambarkan arsitektur UBER sebelumnya.
- Ada REST API yang menghubungkan penumpang dan pengemudi.
- Tiga adapter berbeda digunakan dengan API di dalamnya, untuk melakukan tindakan seperti penagihan, pembayaran, pengiriman email / pesan yang kita lihat saat kita memesan taksi.
- Database MySQL untuk menyimpan semua datanya.
Jadi, jika Anda perhatikan di sini semua fitur seperti manajemen penumpang, penagihan, fitur notifikasi, pembayaran, manajemen perjalanan dan manajemen pengemudi disusun dalam satu kerangka kerja.
Pernyataan masalah
Sementara UBER mulai berkembang di seluruh dunia, kerangka semacam ini memperkenalkan berbagai tantangan. Berikut ini adalah beberapa tantangan utama
- Semua fitur harus dibangun kembali, diterapkan dan diuji lagi dan lagi untuk memperbarui satu fitur.
- Memperbaiki bug menjadi sangat sulit dalam satu repositori karena pengembang harus mengubah kodenya berulang kali.
- Penskalaan fitur secara bersamaan dengan pengenalan fitur baru di seluruh dunia cukup sulit untuk ditangani bersama.
Larutan
ide java terbaik untuk ubuntu
Untuk menghindari masalah seperti itu, UBER memutuskan untuk mengubah arsitekturnya dan mengikuti perusahaan hiper-pertumbuhan lainnya seperti Amazon, Netflix, Twitter, dan banyak lainnya. Jadi, UBER memutuskan untuk memecah arsitektur monolitiknya menjadi beberapa basis kode untuk membentuk arsitektur layanan mikro.
Lihat diagram di bawah untuk melihat arsitektur layanan mikro UBER.
Gambar 5: Arsitektur Layanan Mikro UBER - Arsitektur Layanan Mikro
- Perubahan utama yang kami amati di sini adalah pengenalan API Gateway yang menghubungkan semua pengemudi dan penumpang. Dari API Gateway, semua titik internal terhubung seperti manajemen penumpang, manajemen pengemudi, manajemen perjalanan dan lainnya.
- Unit adalah unit terpisah yang dapat diterapkan dan menjalankan fungsi terpisah.
- Misalnya: Jika Anda ingin mengubah apa pun di Layanan Mikro penagihan, Anda hanya perlu menerapkan Layanan Mikro penagihan dan tidak perlu menerapkan yang lain.
- Semua fitur sekarang diskalakan secara individual, yaitu saling ketergantungan antara setiap fitur telah dihapus.
- Misalnya, kita semua tahu bahwa jumlah orang yang mencari taksi lebih banyak dibandingkan orang yang sebenarnya memesan taksi dan melakukan pembayaran. Ini memberi kita kesimpulan bahwa jumlah proses yang bekerja pada layanan mikro manajemen penumpang lebih banyak daripada jumlah proses yang bekerja pada pembayaran.
Di dalamcara, UBER diuntungkan dengan pergeseran-nyaarsitektur dari monolitik ke Microservices.
Saya harap Anda menikmati membaca posting ini tentang Arsitektur Microservice.Saya akan datang dengan lebih banyak blog, yang juga akan berisi praktik langsung.
Tertarik Mempelajari Lebih Lanjut Tentang Layanan Mikro?
Jika Anda ingin belajar Microservices dan membangun aplikasi Anda sendiri, lihatlah yang dilengkapi dengan pelatihan langsung yang dipimpin instruktur dan pengalaman proyek kehidupan nyata. Pelatihan ini akan membantu Anda memahami Layanan Mikro secara mendalam dan membantu Anda mencapai penguasaan atas subjek tersebut.
Ada pertanyaan untuk kami? Harap sebutkan di bagian komentar ' Arsitektur Microservice 'Dan saya akan menghubungi Anda kembali.