Mengapa Beike, Platform Perumahan Populer, Memilih Apache APISIX

Hai, saya Hui Wang, bertanggung jawab untuk mengembangkan sistem API gateway di Ke Holdings (Beike), platform terintegrasi online dan offline terkemuka untuk transaksi dan layanan perumahan di Tiongkok. Beike menggunakan Apache APISIX sebagai API gateway pada sistem produksi. Sebagai perusahaan yang berbasis data, jutaan lalu lintas produksi akan melewati API gateway setiap hari, dan Apache APISIX dapat memberikan performa yang stabil dan luar biasa. Baru-baru ini Apache APISIX baru saja bergabung dengan inkubator Apache, saya ingin mengambil kesempatan ini untuk berbagi alasan mengapa kami memilih Apache APISIX sejak awal dan beberapa pengalaman saat menggunakannya.

Kong atau Apache APISIX

Untuk persyaratan teknis gateway, pertama-tama, gateway harus memiliki performa yang luar biasa dan kemampuan untuk mendukung akses lalu lintas yang signifikan. Selain itu, gateway juga harus stabil, dengan tingkat kesalahan nol.

Prinsip pemilihan vendor adalah merekonstruksi versi yang lebih stabil berdasarkan atau belajar dari proyek open-source lain untuk mengakses lalu lintas yang lebih besar. Setelah mengevaluasi kelebihan dan kekurangan, saya mendiskusikan ide ini dengan atasan saya, dan kami memutuskan untuk memulai proyek ini. Pilihan pertama yang muncul di pikiran saya adalah Kong, gateway open-source terkenal lainnya.

Setelah menjelajahi situs web resmi Kong dan membaca beberapa artikel terkait, saya pikir Kong adalah pilihan yang cocok karena dapat memenuhi sebagian besar kebutuhan pengguna, dan performanya juga sangat stabil. Saya segera meng-kloning kode dan mulai membacanya. Namun, saya merasa cukup bingung bahkan setelah beberapa hari menyelidiki. Saya rasa saya menemukan alasan mengapa Kong memiliki basis kode yang sangat besar, yaitu karena perlu menyediakan banyak fungsionalitas.

Tiba-tiba, beberapa pertanyaan muncul di pikiran saya. Berapa lama saya bisa sepenuhnya memahami Kong? Berapa lama waktu yang dibutuhkan untuk membangun proyek yang memenuhi semua persyaratan? Apakah saya membutuhkan semua fungsionalitas yang disediakan Kong?

Beberapa hari sebelumnya, API gateway Apache APISIX versi 0.5 dirilis. Dengan sikap belajar, saya segera melihat proyek open-source ini dan terkejut menemukan bahwa Yuansheng Wang dan Ming Wen, dua ahli di bidang API, bersama-sama mengembangkannya. Saya tidak bisa menolak produk ini berdasarkan dukungan para ahli ini.

Karena proyek open-source ini belum lama lahir, fungsionalitas yang didukung oleh Apache APISIX juga cukup terbatas. Namun, semua fungsi penting, seperti load balancing dinamis, circuit breaker, autentikasi identitas, dan pembatasan kecepatan, sudah diimplementasikan. Sementara itu, basis kode yang relatif kecil juga mengurangi biaya pembelajaran. Dibandingkan dengan Kong, saya bisa mengumumkan kemenangan Apache APISIX. Apache APISIX lebih cocok untuk situasi saya saat ini karena dapat memenuhi rencana fitur awal saya tanpa khawatir tentang fungsionalitas yang tidak diperlukan.

Namun, masalah paling kritis adalah bahwa performa Apache APISIX mungkin menjadi kelemahan karena waktu open-source yang terbatas. Dibandingkan dengan hasil tes stres Kong di lingkungan tes yang sama, Apache APISIX akhirnya mengalahkan Kong. Namun, ini tidak adil bagi Kong karena Kong jauh lebih berat dan kompleks. Di sisi lain, tidak ada perbedaan dalam kasus penggunaan saya karena semua fungsionalitas yang dibutuhkan disediakan di Apache APISIX. Menurut laporan tes performa Apache APISIX, CPU single-core dapat mencapai 24k QPS, sementara latensi hanya 0,7 milidetik.

Secara ringkas, saya memilih Apache APISIX karena alasan berikut:

