Apache APISIX Menyatukan Manajemen Lalu Lintas Penuh dengan Service Mesh

Dengan pertumbuhan pesat Cloud Native, Service Mesh juga mulai menjadi sorotan. Saat ini, ada banyak solusi Service Mesh yang terkenal, dan setiap produk memiliki keunggulannya masing-masing. Oleh karena itu, keputusan mengenai solusi Service Mesh bervariasi tergantung pada industri atau latar belakang bisnis yang dihadapi.

Situasi Saat Ini dan Tantangan Service Mesh

Munculnya Service Mesh sangat terkait dengan evolusi arsitektur bisnis saat ini. Dengan tren Cloud Native yang semakin berkembang, sebagian besar perusahaan mulai beralih ke microservices, di mana kita menemukan bahwa aplikasi mulai menjadi semakin kecil, dan setiap aplikasi memiliki beberapa fungsi inti yang sama di dalamnya. Oleh karena itu, kita mulai berpikir, "Apakah ada teknologi yang dapat menyelesaikan skenario umum ini?" Maka, Sidecar muncul.

Dengan Sidecar, beberapa fungsi seperti registrasi dan penemuan layanan, manajemen lalu lintas, observabilitas, dan keamanan dapat ditangani olehnya sehingga layanan bisnis dapat fokus pada pengembangan logika bisnis.

Namun, munculnya Sidecar membuat orang perlahan menyadari beberapa tantangan dalam praktiknya, seperti:

• Ada begitu banyak solusi sehingga sulit untuk bermigrasi setelah dipilih. Saat ini, ada banyak solusi Service Mesh, dan karakteristik serta kemampuan bervariasi dari satu solusi ke solusi lainnya. Setelah salah satu solusi ini dipilih, solusi tersebut akan digunakan tanpa penggantian lagi. Namun, jika kita menemukan bahwa solusi tersebut sulit memenuhi persyaratan baru ketika bisnis berkembang, biaya besar akan dikeluarkan saat bermigrasi.
• Biaya integrasi yang tinggi dengan infrastruktur. Service Mesh yang diimplementasikan dalam praktik seringkali memerlukan integrasi dengan infrastruktur, seperti arsitektur microservice sebelumnya, MQ, atau komponen infrastruktur database. Beberapa masalah warisan atau utang teknis historis juga dapat menciptakan hambatan dalam proses integrasi.
• Kehilangan performa dan konsumsi sumber daya tambahan. Saat ini, tidak peduli solusi Service Mesh mana yang Anda pilih, akan ada beberapa kehilangan performa. Selain itu, karena Sidecar, sumber daya tambahan perlu dialokasikan untuknya saat mengkonfigurasi bisnis.
• Kesulitan besar dalam penskalaan. Beberapa solusi Service Mesh tidak dapat diskalakan dalam hal protokol atau fitur dengan metode konfigurasi yang ada, dan mereka tidak dapat disesuaikan dengan plug and play.

Oleh karena itu, di tengah situasi bisnis dan tantangan tersebut, kita mulai berpikir apakah ada solusi Service Mesh ideal yang dapat menyelesaikan masalah ini.

Bagaimana Service Mesh Ideal Terlihat?

Dalam skenario bisnis, persyaratan kita untuk Service Mesh adalah, seperti yang ditunjukkan di atas, yaitu ada beberapa dimensi persyaratan dalam hal sumber daya, performa, manajemen lalu lintas, dan penskalaan. Tentu saja, selain ini, akan ada juga beberapa persyaratan yang lebih rinci di dimensi lain. Misalnya:

