Bagian 1: Cara Membangun Microservices API gateway menggunakan OpenResty

Dalam artikel ini, mari kita lanjutkan ke bab-bab tentang OpenResty dalam aksi. Saya akan menggunakan tiga bab untuk memperkenalkan cara mengimplementasikan sebuah API gateway mikroservis. Dalam proses ini, kita tidak hanya akan melibatkan pengetahuan OpenResty yang telah kita pelajari sebelumnya, tetapi saya juga akan menunjukkan kepada Anda bagaimana membangun produk baru dan proyek open-source dari awal dari berbagai dimensi seperti industri, produk, dan pemilihan teknologi.

Apa yang Dilakukan oleh API Gateway Mikroservis?

Mari kita lihat terlebih dahulu peran dari API gateway mikroservis. Gambar di bawah ini adalah deskripsi singkatnya:

Seperti yang kita ketahui, API gateway bukanlah konsep baru. Ini telah ada lebih dari sepuluh tahun yang lalu. Fungsinya terutama adalah sebagai pintu masuk lalu lintas dan untuk memproses permintaan terkait bisnis secara terpadu. Dengan demikian, permintaan dapat diproses dengan lebih aman, cepat, dan akurat. Ini memiliki fungsi tradisional berikut:

• Reverse proxy dan load balancing, yang konsisten dengan posisi dan fungsi NGINX;
• Fungsi dinamis seperti upstream dinamis, sertifikat SSL dinamis, dan pembatasan arus serta laju dinamis saat runtime, adalah fungsi yang tidak dimiliki oleh versi open-source NGINX;
• Pemeriksaan kesehatan aktif dan pasif dari upstream, serta pemutus sirkuit layanan;
• Mengembangkan API gateway menjadi platform manajemen API siklus hidup penuh.

Dalam beberapa tahun terakhir, lalu lintas terkait bisnis tidak lagi hanya dimulai oleh klien PC dan browser, tetapi lebih banyak berasal dari ponsel dan perangkat IoT. Dengan populernya 5G di masa depan, lalu lintas ini akan meningkat. Pada saat yang sama, seiring dengan perubahan struktur arsitektur mikroservis, lalu lintas antar layanan juga mulai tumbuh secara eksplosif. Dalam skenario bisnis baru ini, semakin banyak fungsi canggih dari API gateway secara alami muncul:

1. Ramah cloud-native, arsitektur harus menjadi ringan dan mudah untuk dikontainerisasi.
2. Menghubungkan Prometheus, Zipkin, SkyWalking, dan komponen statistik serta pemantauan lainnya.
3. Mendukung proxy gRPC, dan konversi protokol antara HTTP dan gRPC, mengubah permintaan HTTP pengguna menjadi permintaan gRPC layanan internal.
4. Mengambil peran sebagai OpenID Relying Party, terhubung dengan layanan penyedia autentikasi seperti Auth0 dan Okta, dan memperlakukan keamanan lalu lintas sebagai prioritas utama.
5. Mewujudkan Serverless dengan mengeksekusi fungsi pengguna secara dinamis saat runtime, membuat node tepi gateway lebih fleksibel.
6. Tidak mengunci pengguna dan mendukung arsitektur deployment hybrid cloud.
7. Node gateway harus bebas status dan dapat diperluas serta dikurangi secara bebas.

Ketika sebuah API gateway mikroservis memiliki fungsi-fungsi di atas, layanan pengguna hanya perlu memperhatikan bisnis itu sendiri. Fungsi-fungsi yang tidak terkait dengan implementasi bisnis dapat diselesaikan di tingkat gateway yang independen. Misalnya, penemuan layanan, pemutus sirkuit, autentikasi, pembatasan laju, statistik, analisis kinerja, dll.

Dari sudut pandang ini, API Gateway dapat menggantikan semua fungsi NGINX dan menangani lalu lintas utara-selatan; itu juga dapat menyelesaikan peran bidang kontrol Istio dan bidang data Envoy untuk menangani lalu lintas timur-barat.

Mengapa Menciptakan Roda Baru?

Karena status API gateway mikroservis sangat penting, ini selalu menjadi medan pertempuran, dan raksasa IT tradisional telah lama berada di bidang ini. Menurut Laporan Siklus Hidup API yang dirilis oleh Gartner pada tahun 2018, Google, CA, IBM, Red Hat, dan Salesforce adalah produsen terkemuka, dan Apache APISIX, yang lebih familiar bagi pengembang, termasuk dalam kategori visioner.

