Open-Source Project

Community-Driven

High Availability, Stability

Ultimate Performance,

Developer Friendly

Go for Apache APISIX

Looking for the best API Gateway?

Companies choose Apache APISIX as their API gateway after comparing it with Kong. Not only is Apache APISIX is faster, but the experience is also excellent.

Apache APISIX vs Kong:

## Latar Belakang

Dalam beberapa tahun terakhir, banyak perangkat lunak konferensi online terkenal muncul seiring dengan perkembangan pertemuan online dan kerja jarak jauh. Salah satu yang paling terkenal, Zoom, telah menjadi alat pertemuan populer untuk kantor rumah, pengajaran online, dan skenario sosial. Zoom memiliki 350 juta peserta rapat harian dan hampir 470.000 pelanggan bisnis berbayar yang menggunakan platform ini. Selain itu, data terbaru menunjukkan bahwa jumlah menit yang digunakan untuk fasilitasi rapat telah mencapai lebih dari 3,3 triliun per tahun.

Namun, seperti perusahaan SaaS dan internet lainnya, Zoom menghadapi tantangan teknis seiring dengan ekspansi bisnisnya yang cepat.

- **Sejumlah besar layanan mikro**: Karena pertumbuhan bisnis dan tim Zoom yang cepat, lebih dari 100 layanan backend perlu dikirimkan. Namun, sulit untuk mengelola sejumlah besar layanan mikro secara efisien.

- **Berbagai lingkungan penyebaran**: Perusahaan SaaS sering menghadapi skenario di mana pelanggan harus melakukan penyebaran di cloud khusus, cloud pribadi, dan multi-cloud. Layanan bisnis Zoom tersebar di seluruh dunia, sehingga ada tantangan teknis dengan sejumlah besar lingkungan cloud hybrid.

- **Infrastruktur yang kompleks**: Perusahaan internet menengah dan besar umumnya memiliki tim infrastruktur khusus yang bertanggung jawab atas gateway API, pusat konfigurasi, manajemen kunci, log, pemantauan alarm, database, dll.
Karena tim R&D Zoom tersebar secara global, merupakan tantangan besar untuk mengintegrasikan middleware dan infrastruktur yang kompleks ini ke dalam pipeline pengiriman berkelanjutan.

**Tantangan di atas bukanlah hubungan aditif yang sederhana, melainkan hubungan multiplikatif. Dengan kata lain, situasi sebenarnya jauh lebih kompleks.** Namun, alat sumber terbuka yang sebelumnya digunakan oleh Zoom tidak lagi memenuhi persyaratan Zoom saat ini. Itulah mengapa pipeline pengiriman berkelanjutan yang andal sangat penting.

Berikut adalah alasan rinci mengapa Zoom tidak melanjutkan penggunaan alat sumber terbuka sebelumnya.

| Helm/Kustomize  | Terraform/Pulumi  | KubeVela + Crossplane  |
| ------------ | ------------ | ------------ |
| Tidak dapat menghubungkan sistem selain Kubernetes  | Sulit menggunakan Terraform di lapisan Kubernetes dan middleware kecuali mengembangkan Provider tambahan  | Teknologi yang terlalu baru dengan pembaruan cepat, tidak cukup aman dan stabil untuk diadopsi di lingkungan produksi  |
| Sulit mengontrol platform secara terpusat dalam mode sub-repositori Git  | Meningkatkan biaya mempelajari bahasa manajemen konfigurasi lain: hcl  | Definisi Trait + template Cuelang Kubevela dan kemampuan ekspresi pemrogramannya tidak cukup untuk mencakup berbagai platform middleware non-cloud-native di luar sistem Kubernetes  |
| Sulit memelihara dan men-debug karena logika template Helm Chart yang kompleks  | Mode kontrol terpusat Mono Repo tidak cocok untuk tim besar  | /  |
| Sistem parameter yang tidak cukup kuat untuk mengelola parameter dinamis di sejumlah besar lingkungan  | /  | /  |

Karena keterbatasan alat sumber terbuka di atas, Zoom akhirnya menyelidiki beberapa solusi utama untuk membangun pipeline pengiriman berkelanjutan dasar.

Setelah beberapa putaran perbandingan dan verifikasi, Zoom akhirnya memilih APISIX Ingress Controller untuk mendukung pipeline pengiriman berkelanjutan barunya.

## Apache APISIX Ingress Controller

### Apa itu Apache APISIX Ingress Controller?

