Bagaimana APISIX Memfasilitasi Deployment Lokal Platform Media Sosial Beeto di Timur Tengah

Ikhtisar

Tantangan

• Arsitektur layanan monolitik mengakibatkan biaya pemeliharaan dan operasi yang tinggi
• Penyebaran arsitektur yang kompleks dan panggilan layanan, serta beberapa tumpukan teknologi

Hasil

• Menyatukan lalu lintas utara-selatan dan timur-barat, menghemat sumber daya dan biaya tenaga kerja serta memungkinkan manajemen yang dinamis dan terpadu
• Menyederhanakan arsitektur penyebaran, sehingga mengurangi interaksi antara gateway dan pengguna
• Berbagai plugin ekstensi APISIX membantu Beeto mengelola verifikasi izin, distribusi rute, dan fungsi pemeriksaan kesehatan layanan dengan efisien
• APISIX memungkinkan Beeto meluncurkan dan memigrasi layanan secara dinamis, yang ramah bagi pengembang

Pengenalan Beeto

Untuk pasar Timur Tengah, Beeto adalah platform media sosial berbahasa Arab, dengan desain produk dan arsitektur teknis yang terlokalisasi. Platform ini pernah menempati peringkat ke-4 dalam Daftar Teratas App Store iOS Arab Saudi, melampaui raksasa platform sosial veteran seperti Facebook.

Perkembangan internet di Timur Tengah sudah matang, dengan penetrasi pengguna aktif yang sangat tinggi di jejaring sosial. Terutama di Arab Saudi, di mana 90% orang menggunakan internet pada tahun 2019. Tingkat penetrasi pengguna aktif di Arab Saudi menempati peringkat ke-9 pada tahun 2020.

Kematangan pasar internet ini menghasilkan popularitas perangkat lunak sosial internasional seperti WhatsApp, YouTube, dan Instagram. Namun, tidak ada perangkat lunak sosial lokal yang serupa dengan Twitter. Oleh karena itu, dengan tujuan "internet yang matang tetapi sedikit lokalisasi" di Timur Tengah, Beeto meluncurkan pengembangan produk yang terlokalisasi di sana.

Lokalisasi Penting bagi Beeto

Dibandingkan dengan aplikasi aliran umpan seperti Twitter dan Facebook, Beeto telah merencanakan kerangka kerja yang relatif lengkap untuk menyebarkan arsitektur bisnisnya di Timur Tengah. Misalnya, Beeto berkomitmen untuk memenuhi interaksi hubungan atribut sosial, konsumsi konten (teks, siaran langsung video, iklan lokal, dll.), serta berbagai bisnis seperti hadiah, penarikan, pemungutan suara, dan undian dalam kategori keuangan dan layanan, bahkan persyaratan pengawasan platform dan tinjauan keamanan konten.

Seperti yang telah disebutkan sebelumnya, kematangan internet di pasar Timur Tengah secara tidak langsung membutuhkan produk berkualitas tinggi. Oleh karena itu, versi pertama arsitektur bisnis Beeto adalah produk lengkap yang mengintegrasikan semua fitur yang seharusnya dimiliki oleh perangkat lunak sosial mainstream. Sementara itu, tujuan Beeto adalah menjadi platform sosial Arab terbesar dan komunitas Arab terbaik di Timur Tengah dengan "fitur lokalisasi". Dalam mencapai tujuan ini, Beeto menganalisis persyaratan lokalisasi sebagai berikut.

Masalah dalam Desain Arsitektur Beeto

Lokalisasi mencakup kebutuhan sosial lokal yang ada pada tingkat bisnis, dan operasi lokalisasi pada tingkat teknis, seperti penyebaran layanan dan penyimpanan data. Mereka yang familiar dengan Weibo atau Twitter akan tahu bahwa dibutuhkan puluhan atau ratusan sistem arsitektur untuk berkolaborasi di balik produk aliran informasi yang besar seperti itu. Masalah dalam arsitektur Beeto ditunjukkan sebagai berikut.

Arsitektur Layanan Monolitik Menyebabkan Biaya Tinggi

Layanan Beeto dapat dibagi menjadi delapan bagian, seperti di bawah ini.

Implementasi bisnis ini memerlukan penyebaran yang terlokalisasi di Timur Tengah. Setiap layanan adalah arsitektur monolitik terpisah jika setiap bisnis dipisahkan berdasarkan layanan.