Jadi, pertanyaannya adalah, mengapa kita harus menciptakan roda baru?

Secara sederhana, ini karena tidak ada API gateway untuk mikroservis saat ini yang memadai untuk kebutuhan kita. Mari kita lihat terlebih dahulu produk komersial closed-source. Mereka memiliki fungsi yang lengkap, mencakup manajemen siklus hidup penuh dari desain API, SDK multibahasa, dokumentasi, pengujian, dan rilis, serta menyediakan layanan SaaS. Beberapa terintegrasi dengan cloud publik, yang sangat mudah digunakan. Tetapi pada saat yang sama, mereka juga membawa dua masalah.

Masalah pertama adalah masalah penguncian platform. API gateway adalah pintu masuk lalu lintas bisnis. Tidak seperti lalu lintas non-bisnis yang dipercepat oleh CDN seperti gambar dan video, yang dapat dimigrasikan secara bebas, API gateway akan mengikat banyak logika terkait bisnis. Begitu Anda menggunakan solusi closed-source, sulit untuk bermigrasi ke platform lain dengan lancar dan dengan biaya rendah.

Masalah kedua adalah masalah bahwa itu tidak dapat dikembangkan lagi. Umumnya, perusahaan besar dan menengah akan memiliki kebutuhan unik mereka sendiri dan memerlukan pengembangan yang disesuaikan, tetapi pada saat ini Anda hanya dapat mengandalkan produsen, dan tidak dapat melakukan pengembangan ulang.

Ini adalah salah satu alasan mengapa solusi API gateway open-source menjadi populer. Namun, produk open-source yang ada tidak serba bisa, dan mereka juga memiliki banyak kekurangan:

1. Bergantung pada database relasional seperti PostgreSQL dan MySQL. Dengan cara ini, node gateway hanya dapat melakukan polling ke database ketika ada perubahan konfigurasi. Ini tidak hanya menyebabkan konfigurasi berlaku lambat tetapi juga menambah kompleksitas kode, membuatnya sulit dipahami. Pada saat yang sama, database juga akan menjadi titik tunggal dan bottleneck kinerja sistem, yang tidak dapat menjamin ketersediaan tinggi secara keseluruhan. Jika Anda menggunakan API gateway di lingkungan Kubernetes, database relasional akan lebih rumit, yang tidak mendukung penskalaan cepat.
2. Plugin tidak dapat dimuat secara panas. Ketika Anda menambahkan plugin baru atau memodifikasi kode plugin yang ada, Anda harus memuat ulang layanan untuk membuatnya berlaku. Ini sama dengan kebutuhan untuk memuat ulang setelah memodifikasi konfigurasi NGINX, yang akan memengaruhi permintaan pengguna.
3. Struktur kode kompleks dan sulit dipahami. Beberapa proyek open-source telah membuat enkapsulasi berorientasi objek multi-layer, dan beberapa logika sederhana menjadi kabur. Namun, untuk skenario API gateway, ekspresi langsung akan lebih jelas dan efisien, dan juga lebih mendukung pengembangan ulang.

Oleh karena itu, kita membutuhkan API gateway yang lebih ringan, ramah cloud-native, dan ramah pengembangan. Tentu saja, kita tidak bisa membangun mobil di belakang pintu tertutup. Kita perlu memahami dengan mendalam karakteristik API gateway yang ada. Pada saat ini, panorama Cloud Native Software Foundation (CNCF) adalah referensi yang baik:

Komponen Inti dan Konsep API Gateway

Tentu saja, sebelum mengimplementasikannya, kita perlu memahami komponen inti dari API Gateway. Menurut fungsi API gateway yang telah kita sebutkan sebelumnya, setidaknya diperlukan komponen berikut untuk mulai berjalan.

Pertama adalah Route. Ini mencocokkan permintaan klien dengan mendefinisikan beberapa aturan, kemudian memuat dan mengeksekusi plugin yang sesuai berdasarkan hasil pencocokan, dan meneruskan permintaan ke upstream yang ditentukan. Aturan pencocokan routing ini dapat terdiri dari host, uri, header, dll. Lokasi yang familiar di NGINX adalah implementasi dari routing.

