Apa Itu Service Discovery dalam Microservices

Apa Itu Service Discovery? Mengapa Anda Membutuhkannya?

Pada awal masa internet, orang harus memasukkan rangkaian panjang alamat IP untuk mengakses layanan online. Alamat IP tidak panjang, tetapi sebagai rangkaian angka yang tidak bermakna, mengingat alamat spesifik dari layanan tertentu adalah tantangan, yang mengarah pada penemuan sistem nama domain. Setiap layanan online mendaftarkan nama domain ke penyedia nama domain dan kemudian membangun tautan antara nama domain dan alamat IP tertentu melalui DNS (Domain Name System). Dengan cara ini, orang dapat dengan mudah mengetikkan nama domain yang mudah diingat dan mengakses layanan online pada alamat IP tertentu, yang merupakan bentuk awal dari service discovery.

Ketika jumlah layanan dalam sebuah perusahaan mencapai ukuran tertentu (misalnya, dibagi menjadi microservices), ada juga masalah bahwa alamat IP sangat sulit diingat, sehingga diperlukan sistem service discovery. Layanan dalam perusahaan mendaftar ke sistem, dan layanan lain yang ingin mengaksesnya mencari alamat IP yang sesuai dari sistem, sehingga tidak perlu layanan "mengingat" alamat IP yang kompleks dan berubah-ubah.

Perubahan alamat IP dapat membingungkan pengunjung.

Dengan memperkenalkan DNS sebagai mekanisme service discovery, perubahan IP sekarang dapat ditangani dengan fleksibel.

Pengenalan Sistem Service Discovery Umum

Sebagai sistem service discovery, setidaknya perlu memenuhi empat fungsi:

1. API untuk pendaftaran
2. API untuk query
3. Ketersediaan tinggi: bagaimanapun, sistem service discovery adalah saraf dari seluruh sistem dan tidak boleh lumpuh atau crash
4. Ekosistem: seperti yang kita tahu, programmer malas dan lebih suka memiliki pustaka yang dapat berinteraksi dengan API dengan mudah

Mari kita lihat beberapa sistem service discovery open-source utama di pasaran:

Consul

Consul adalah sistem service discovery yang dikembangkan oleh Hashicorp, perusahaan open-source terkemuka. Sebagai perangkat lunak yang sudah lama ada yang merilis versi pertamanya pada 17 April 2014, Consul memiliki salah satu ekosistem terkaya dan bahkan memiliki pengembang pihak ketiga yang mengembangkan SDK Haskell untuknya. Sebagian besar SDK Consul hanyalah pembungkus untuk API HTTP-nya, sehingga tidak banyak pekerjaan pengembangan.

Consul mendukung pendaftaran dan query layanan melalui API HTTP. Ini mendukung HTTP long polling untuk mendorong data secara tepat waktu selama query untuk menghindari polling. Juga, Consul mendukung query instance layanan yang sesuai melalui DNS.

Penyebaran Consul menarik karena setiap instance Consul disebut sebagai agen, yang dapat berupa klien atau server. Di sisi klien, Consul mempertahankan status klien; di sisi server, Consul mendukung penyebaran terdistribusi melalui algoritma konsistensi Raft, untuk mencapai ketersediaan tinggi.

Eureka

Eureka adalah proyek yang diopen-source oleh Netflix, yang juga cukup tua (ada jejak commit sejak 2012.). Namun, proyek ini belum dirawat selama satu tahun. Banyak pengguna telah bermigrasi ke Nacos, yang akan disebutkan di bawah ini.

Eureka mendukung interaksi melalui API HTTP dan SDK Java. Banyak pengguna Eureka sebenarnya dibawa melalui proyek dalam ekosistem Java seperti Spring Cloud. Desain ketersediaan tinggi Eureka, jika Anda ingin menggambarkannya dalam CAP (Teorema CAP menyatakan bahwa sistem terdistribusi hanya dapat menyediakan dua dari tiga properti secara bersamaan: Konsistensi, Ketersediaan, dan Toleransi Partisi), adalah AP, yang memungkinkan klien melihat data yang kedaluwarsa ketika partisi jaringan, menghindari bencana sekunder karena masalah jaringan.