Diagram arsitektur monolitik di atas menunjukkan arsitektur penyebaran yang umum. Ambil contoh layanan aliran umpan Beeto. Jika kita ingin memenuhi permintaan pengguna untuk menjelajahi aliran umpan, kita harus mendukung akses jaringan publik, yaitu akses lalu lintas utara-selatan; pada saat yang sama, layanan aliran umpan juga menyediakan beberapa panggilan internal dalam bentuk bisnis topik, yaitu panggilan lalu lintas timur-barat.

Oleh karena itu, layanan secara keseluruhan mendukung mode panggilan eksternal dan internal. Setelah penyeimbangan beban Layer 7, lalu lintas pengguna didistribusikan ke server yang berbeda, dan kemudian sumber daya penyimpanan yang berbeda dipanggil. Lalu lintas timur-barat juga serupa. Kluster Layer 7 menangani lalu lintas utara-selatan dan timur-barat, penyeimbangan beban, autentikasi, dan pemantauan node.

Ketika layanan dari beberapa bisnis digabungkan, arsitektur keseluruhan dapat menjadi:

Seperti yang dapat Anda lihat, layanan ada di lapisan adaptasi, bisnis, dan layanan dasar. Arsitektur penyebaran untuk masing-masing layanan ini memiliki detail arsitektur monolitik yang disebutkan di atas, sehingga ada beberapa kluster Layer 7 di antaranya, yang merupakan sistem arsitektur yang sangat besar dan kompleks.

Namun, karena produk Beeto berada dalam tahap awal dan produk diluncurkan di Timur Tengah, tetapi tim R&D-nya berada di Tiongkok, biaya server dan pemeliharaan yang besar diperlukan. Selain itu, seiring dengan peningkatan bisnis di kemudian hari, jumlah layanan monolitik pasti akan meningkat, sehingga lebih sulit untuk mengontrol biaya dan operasi pemeliharaan.

Kesulitan dalam Meluncurkan Beberapa Layanan

Selain kompleksitas penyebaran arsitektur, panggilan antar layanan dalam kluster juga sangat kompleks.

Lalu lintas utara-selatan didistribusikan ke berbagai kumpulan layanan, dan lalu lintas timur-barat juga saling terkait di antara berbagai layanan, dengan hubungan panggilan antara layanan-layanan ini saling terkait.

Selain itu, hubungan panggilan ini perlu dipertahankan oleh layanan, yang menyebabkan pelacakan panggilan yang tidak jelas dan manajemen yang buruk.

Selain hubungan panggilan yang kompleks, ada juga perbedaan tumpukan teknologi antara setiap layanan. Misalnya, pada protokol panggilan, beberapa layanan menyediakan HTTP, sementara yang lain menyediakan RPC; Dalam hal pengembangan bahasa pemrograman, ada campuran Java, Go, dan bahasa pemrograman lainnya.

Sistem arsitektur multi-layanan seperti ini jelas akan mengekspos masalah biaya penyebaran dan pemeliharaan yang tinggi ketika diimplementasikan secara lokal. Selain itu, Beeto perlu mengeluarkan biaya server pada setiap set layanan Layer 7, sementara perbedaan lalu lintas setiap layanan menyebabkan ketidakseimbangan lalu lintas, yang mengakibatkan tingkat pemanfaatan sumber daya seperti server yang rendah dan pemborosan sumber daya.

Karena Beeto lebih fokus pada peningkatan dan iterasi bisnis, arsitektur dirancang untuk memfasilitasi pemeliharaan dan manajemen terpadu, jadi bagaimana mencapai tujuan ini?

Gateway APISIX Memberdayakan Arsitektur Beeto

Untuk mengatasi masalah manajemen layanan yang tidak nyaman dan biaya tinggi serta memanfaatkan kinerja dinamis APISIX dengan etcd, yang lebih sesuai dengan persyaratan produk Beeto, APISIX diperkenalkan sebagai gateway API dalam penyebaran arsitektur, dan kluster gateway dibangun, seperti yang ditunjukkan pada gambar di bawah ini.

Kluster gateway APISIX menyediakan alat ekstensi seperti pusat registri, kontrol layanan, pemantauan layanan, penerusan protokol, dan plugin untuk semua layanan. Kluster layanan dapat didaftarkan ke gateway, dan layanan baru dapat ditambahkan dan dihapus langsung melalui gateway.

Setelah gateway diperkenalkan, pelacakan panggilan seluruh kluster menjadi lebih jelas. Lalu lintas utara-selatan diarahkan dan diteruskan oleh gateway, dan lalu lintas timur-barat oleh gateway untuk layanan di intranet. Pada tingkat fungsional, APISIX bertanggung jawab untuk mempertahankan autentikasi yang dipanggil oleh lalu lintas ini sehingga lapisan gateway dapat memahami perbedaan kinerja dan perbedaan lalu lintas antara layanan.