• Pertama, pada tingkat pengalaman penggunaan, perlu mencapai biaya awal yang lebih rendah karena mungkin ada lebih banyak operasi dan pemeliharaan yang diperlukan untuk menerapkan Service Mesh daripada pengembang. Oleh karena itu, biaya awal adalah salah satu faktor yang mempengaruhi pemilihan solusi.
• Kedua, pada tingkat teknis, konfigurasi control plane harus mudah dimulai. Pada saat yang sama, izin yang relevan dapat dikontrol dengan ketat dan aman, dan konfigurasi harus lebih mendekati tingkat publik.
• Di sisi data, lebih baik mendukung beberapa protokol atau bahkan protokol kustom secara native karena Anda perlu mempertimbangkan masalah yang disebabkan oleh migrasi sistem historis. Karena adanya Sidecar, juga perlu dipertimbangkan bahwa jejak sumber dayanya dapat dikelola sehingga biaya dapat dikontrol secara efektif. Penskalaan juga diperlukan untuk kustomisasi.
• Terakhir, dalam ekosistem produk, baik komunitas maupun perbaikan produk perlu sesuai dengan kecepatan "respon tepat waktu".

Karena kita memiliki persyaratan dan tujuan yang jelas, langkah selanjutnya adalah mengimplementasikan dan membangun solusi yang mendekati ideal tersebut.

Solusi Service Mesh Berbasis APISIX

Apache APISIX adalah API gateway cloud-native yang dinamis, real-time, dan berkinerja tinggi yang menyediakan fitur manajemen lalu lintas yang kaya seperti load balancing, upstream dinamis, canary release, circuit breaking, autentikasi, observabilitas, dan banyak lagi.

Ratusan perusahaan di seluruh dunia telah menerapkan Apache APISIX untuk menangani lalu lintas bisnis kritis, mencakup keuangan, internet, manufaktur, ritel, operator, dll., seperti NASA, European Factory Platform, China Airlines, China Mobile, Tencent, Huawei, Weibo, Netease, Ke Holdings Inc., 360, Taikang, Nayuki Holdings Limited, dll. Oleh karena itu, solusi Service Mesh berbasis APISIX akan sangat diminati tidak hanya pada tingkat penggunaan tetapi juga ketika menghadapi berbagai sektor industri.

Arsitektur solusi Service Mesh saat ini didasarkan pada Istio sebagai control plane dan APISIX sebagai data plane.

Pertama, kami memilih Istio sebagai control plane karena Istio adalah solusi Service Mesh paling populer saat ini, dan memiliki komunitas yang aktif, yang membuat hampir semua vendor cloud utama mendukung Istio, dan juga mewakili permintaan dan arah pasar saat ini. Jadi dalam hal pilihan control plane, tidak ada modul yang dikembangkan sendiri. Sebaliknya, kami memilih untuk mengadopsi Istio, yang lebih cocok dan memiliki tingkat penerimaan yang lebih tinggi.

Data plane adalah tempat Apache APISIX dapat memanfaatkan keunggulannya. Sebagai API gateway cloud-native, tindakan apa yang telah diambil APISIX sebagai data plane Istio dalam solusi Service Mesh ini?

Mereka yang familiar dengan APISIX tahu bahwa APISIX menggunakan etcd untuk penyimpanan data. Tetapi jika kita menggunakan APISIX sebagai Sidecar, dari mana konfigurasinya berasal? Ini adalah pertanyaan yang perlu dipertimbangkan. Jika kita memasukkan komponen etcd ke dalam Sidecar juga, kita akan menemukan bahwa konsumsi sumber daya sangat besar dan tidak cukup fleksibel.

Oleh karena itu, dalam proses ini, kami pertama-tama menambahkan pusat konfigurasi yang disebut xDS ke APISIX untuk menghilangkan kebutuhan akan etcd, dan kemudian memperkenalkan Amesh, seperti yang ditunjukkan di atas, sebuah program Go yang dikompilasi menjadi library link dinamis yang dimuat saat APISIX dimulai. Ini menggunakan protokol xDS untuk berinteraksi dengan Istio. Kemudian, ia menulis konfigurasi yang diperoleh ke pusat konfigurasi xDS APISIX, yang menghasilkan aturan routing spesifik dan akhirnya menggunakan APISIX untuk merutekan permintaan yang sesuai.

Setelah konfigurasi arsitektur di atas, hasil berikut dapat dicapai:

