Dynamic

Rich Features

Cluster Management

Go for Apache APISIX

Looking for the best API Gateway?

Built on NGINX, with more features than NGINX.

 Many companies have migrated from NGINX to Apache APISIX, immediately achieving fast growth and reducing operational costs.

Apache APISIX vs NGINX:

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

API Gateway untuk Web3: Bagaimana APISIX Memberdayakan Hyperchain

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

    Tidak ada kegagalan besar yang terjadi sejak APISIX diluncurkan di vivo, dan ketersediaan sistem melebihi **99,99%**.

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

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

Apache APISIX vs NGINX:
Dynamic Configuration,
Cluster Management

Looking for the best API Gateway?

Go for Apache APISIX

Dynamic

Rich Features

Cluster Management

Apache APISIX vs NGINX

Case Studies

API Gateway untuk Web3: Bagaimana APISIX Memberdayakan Hyperchain

Bagaimana vivo Berintegrasi dengan APISIX

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

Siap mengelola API Anda?

Apache APISIX vs NGINX:.css-j8kk69{background-image:var(--chakra-colors-gradient-600);color:transparent;-webkit-background-clip:text;background-clip:text;}Dynamic Configuration,Cluster Management

Looking for the best API Gateway?

Go for Apache APISIX

Dynamic

Rich Features

Cluster Management

Apache APISIX vs NGINX

Case Studies

API Gateway untuk Web3: Bagaimana APISIX Memberdayakan Hyperchain

Bagaimana vivo Berintegrasi dengan APISIX

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

Siap mengelola API Anda?

Apache APISIX vs NGINX:
Dynamic Configuration,
Cluster Management