Berhenti Menggunakan Spring Cloud Gateway! Bagaimana Aplikasi Fintech Huanbei Memanfaatkan Apache APISIX

Cinta & Benci terhadap Java

Mengapa Sistem Keuangan Lebih Memilih Java

Java selalu populer dan menjadi pilihan banyak pengembang sejak dirilis karena keunggulan bahasanya dan ekosistem yang besar.

Dalam 15 hingga 20 tahun terakhir, banyak sistem keuangan memilih Java sebagai tumpukan teknologi utama mereka. Setelah beberapa investigasi, kami menyimpulkan keunggulan Java berikut:

Karena alasan di atas, Java mendapatkan favorit dari sistem perangkat lunak keuangan.

Status Quo Java di Era Cloud-Native

Dengan perkembangan teknologi yang pesat, industri akan segera meninggalkan arsitektur monolitik, dan microservices serta cloud-native akan menjadi arus utama. Namun, dalam lingkungan teknologi beberapa tahun terakhir, Java mulai kehilangan peran dominannya dalam beberapa skenario bisnis.

Pertama, Java memiliki kinerja yang lemah; Anda akan memahami mengapa saya mengatakan ini dengan membandingkan Java dengan tumpukan teknologi terkait C.

Kedua, Java berjalan di atas mesin virtual, dan mesin virtual tersebut mengelola manajemen memori Java. Oleh karena itu, Java menjadi kurang kompetitif ketika dibutuhkan kinerja tinggi atau perubahan dinamis.

Selain itu, Java membutuhkan lebih banyak sumber daya. Sebuah framework mudah dibangun tanpa mempertimbangkan biaya. Namun, karena komputasi telah menjadi lebih detail dan granular di era cloud-native, sumber daya menjadi lebih berharga dari sebelumnya. Selain itu, Java akan memakan banyak sumber daya untuk dijalankan karena berat dan perlu di-restart dari waktu ke waktu. Akibatnya, Java akan mengalami masalah dengan permintaan QPS yang tinggi dan kelangsungan bisnis.

Terakhir tetapi tidak kalah penting, masalah pointer juga patut dibahas. Pointer adalah sumber daya yang baik bagi pengembang yang terbiasa dengan C/C++. Namun, Java berjalan di atas mesin virtual, yang berarti manajemen memori ditangani oleh GC (Garbage Collection) alih-alih pengembang. Dalam kasus tersebut, kinerja Java mungkin tidak cukup untuk beberapa situasi ketika ada tuntutan ketat untuk konkurensi tinggi, lalu lintas, dan kinerja.

Mengapa HuanBei Memilih APISIX

Shuhe Group adalah platform teknologi keuangan yang menyediakan layanan efisien dan cerdas untuk perusahaan dan individu dalam bisnis; mereka memiliki produk seperti HuanBei, EnjoyPay, dll. HuanBei adalah platform yang menawarkan layanan cicilan yang melayani berbagai skenario konsumsi. Dengan bekerja sama dengan lembaga keuangan berlisensi, HuanBei juga menyediakan layanan pinjaman pribadi dan menawarkan dana pinjaman startup. HuanBei selalu menggunakan tumpukan teknologi Java untuk mengembangkan produknya dalam bisnis.

Spring Cloud Gateway adalah gateway yang bertujuan untuk mengelola microservices dengan lebih baik di bawah ekosistem Spring Cloud. Spring Cloud Gateway adalah API gateway yang baik untuk perusahaan yang menggunakan Java sebagai bahasa pengembangan utama mereka. Namun, dalam pembaruan API gateway baru-baru ini, HuanBei meninggalkan Spring Cloud Gateway yang telah lama digunakan dan mulai menggunakan Apache APISIX.

Perbedaan Arsitektur Antara Spring Cloud Gateway & APISIX

HuanBei menggunakan tiga sistem API gateway yang berbeda sebelum mengadaptasi APISIX. HuanBei menggunakan Spring Cloud Gateway sebagai gateway sistem operasi dan keluar serta OpenResty sebagai gateway sistem bisnis.

HuanBei menggunakan Spring Cloud Gateway sebagai gateway sistem operasi dan keluar awalnya karena Spring Cloud Gateway memiliki ekosistem yang besar dan sistem pengembangan terdistribusi yang mudah di-deploy & mudah di-maintain. Untuk membangun model bisnis dengan cepat, HuanBei menggunakan semua layanan yang disediakan oleh Spring Cloud ketika fondasi bisnis dibangun.