Kedua adalah plugin, jiwa dari API gateway. Fungsi seperti autentikasi, pembatasan lalu lintas dan laju, pembatasan IP, Prometheus, Zipkin, dll., semuanya diimplementasikan melalui plugin. Karena ini adalah plugin, itu harus plug-and-play; lebih jauh, plugin tidak dapat berinteraksi satu sama lain. Seperti kita membangun balok Lego, kita perlu menggunakan aturan seragam dan antarmuka pengembangan yang disepakati untuk berinteraksi dengan lapisan bawah.

Selanjutnya adalah schema. Karena ini adalah gateway untuk memproses API, perlu untuk memverifikasi format API, seperti tipe data, konten bidang yang diizinkan, bidang yang harus diunggah, dll. Pada saat ini, diperlukan lapisan schema untuk definisi dan pemeriksaan yang seragam dan independen.

Terakhir adalah penyimpanan. Ini digunakan untuk menyimpan berbagai konfigurasi pengguna dan bertanggung jawab untuk mendorong ke semua node gateway ketika ada perubahan. Ini adalah komponen dasar yang sangat kritis di lapisan bawah. Pilihannya menentukan bagaimana plugin lapisan atas ditulis, apakah sistem dapat mempertahankan ketersediaan tinggi dan skalabilitas, dll., jadi kita perlu membuat keputusan yang hati-hati.

Selain itu, di atas komponen inti ini, kita juga perlu mengabstraksikan beberapa konsep umum API gateway, yang umum di antara berbagai API gateway.

Route

Mari kita bicara tentang Route terlebih dahulu. Sebuah rute akan terdiri dari tiga bagian: kondisi pencocokan, plugin yang terikat dan upstream, seperti yang ditunjukkan pada gambar berikut:

Kita dapat menyelesaikan semua konfigurasi langsung di Route, yang merupakan cara termudah. Tetapi dalam kasus banyak API dan upstream, melakukan hal ini akan menyebabkan banyak konfigurasi duplikat. Pada saat ini, kita membutuhkan dua konsep Service dan Upstream untuk membuat lapisan abstraksi.

Service

Mari kita lihat Service berikutnya. Ini adalah abstraksi dari jenis API tertentu, dan juga dapat dipahami sebagai abstraksi dari sekelompok Route. Ini biasanya memiliki korespondensi 1:1 dengan layanan upstream, dan hubungan antara Route dan Service biasanya N:1. Saya juga menggunakan gambar untuk mewakili:

Melalui lapisan abstraksi Service ini, kita dapat memisahkan Plugin dan Upstream yang duplikat. Dengan cara ini, ketika Plugin dan Upstream berubah, kita hanya perlu memodifikasi Service alih-alih memodifikasi data yang terikat pada beberapa Route.

Upstream

Terakhir, mari kita bicara tentang Upstream. Melanjutkan contoh di atas, jika upstream dalam dua Route adalah sama, tetapi plugin yang terikat berbeda, maka kita dapat mengabstraksikan upstream secara terpisah, seperti yang ditunjukkan pada gambar berikut:

Dengan cara ini, ketika node upstream berubah, Route sama sekali tidak menyadarinya, dan semuanya diproses di dalam Upstream.

Dari proses derivasi tiga konsep utama ini, kita juga dapat melihat bahwa abstraksi ini didasarkan pada skenario penggunaan praktis daripada imajinasi. Ini berlaku untuk semua API gateway, terlepas dari solusi teknis tertentu.

Ringkasan

Dalam artikel ini, kami memperkenalkan peran, fungsi, komponen inti, dan konsep abstrak dari API gateway mikroservis, yang merupakan dasar dari API gateway.

Berikut adalah pertanyaan untuk Anda pikirkan: "Mengenai lalu lintas utara-selatan tradisional dan lalu lintas timur-barat antara mikroservis, apakah Anda pikir API gateway dapat menangani keduanya?" Jika Anda sudah menggunakan API gateway, Anda juga dapat menuliskan pemikiran Anda tentang pemilihan teknologi. Selamat berkomunikasi dan berdiskusi, dan Anda dipersilakan untuk membagikan artikel ini dengan rekan dan teman Anda untuk belajar dan berkembang bersama.

Selanjutnya: Bagian 2: Cara Membangun API Gateway Mikroservis Menggunakan OpenResty Bagian 3: Cara Membangun API Gateway Mikroservis Menggunakan OpenResty