Nacos

Nacos adalah sistem service discovery yang dikembangkan oleh Alibaba, yang namanya berasal dari penggabungan beberapa huruf pertama dari Naming dan Configuration Service. Sejak rilis versi 0.1.0 pada 20 Juli 2018, Nacos sekarang telah berkembang ke versi 2.1.

Seperti banyak proyek open-source Alibaba, Nacos cukup populer di kalangan pengembang Java di China, dan popularitasnya bahkan lebih besar daripada Eureka.

Ini mendukung pendaftaran dan query layanan melalui API HTTP dan SDK seperti Java/Go/Python/NodeJS/C#. Saat ini, pengembang Nacos juga sedang mengerjakan API baru berdasarkan gRPC. Untuk API HTTP, Nacos saat ini hanya mendukung polling untuk daftar layanan. Jadi Nacos secara resmi lebih memilih pendekatan SDK, yang merupakan pendekatan polling + push berbasis UDP dengan kinerja real-time yang lebih baik. Nacos juga sedang mengerjakan API baru berdasarkan gRPC, yang akan memperkenalkan kemampuan push sisi server, manfaat besar bagi sistem yang tidak memiliki akses ke SDK.

Ketersediaan tinggi Nacos sebagian karena kemampuan persistensi yang disediakan dalam SDK klien, dan sebagian karena konsistensi sisi server melalui protokol Raft dan Distro.

Metode Interfacing Umum dan Kelebihan serta Kekurangannya

Mengabaikan protokol pribadi, metode interfacing service discovery dapat dibagi menjadi tiga kategori:

1. HTTP polling
2. DNS
3. HTTP long polling atau gRPC server streaming

HTTP polling sederhana untuk diimplementasikan tetapi tidak real-time.

Beban kinerja DNS minimal. DNS juga tidak real-time karena cache DNS, dan memiliki keuntungan sebagai standar yang diterima luas dan independen dari implementasi. Namun, ada dua sisi dari koin, yang berarti sistem service discovery tidak dapat menambahkan bidang tambahan ke respons DNS kecuali bidang Additional dalam respons DNS digunakan, tetapi ini memerlukan penanganan khusus oleh klien.

HTTP long polling atau gRPC server streaming adalah yang paling real-time dari ketiganya. Karena keduanya berbasis HTTP, respons dapat dengan mudah disesuaikan. Kerugiannya adalah relatif sulit untuk diimplementasikan di sisi klien.

Bagaimana APISIX Berinteraksi dengan Sistem Service Discovery

Sebagai gateway cloud-native, APISIX mendukung pengambilan node upstream dari sistem service discovery dan dirancang untuk mendukung interfacing dengan sistem service discovery baik di data plane maupun control plane.

Data Plane

APISIX mendukung integrasi dengan DNS, Eureka, Consul (mode KV), Nacos, dan K8s di data plane.

Saat berinteraksi dengan layanan DNS, APISIX akan menggunakan catatan SRV atau A/AAAA dari DNS untuk mendapatkan node upstream spesifik dari suatu layanan. Ketika permintaan dibuat untuk mengakses upstream, pertama-tama akan mencoba mengambilnya dari cache DNS. Jika tidak, akan memulai query DNS untuk mendapatkan alamat IP spesifik di dalam catatan yang sesuai.

Adapun jenis service discovery lainnya, mereka disinkronkan di latar belakang. Ketika permintaan dibuat untuk mengakses upstream, bagian data yang sesuai dengan nama layanan diambil dari data yang saat ini disinkronkan. Untuk K8s dan Consul KV, kita bisa mendapatkan alamat IP yang berubah secara real-time dengan cara ini, karena mereka mendukung HTTP long polling. Untuk Eureka dan Nacos, kami saat ini hanya melakukan polling untuk data.

Control Plane

APISIX juga mendukung service discovery di control plane. Kami sedang mengerjakan apisix-seed, yang akan menyinkronkan data dari sistem service discovery ke etcd sehingga data plane dapat menyinkronkan node upstream terbaru dari etcd.