• Amesh dan APISIX mempertahankan siklus hidup yang sama dan dapat dihidupkan dan dimatikan bersama.
• Berkat dukungan native APISIX untuk xDS Discovery, data dikonversi satu sama lain melalui protokol xDS, menghasilkan tingkat konsumsi sumber daya yang terkontrol.
• CRD dapat digunakan untuk memperluas seluruh solusi dengan cepat dan mudah, terutama untuk fitur yang belum didukung oleh Istio. Misalnya, konfigurasi plugin paling kaya ke APISIX dikonfigurasi oleh CRD; dengan menggunakan controller dan Istio bersama-sama, skalabilitas solusi Service Mesh Istio dan APISIX dimaksimalkan.

Performa Spesifik dari Solusi

Peningkatan Performa yang Signifikan

Data selalu menjadi cara paling intuitif dan efektif untuk menyajikan produk teknologi. Kami menggunakan APISIX dan Envoy sebagai data plane dalam solusi Service Mesh, menggunakan volume hingga 5.000 rute untuk melakukan pengujian stres dalam berbagai skenario, dan akhirnya menyajikan perbandingan data berikut.

Skenario pengujian adalah "Mencocokkan rute ke-3000 dari 5000 rute". Karena banyaknya skenario pengujian, hanya rute yang cocok dengan bagian tengah yang dijelaskan di bawah ini, dan ada juga skenario yang mencocokkan rute awal dan akhir. (Ada terlalu banyak data untuk ditampilkan, jadi data berikut adalah hasil pengujian dengan volume 3000 rute).

Seperti yang dapat Anda lihat dari data di atas, APISIX menunjukkan peningkatan performa 5x pada tingkat QPS untuk tekanan yang sama dan konfigurasi mesin yang sama. Juga, pada tingkat latensi permintaan, APISIX lebih rendah daripada Envoy dalam urutan besaran, dengan latensi APISIX dalam kisaran mikrodetik dan Envoy dalam kisaran milidetik. Tentu saja, Anda juga dapat melihat bahwa dalam pengukuran ini, konsumsi CPU APISIX hanya 50% ketika CPU Envoy sudah berjalan pada kapasitas penuh.

Pengurangan Penggunaan Sumber Daya

Saat menyuntikkan Sidecar ke dalam solusi Service Mesh, sumber daya tambahan biasanya dikonsumsi. Solusi berbasis API dapat mengurangi konsumsi sumber daya hingga 60%. Mengapa ini mungkin?

Pertama, konfigurasi didistribusikan sesuai permintaan. Istio dilengkapi dengan beberapa kebijakan sesuai permintaan untuk manajemen sumber daya Sidecar, seperti pemisahan berdasarkan namespace, tetapi proses ini menimbulkan beban mental tambahan dan kesulitan manajemen pada operasi pengguna.

Kedua adalah apakah konfigurasi mudah dipahami. Saat Anda mengkonfigurasi rute di Envoy, informasi routing saat diperiksa melalui Dump menunjukkan bahwa sudah ada ribuan di Envoy sementara kenyataannya tidak sebanyak itu, yang memiliki banyak implikasi, seperti mempengaruhi kecepatan startup dan menyebabkan beberapa konfigurasi menjadi besar, sehingga meningkatkan penggunaan sumber daya.

Dengan APISIX, Anda dapat menghindari semua masalah ini. Konfigurasi APISIX sederhana dan jelas, mengurangi data yang disimpan dalam memori, dan dikombinasikan dengan performa tingginya, mengurangi konsumsi sumber daya CPU. Konsumsi sumber daya dari seluruh solusi berkurang sekitar 60%.

Biaya Belajar Rendah dan Kemampuan Kustomisasi Tinggi

Pertama, sebagai proyek open source aktif dari Apache Software Foundation, APISIX menyediakan dokumentasi dan sumber belajar yang kaya di komunitas, yang mengurangi biaya belajar bagi mereka yang ingin memulai dengan APISIX.

Kedua, kode sumber APISIX didasarkan pada implementasi Lua, yang relatif mudah dibaca dan dipahami, karena ini adalah bahasa skrip ringan, sehingga lebih jelas untuk melihat kode sumber APISIX.