• Dengan syarat dapat memenuhi semua kebutuhan proyek, biaya pembelajaran Apache APISIX rendah
• Kong memiliki basis kode yang besar, yang membuatnya sulit untuk memelihara kode
• Penulis Apache APISIX lebih aktif di komunitas OpenResty, yang dapat memberikan kualitas kode yang lebih baik
• Yang paling penting adalah dapat dengan cepat menyelesaikan pertanyaan apa pun dengan berkomunikasi langsung dengan penulis

Alasan untuk APISIX yang disediakan oleh situs web resmi ditunjukkan pada gambar berikut:

Kemampuan apa yang dapat disediakan oleh Apache APISIX

• Pembaruan Panas dan Plugin Panas
• Load balancing dinamis
• Pemeriksaan kesehatan aktif dan pasif
• Circuit Breaking
• Autentikasi
• Pembatasan kecepatan
• Konversi protokol gRPC
• TCP/UDP dinamis, gRPC, WebSocket, broker MQTT
• Dashboard
• Daftar Larangan dan Izin
• Serverless

Apache APISIX telah dirilis dalam hampir sepuluh versi, mendukung jauh lebih banyak fungsionalitas daripada yang tercantum di sini. Diagram arsitektur digambar sesuai dengan situasi bisnis, sebagai berikut:

Kisah bagaimana kami mengintegrasikan APISIX

Setelah beberapa hari membaca kode, saya memiliki pemahaman dasar tentang Apache APISIX, tetapi sebuah pertanyaan muncul: Saya belum pernah mengembangkan proyek open-source. Bagaimana saya bisa menyelesaikannya? Saya membuat tiga cabang berbeda secara lokal, satu cabang Apache APISIX menunjuk ke repositori open-source upstream, cabang dev lainnya digunakan untuk iterasi bisnis reguler, dan cabang utama terakhir digunakan untuk peningkatan online.

Setelah dua minggu kerja keras, proyek saya akhirnya memiliki beberapa struktur dasar. Saatnya untuk memeriksa hasilnya; itulah bagaimana kami memulai tahap tes stres. Layanan ini di-deploy di Tencent Cloud dengan server 8 Core dan 32 GB memori, dan upstream adalah lingkungan produksi cloud reguler, sehingga tidak dapat diuji terlalu keras. Laporan performa adalah sebagai berikut:

Ringkasan laporan performa: Waktu konsumsi antarmuka berkurang 47%, tidak ada kesalahan yang muncul, dan stabilitas meningkat. Nilai puncak TPS meningkat 82%, tidak ada kesalahan yang muncul, dan stabilitas meningkat.

Lingkungan pengembangan sudah siap, dan kami mulai mempelajari deployment cloud. Apache APISIX mendukung banyak metode instalasi: Docker, Paket RPM, Luarocks, dan kode sumber. Kabar buruknya adalah tidak ada yang diizinkan untuk diinstal di lingkungan cloud, dan kode sumber hanya dapat ditempatkan di jalur rute tetap. Oleh karena itu, banyak fitur Apache APISIX tidak akan didukung karena dikembangkan berdasarkan OpenResty 1.15.8. Apa yang bisa saya lakukan? File yang dikompilasi dihasilkan di repositori kode, harus dikompilasi di bawah direktori tertentu, dan Anda tidak dapat menggunakan binding statis PCRE, yang menghabiskan waktu kami 1-2 hari. Akhirnya, kami menyesuaikan rilis abu-abu; lalu lintas naik dari 2% ke volume total dalam beberapa minggu. Untungnya, semuanya berhasil pada akhirnya.

Setelah beberapa minggu pemantauan, layanan online relatif stabil. Banyak fungsionalitas Apache APISIX 0.5 harus diimplementasikan melalui panggilan antarmuka API. Parameter permintaan rentan terhadap kesalahan sintaksis, dan tidak ada halaman yang intuitif dan nyaman. Selain itu, skenario bisnis kami perlu memiliki fungsionalitas untuk memeriksa layanan upstream. Kebetulan, Apache APISIX versi 0.7 baru saja dirilis, dan versi 0.7 mendukung konsol dan eksplorasi layanan upstream, yang persis seperti yang kami butuhkan saat ini. Kabar baik! Kami harus meningkatkan!