Kami sekarang telah mengimplementasikan dukungan untuk Nacos dan Zookeeper di control plane. Karena dukungan service discovery di control plane diimplementasikan melalui SDK resmi, ini memiliki keuntungan yang tidak tersedia dengan metode HTTP biasa. Misalnya, dalam implementasi apisix-seed dari Nacos, kami mendukung push berbasis UDP, sehingga data lebih efisien waktu daripada HTTP polling.

Keuntungan Dukungan APISIX untuk Skenario Service Discovery

Dengan mengintegrasikan service discovery langsung di gateway, Anda dapat sangat menyederhanakan pekerjaan untuk menghadirkan layanan Anda secara online. Konfigurasikan APISIX untuk berinteraksi dengan sistem service discovery Anda dan biarkan APISIX melakukan sisanya untuk Anda. Misalnya, jika perusahaan Anda menggunakan Nacos sebagai sistem service discovery, yang perlu Anda lakukan adalah mengonfigurasi APISIX untuk mengaktifkan service discovery Nacos dan kemudian cukup mengonfigurasi nama layanan upstream dari APISIX dan APISIX akan secara otomatis mengambil node IP spesifik yang sesuai dengan upstream tersebut.

Ini adalah keuntungan yang dapat secara signifikan mengurangi jumlah pekerjaan yang diperlukan saat bermigrasi gateway, misalnya, dari Spring Cloud Gateway ke APISIX. Jika Spring Cloud Gateway digunakan untuk menerapkan Eureka atau Nacos untuk service discovery, transisi ke sistem baru dapat dilakukan hanya dengan mengaktifkan dukungan untuk Eureka atau Nacos dalam APISIX.

Huan Bei Loan memiliki pengalaman luas di bidang ini, dan penggantian Spring Cloud Gateway dimaksudkan untuk lebih meningkatkan stabilitas, pengawasan, akurasi, dan efektivitas.

Mengutip teks asli Huan Bei Loan:

Sebagai bisnis, biaya tetap menjadi prinsip yang harus dipertimbangkan. Dalam fase pertumbuhan liar, mungkin perlu untuk meningkatkan pertumbuhan bisnis secepat mungkin. Namun, dalam lingkungan saat ini, prioritas pasti adalah biaya dalam anggaran. Dalam hal ini, efisiensi dan biaya hanya dapat dipertahankan dengan satu cara atau lainnya. Jadi dengan biaya terbatas, perusahaan akan lebih sedikit membicarakan kemajuan teknologi. Dalam proses seleksi, staf teknis akan lebih sedikit mempertimbangkan seberapa besar dampak teknologi yang mereka pilih terhadap tim, seberapa besar manfaat yang akan dibawa ke operasi dan arsitektur yang ada, dll., tetapi lebih dari perspektif biaya.

Selain itu, APISIX mendukung konfigurasi beberapa service discovery secara bersamaan. Banyak perusahaan, karena alasan historis, mungkin memiliki beberapa sistem service discovery. Misalnya, sejauh yang saya tahu, beberapa perusahaan akan memiliki service discovery Eureka lama dan service discovery Nacos baru. APISIX hanya perlu mengaktifkan Eureka dan Nacos untuk menghadapi situasi ini.

Jika Anda saat ini mengonfigurasi node upstream langsung di APISIX, Anda juga dapat mempertimbangkan untuk menyebarkan sistem service discovery terpisah dan membiarkan sistem service discovery menyimpan konfigurasi node spesifik. Manfaat memindahkan konfigurasi node upstream, dari APISIX, ke sistem service discovery khusus adalah bahwa klien dapat melakukan pendaftaran layanan sendiri, dan sistem service discovery khusus sering menyediakan fungsionalitas tambahan seperti pemeriksaan kesehatan yang lebih kaya.

Di masa depan, kami juga akan mendukung integrasi berbagai komponen pendaftaran dan penemuan layanan pada APISIX Ingress Controller untuk memudahkan pengguna. Pada saat itu, pengguna tidak hanya dapat menentukan endpoint layanan K8s sebagai node upstream pada APISIX Ingress Controller, tetapi juga dapat mengintegrasikan node yang diperoleh oleh service discovery.