[Apache APISIX Ingress Controller](https://github.com/apache/apisix-ingress-controller) adalah pengontrol ingress cloud-native yang menggunakan Apache APISIX sebagai bidang data untuk membawa lalu lintas dan memperluas fungsionalitas Kubernetes menggunakan CRD (CustomResourceDefinition). Ini bertanggung jawab untuk berinteraksi dengan server API Kubernetes, menerapkan kontrol akses berbasis peran (RBAC), memantau perubahan, menerapkan konversi objek dalam pengontrol Ingress, membandingkan perubahan, dan kemudian menyinkronkannya ke Apache APISIX. Selain itu, ini dapat mendukung sumber daya kustom, termasuk APISIX Route, APISIX Upstream, dan ingress asli Kubernetes lainnya, untuk mengontrol lalu lintas eksternal yang mengakses layanan yang disebarkan di Kubernetes.

Berikut adalah [Diagram Waktu APISIX Ingress Controller](https://apisix.apache.org/docs/ingress-controller/design/#timing-diagram).

![Diagram Waktu APISIX Ingress](https://static.api7.ai/2022/10/27/635a5613af56a.jpeg)

## Mengapa Zoom Memilih APISIX Ingress Controller?

Menurut latar belakang di atas, muncul pertanyaan: seperti apa pipeline pengiriman berkelanjutan yang ingin dibangun Zoom, dan bagaimana Zoom mengadopsi APISIX Ingress untuk membangun pipeline pengiriman berkelanjutan dasarnya?

Zoom sebelumnya menggunakan NGINX sebagai gateway API. Namun, dengan perkembangan bisnis yang cepat dan peningkatan layanan mikro, keterbatasan solusi NGINX saat ini semakin terlihat.

Tim yang berbeda harus memelihara NGINX secara terpisah, dan ribuan baris file konfigurasi NGINX membuat pemeliharaan menjadi sulit. Selain itu, NGINX tidak dapat dengan cepat melakukan scaling ketika menyebarkan banyak baris di server cloud. Tentang mode reloading NGINX, Anda dapat memeriksa [blog ini](https://api7.ai/blog/how-nginx-reload-work). Bisnis Zoom mulai berkembang menuju Ingress Controller.

Tim Gateway API meneliti beberapa solusi sumber terbuka. Setelah simulasi migrasi dan analisis konfigurasi bisnis aktual di NGINX dan sejumlah besar pengujian benchmark kinerja dan perbandingan ekosistem plugin, Zoom akhirnya memilih proyek APISIX Ingress Controller dari Apache Software Foundation, menjelajahi gateway Cloud-Native yang lebih canggih.

Mempertimbangkan skenario bisnisnya, Zoom lebih menekankan pada dua bagian berikut, yang dapat dipenuhi oleh APISIX Ingress.

- **Keamanan Data**: Zoom sangat memperhatikan privasi pelanggan dan keamanan layanan; oleh karena itu, autentikasi dan verifikasi mTLS banyak digunakan di ruang rapat online dan panggilan telepon. Namun, banyak gateway API serupa hanya dapat menyediakan layanan seperti itu dalam versi enterprise mereka, sementara APISIX Ingress memberikan kemudahan dan kenyamanan yang besar untuk mencapai tujuan ini.

- **Stabilitas Layanan**: Layanan backend Zoom memerlukan penyebaran Multi-AZ (Multi-Availability Zones) untuk ketersediaan tinggi di berbagai wilayah. Umumnya, bisnis ditempatkan di DC lain. Jika terjadi kesalahan di DC asli, lalu lintas klien perlu dialihkan ke DC lain, di mana APISIX Ingress dapat memenuhi persyaratan tersebut dengan sukses.

### Fitur Apache APISIX Ingress Controller

Menggunakan Apache APISIX sebagai bidang data untuk membawa lalu lintas bisnis, Apache APISIX Ingress Controller mewarisi keunggulan berikut dari Apache APISIX.

- **Kinerja Tinggi dan Stabilitas**: Sebagai gateway API sumber terbuka dinamis berkinerja tinggi, Apache APISIX tangguh dan stabil dalam kinerjanya, digunakan dalam banyak [skenario lalu lintas besar perusahaan](https://apisix.apache.org/blog/tags/case-studies/).

- **Komunitas yang Aktif**: Sebagai proyek gateway API sumber terbuka tingkat atas dan paling aktif, Apache APISIX memiliki komunitas yang aktif dan telah mempertahankan tingkat pertumbuhan yang sangat baik sejak hari pertama.

- **Ekosistem yang Kaya**: Apache APISIX mendukung protokol L7, termasuk HTTP(S), HTTP2, Dubbo, protokol IoT MQTT, dll. Selain itu, APISIX mendukung protokol L4 seperti TCP/UDP. Selain itu, dukungan penuh ARM64 didukung di Apache APISIX 3.0.

- **Banyak Plugin**: Ada hampir 100 plugin yang dirilis dari APISIX resmi yang dapat digunakan pengguna dengan drag and drop sederhana. Reloading panas dan orkestrasi dinamis plugin memberikan kemudahan besar bagi pengguna.

Selain itu, APISIX Ingress Controller juga memiliki keunggulan unik berikut:

- **Kompatibilitas yang Baik**: APISIX Ingress Controller mendukung beberapa versi sumber daya ingress dan dapat kompatibel dengan berbagai versi Kubernetes.

- **Pembaruan Dinamis**: Tidak perlu melakukan reload layanan saat memodifikasi rute, sertifikat, dan konfigurasi lainnya, memastikan kelancaran operasi bisnis.

- **Scaling yang Fleksibel**: Karena APISIX Ingress Controller mengadopsi struktur yang memisahkan bidang kontrol dan bidang data, kluster bidang data Apache APISIX dapat diperluas secara independen tanpa melakukan scaling pada APISIX Ingress Controller.

![Arsitektur APISIX Ingress Controller](https://static.api7.ai/2022/10/27/635a56148940c.jpeg)

- **Ramah untuk Operasi dan Pemeliharaan**: Di bawah arsitektur saat ini, pengguna dapat memilih untuk menyebarkan kluster bidang data APISIX di kluster Kubernetes atau lingkungan mesin fisik bare-metal sesuai dengan situasi aktual. Selain itu, karena pemisahan arsitektur APISIX ingress, APISIX pada bidang data membawa lalu lintas sementara APISIX ingress controller adalah komponen bidang kontrol. Oleh karena itu, kegagalan APISIX Ingress Controller tidak akan memengaruhi lalu lintas bisnis.

Setelah pemilihan gateway selesai, tim Gateway API menghadapi tantangan baru: bagaimana memigrasikan konfigurasi gateway API asli dari ratusan layanan ke APISIX Ingress? Tim Infrastruktur Zoom sedang mengembangkan pipeline pengiriman berkelanjutan, yang dapat secara signifikan mengurangi biaya migrasi dari konversi nginx.conf dan konfigurasi Ingress lainnya ke APISIX Ingress.

## Proses dan Fungsi Membangun Pipeline Pengiriman Berkelanjutan

### Pipeline Pengiriman Berkelanjutan Zoom

Pipeline pengiriman berkelanjutan adalah sistem pengiriman aplikasi end-to-end yang mengimplementasikan model tunggal untuk mendeklarasikan semua persyaratan pengiriman aplikasi dan mengatur serta mengeksekusi semua langkah pengiriman berkelanjutan dalam satu baris.

![Pipeline Pengiriman Berkelanjutan Zoom](https://static.api7.ai/2022/10/27/635a56149b270.jpg)

Ada enam bagian dalam pipeline pengiriman berkelanjutan:

1. **Persiapan**: menyiapkan sumber daya yang telah ditetapkan, termasuk infrastruktur, middleware, sumber daya layanan cloud, dll.;

2. **Konfigurasi**: menyiapkan file konfigurasi dan kunci yang diperlukan oleh aplikasi;

3. **Penyebaran**: menggunakan K8s untuk penyebaran dalam skenario cloud-native (termasuk informasi tentang kontainer, gambar kontainer, parameter, versi, dan instance);

4. **Akses**: membuat Layanan Kubernetes dan secara otomatis mengonfigurasi aturan perutean Apache APISIX Ingress jika penyebaran memerlukan akses eksternal;

5. **Observasi**: Melakukan konfigurasi terkait observabilitas, seperti pemantauan, alarm, logging, dan analisis tracing;

6. **Scaling**: Mendeklarasikan aturan scaling dinamis KEDA (Kubernetes Event-driven Autoscaling) melalui metrik pemantauan.

### Bagaimana Mengadopsi APISIX Ingress dalam Pipeline

![Ikhtisar Arsitektur Pipeline Zoom](https://static.api7.ai/2022/10/27/635a5616254ed.jpg)

**Manajemen Proyek**

Manajer Proyek lebih memperhatikan iterasi R&D dan bagaimana mengelola kemajuan rilis iteratif dan efisiensi personel pada garis waktu yang sesuai dengan iterasi. Zoom menggunakan alur kerja GitOps secara internal untuk membangun konfigurasi Gateway API ke dalam model pengiriman aplikasi. Di bawah model ini, definisi aturan perutean APISIX diintegrasikan dengan "Penyebaran" dan tautan lainnya, menyerahkan kontrol perubahan ke GitHub. Dengan pembuatan dan penggabungan cabang GitHub, pipeline mewujudkan garis waktu yang konsisten antara rilis dan rollback konfigurasi aplikasi dan gateway.

```yaml
# Cuplikan Kode Pipeline CD Zoom di Repositori Git
deploy:
  type: Deployment
  replicas: ~{ replicas, 2 }
  version: "latest"
  containers:
    - name: my-app
      image: "busybox"
      command: "echo 'Demo' && sleep 99d"
access:
  - protocol: https
    host: my-domain.my-org.com
    cert: my-tls-cert
    apisix:
      routes:
        http:
          - name: my-api
            authentication:
              # ......
            match:
              paths:
                - /my-api/*
```

Cara ini menyederhanakan manajemen rilis menjadi manajemen alur kerja dalam GitHub dan memecahkan masalah ketertinggalan waktu antara sistem hulu dan hilir yang mencocokkan perubahan ketika beberapa iterasi diproses secara bersamaan.

**Pengembangan Aplikasi**

Pengembang terutama fokus pada kemampuan perutean dan autentikasi API, yang sangat terkait dengan layanan bisnis dan harus diisi oleh pengembang untuk mencapai efek otomatis. Selain itu, mereka memperhatikan pengembangan dan implementasi fungsi bisnis dan bisnis tingkat atas, berharap dapat membangun infrastruktur yang siap pakai.

Dari kode di atas, kita dapat melihat bahwa pengembang hanya perlu mendefinisikan `Authentication` dan `Match` dalam pipeline pengiriman berkelanjutan ini. Mereka tidak perlu mengetahui logika dasar:

- Pertama, menerjemahkannya ke dalam Deployment dan Service Kubernetes.
- Kemudian, memanggil API platform untuk memverifikasi kebenaran jalur.
- Terakhir, menerjemahkannya ke dalam objek ApisixRoute.

Mengintegrasikan konfigurasi APISIX dan alur kerja pipeline pengiriman berkelanjutan memberikan cara yang lebih hemat tenaga bagi pengembang.

**Manajemen Lingkungan**

Persyaratan manajemen dan kontrol lingkungan yang kompleks sering terjadi dalam skenario toB, dan masalah pengiriman di beberapa skenario cloud pribadi, cloud khusus, dan cloud hybrid perlu dipertimbangkan.

Beberapa konfigurasi APISIX ingress diimplementasikan untuk memenuhi persyaratan menyamarkan perbedaan lingkungan. Dengan cara ini, manajer sistem dapat mengontrol secara komprehensif perbedaan di beberapa lingkungan heterogen. Semua layanan yang disebarkan ke lingkungan efektif, menghindari beban kognitif dan operasi penyebaran khusus yang disebabkan oleh perbedaan lingkungan bagi pengembang aplikasi dan operasional. Misalnya, Zoom dapat menggunakan konfigurasi kustom untuk menonaktifkan tracing untuk beberapa lingkungan, mengonversi objek ApisixRoute ke objek Ingress asli dan Anotasi NGINX Ingress, dan menggunakan gambar yang berbeda untuk menarik rahasia.

Selain itu, isolasi multi-tenant diperlukan ketika beberapa lini bisnis menggunakan lingkungan APISIX. **APISIX Ingress menyediakan pemilih Anotasi** yang memungkinkan objek ApisixRoute yang berbeda diambil oleh instance lain dari APISIX Ingress Controller.

**Manajemen Infrastruktur**

Tim Gateway API perlu mengontrol semua instance APISIX, mengonfigurasi kebijakan keamanan secara komprehensif, mengimplementasikan multi-zona ketersediaan, dan sebagainya.

Setiap plugin pipeline menyediakan item konfigurasi untuk insinyur infrastruktur. Dalam plugin `ingress-apisix`, ada properti `defaultPlugins`.

Setelah tim gateway API mengonfigurasi properti ini, pengaturan akan berlaku untuk semua layanan, yang cocok untuk strategi keamanan dan kontrol risiko yang terpadu.

## Kesimpulan

APISIX Ingress Controller memainkan peran penting dalam pipeline pengiriman berkelanjutan Zoom, mengurangi tekanan pada manajemen proyek, pengembangan aplikasi, manajemen lingkungan, dan manajemen middleware dan infrastruktur. Kasus Zoom layak dipelajari oleh perusahaan lain, dan kami berharap APISIX Ingress Controller dapat berkontribusi pada inovasi lebih banyak perusahaan.

Selain itu, Apache APISIX Ingress secara resmi merilis V1.5 pada Agustus 2022, yang menyatukan proposal semua versi API sumber daya dan meningkatkan semua versi API CRD ke V2. Pada saat yang sama, ini mendukung sebagian besar sumber daya Gateway API. Apache APISIX Ingress telah memungkinkan sumber daya Ingress untuk menggunakan plugin APISIX apa pun dengan menambahkan Anotasi baru “k8s.apisix.apache.org/plugin-config-name” ke sumber daya Ingress. Dengan cara ini, ini akan secara signifikan meningkatkan kemudahan penggunaan APISIX Ingress Controller dan mengurangi biaya bagi pengguna untuk bermigrasi dari Ingress Controller lain ke APISIX Ingress Controller.

Untuk informasi lebih lanjut, silakan periksa [Apache APISIX Ingress V1.5](https://apisix.apache.org/blog/2022/08/05/apisix-ingress-1.5rc1-release/).


Zoom mengintegrasikan APISIX Ingress Controller dalam pipeline pengiriman berkelanjutannya untuk mewujudkan manajemen keseluruhan proyek, aplikasi, lingkungan, dan manajemen infrastruktur.

Bagaimana Zoom Menggunakan APISIX Ingress dalam Pipelines Continuous Delivery-nya?

## Ikhtisar

### Tantangan

1. Lalu lintas besar mengakibatkan banyak peringatan CPU IDLE terlalu rendah setiap hari.
2. Terlalu banyak komponen yang bergantung pada arsitektur sistem.
3. Biaya O&M (Operasi dan Pemeliharaan) yang tinggi.

### Tujuan

1. Memilih API gateway yang berkinerja tinggi untuk memenuhi kebutuhan iQIYI.
2. Meminimalkan biaya migrasi.
3. Menemukan API gateway dengan komunitas yang aktif dan ekosistem yang sehat.
4. Membangun API gateway baru yang sesuai dengan tren cloud-native.

### Hasil

1. Performa meningkat **10x** dari sebelumnya, menangani **jutaan QPS setiap hari**.
2. Mudah mendukung **lebih dari 9.000 proyek bisnis API online**.
3. Berhasil mewujudkan pemulihan data bencana dari **beberapa situs dan tingkat di seluruh China**.

## Apa yang terjadi di balik iQIYI?

Cong He, insinyur R&D senior di [iQIYI](https://en.wikipedia.org/wiki/IQIYI), membagikan pidato di Apache APISIX Meetup di Shanghai baru-baru ini. Dia bekerja di tim komputasi cloud departemen infrastruktur IIG dan bertanggung jawab atas pengembangan gateway dan pekerjaan Ops di iQIYI. Mari kita masuk ke pidatonya dan cerita API gateway iQIYI untuk memahami Apache APISIX dengan lebih baik.

Didirikan pada 22 April 2010 oleh Baidu, perusahaan di balik mesin pencari online terbesar di China, [**iQIYI**](https://www.iq.com/?lang=en_us) saat ini merupakan salah satu situs video online terbesar di dunia, dengan hampir 6 miliar jam dihabiskan di layanannya setiap bulan dan lebih dari 500 juta pengguna aktif bulanan.

iQIYI sebelumnya mengembangkan API gateway sendiri yang disebut Skywalker, pengembangan kustom berdasarkan Kong. Skywalker perlu menangani lalu lintas besar saat ini, dan **puncak harian layanan gateway bisa mencapai satu juta QPS dan ribuan rute API**. Namun, kekurangan produk ini mulai terlihat secara bertahap.

1. Performa gateway tidak lagi memenuhi persyaratan iQIYI, dan menerima banyak peringatan CPU IDLE terlalu rendah setiap hari karena lalu lintas besar.
2. Terlalu banyak ketergantungan komponen pada arsitektur sistem.
3. Biaya O&M (Operasi dan Pemeliharaan) terlalu tinggi.

Setelah mengambil alih proyek ini tahun ini, Cong mulai menyelidiki produk gateway serupa untuk menyelesaikan masalah dan kesulitan di atas dan akhirnya menemukan Apache APISIX.

## Bagaimana Apache APISIX Mengungguli Kong

Sebelum memilih Apache APISIX, iQIYI sudah mulai menggunakan Kong, tetapi kemudian meninggalkannya.

### Mengapa meninggalkan Kong?

Setelah praktik nyata dengan Kong, Cong menunjukkan mengapa timnya meninggalkan Kong. Berikut adalah beberapa kelemahan inti Kong.

1. Rute Kong menggunakan kueri traversal, yang tidak cepat.
2. Basis data Postgres Kong mengakibatkan penyebaran yang membengkak, sinkronisasi yang tidak efisien, dan ketersediaan yang rendah.
3. Kode memiliki tingkat kopling yang tinggi.

### Mengapa memilih APISIX?

> "Kami membandingkan performa antara Apache APISIX dan Kong selama penyelidikan, dan secara mengejutkan menemukan **Apache APISIX 10 kali lebih baik daripada Kong dalam hal optimasi performa**. Kami juga membandingkan Apache APISIX dengan beberapa produk gateway utama lainnya, dan **latensi respons Apache APISIX selalu lebih dari 50% lebih rendah daripada produk lain**. Selain itu, Apache APISIX masih dapat berjalan stabil bahkan jika penggunaan CPU mencapai lebih dari 70%. APISIX benar-benar luar biasa!" kata Cong.

Baik Apache APISIX maupun Kong dikembangkan berdasarkan OpenRestry pada tingkat teknis, yang membawa biaya migrasi yang relatif rendah. Selain itu, Apache APISIX memiliki adaptabilitas yang sangat baik yang dapat dengan mudah disebarkan di banyak lingkungan berbeda, termasuk platform komputasi awan.

> "Sementara itu, kami juga menemukan bahwa Apache APISIX adalah proyek open-source yang sangat aktif yang menyelesaikan masalah dengan sangat cepat. Kerangka kerja cloud-native-nya juga sejalan dengan rencana tindak lanjut perusahaan kami. Oleh karena itu, kami memilih Apache APISIX sebagai API gateway kami."

## Inovasi Arsitektur API Gateway iQIYI setelah Menggunakan APISIX

Setelah memilih API gateway yang hebat, iQIYI mulai membangun arsitektur API gateway barunya, yang ditunjukkan di bawah ini, termasuk nama domain, gateway, instance layanan, dan alarm pemantauan.

![Diagram Arsitektur API Gateway iQIYI](https://static.api7.ai/2022/12/02/6389647220deb.jpeg)

DPVS adalah proyek open-source yang dikembangkan berdasarkan LVS oleh iQIYI. Alarm pemantauan Hubble juga merupakan pengembangan kustom yang mendalam berdasarkan proyek open-source, dan beberapa optimasi pada performa dan kegunaan tinggi Consul dilakukan.

### Prestasi 1: Meningkatkan bidang data dan kontrol untuk manajemen kluster dan layanan

Bidang data terutama berorientasi pada pengguna depan, dan seluruh arsitektur dari LB ke gateway memiliki penyebaran multi-situs dan multi-link untuk pemulihan bencana, sehingga **pengguna dapat mengakses pusat data terdekat mereka**.

Untuk bidang kontrol, terdapat platform microservice untuk **mengelola beberapa kluster dan layanan**. Platform microservice memungkinkan pengguna untuk mengalami layanan satu atap tanpa mengirim tiket, **menghemat banyak waktu**. Di backend, pengontrol gateway terutama mengontrol konfigurasi semua API, seperti pembuatan API dan plugin, sementara pengontrol layanan **menangani pendaftaran, pembatalan, dan pemeriksaan kesehatan**.

![microservice-gateway.webp](https://static.api7.ai/2022/11/21/637b4c61c02c0.webp)

### Prestasi 2: Menambahkan lebih banyak fitur: kontrol keamanan, pembatasan laju, dan pemantauan

iQIYI mengimplementasikan beberapa fungsionalitas dasar dalam arsitektur API seperti pembatasan laju, autentikasi, alarm, pemantauan, dll., setelah menyesuaikan diri dengan [Apache APISIX](https://github.com/apache/apisix).

Bagian pertama adalah tentang HTTPS. Untuk kontrol keamanan, iQIYI tidak menyimpan sertifikat atau kunci apa pun di server gateway tetapi di server jarak jauh yang khusus. Namun, hal ini sulit untuk diwujudkan saat menggunakan Kong; sebaliknya, iQIYI menggunakan NGINX awalan untuk melakukan offload HTTPS. Setelah bermigrasi ke Apache APISIX, iQIYI berhasil mengimplementasikan fitur ini di Apache APISIX, yang **menghemat satu lapisan transfer lebih lanjut di tautan**.

Dalam hal [pembatasan laju](https://apisix.apache.org/docs/apisix/plugins/limit-count/), selain fungsionalitas pembatasan laju dasar, **pembatasan laju yang tepat dan pembatasan laju terhadap granularitas pengguna juga diimplementasikan**. Untuk autentikasi, **layanan khusus untuk autentikasi paspor** disediakan. Selain itu, iQIYI dapat mengakses cloud keamanan WAF perusahaan untuk menyaring industri bawah tanah.

**Fungsionalitas alarm pemantauan dicapai dengan menggunakan plugin bawaan Apache APISIX - [Prometheus](https://apisix.apache.org/docs/apisix/next/plugins/prometheus/)**, dan data indikator akan langsung dikirim ke sistem pemantauan perusahaan. Apache APISIX juga mendukung iQIYI dengan **layanan pencatatan dan analisis jejak**.

### Prestasi 3: Membangun proses pembaruan penemuan layanan dinamis

Mengenai penemuan layanan yang disebutkan di atas, terutama mendaftarkan layanan ke kluster Consul melalui pusat layanan dan kemudian menggunakan penemuan layanan DNS untuk memperbaruinya secara dinamis. QAE dalam grafik adalah platform microservice yang digunakan secara internal di perusahaan kami. **Mari kita gunakan contoh untuk secara singkat mendemonstrasikan proses pembaruan instance.**

Saat memperbarui instance, kami akan pertama-tama mencatat keluar node yang sesuai dari Consul dan mengirim permintaan pembaruan cache DNS ke gateway melalui pengontrol API gateway. Ketika cache telah berhasil diperbarui, pengontrol akan mengirim kembali permintaan ke platform QAE untuk menghentikan semua node aplikasi backend yang terkait untuk menghindari pengalihan lalu lintas ke node yang offline.

![Proses pembaruan penemuan layanan dinamis iQIYI](https://static.api7.ai/2022/12/02/63897fa31ff83.jpeg)

### Prestasi 4: Meningkatkan kemampuan rute terarah

Gateway memiliki penyebaran multi-situs, dan satu set lengkap tautan cadangan multi-situs dibangun sebelumnya. Selain itu, Cong juga menyarankan pengguna untuk memiliki penyebaran akses terdekat multi-situs untuk layanan backend mereka. Dengan demikian, pengguna dapat membuat layanan API di platform gateway Skywalker, dan pengontrol akan menyebarkan rute API ke semua kluster gateway DC. Sementara itu, CNAME default domain layanan akan diarahkan ke nama domain gateway yang terpadu.

**Apache APISIX dapat langsung menyediakan layanan dengan penyebaran multi-situs akses terdekat dan kemampuan failover untuk pemulihan bencana dan mendukung resolusi rute kustom yang ditentukan oleh pengguna.** Selain itu, pengguna dapat menyesuaikan konfigurasi resolusi rute melalui nama domain UUID jika mereka membutuhkan failover, penyebaran biru-hijau, dan rilis canary. Selain itu, **Apache APISIX juga mendukung penjadwalan kustom pemulihan layanan backend**.

![Diagram rute terarah iQIYI](https://static.api7.ai/2022/12/02/63898546bd508.jpeg)

### Prestasi 5: Meningkatkan toleransi bencana multi-situs & multi-level

Untuk menangani situasi seperti lalu lintas besar, banyak kluster, dan audiens klien yang luas, iQIYI membutuhkan akses ke layanan terdekat dan pemulihan bencana pada tingkat operasional.

**Selain cadangan multi-situs dan multi-link untuk pemulihan bencana, iQIYI masih perlu mempertimbangkan masalah tentang situasi multi-level dan multi-node. APISIX membantu dalam hal ini.** Klien semakin dekat dengan node mati, semakin besar dampaknya pada bisnis dan lalu lintas.

1. Jika node layanan backend terjauh mati, iQIYI dapat mencapai pemutusan node tunggal atau failover dari DC mati melalui pusat layanan dan mekanisme pemeriksaan kesehatan gateway. Dengan demikian, dampaknya akan terbatas pada layanan tertentu, tidak memengaruhi pengguna.
2. Jika gateway mati, maka iQIYI dapat menggunakan mekanisme pemeriksaan kesehatan L4 DPVS untuk memutus node gateway yang gagal, dan dampaknya relatif kecil, tidak memengaruhi pengguna.
3. Jika tindakan pemutusan sirkuit di atas tidak dapat memperbaiki node mati, maka iQIYI dapat mencapai failover otomatis di DNS melalui uji ketersediaan multi-node granularitas nama domain di ekstranet. Namun, metode ini relatif lambat dan dapat memengaruhi banyak layanan lain, dan pengguna dapat menyadarinya.

## Rencana Masa Depan iQIYI

Dalam integrasi dengan APISIX, iQIYI mencoba mengoptimalkan beberapa masalah untuk lebih sesuai dengan bisnisnya.

1. Mempertimbangkan kemungkinan bottleneck dari beberapa komponen dependen, seperti etcd, pemantauan Prometheus, dan layanan pencatatan, **iQIYI berencana menggunakan metode penyebaran hybrid. Yaitu: berbagi informasi di dalam kluster besar dan menjaga kluster kecil tetap independen.** Misalnya, layanan vital akan disebarkan dengan kluster kecil.

2. Lebih banyak **pengurangan dan optimasi yang sesuai untuk metrik pemantauan Prometheus** akan dilakukan, terutama untuk penemuan layanan DNS.

> Cong berkata, "Kami berharap Apache APISIX dapat mendukung lebih banyak fitur dan mempertahankan efisiensi performa yang sangat baik serta stabilitas dalam pengembangan dan pembaruan di masa depan."

## Mencari Dukungan APISIX?

Apakah Anda ingin mempercepat pengembangan Anda dengan percaya diri seperti iQIYI? Untuk memaksimalkan dukungan APISIX, Anda membutuhkan API7. Kami menyediakan dukungan mendalam untuk APISIX dan solusi manajemen API berdasarkan kebutuhan Anda!

Hubungi kami kapan saja: [https://api7.ai/contact](https://api7.ai/contact).


Tim teknis iQIYI membandingkan APISIX dengan Kong, serta memperbarui dan mengintegrasikan infrastruktur iQIYI untuk berhasil membangun API gateway yang benar-benar baru.

iQIYI Membuka Inovasi API Gateway dengan Apache APISIX

## Ikhtisar

Sebagai penyedia infrastruktur blockchain konsorsium tingkat perusahaan terkemuka di dunia dan penyedia solusi, [Hyperchain Technologies](https://www.hyperchain.cn/en/about/company) berkomitmen untuk membangun infrastruktur inovatif dan memberdayakan perkembangan digital masyarakat. Selama pertumbuhan pesatnya, Hyperchain menghadapi banyak masalah saat membangun platform blockchain Hyperchain, sebagai berikut:

- Tidak ada manajemen lalu lintas yang terstandarisasi dengan risiko potensial keruntuhan sistem
- Kontrol keamanan dan manajemen autentikasi yang tidak lengkap
- Kontrol izin yang tidak nyaman
- Biaya tinggi pada alamat IP jaringan publik
- Node blockchain yang tidak stabil: node tunggal rentan terhadap serangan
- Kurangnya manajemen terpadu dari berbagai protokol

Hyperchain mencoba Kong dan NGINX, tetapi sayangnya, mereka tidak dapat memenuhi skenario bisnis Hyperchain. **Namun, setelah mengadopsi Apache APISIX, semua masalah yang disebutkan di atas teratasi, memberikan platform blockchain Hyperchain vitalitas yang tak terbatas.**

### Tentang Platform Blockchain Hyperchain

Platform blockchain Hyperchain merujuk pada penyematan kerangka blockchain ke dalam platform komputasi awan, memanfaatkan keunggulan infrastruktur layanan cloud dalam penyebaran dan manajemen. Ini adalah platform blockchain terbuka yang dapat menyediakan pengembang dengan ekosistem blockchain yang nyaman dan berkinerja tinggi serta layanan dukungan terkait, dan juga mendukung ekspansi dan operasi bisnis pengembang di web3.

**Platform blockchain Hyperchain dapat membangun jaringan blockchain dengan cepat dan fleksibel. Dengan platform ini, perusahaan dapat mengelola bisnis blockchain secara terpadu.** Misalnya, melalui platform, kita dapat menandatangani kontrak di lingkungan pengembangan terintegrasi dan kemudian menyebarkan kontrak ke jaringan blockchain yang telah kita buat. Modul layanan atas dapat memanggil kontrak terkait blockchain untuk melanjutkan proses bisnis.

Karena ada banyak node dalam rantai, mulai dari puluhan hingga ribuan, menjadi sulit bagi kita untuk memantau dan memelihara operasi rantai tanpa dukungan platform. **Dengan menggunakan platform blockchain Hyperchain, pengguna tidak hanya dapat menghemat biaya tetapi juga mengelola blockchain dengan lebih nyaman dan meningkatkan keamanan seluruh sistem.**

Mari kita ambil Hyperchain sebagai contoh untuk memahami bagaimana dan mengapa perusahaan blockchain harus memilih Apache APISIX di antara banyak gateway API. Di bawah ini, kita akan menganalisis aplikasi APISIX baik dalam platform blockchain Hyperchain maupun node blockchain.

## Aplikasi APISIX dalam Platform Blockchain Hyperchain

Di bawah ini adalah diagram interaksi aplikasi APISIX dalam platform blockchain Hyperchain. Layanan backend mendaftarkan informasi layanan ke etcd sesuai dengan karakteristik bisnisnya dan kemudian mendaftarkan layanan ke APISIX melalui modul pendaftaran rute.

APISIX berfungsi sebagai pintu masuk terpadu dari layanan mikro internal dalam sistem. Permintaan eksternal pertama kali dikirim ke APISIX; kemudian, mereka mengunjungi lapisan akses melalui API setelah melewati autentikasi dan kemudian mengunjungi layanan inti melalui RPC (remote procedure call).

![Diagram interaksi aplikasi Hyperchain](https://static.api7.ai/2022/11/15/637335a53d73c.png)

### Penerusan Rute

Terkadang, API diharapkan untuk diekspos di bawah nama domain yang sama. Dalam kasus ini, kita dapat menambahkan beberapa awalan ke jalur API dari layanan yang sama, seperti `/baas-core` atau `/baas-other`. Ketika klien meminta API ini, gateway API perlu menghapus awalan yang ditambahkan ini dan kemudian meneruskan permintaan ke layanan backend. Plugin [proxy-rewrite](https://apisix.apache.org/docs/apisix/plugins/proxy-rewrite/) dari APISIX dapat membantu kita menangani kasus seperti ini dengan mudah.

Contoh:
Ketika mengunjungi: http://apisix:8080/baas-{service}/api/v1/…
Permintaan dapat diteruskan ke http://{service}/api/v1/…
dengan menulis ekspresi reguler: `^/baas-core/(.*)$,/$1`

![Edit plugin proxy-rewrite](https://static.api7.ai/2022/11/15/637335b538dc0.png)

### Manajemen Batas Lalu Lintas

Pengguna dapat memilih blockchain konsorsium sesuai kebutuhan mereka, tidak hanya dari Hyperchain tetapi juga IBM data Fabric, Baidu XuperChain, dll. Oleh karena itu, Hyperchain perlu melakukan manajemen siklus hidup semua blockchain konsorsium dalam sistem.

Saat membuat rantai konsorsium, Hyperchain hanya perlu menulis kode keras pada platform blockchain dan mengunggah komponen drive yang dapat dipasang ke platform blockchain untuk dipanggil guna membuat rantai konsorsium. Dalam beberapa kasus penyebaran pribadi, komponen drive yang dapat dipasang dapat mendukung dengan cepat.

Setiap panggilan ke komponen drive adalah proses yang perlu dibatasi, terutama ketika jumlahnya besar. Oleh karena itu, plugin [limit-req](https://apisix.apache.org/docs/apisix/plugins/limit-req/) dari APISIX dapat bermanfaat dalam membatasi input dan output lalu lintas platform untuk memastikan stabilitasnya.

Plugin limit-req memungkinkan konfigurasi yang disesuaikan tentang rate dan burst.

![Model plugin limit-req](https://static.api7.ai/2022/11/15/637335b790f49.jpeg)

### Kontrol Keamanan dan Manajemen Otoritas

Untuk berkolaborasi dengan APISIX, Hyperchain mengembangkan plugin untuk keadaan penyebaran pribadi. Pihak A sering lebih suka menggunakan layanan autentikasi mereka sendiri atau sistem akun layanan. Ketika lalu lintas frontend mengunjungi situs web, itu akan pertama kali melalui plugin Access-auth, dan hanya dapat mengakses backend BFF (Backend for Frontend) jika melewati autentikasi.

![Diagram proses autentikasi](https://static.api7.ai/2022/11/15/637335b994030.png)

Menurut tiga faktor kunci dari spesifikasi standar Restful (informasi autentikasi, jalur Restful, dan kata kerja HTTP seperti GET, POST, PUT, DELETE, PATCH, dll.), autentikasi akun-peran-otoritas dilakukan. Jika autentikasi berhasil, informasi pengguna akan dikembalikan di header; jika tidak, akan kembali ke 403.

![Jalur autentikasi API](https://static.api7.ai/2022/11/15/637335bd3e080.png)

### Hot Reloading

APISIX menawarkan [hot reloading](https://apisix.apache.org/docs/java-plugin-runner/hot-reloading/) dari plugin yang dikembangkan secara internal. Ini menghemat waktu selama pengembangan dan memungkinkan pengguna untuk mengubah bagian dari kode mereka tanpa memulai ulang seluruh plugin runner. Dengan cara ini, pengembang dapat melakukan penyesuaian pada antarmuka di backend, yang segera berlaku, yang nyaman dan ramah untuk rilis online.

### Mengapa bukan Kong?

Hyperchain sebelumnya menggunakan Kong tetapi akhirnya menggantinya dengan Apache APISIX terutama karena

- **Biaya Penyebaran dan Pemeliharaan yang Tinggi**

    Kluster Kong perlu bekerja sama dengan database Postgresql dan membutuhkan administrator database tertentu untuk ketersediaan tinggi. Penyebaran kluster dari database Postgresql relatif sulit untuk diimplementasikan dan meningkatkan biaya operasi dan pemeliharaan selanjutnya.

- **Meningkatkan Kompleksitas Sistem dan Tingkat Kegagalan**

    Platform blockchain Hyperchain menggunakan database MySQL, menghasilkan dua database relasional dalam sistem jika mengadopsi Kong, yang membuat sistem lebih rumit. Ini juga meningkatkan tingkat kegagalan dalam meningkatkan kompatibilitas antara dua set database.

## Aplikasi APISIX dalam Node Blockchain

![Diagram blockchain Hyperchain](https://static.api7.ai/2022/11/15/637335bfa08dc.png)

### Menghemat Biaya pada Alamat IP Jaringan Publik

Pengguna membeli blockchain melalui platform blockchain Hyperchain. Kemudian bisnis tingkat atas dan klien pengembang dapat terhubung ke node. Layanan dapat terhubung ke satu atau lebih node, dan pengguna dapat mengakses satu atau lebih node, yang menimbulkan masalah: hampir semua node akan dikunjungi, membebani tekanan kunjungan pada node tunggal.

Ini relatif mudah ditangani dalam beberapa lingkungan penyebaran pribadi. Namun, terlalu banyak node dan IP jaringan publik diperlukan untuk sistem yang menargetkan pengguna internet. Harga setiap IP jaringan publik dengan lalu lintas 4 megabyte dapat mencapai hampir 200 CNY per bulan. Ada ribuan node di platform Hyperchains, yang mengonsumsi biaya IP publik yang tinggi.

APISIX mengelola semua permintaan kunjungan dan mendistribusikan lalu lintas ke node blockchain yang sesuai. Dengan cara ini, Hyperchain menghemat biaya yang tinggi.

![Mode Hyperchain dengan APISIX](https://static.api7.ai/2022/11/15/637335c23f4f8.png)

### Kontrol Izin yang Nyaman

Ada berbagai blockchain di platform blockchain Hyperchain, dan setiap rantai memiliki kontrol izin RBAC yang rumit. Oleh karena itu, berbagai jenis sertifikat diperlukan untuk ditambahkan di sisi klien, seperti sertifikat TLS, yang juga membingungkan pengguna.

Saat ini, plugin [key-auth](https://apisix.apache.org/docs/apisix/plugins/key-auth/) dari APISIX dapat digunakan untuk menyelesaikan masalah ini dengan efisien. Pengguna yang berwenang dapat langsung mengakses blockchain tanpa khawatir tentang konfigurasi izin, karena APISIX menyatukan rantai dasar.

### Klustering Meningkatkan Stabilitas Node

Seperti yang disebutkan di atas, node sering dikunjungi. Konkurensi tinggi ada di sebagian besar pengguna bank karena TPS (Transaksi Per Detik) dapat mencapai 40.000-50.000 kali.

Ternyata, node tunggal pada blockchain rentan karena setiap transaksi akan memengaruhi node yang dikunjungi.

Hyperchain menyebarkan Apache APISIX pada K8s dengan Horizontal Pod Autoscaler. Karena APISIX menggunakan etcd dengan skalabilitas dinamis yang baik, ini dapat secara efektif menyelesaikan masalah dampak lalu lintas titik tunggal.

### Mendukung Berbagai Protokol

Protokol dari rantai heterogen pada platform blockchain Hyperchain beragam, seperti protokol HTTP, protokol Websocket, protokol gRPC, protokol TCP, protokol UDP, dll.

APISIX mendukung berbagai protokol, secara fleksibel menyesuaikan lapisan dasar dari blockchain yang berbeda, sehingga mengurangi biaya pengembangan.

### Mengapa bukan NGINX?

Tampaknya Hyperchain dapat memanfaatkan NGINX untuk menyelesaikan masalahnya. Namun, setelah percobaan, Hyperchain meninggalkannya karena

- **Tidak Cocok untuk Ekspansi Dinamis**

    Hyperchain perlu menambah dan menghapus node di platform blockchain secara sering, yang hanya dapat berlaku setelah memulai ulang, yang tidak nyaman bagi pengembang. Selain itu, pengembang harus menulis kode aturan yang kompleks untuk plugin di file conf NGINX.

- **Sulit untuk Diklusterkan**

    NGINX tidak mendukung kluster, yang relatif kompleks dan tidak ramah bagi pengguna.

- **Tidak Ada Dukungan Langsung untuk TCP dan UDP**

    NGINX hanya dapat memproksi protokol lapisan 7 daripada protokol lapisan 4 dan tidak dapat langsung mendukung protokol TCP dan UDP. Selain itu, modul tidak dikompilasi secara default, memerlukan pemrosesan tambahan.

- **Tidak Ada Dashboard**

    Tidak ada antarmuka visual NGINX, yang menyulitkan pengembang dan operator untuk mengelola begitu banyak node.

## Ringkasan

Dari konten yang disebutkan di atas, kita tahu bahwa Apache APISIX adalah gateway API dinamis yang dapat diterapkan di area blockchain. Selain itu, Apache APISIX menyediakan fitur manajemen lalu lintas yang kaya seperti Load Balancing, Dynamic Upstream, Canary Release, Circuit Breaking, Authentication, Observability, dll.

Kami berharap APISIX dapat mendukung lebih banyak perusahaan blockchain untuk memasuki fase perkembangan lainnya.
Selamat datang untuk mempelajari lebih lanjut tentang Apache APISIX.
Anda dapat menghubungi kami di https://api7.ai/contact.


Bagaimana perusahaan unicorn blockchain—Hyperchain menggunakan APISIX, sebuah gateway API open-source, untuk memberdayakan Hyperchain Blockchain Platform dalam mengelola lalu lintas blockchain di web3, dengan menyebutkan perbandingan antara APISIX, Kong, dan NGINX.

Apache APISIX vs Kong:
93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

Bagaimana Zoom Menggunakan APISIX Ingress dalam Pipelines Continuous Delivery-nya?

iQIYI Membuka Inovasi API Gateway dengan Apache APISIX

API Gateway untuk Web3: Bagaimana APISIX Memberdayakan Hyperchain

Siap mengelola API Anda?

Apache APISIX vs Kong:.css-j8kk69{background-image:var(--chakra-colors-gradient-600);color:transparent;-webkit-background-clip:text;background-clip:text;}93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

Bagaimana Zoom Menggunakan APISIX Ingress dalam Pipelines Continuous Delivery-nya?

iQIYI Membuka Inovasi API Gateway dengan Apache APISIX

API Gateway untuk Web3: Bagaimana APISIX Memberdayakan Hyperchain

Siap mengelola API Anda?

Apache APISIX vs Kong:
93x Faster & 200% QPS