Terakhir, pengembangan sekunder berbasis APISIX sangat mudah. Ketika Anda ingin menyesuaikan plugin untuk bisnis Anda, tidak hanya bahasa Lua native yang didukung, tetapi Anda juga dapat menggunakan Plugin Runner APISIX untuk mengimplementasikan pengembangan sekunder dalam bahasa yang lebih familiar seperti Python, Java, Go, dan bahkan Wasm.

Kekuatan ekosistem APISIX juga berasal dari ekstensibilitas produk yang kuat.

APISIX sendiri menawarkan berbagai plugin untuk keamanan, logging, observabilitas, dan banyak lagi. Plugin ini dapat digunakan sepenuhnya ketika APISIX digunakan sebagai komponen gateway tradisional. Namun, ketika APISIX digunakan bersama Istio pada control plane untuk membuat service mesh, banyak sumber daya tidak didefinisikan pada control plane Istio. Jadi apa yang dapat dilakukan dalam kasus ini?

Di sinilah CRD kustom masuk. Misalnya, jika kita ingin membuat plugin fault injection, plugin ini sudah tersedia di APISIX, jadi kita hanya perlu mengkonfigurasi beberapa parameter tambahan di sini. Tentu saja, ini hanya contoh plugin fault injection. Ada juga plugin autentikasi identitas aman, pembatasan kecepatan, dan plugin umum lainnya di APISIX yang dapat diakses dengan cara ini untuk mencapai kontrol yang lebih halus.

Manfaat paling langsung dari penggunaan CRD dengan cara ini adalah membuat ekstensi lebih native, menggunakan konfigurasi deklaratif untuk memudahkan pengguna menerima sementara tidak mengganggu konfigurasi asli Istio untuk kompatibilitas yang sempurna. Manfaat lainnya adalah biaya migrasi lebih rendah bagi pengguna yang sudah menggunakan solusi Istio.

Secara keseluruhan, solusi Service Mesh berbasis APISIX lebih mudah digunakan dan dapat diperluas untuk pengembang atau pengguna, serta memiliki performa yang luar biasa dan dukungan ekosistem yang kaya. Berkat kemampuan produk APISIX, ia juga memiliki dukungan yang baik pada tingkat plugin dan multi-protokol. Kami berharap dapat membawa versi berikutnya dari Service Mesh berbasis APISIX pada akhir tahun ini. Silakan nantikan!

Prospek Masa Depan untuk Solusi Service Mesh Berbasis APISIX

Secara retrospektif, solusi Service Mesh berbasis APISIX sudah bekerja menuju tantangan yang disebutkan dalam artikel sebelumnya, dan sedang menuju solusi Service Mesh ideal.

Dengan solusi Service Mesh berbasis APISIX, Anda dapat melihat bahwa lalu lintas masuk dari luar melalui APISIX Ingress dan diproses melalui APISIX di tengah. Dalam proses ini, APISIX Ingress menangani lalu lintas utara-selatan, dan Amesh + Istio menangani lalu lintas timur-barat.

Arsitektur penyebaran seperti ini dapat membawa beberapa nilai tingkat bisnis, seperti penghematan biaya dan tumpukan teknologi yang seragam, di mana Anda dapat dengan cepat mereplikasi kemampuan umum yang digunakan di dalam gateway tradisional ke Service Mesh. Ini memungkinkan manajemen yang seragam pada tingkat bisnis, sehingga mengontrol biaya dan sangat menggunakan kembali pengalaman di gateway, Ingress, dan Service Mesh.

Dalam iterasi selanjutnya, solusi Service Mesh berbasis APISIX akan terus diperdalam, mencapai arah yang direncanakan seperti:

• Membangun implementasi kemampuan xRPC bersama dengan fungsionalitas APISIX.
• Melakukan dukungan multi-protokol heterogen native.
• Mencakup semua jenis skenario dan konfigurasi, termasuk Istio, untuk secara signifikan mengurangi biaya migrasi pengguna.

Kesimpulannya, di antara tren teknologi saat ini, Service Mesh pasti akan menjadi tren populer di masa depan. Meskipun berbagai solusi masih belum sempurna, situasi keseluruhan adalah spiral ke atas. Tentu saja, Service Mesh berbasis APISIX juga bergerak menuju solusi Service Mesh ideal yang ada dalam pikiran semua orang.