Dengan perkembangan bisnis, gateway mulai mengalami beberapa masalah stabilitas dalam arsitektur asli, seperti overflow memori, penggunaan CPU tinggi, dll. Oleh karena itu, HuanBei menggunakan Apache APISIX sebagai satu-satunya gateway dalam arsitektur untuk meningkatkan kinerja gateway dan mengelola beberapa gateway secara seragam.

Dalam kerangka gateway baru, gateway akan langsung mentransfer lalu lintas permintaan ke sistem bisnis melalui service discovery. Namun, jika aplikasi backend tidak mendukung service discovery atau tidak memiliki Pod yang sehat di Consul, sistem akan mengalihkan lalu lintas ke K8s Ingress intranet sebelumnya.

Aplikasi Praktis APISIX

Huanbei harus memodifikasi konfigurasi APISIX dalam skenario bisnis nyata karena tidak dapat langsung menggunakan Apache APISIX karena memiliki beberapa kerangka gateway internal.

Pembangunan & Deployment APISIX

Selama pengembangan internal, HuanBei menempatkan kode sumber gateway APISIX dan kode kustom di jalur rute yang berbeda dan membiarkan mereka bekerja sama dan beriterasi secara independen. HuanBei menggunakan gambar Docker untuk mendeploy gateway. Pertama, ia akan membuat gambar default berdasarkan versi tertentu APISIX, dan kemudian menggunakan kode kustom untuk membungkusnya menjadi gambar baru.

Pembungkusan kode kustom tidak menggunakan lua_package_path untuk menentukan direktori kode; alih-alih, ia langsung menimpa gambar default apisix di bawah direktori kode sumber jika ada file dengan nama yang sama. Dockerfile ditunjukkan di bawah ini:

FROM registry.xxx.net:5001/apisix-shuhe:v1.5
ENV APP_NAME={{APP_NAME}}
COPY {{PRODUCT_FILE}} /tmp/deploy2/artifact.tar.gz