Cabang Apache APISIX mudah ditingkatkan ke 0.7, tetapi bagaimana kami bisa menggabungkan kode? Perubahan kode antara kedua versi ini sangat besar. Saya mencoba menggabungkannya terlebih dahulu, tetapi ada terlalu banyak konflik, dan kami berada pada kecepatan yang berbahaya. Metode standar untuk menyelesaikan konflik tidak realistis, yang dapat menyebabkan banyak bug tersembunyi. Apakah ada solusi yang efisien? Saya mencari online dan menemukan metode pintas: git checkout –ours dan git checkout –theirs (silakan cari jika Anda belum pernah menggunakannya), dan menyelesaikan peningkatan dari APISIX 0.5 ke 0.7 dalam beberapa menit. Tentu saja, ini juga harus berterima kasih pada kekokohan kode APISIX, yang memungkinkan saya hanya perlu menambahkan plugin bisnis tanpa ada coupling.

Karena Apache APISIX versi 0.7 menyediakan konsol, tidak perlu lagi mengeja JSON. Saya segera memeriksa pemeriksaan kesehatan, dan tidak ada masalah awalnya, dan saya dapat merasakan status layanan upstream. Namun, ketika saya memeriksa log layanan upstream, saya menemukan bahwa setelah beberapa kali reboot, frekuensi pemeriksaan kesehatan terus meningkat. Saya menduga mungkin ada bug dalam pemeriksaan kesehatan. Setelah membaca kode sumber, saya menemukan bahwa checker untuk setiap router tidak unik secara global. Sebaliknya, setiap pekerja memiliki checker. Kami dapat menyelesaikan masalah ini dengan menggunakan nama yang sama untuk semua pekerja yang dibuat. Meskipun ini adalah perbaikan kecil, PR hot-fix diperlukan.

Saya meningkatkan bisnis online APISIX ke 0.7 dan memantau penggunaan sumber daya layanan. Setelah semua, ini adalah perubahan versi yang signifikan, dan saya tidak merasakan apa pun selama beberapa jam pertama, mirip dengan perubahan 0.5 terakhir. Saya akan melihat lagi ketika saya pulang kerja. Tampaknya penggunaan memori tidak benar. Versi 0.5 relatif stabil, tetapi versi 0.7 tampaknya memiliki kebocoran memori. Karena penggunaan memori tumbuh sangat lambat, saya memutuskan untuk memantaunya sepanjang malam. Keesokan harinya, saya membandingkan data yang dipantau, menentukan bahwa ada kebocoran memori, dan segera mengembalikan ke versi sebelumnya. Setelah semuanya selesai, saya memberikan umpan balik kepada Yuan Sheng tentang masalah ini. Menurut skenario yang saya jelaskan, saya menemukan masalah melalui tes stres. Ini adalah masalah dengan radix tree. Masalah yang sama tidak pernah terjadi lagi setelah saya meningkatkan dependensi karena Yuan Sheng merilis versi baru dari radix tree.

Setelah meluncurkan kembali proyek, Apache APISIX versi 0.7 masih bisa memberikan kejutan dari waktu ke waktu. Ketergantungan routing yang digunakan dalam Apache APISIX versi 0.5 adalah libr3, sementara Apache APISIX 0.7 menggunakan radix tree, yang berkinerja lebih baik. Persentase penggunaan CPU dan memori keduanya menurun. Di Apache APISIX 0.5, penggunaan CPU adalah 1-10%, dan memori adalah 0,1%. Di Apache APISIX 0.7, penggunaan CPU berkurang menjadi 1-2%, dan memori kurang dari 0,1%, yang sangat baik.

Rencana Masa Depan

Apache APISIX telah diluncurkan selama dua bulan, dan tidak ada kegagalan atau kesalahan. Ini baru permulaan, dan kami dapat melakukan lebih banyak di masa depan untuk menunjukkan lebih banyak kemampuan kepada penyedia layanan. Gateway menyediakan proxy terbalik dan membantu beberapa tim yang tidak memiliki waktu untuk mengembangkan fungsi untuk memastikan stabilitas layanan, termasuk layanan seperti pembatasan arus, circuit breaker, pemantauan, dan platform akses.

Akhirnya, saya ingin berterima kasih kepada Yuan Sheng dan Wen Ming karena telah menyediakan produk yang luar biasa dan komunitas Apache APISIX untuk fungsionalitas iteratif yang berkontribusi. Sekarang lalu lintas harian gateway telah melebihi 100 juta, dan tidak ada masalah performa. Terima kasih atas waktu dan perhatian Anda!