Tentu saja, karena gateway membawa semua lalu lintas dalam arsitektur ini, jumlah layanan akan meningkat di kemudian hari seiring dengan perluasan layanan, biaya pemeliharaan gateway akan meningkat, dan solusi baru perlu dipertimbangkan. Namun, dalam konteks saat ini, solusi ini masih merupakan pilihan terbaik.

Praktik setelah Menerapkan APISIX

Apache APISIX, sebagai gateway API, dapat menangani berbagai kebijakan di tingkat gateway, seperti autentikasi, penerusan layanan, dan pemeriksaan kesehatan. Oleh karena itu, Beeto telah melakukan banyak percobaan pada tingkat praktik bisnis setelah memperkenalkan APISIX.

Keamanan: Plugin Autentikasi

Lalu Lintas Utara-Selatan: Cookie

Seperti yang telah disebutkan sebelumnya, lalu lintas akses pengguna jaringan publik melewati gateway. Autentikasi pengguna jaringan publik adalah permintaan pengguna berdasarkan autentikasi cookie. Ketika pengguna meminta untuk membawa cookie ke gateway, itu diverifikasi oleh plugin autentikasi.

Seperti yang ditunjukkan dalam diagram alir di atas, plugin akan melakukan validasi lokalisasi terlebih dahulu dan kemudian melakukan verifikasi autentikasi layanan jarak jauh sesuai dengan kebijakan. Setelah permintaan diperiksa cookie, itu akan diteruskan ke layanan yang ditentukan.

Keuntungan dari melakukan ini ada dua:

1. Keamanan cookie pengguna terjamin. Hanya lapisan gateway yang dapat menerima dan memproses cookie selama eksekusi karena cookie adalah data sensitif. Ini mencegah masalah keamanan yang disebabkan oleh ketidakkonsistenan aturan pemrosesan bisnis dan secara efektif menghindari kebocoran cookie yang disebabkan oleh faktor manusia dan ketidakaturan.

2. Mengurangi kompleksitas autentikasi cookie untuk layanan. Cookie perlu diverifikasi secara lokal atau jarak jauh dan memerlukan peningkatan layanan secara bersamaan ketika cookie ditingkatkan. APISIX mengelola dan memverifikasi secara terpadu, menghemat biaya verifikasi layanan bisnis dan menunjukkan hasil, yang dapat digunakan untuk pemrosesan aturan bisnis, sehingga memastikan bahwa setiap pemrosesan bisnis lebih fokus pada bisnis itu sendiri.

Lalu Lintas Timur-Barat: Token

Dalam diagram di bawah ini, Layanan A memanggil Layanan B. Secara umum, API adalah semua yang diperlukan untuk saling memanggil. Namun, dalam proses internal, perlu memahami "siapa yang memanggil API, bagaimana itu dipanggil, apakah perlu memeriksa otoritas, dan apakah perlu mengontrol peneliti", dan sebagainya, yang perlu ditangani secara internal.

Dengan gateway APISIX, proses menjadi jauh lebih sederhana. Panggilan timbal balik semua layanan internal hanya perlu didaftarkan pada layanan autentikasi Auth, dan kunci App dikeluarkan untuk setiap layanan untuk menunjukkan ID identitas layanan. Pada saat yang sama, panggilan timbal balik layanan internal juga akan melewati gateway. Setelah membawa token melalui gateway, gateway akan mengautentikasi token melalui plugin token. Setelah autentikasi berhasil, identifikasi autentikasi akan diteruskan ke layanan yang dipanggil. Selama seluruh proses, sistem layanan akan melakukan registrasi autentikasi dan menyelesaikan panggilan timbal balik.

Berkat aturan token dari kunci App, operasi di atas dapat dengan mudah dilacak kembali ke sumber panggilan, yang dapat digunakan untuk pemecahan masalah dan kontrol izin, serta memberikan kontrol yang efektif pada panggilan ilegal. Oleh karena itu, keuntungan dari autentikasi terpadu adalah, baik untuk lalu lintas utara-selatan maupun timur-barat, itu memastikan keamanan dan keseragaman kluster, yang sangat membantu dalam pelacakan masalah dan kontrol panggilan.

Skalabilitas: Ekspansi dan Migrasi Layanan Tanpa Status