RUN mkdir /tmp/deploy/ && tar -xf /tmp/deploy2/artifact.tar.gz -C /tmp/deploy/ && \
cp -R /tmp/deploy/apisix/ /usr/local/apisix/ && \
cp /tmp/deploy/bin/apisix /usr/bin/apisix && \
cp /tmp/deploy/conf/apisix-$APP_NAME.yaml /usr/local/apisix/conf/apisix.yaml && \
cp /tmp/deploy/conf/config-$APP_NAME.yaml /usr/local/apisix/conf/config.yaml && \
set -x && \
bin='#! /usr/local/openresty/luajit/bin/luajit\npackage.path = "/usr/local/apisix/?.lua;" .. package.path' && \
sed -i "1s@.*@$bin@" /usr/bin/apisix && \
rm -rf /tmp/*

Log APISIX disimpan secara lokal (bisa dikumpulkan oleh Syslog atau plugin lain); kita bisa memodifikasi template konfigurasi NGINX dan memeriksa Profile yang digunakan untuk memutuskan apakah kita ingin menyimpan log secara lokal atau menyimpannya di FLUENTD melalui Syslog. Kita juga perlu mengganti variabel FLUENTD_HOST saat membangun gambar seperti yang ditunjukkan di bawah ini:

{% **if** gw_profile and **string**.find( gw_profile,'local') then %}
access_log logs/access.**log** main;error_log logs/
**error**.**log** warn;
{%else%}
access_log syslog:server=${FLUENTD_HOST}:5141 json_format;
error_log syslog:server=${FLUENTD_HOST}:5142 warn;
{%end%}

Dalam template konfigurasi NGINX, HuanBei tidak hanya memodifikasi penyimpanan log tetapi juga menambahkan variabel lingkungan ENV dan konfigurasi lua_shared_dicts dalam loop serta memperbaiki beberapa parameter optimasi NGINX.

HuanBei memisahkan lalu lintas berdasarkan kebutuhan bisnis yang berbeda dan membuat beberapa gateway dengan fungsionalitas yang serupa. Oleh karena itu, HuanBei menggunakan rencana "satu kode sumber tetapi beberapa aplikasi gateway" secara internal. Pertama, HuanBei mengonfigurasi file config-xxx.yaml setiap gateway dengan menggunakan fungsi Profile, dan kemudian dapat membangun gambar Docker gateway yang berbeda berdasarkan nama aplikasinya saat membangun gambar melalui platform DevOps.

Plugin Kustom Tingkat Perusahaan

Saat mengunjungi sistem operasi secara internal, sistem akan memanggil banyak API backend untuk mengambil data, dan API ini perlu dimasukkan dalam whitelist konfigurasi API gateway. Sistem izin harus memelihara daftar API terkait karena halaman akan menawarkan berbagai rentang API berdasarkan peran setiap pengguna yang login di sistem operasi. Setiap kali ada panggilan API baru dari halaman, pengembang perlu menambahkan konfigurasi dua kali di gateway dan sistem izin, yang berlebihan dan berulang.

Untuk mencapainya, HuanBei menghilangkan penghalang antara konfigurasi gateway dan konfigurasi sistem izin, dan hanya menyimpan pintu masuk sistem izin. Sistem manajemen konfigurasi gateway akan mengambil API izin secara berkala dan kemudian mengubahnya menjadi konfigurasi whitelist API gateway. Perilaku ini akan menghilangkan satu tindakan konfigurasi pengguna yang tidak diperlukan dan membantu sistem izin melakukan kontrol izin. Selain itu, ini menjamin bahwa API backend yang dipanggil di halaman operasi ada dalam konfigurasi sistem izin.

Dalam skenario bisnis, selalu ada beberapa kebutuhan yang tidak dapat dipenuhi oleh plugin asli, yang membutuhkan pengembangan kustom. APISIX menyediakan banyak alat yang dapat membantu mengkustomisasi plugin asli dengan mudah. Tabel berikut mencantumkan beberapa plugin kustom yang dikembangkan berdasarkan APISIX di dalam HuanBei:

Rilis Canary Gateway

Sebelumnya HuanBei menggunakan OpenShift sebagai kontainer K8s-nya (saat ini telah ditingkatkan ke cluster ACK), dan Ingress dibangun dengan Haproxy.

Karena Haproxy Ingress K8s jaringan publik tidak dapat membagi lalu lintas domain tunggal ke dua jalur rute Namespace yang berbeda, kita perlu mempertimbangkan untuk mendeploy gateway baru di Namespace yang sama dengan gateway lama. Dengan kata lain, setiap jalur rute domain akan memiliki beberapa layanan, dan kita dapat mengontrol lalu lintas gateway baru dan lama dengan menetapkan porsi yang berbeda dari total lalu lintas.

Alur implementasi aktual ditunjukkan di bawah ini, ia akan menambahkan grup c dan d untuk mendeploy gateway baru di bawah Namespace gateway lama, dan dapat mengontrol proporsi lalu lintas gateway baru dan lama.

Faktor Gateway yang Terkait dengan Java

Banyak pengembang Java akan memilih Spring Cloud dalam arsitektur microservice karena Spring Cloud dapat mendukung Java dengan mulus, dan menyematkan pustaka kelas dalam kode sumber. Namun, situasi sulit dalam peningkatan muncul dalam praktik. Misalnya, jika tim perlu memelihara beberapa pustaka kelas, dan ada 10 bahasa berbeda dengan 10 versi berbeda, maka tim ini perlu memelihara 100 pustaka kelas yang berbeda.

Saat ini, kita dapat dengan mudah menggunakan proxy (API gateway) untuk menyelesaikan masalah multi-versi dan multi-bahasa. Jadi, apa manfaat bagi perusahaan yang menggunakan tumpukan teknologi Java dan memilih APISIX sebagai API gateway mereka? Kami menyimpulkan berdasarkan dua aspek dari pengalaman praktis HuanBei.

Untuk Perusahaan

1. Fungsi & Kinerja yang Hebat

QPS APISIX bisa mencapai 80k jika HuanBei menggunakan mesin virtual 4-core tanpa plugin apa pun untuk menguji stres APISIX. Selain itu, APISIX dengan sempurna menyelesaikan masalah kinerja Spring Cloud Gateway saat menerima lalu lintas konsumen, dan kinerjanya meningkat 30% di lingkungan produksi dibandingkan dengan gateway sebelumnya.

Selain itu, APISIX dapat memenuhi semua persyaratan perusahaan dalam pengujian aktual, seperti autentikasi dan identifikasi, observabilitas, service discovery, pembatasan laju, dan transfer lalu lintas lapisan empat dan tujuh. Mengenai ekstensi fitur, APISIX mendukung lebih dari 70 plugin, dan sebagian besar bisnis dapat menggunakan plugin aslinya, yang mengurangi banyak pekerjaan pengembangan.

2. Mengurangi Biaya Bisnis

Sebelum menggunakan APISIX, perusahaan harus menambah jumlah server untuk menyelesaikan masalah kinerja, yang secara signifikan meningkatkan biaya perangkat keras.

HuanBei telah menghitung biaya, dan menemukan bahwa biaya server telah berkurang sekitar 60% setelah menggunakan APISIX. Selain itu, setelah menyatukan tumpukan teknologi, bisnis dapat memperluas fitur yang berbeda dengan cepat berdasarkan arsitektur asli APISIX, mengurangi biaya pengembangan, dan mempercepat waktu rilis produk.

Untuk Pengembang

1. Memenuhi Kebutuhan Bisnis

Semua perangkat lunak atau teknologi yang digunakan dalam bisnis harus melayani kebutuhan. Namun, dari hasil pengujian dan penelitian praktis, APISIX memiliki stabilitas, observabilitas, dan kemampuan ekstensi yang lebih baik.

Perangkat lunak bertujuan untuk melayani bisnis. Oleh karena itu, jika kebutuhan bisnis dapat membantu perusahaan menghemat sumber daya, tidak peduli tumpukan teknologi apa yang digunakan perusahaan ini, ia juga harus menggunakan komponen yang sesuai dengan perusahaan.

2. Mengurangi Biaya Pemeliharaan

Dibandingkan dengan OpenResty yang sebelumnya digunakan, APISIX memiliki biaya pembelajaran yang lebih rendah dan lebih mudah di-maintain. Sementara itu, plugin APISIX yang kaya menyederhanakan deployment dan pengembangan beberapa fitur standar, mengurangi waktu rilis produk.

Sementara itu, fitur log dan debugging dinamis APISIX yang kuat membantu mendeteksi titik kegagalan dalam bisnis sehingga kita dapat dengan cepat menemukan kesalahan dan menghemat waktu.

Kesimpulan: Tren Pengembangan Industri Keuangan

Pada tahap pertumbuhan yang brutal, satu-satunya hal yang penting adalah efisiensi. Jadi direktur akan lebih memilih bahasa yang mereka kenal untuk membangun sistem dan memilih tumpukan teknologi yang berbeda selama pemilihan kerangka kerja tingkat rendah untuk meluncurkan model bisnis dengan lebih cepat. Direktur yang berbeda akan memilih tumpukan teknologi yang berbeda, yang akan menyebabkan banyak masalah di masa depan. Namun, sebagian besar perusahaan keuangan aktif dan perusahaan layanan keuangan akan menghadapi masalah teknis yang sama: masalah multi-tumpukan teknologi. Ketika masalah ini terjadi, mereka perlu menggabungkan tumpukan teknologi mereka menjadi satu.

Ketika bisnis perusahaan berjalan dengan baik, saatnya bagi perusahaan untuk memisahkan sistemnya secara vertikal. Perusahaan perlu mengubah arsitektur silo informasi menjadi arsitektur tiga lapis yang terdiri dari front-end, middle-end, dan back-end. Kemudian, ketika sistem beroperasi dengan stabil, saatnya bagi perusahaan untuk mengimplementasikan komponen tingkat rendah sendiri.

Tujuan akhir membangun sistem adalah untuk berbagi. Sistem memiliki biaya pemeliharaan yang lebih rendah jika memiliki pengulangan yang lebih baik. Oleh karena itu, ketika operasi bisnis stabil, banyak perusahaan mulai memisahkan secara vertikal atau mengimplementasikan komponen dasar tingkat rendah untuk mengontrol biaya pemeliharaan.

Bagi perusahaan, biaya selalu menjadi prinsip terpenting yang harus dipertimbangkan. Pada tahap pertumbuhan yang brutal, perusahaan hanya perlu meluncurkan dan membiarkan bisnis beroperasi secepat mungkin. Namun, biaya harus memiliki prioritas tertinggi di bawah anggaran dalam lingkungan besar ini. Dalam kasus tersebut, kita harus memilih antara efisiensi dan biaya. Oleh karena itu, perusahaan tidak akan menggunakan teknologi terbaru jika anggaran terbatas. Demikian pula, staf teknis tidak akan mempertimbangkan pertanyaan berikut ketika mereka memilih tumpukan teknologi: Bagaimana teknologi baru ini akan memengaruhi tim? Berapa banyak manfaat yang bisa dibawa oleh teknologi baru ini ke infrastruktur saat ini?

Staf teknis hanya akan mempertimbangkan biaya teknologi baru ini.