Name: Apache APISIX
Author: Apache Software Foundation

## 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

Sejak Mei 2021, [vivo](https://www.vivo.com/en) telah memperkenalkan [Apache APISIX](https://apisix.apache.org/) sebagai API Gateway-nya. Setelah lebih dari satu tahun praktik di vivo, APISIX telah menyelesaikan banyak masalah teknis dan bisnis serta digunakan dalam skala besar.

### Masalah Sebelum Menggunakan APISIX

- **Manajemen Kompleks Skenario Bisnis dan Pemeliharaan Sistem**

    Karena pertumbuhan bisnis yang cepat, terdapat berbagai skenario dan sistem yang melayaninya, yang memerlukan cara terpadu untuk dikelola oleh vivo.

- **Interaksi antara Data Plane dan Control Plane**

    Untuk perusahaan menengah dan besar seperti vivo, masalah kecil yang terjadi di data plane dapat berdampak pada control plane.

- **Tidak Ada Dukungan untuk Sumber Daya Multi-Dimensi**

    Proyek yang beragam menyebabkan berbagai nama domain dan URL. Departemen bisnis perlu mencari berdasarkan dimensi sumber daya yang berbeda.

- **Dampak Masalah yang Tidak Terkendali**

    Karena proyek vivo yang kompleks, dampak masalah yang dihadapi tidak terkendali. Penggunaan beberapa plugin yang rumit memperburuk hal ini.

Dengan mengganti NGINX dengan APISIX, vivo akhirnya berhasil mencapai serangkaian prestasi seperti di bawah ini.

### Prestasi Setelah Menggunakan APISIX

- **Ketersediaan Tinggi**

    vivo melaporkan bahwa tidak ada kegagalan besar pada penerapan yang dioperasikan pelanggan ini selama periode yang dijelaskan. Hasil historis pelanggan ini bukan komitmen ketersediaan tingkat produk API7; sumber tersebut tidak memublikasikan metodologi pengukuran.

- **Kinerja Tinggi**

    Menangani lalu lintas online yang signifikan dan melayani sejumlah besar layanan, lalu lintas penerusan online saat ini mencapai hampir **satu juta QPS** (Queries-per-second).

- **Fitur yang Kaya**

    Berkat [fitur yang kaya](https://apisix.apache.org/blog/2022/11/02/apache-apisix-v3-preview/) dari APISIX, APISIX dapat mencakup hampir semua skenario proxy NGINX yang umum. Sekitar 50% proyek vivo telah bermigrasi dari NGINX ke kluster APISIX.

- **Mendukung Pembangunan dan Pengembangan Cloud-Native**

    K8s bare metal yang mendukung kontainerisasi telah mencapai skala **10.000**. Sekitar 40% proyek telah bermigrasi dari bare metal dan mesin virtual ke platform kontainer K8s, mendukung dan mempromosikan kemajuan kontainerisasi vivo.

## Desain Sistem vivo Berbasis APISIX

Selanjutnya, mari kita lihat desain sistem vivo setelah mengadopsi APISIX.

### Tampilan Arsitektur yang Disesuaikan pada APISIX

![Arsitektur gateway API vivo dengan APISIX](https://static.api7.ai/2022/11/23/637dc2f51318e.jpg)

Dari diagram di atas, kita dapat menganalisis bahwa vivo telah:

- Menyelesaikan pembangunan gateway lalu lintas **Layer 4** dan **Layer 7**, yang didukung oleh APISIX
- Mewujudkan akses lalu lintas dan penyebaran campuran bare metal, mesin virtual, dan kontainer
- Menerapkan manajemen kluster APISIX
- Menghubungkan platform DevOps internal dan layanan penyebaran bisnis untuk mengakses lalu lintas dengan cepat dan otomatis
- Meningkatkan pembangunan pemantauan

### Peningkatan Manajemen Konfigurasi dan Peluncuran

Untuk lebih memenuhi kebutuhan aktual departemen bisnis, vivo telah melakukan serangkaian adaptasi pada APISIX. Berikut adalah beberapa penyesuaian tersebut, termasuk perubahan control plane, manajemen pemisahan kluster, dan penerusan data.

#### Perubahan Control Plane

Proses keseluruhannya dapat seperti ini:

Setelah data dikonfigurasi di platform perubahan A6, informasi akan dikirim melalui RPC notify ke ManagerAPI, yang dibangun oleh vivo berdasarkan [APISIX Dashboard](https://github.com/apache/apisix-dashboard) yang bersumber terbuka.

Kemudian lalu lintas akan dikirim ke `apisix-agent`. APISIX secara berkala memeriksa apisix-agent melalui proses istimewa untuk mendapatkan tugas perubahan secara massal. Selanjutnya, proses istimewa memberi tahu `worker` melalui antrian bersama untuk mewujudkan perubahan dalam memori.

Sementara itu, APISIX memberi tahu `apisix-agent` tentang hasil tugas dan kemudian mengirimkannya ke ManagerAPI. Selain itu, platform perubahan A6 dapat memeriksa ManagerAPI untuk mendapatkan hasil tugas.

![Mode manajemen dan penerbitan vivo](https://static.api7.ai/2022/11/25/638036da44e7f.jpeg)

[etcd](https://etcd.io/docs/v3.5/learning/why/#comparison-chart "etcd") adalah sorotan dari APISIX, memungkinkan operasi independen dari control dan data plane. Mempertimbangkan keunikan arsitekturnya, vivo membuang etcd dalam proses di atas. Berikut adalah beberapa alasannya.

Karena keragaman proyek vivo, terdapat berbagai nama domain dan URL. Selain itu, departemen bisnis perlu melakukan pencarian berdasarkan dimensi yang berbeda. Berkat kemampuan adaptasi APISIX yang tidak hanya dengan etcd tetapi juga berbagai jenis database, vivo dapat dengan mudah memanfaatkan database seperti MongoDB, untuk bekerja sama dengan APISIX.

Selain itu, vivo melakukan kontribusi berikut untuk kompatibel dengan Apache APISIX.

- **Mengembangkan Komponen Agent**

    Sejak Mei 2021, vivo memperkenalkan Apache APISIX. Mempertimbangkan latar belakang dan konteks teknis, vivo tidak yakin dapat mengadopsi APISIX karena vivo tidak memiliki pengalaman dengan OpenResty dan Lua. Selain itu, ada banyak tugas non-penerusan, seperti pengumpulan log dan penanganan pemantauan, yang dapat meningkatkan kompleksitas manajemen data plane. Akibatnya, vivo mengembangkan komponen agent untuk mengurangi kompleksitas pengembangan.

- **Menulis Data ke Disk**

    Untuk membuat sistem dapat disesuaikan dan memungkinkan data plane berjalan secara independen, sehingga mengurangi ketergantungan pada control plane, vivo menulis file konfigurasi ke disk. Ketika APISIX dimulai, ia mendukung pengambilan lengkap dari pusat konfigurasi dan juga mendukung pengambilan langsung sumber daya konfigurasi dari direktori file disk lokal. Cara ini secara dramatis meningkatkan independensi data dan ketangguhan sistem. Selain itu, sangat intuitif untuk memahami informasi rute dan upstream yang dikonfigurasi pada disk yang ditempatkan di disk, yang membantu dalam pemecahan masalah.

- **Callback Hasil Tugas Perubahan**

    Sebagai perusahaan besar, vivo perlu memastikan bahwa perubahan pada sumber daya seperti router dan upstream dapat dijamin efektif dan berhasil, dan sistem dapat melaporkan kesalahan bahkan jika perubahan ini gagal. Logika ACK (Acknowledgement Code) seperti ini memastikan bahwa pekerja NGINX pada satu mesin dapat melakukan callback. Ketika tugas callback berhasil, semua pekerja pada APISIX akan memperbarui perubahan sumber daya ke memori yang relevan.

#### Manajemen Pemisahan Kluster

![Manajemen Pemisahan Kluster](https://static.api7.ai/2022/11/25/6380381595b00.jpeg)

Versi open-source APISIX menyediakan [etcd](https://apisix.apache.org/docs/apisix/FAQ/#why-does-apache-apisix-use-etcd-for-the-configuration-center) untuk digunakan bersama oleh semua orang. Namun, proyek perusahaan sangat kompleks, dan masalah yang dihadapi tidak terkendali. Selain itu, penggunaan plugin yang rumit tidak dapat dihindari, memengaruhi kinerja sistem.

Oleh karena itu, manajemen dilakukan dengan pemisahan kluster untuk mewujudkan isolasi konfigurasi kluster pada APISIX, yang dapat:

- Mengontrol domain kesalahan dan secara efektif mendukung kompleksitas proyek tanpa memengaruhi proyek lain
- Secara efektif mengurangi beban yang disebabkan oleh lapisan non-penerusan APISIX ketika node kontainer sering berubah
- Mengurangi dampak beban yang disebabkan oleh pemeriksaan kesehatan

#### Meningkatkan QPS yang Dibawa oleh HTTPS

Menurut persyaratan terkait dari Kementerian Perindustrian dan Informatika di Tiongkok, lalu lintas jaringan eksternal harus melalui protokol HTTPS. Sebagai protokol enkripsi HTTP berbasis TLS, HTTPS membebani CPU dalam proses enkripsi dan dekripsi.

Ketika konfigurasi routing dan lainnya sama, lalu lintas yang dapat dibawa oleh HTTPS adalah sekitar **1/8 - 1/10** dari HTTP.

Setelah memasang kartu akselerator Intel® QAT (QuickAssist Technology), vivo menyerahkan penanganan dekripsi ke kartu akselerator QAT, yang membebaskan CPU, sehingga meningkatkan QPS yang dibawa oleh HTTPS pada satu mesin. Seperti yang dapat dilihat dari gambar di bawah ini, **kapasitas beban HTTPS satu mesin meningkat sekitar dua kali lipat**.

![data menunjukkan peningkatan vivo dalam membawa lalu lintas](https://static.api7.ai/2022/11/23/637dc306a5fa1.jpg)

## Bagaimana vivo Menggabungkan Bisnis dengan APISIX

### Mendukung Pengembangan Kontainerisasi

Untuk mendukung pengembangan kontainerisasi, vivo mengembangkan sendiri kontroler ingress K8s. Berikut adalah beberapa fungsinya.

1. Menyesuaikan mekanisme perubahan konfigurasi push asinkron yang dimodifikasi oleh vivo

2. Melakukan pemberitahuan pemrosesan acara multi-kluster K8s ke APISIX

3. Menangani skenario proyek kompleks seperti:

- Satu server dengan banyak port

- Ketika server kerangka kerja RPC lain, seperti Dubbo dan gRPC, terhubung ke K8s, diperlukan satu set logika pemrosesan terpadu untuk memberi tahu APISIX atau kerangka kerja lain tentang informasi port sesuai dengan karakteristik konfigurasi proyek

4. Menyesuaikan kebutuhan khusus dari DevOps internal perusahaan dan skenario otomatisasi lainnya, memfasilitasi penyebaran cepat, dan mengaktifkan lalu lintas

### Membantu Proyek Bermigrasi dari NGINX ke APISIX

Proyek vivo telah disebarkan pada kluster NGINX yang ada dan telah berjalan stabil untuk waktu yang lama. Namun, hal ini membawa beban kerja non-bisnis dan ketidakstabilan pada proyek. Akibatnya, sangat menantang untuk melakukan migrasi. Jadi bagaimana cara mempromosikan migrasi proyek ke APISIX?

- Pertama, temukan proyek dari departemen yang bekerja sama, layani departemen bisnis dengan baik untuk menetapkan tolok ukur, dan berikan bimbingan dan pelatihan teknis

- Bangun sistem control plane yang mudah digunakan untuk memfasilitasi akses bisnis dan manajemen multi-dimensi departemen bisnis

- Berikan kemampuan konversi otomatis dan konfigurasi dasar yang mengubah konfigurasi NGINX ke konfigurasi APISIX

### Meningkatkan APISIX dan Mendukung Versi Open-Source

Berdasarkan versi APISIX 2.4, vivo melakukan beberapa penyesuaian dan merilis versi baru, yang ditingkatkan ke versi yang lebih baru pada kuartal kedua tahun ini.

Di satu sisi, berkat arsitektur modular APISIX, relatif mudah untuk mengintegrasikan kode Lua yang dimodifikasi oleh vivo ke cabang versi APISIX yang lebih tinggi. Di sisi lain, vivo juga terus meningkatkan bagian OpenResty, dengan sekitar satu versi per tahun. Karena vivo menggunakan banyak PATCH dan beberapa fungsi berguna seperti QAT, meningkatkan komponen ini sulit dan memakan waktu.

Versi gratis dari fitur komunitas NGINX lambat diperbarui dan tidak aktif. Vivo sedang mempertimbangkan apakah akan membangun bersama dengan APISIX. Untuk mengurangi tenaga kerja yang diperlukan untuk melakukan pengujian sistem terkait, vivo mengadopsi Robot Framework, kerangka kerja otomatisasi pengujian generik untuk pengujian integrasi sistem. Mereka mempromosikan komponen terkait untuk cakupan pengujian unit dan model pengembangan TDD (Test-driven development).

## Rencana Masa Depan vivo

Tahun depan, vivo berencana untuk memperluas [APISIX](https://apisix.apache.org/blog/2022/09/13/why-is-apache-apisix-the-best-api-gateway/) sebagai gateway lalu lintas menjadi gateway API, memanfaatkan keunggulannya dalam [pembatasan laju](https://apisix.apache.org/docs/apisix/plugins/limit-count/#attributes), [autentikasi](https://apisix.apache.org/docs/ingress-controller/tutorials/mtls/), pemutusan sirkuit, dll. Mempertimbangkan penggabungan APISIX dengan DPDK-NGINX, vivo juga akan membina tenaga teknis dan bergabung dengan pembangunan komunitas. Selain itu, vivo akan mengkonsolidasikan keterampilan dasar untuk meletakkan fondasi yang baik, membangun lalu lintas dan tata kelola layanan.

Selamat mempelajari lebih lanjut tentang Apache APISIX.

Anda dapat menghubungi kami di [https://api7.ai/contact](https://api7.ai/contact).


How does the famous mobile manufacturer vivo adopt APISIX as its API gateway and adjust it to fit its businesses?

Bagaimana vivo Berintegrasi dengan APISIX

## Ikhtisar

### Tantangan

- Tantangan signifikan dalam tata kelola data seiring dengan ekspansi bisnis Airwallex ke seluruh dunia
- Manajemen yang rumit dari berbagai sistem dan interkoneksi menyebabkan masalah pada sistem lain ketika satu masalah terjadi

### Hasil

- Kinerja stabil selama **15 bulan** berjalan di lingkungan produksi
- **99%** dari penundaan respons berada dalam **23 ms** ketika routing dinamis, pembatasan tingkat multi-tenant, daftar putih IP multi-tenant, autentikasi, dan otorisasi diaktifkan
- Dukungan yang aman dan efisien untuk kedaulatan data yang mencakup lebih dari **50 mata uang** di lebih dari **130 negara dan wilayah**

## Tentang Airwallex

Sebagai perusahaan fintech global, [Airwallex](https://www.airwallex.com/us) telah membangun platform keuangan global, dengan jaringan pembayarannya mencakup lebih dari 50 mata uang di lebih dari 130 negara dan wilayah di seluruh dunia, dan menyediakan produk fintech digital untuk perusahaan.

![Bisnis Airwallex](https://static.api7.ai/apisix-webp/202108/1646626634389-7d9a0a82-a76c-4645-93b6-8a431bb1f9a1.webp)

> Artikel ini berasal dari wawancara dengan Yang Li, Ph.D., Committer Apache APISIX dan Technical Platform Lead di Airwallex, yang bertanggung jawab atas evolusi platform teknologi Airwallex.

## Kedaulatan Data Menjadi Tantangan bagi Airwallex

[Kedaulatan data](https://api7.ai/blog/leveraging-api-gateway-for-data-sovereignty-and-data-compliance) semakin penting dalam tata kelola data di ruang siber. Airwallex melayani pengguna di berbagai wilayah, yang secara alami melibatkan masalah kedaulatan data.

Sebelumnya, tanpa persyaratan kedaulatan data, data dapat ditempatkan di Eropa dan disinkronkan ke Asia atau pusat data mana pun di dunia. Diagram interaksi data terlihat seperti ini:

![Interaksi Multi-kluster](https://static.api7.ai/202108/1635907812257-962b1247-f5ca-448f-904d-fd47c3ea4586.png)

Namun, di era di mana kedaulatan data dihargai, data berada di bawah kendali, dan arsitektur sebelumnya tidak dapat diadopsi. Di Eropa, hanya data Eropa yang dapat diproses, dan demikian pula, hanya data Asia yang dapat diproses di Asia. Perubahan interaksi data adalah sebagai berikut.

![Interaksi di lingkungan kedaulatan data](https://static.api7.ai/uploads/2023/02/01/63Z7AhJx_2.webp)

Akibatnya, kedaulatan data menjadi tantangan signifikan bagi bisnis global Airwallex. Airwallex bermaksud untuk memigrasikan data dari Eropa ke wilayah lain, dan harus memastikan bahwa persyaratan kedaulatan data dari negara pihak ketiga sesuai dengan yang dimiliki oleh UE.

## Mengapa Airwallex Memilih APISIX?

Ketika memilih gateway API, Airwallex terutama membandingkan produk gateway utama dari enam dimensi:

- **Stabilitas**: Airwallex sangat menekankan pada stabilitas gateway API. Di antara 1000 situs web teratas di dunia, **62,1% berbasis NGINX**, yang menunjukkan bahwa server web berbasis NGINX telah melewati uji coba dalam skenario yang kompleks dan beragam di lingkungan produksi. Apache APISIX berbasis NGINX. Selain itu, desain **fitur [full dynamic](https://api7.ai/blog/how-nginx-reload-work) Apache APISIX** juga memungkinkan untuk memodifikasi rute tanpa memuat ulang dan mempertahankan koneksi panjang klien. Selain itu, **Airwallex juga melakukan tes stres pada Apache APISIX, yang masih dapat berjalan stabil ketika penggunaan CPU mencapai lebih dari 70%.**

- **Kinerja**: Setiap permintaan API akan melewati gateway API. Mengurangi [kerugian kinerja](https://api7.ai/blog/apisix-kong-3-0-performance-comparison) gateway dapat secara signifikan mengurangi waktu respons keseluruhan API Airwallex.
  
    > "Dalam PoC, kami membandingkan produk gateway utama: **penundaan respons Apache APISIX lebih dari 50% lebih rendah daripada gateway lainnya**. Selain itu, data plane independen Apache APISIX memungkinkan instance independen dalam kluster, sehingga secara inheren mendukung ekspansi horizontal." kata Li.

- **Skalabilitas**: Airwallex membutuhkan APISIX untuk bekerja sebagai gateway API yang mendukung **[autentikasi](https://api7.ai/blog/api-gateway-authentication), kontrol izin, [penemuan layanan](https://api7.ai/blog/what-is-service-discovery-in-microservices), [pembatasan tingkat](https://api7.ai/blog/rate-limiting-in-api-management), penurunan, load balancing, daftar putih, dan routing dinamis** yang kompleks.

- **Komunitas yang Aktif**: Komunitas yang aktif adalah kunci bagi Gateway API untuk mengikuti perkembangan teknologi.

    > **Komunitas [Apache APISIX](https://api7.ai/category/community) aktif sejak masih menjadi proyek inkubasi Apache, dilihat dari jumlah kontributor, waktu respons masalah, dan jumlah Pull Request.** kata Li.

- **Penyebaran Pribadi**: Gateway API adalah komponen arsitektur teknis inti dari Airwallex, dan yang menyebarkan gateway API di tepi jaringan pribadinya sendiri. **Apache APISIX memiliki adaptabilitas lingkungan yang baik dan dapat dengan mudah disebarkan di berbagai lingkungan, termasuk platform komputasi awan.**

- **Lisensi Sumber Terbuka yang Ramah Bisnis**: Lisensi Apache 2.0 memungkinkan Airwallex untuk memodifikasi kode APISIX dan mengkomersialkannya tanpa khawatir tentang vendor lock-in.

## Solusi Routing Cerdas Apache APISIX

**Airwallex memilih Apache APISIX untuk membuat solusi routing cerdas**, dan gateway Apache APISIX-lah yang memutuskan di mana data harus diproses.

![Gateway dua lapis Airwallex](https://static.api7.ai/uploads/2023/02/01/cGg9YfNp_3.webp)

Gateway terdiri dari dua lapis. Lapisan pertama bertanggung jawab untuk merutekan permintaan, menentukan pusat data mana yang harus dicapai berdasarkan kondisi. Lapisan kedua bertanggung jawab atas penerusan lalu lintas.

Selain itu, **Airwallex mengimplementasikan fungsi utama sebagai [plugin](https://api7.ai/blog/how-to-implement-plugin-orchestration-in-api-gateway) kustom** untuk meningkatkan ke versi baru Apache APISIX kapan saja. Dengan cara ini, tidak akan ada kondisi balapan antara pustaka kode Airwallex dan kode inti dari repositori utama Apache APISIX. Namun, memodifikasi kode inti terkadang diperlukan. Pada saat ini, Li akan berusaha sebaik mungkin untuk mengimplementasikan fungsi-fungsi ini di komunitas sumber terbuka. **Kontributor di komunitas sangat antusias mendiskusikan implementasi fungsi, dan dalam kebanyakan kasus, mereka dapat dengan cepat memberikan solusi yang tersedia.**

## Bagaimana Airwallex Mendapat Manfaat dari Menggunakan APISIX?

Berikut adalah diagram yang menunjukkan integrasi Airwallex dengan APISIX.

![Diagram Integrasi Airwallex dan APISIX](https://static.api7.ai/uploads/2023/01/31/Q0LbIb0E_88.webp)

Airwallex menggunakan Apache APISIX sebagai komponen inti dari model gateway microservice. Ini disebarkan di tepi jaringan dan menyediakan fungsi gateway umum untuk semua lalu lintas yang masuk ke Airwallex. Masalah yang dipecahkan termasuk:

- **Kedaulatan Data**: Untuk infrastruktur keuangan yang beroperasi lintas batas, kedaulatan data adalah persyaratan regulasi yang kritis. Untuk itu, **Airwallex mengembangkan plugin routing yang sesuai dengan regulasi dinamis dengan memanfaatkan kemampuan pemilihan upstream dinamis Apache APISIX**. Routing dinamis dapat secara cerdas memilih upstream untuk distribusi permintaan sesuai dengan karakteristik permintaan pengguna, mengabstraksikan masalah kolaborasi multi-pusat data yang kompleks dari lapisan layanan ke lapisan gateway. Inti dari routing dinamis adalah menjawab dua pertanyaan: bagaimana mengelompokkan upstream dan bagaimana mencocokkan permintaan dan kelompok.

- **Isolasi dalam Microservices**: Airwallex berharap bahwa tim teknik dari setiap microservice dapat secara independen mengontrol layanan mereka sendiri, secara efektif mengurangi biaya komunikasi dan koordinasi, dan meningkatkan efisiensi teknik. Konsep arsitektur ini mengharuskan komponen infrastruktur yang digunakan bersama oleh berbagai tim, seperti Gateway API, dapat mendukung isolasi tenant. **APISIX sangat cocok untuk memenuhi isolasi tenant.** Sambil memastikan kekokohan dan kontrol biaya dari seluruh sistem, APISIX memungkinkan tim bisnis untuk mengonfigurasi dan memperluas fungsi gateway sesuai dengan kebutuhan mereka sendiri, mempertahankan independensi tim dan layanan microservice.

- **Pembatasan Tingkat Multi-Tenant**: Dalam lingkungan multi-tenant, karakteristik lalu lintas setiap tenant berbeda. Menerapkan pembatasan tingkat yang sama pada tenant yang berbeda tidak dapat memenuhi kebutuhan komersial. **Pembatasan tingkat [multi-tenant](https://api7.ai/blog/rate-limiting-in-api-management) dapat lebih sesuai berdasarkan karakteristik pengguna.**

- **Daftar Putih IP Multi-Tenant**: IP akses setiap tenant bervariasi dalam lingkungan multi-tenant. **Daftar putih IP multi-tenant memungkinkan setiap tenant untuk mengontrol daftar putih mereka sendiri tanpa khawatir tentang invasi pengguna lain terhadap sumber daya mereka sendiri.**

- **Autentikasi**: Pembaruan kunci yang sering adalah tautan kritis untuk memastikan keamanan sumber daya pengguna. **APISIX tidak hanya mendukung [autentikasi](https://api7.ai/blog/understanding-microservices-authentication-services) permintaan tetapi juga pembaruan kunci dinamis.**

- **Otorisasi**: Manajemen izin aplikasi perusahaan sangat rumit, dan skenario aplikasi yang berbeda memiliki model manajemen izin yang sama sekali berbeda. **APISIX dapat memverifikasi apakah pengguna yang meminta memiliki izin yang cukup untuk mengakses antarmuka sesuai dengan konfigurasi routing dan mencegat lalu lintas ilegal pertama kali.**

Lingkungan produksi Airwallex telah berjalan selama **15 bulan**, dan kinerja keseluruhan sangat stabil. Sekitar **99% dari penundaan respons berada dalam 23ms** ketika routing dinamis, pembatasan tingkat multi-tenant, daftar putih IP multi-tenant, autentikasi, otorisasi, dan fungsi lainnya diaktifkan.

**Berkat mekanisme plugin yang luar biasa dari Apache APISIX, Airwallex dapat menambahkan plugin pribadi yang memenuhi kebutuhan bisnis tanpa memodifikasi kode intinya.** Sistem pengujian yang lengkap lebih lanjut menjamin kualitas perangkat lunak, dan Anda dapat dengan aman menambahkan persyaratan personalisasi plugin sambil memastikan bahwa logika inti asli tidak rusak.

## Rencana Masa Depan

Rencana lanjutan Airwallex terutama mencakup tiga aspek:

1. Menggunakan jaringan multi-layer untuk membagi logika gateway ke dalam lapisan yang berbeda, seperti mendistribusikan lalu lintas sesuai dengan kedaulatan data atau logika gateway lainnya.

2. Manajemen routing yang mudah dibaca dan mudah digunakan sangat penting untuk keberhasilan gateway API. Manajemen routing perlu ramah bagi pengembang sehingga pengembang dapat dengan mudah memahami apa yang dapat dilakukan gateway untuk mereka dan bagaimana mengonfigurasi dan mempublikasikannya.

3. Menggunakan permintaan kode warna untuk membantu mengimplementasikan pengujian lingkungan produksi. Menggunakan permintaan kode warna dari gateway API untuk mengimplementasikan pengujian lingkungan produksi dapat memberikan lebih banyak fleksibilitas dan kemudahan penggunaan.

## Mencari Dukungan APISIX?

[Apache APISIX](https://api7.ai/apisix) adalah gateway API cloud-native sumber terbuka, dinamis, skalabel, dan berkinerja tinggi untuk semua API dan microservices Anda. Disumbangkan ke Apache Software Foundation oleh API7.ai, APISIX telah tumbuh menjadi proyek sumber terbuka Apache tingkat atas.

Apakah Anda ingin mempercepat pengembangan dengan percaya diri seperti Airwallex? Untuk memaksimalkan dukungan APISIX, Anda membutuhkan [API7](https://api7.ai/). Kami menyediakan dukungan mendalam untuk APISIX dan solusi manajemen API berdasarkan kebutuhan Anda!

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

Lebih lanjut tentang narasumber:

![Yang Li, Airwallex](https://static.api7.ai/uploads/2023/01/31/uGbiZnt5_Airwallex2.webp)


Airwallex mengatasi tantangan teknis yang dibawa oleh data sovereignty dan membuat solusi routing cerdas dengan bantuan Apache APISIX.

Apa itu Apache APISIX?

Jalankan Apache APISIX sesuai kebutuhan tim Anda

Operasikan Apache APISIX secara mandiri

Dapatkan bantuan untuk deployment yang ada

Evaluasi API7 Enterprise

Mengapa Apache APISIX?

APISIX dibandingkan alternatif lain

Studi kasus

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

Bagaimana vivo Berintegrasi dengan APISIX

Bagaimana Airwallex Memberdayakan Pembayaran Global Menggunakan Apache APISIX?

Pilih langkah berikutnya untuk deployment Apache APISIX Anda