Arsitektur penyebaran keseluruhan kluster Beeto dari atas ke bawah terdiri dari: kluster gateway APISIX - kluster layanan bisnis dari layanan tanpa status - kluster pusat data dari layanan dengan status. Ketika disebarkan secara lokal di Timur Tengah, semuanya disebarkan pada kluster cloud utama. Menurut skala cakupan cloud di Timur Tengah dan produsen cloud di wilayah yang berbeda, perlu mempertimbangkan ekspansi dan migrasi layanan cloud saat menyebarkan layanan.

Dalam proses migrasi, Beeto fokus pada migrasi layanan tanpa status. Tidak cocok untuk penyesuaian dinamis karena biaya migrasi pusat data yang terbatas; sebagian besar permintaan dibawa oleh layanan tanpa status, sehingga sangat penting untuk memastikan bahwa layanan tanpa status memiliki skalabilitas yang baik.

Dalam arsitektur Beeto, skalabilitas layanan terutama tercermin dalam dua aspek: skalabilitas layanan monolitik dan skalabilitas kluster keseluruhan. Misalnya, jika layanan monolitik kehabisan sumber daya dan perlu diperluas, gateway APISIX dapat menambahkan node secara dinamis untuk penskalaan. Demikian pula, dalam situasi lintas kluster atau lintas cloud, skalabilitas kluster dapat dicapai dengan menyebarkan beberapa gateway APISIX dan memigrasikan layanan yang berbeda ke node gateway yang berbeda.

Untuk layanan bisnis, arsitektur keseluruhan tetap tidak berubah sehingga ekspansi dan kontraksi dinamis berbagai layanan dan migrasi layanan dapat direalisasikan pada lapisan gateway. Seluruh proses memiliki rencana dan tujuan yang jelas, dan begitu perubahan terlibat, arsitektur keseluruhan tidak akan menjadi tidak stabil.

Ekstensibilitas Fungsional: Penerusan Dinamis Layanan

Selain skenario umum gateway yang sudah dikenal seperti yang disebutkan di atas, Apache APISIX juga memberikan bantuan signifikan kepada Beeto dalam hal penerusan dinamis layanan.

Mereka yang familiar dengan UI dan backend APPs harus tahu bahwa halaman produk yang berbeda disediakan oleh layanan yang berbeda. Sebuah halaman terdiri dari modul yang berbeda, yang kontennya semua dikirim dari API. Data apa pun yang dikirim API ke modul akan dirender di ujung. Ini adalah spesifikasi rendering sisi klien yang umum untuk membuat proses rendering sisi klien lebih generik dan pemrosesan bisnis lebih fleksibel.

Dalam implementasi PageA pada gambar di atas, misalnya, klien memanggil API Layanan A, mengirim data modul yang sesuai, dan menyelesaikan rendering PageA. Operasi ini akan menyebabkan masalah bahwa klien perlu memelihara setiap halaman dan API ke setiap layanan. Jika konten berubah, itu perlu diselesaikan dengan publikasi, yang sangat tidak ramah dalam hal operabilitas dan efisiensi.

Solusi untuk masalah di atas adalah mengimplementasikan distribusi layanan yang terpadu dalam arsitektur keseluruhan. Klien pertama-tama meminta alamat API, meneruskan semua permintaan jenis ini ke satu API, memproses parameter permintaan dan aturan URL untuk alamat URL pada tingkat gateway, dan kemudian memperkenalkan plugin distribusi. Akhirnya, permintaan yang diurai diteruskan langsung ke layanan yang ditentukan pada lapisan gateway sesuai dengan aturan konfigurasi.

Klien hanya perlu menentukan spesifikasi rendering selama seluruh proses, bukan sumber data. Lapisan gateway mengambil tanggung jawab distribusi layanan dan meneruskan lalu lintas langsung. File konfigurasi plugin di APISIX dapat diperbarui secara dinamis secara real-time, dan aturan penerusan dapat disesuaikan secara dinamis, yang sangat fleksibel. Sebenarnya, untuk aplikasi seperti arsitektur BFF (Backend for Frontend), persyaratan seperti itu dapat diselesaikan pada lapisan gateway.

Kesimpulan

Artikel ini menyajikan praktik aplikasi pengenalan Apache APISIX oleh Beeto dari perspektif pemikiran desain dan bisnis.

APISIX mendukung Beeto dalam mengontrol biaya sumber daya dan beberapa lini produk bisnis serta membantu Beeto mewujudkan penyebaran yang terlokalisasi, manajemen terpadu, dan skenario yang ramah pemeliharaan di Timur Tengah.