Salah satu masalah kritis yang muncul saat membangun sistem multi-pengguna adalah penskalaan. Ada berbagai solusi untuk masalah ini: sharding, model layanan, Sistem Entitas-Komponen. Hari ini kami akan mempertimbangkan semua opsi, dan juga membahas kasus praktis untuk menyelesaikan masalah. Bergabunglah sekarang!
Bagian 1Bagian 2Saya menyampaikan kata itu kepada penulis.Pendekatan tradisional untuk membangun sistem multi-pengguna. Arsitektur layanan
Secara historis, metode pertama untuk memecahkan masalah penskalaan adalah sharding - membagi seluruh sistem menjadi sejumlah server dengan kriteria apa pun tanpa keadaan umum di dunia. Artinya, hingga sejumlah pengguna tertentu, mereka bisa berada di server yang sama, saling bertemu dan berinteraksi satu sama lain; tetapi ketika menambahkan yang baru, mereka berakhir dalam salinan ruang virtual yang berjalan di server lain, dan, karenanya, tidak dapat berinteraksi dengan yang lain. Jelas bahwa ini bukan solusi untuk masalah ini, ini adalah solusi. Dan meskipun sharding masuk akal bahkan sekarang, dalam banyak kasus diperlukan pendekatan yang benar-benar dapat meningkatkan kemungkinan beban di server.
Teknik umum kedua adalah model layanan. Server memiliki sejumlah komponen yang dapat dengan mudah diduplikasi. Misalnya, ini adalah database dan bekerja dengannya, atau server aset yang mengirimkannya ke klien, atau server otorisasi. Semua layanan ini dibedakan oleh fakta bahwa Anda dapat memilikinya dalam banyak hal, dan memaralelkan permintaan untuk mereka.
Masalah utama adalah keadaan bersama
Tetapi masalah utamanya berbeda. Apa yang harus dilakukan dengan keadaan dunia tertentu, keadaan ruang virtual? Misalkan "dunia" kita terdiri dari satu adegan 3D, satu set objek di atasnya, dan beberapa pengguna yang terhubung. Secara teoritis, kita dapat menduplikasi beberapa komponen perangkat lunak yang bertanggung jawab untuk bekerja dengan adegan di sisi server. Tetapi masalahnya adalah bahwa keadaan adegan adalah satu hal yang umum untuk semua komponen ini. Karena itu, ketika memparalelkan penangan, kita perlu memecahkan masalah sinkronisasi pekerjaan dengan data, dan pada saat yang sama pada sinkronisasi itu sendiri kita bisa kehilangan kinerja lebih daripada menang dalam paralelisme.
Solusi: Sistem Entitas-Komponen. Masalah dalam kasus Timur Jauh
Salah satu pendekatan yang relatif baru untuk masalah tersebut adalah ECS (Entity - Component System). Dalam versi ini, kami mewakili objek sistem sebagai entitas tertentu yang memiliki beberapa properti. Sebagai contoh, ini mungkin posisi objek dalam ruang dan kecepatannya. Terlebih lagi, semua yang kita simpan pada objek itu sendiri hanyalah beberapa data, tetapi bukan logika bekerja dengannya. Artinya, dalam kasus kami, enam angka hanya akan ditugaskan ke objek - vektor koordinat dan vektor kecepatan.
Bagian kedua ECS adalah pekerja, sistem yang bekerja dengan jenis komponen tertentu. Misalnya, dalam kasus kami, ini mungkin merupakan sistem yang mengubah koordinat suatu objek setiap detik, menambah kecepatannya. Gagasan utamanya adalah pekerja tidak tahu apa-apa tentang objek seperti itu - ia hanya memiliki antrian, pipa komponen yang harus diproses sesuai dengan aturan tertentu. Dengan demikian, kita dapat memparalelkan pekerja, serta layanan yang diparalelkan.
Sistem agen sebagai metode penulisan kode paralel
Pendekatan multi-agen juga bukan hal baru khusus, tetapi baru-baru ini, minat dalam sistem agen telah berkembang. Ada beberapa artikel yang cukup bagus yang menceritakannya secara terperinci, jadi di sini kami hanya menyebutkan secara singkat prinsip-prinsip paling umum dari sistem tersebut:
- Komponen utama dari sistem adalah komponen yang disebut agen atau aktor. Dalam beberapa hal, itu menyerupai objek yang dikenal semua orang, tetapi aktor tidak memiliki metode publik, satu-satunya cara untuk berkomunikasi dengannya adalah mengiriminya pesan;
- Untuk mengirim pesan ke agen ada konsep "tautan". Tautan menyediakan antarmuka tertentu (dalam berbagai implementasi itu bisa terlihat sangat berbeda), yang memungkinkan Anda mengirim pesan. Salah satu properti penting di sini adalah transparansi lokasi, dan keberadaan setiap agen dengan alamat - string yang memungkinkan Anda untuk mendapatkan tautan ke agen terlepas dari lokasi fisiknya, yaitu. agen dapat ditemukan dan bekerja di sistem agen pada komputer yang sama, atau mungkin pada yang lain - dalam hal ini, tautan diperoleh di beberapa alamat jaringan;
- Agen memiliki antrian pesan, dan mereka diproses secara berurutan. Agen dapat menjadi mesin keadaan yang mengubah keadaan dan penangan pesan dalam urutan reaksi terhadap mereka;
- Sebagai aturan, sistem multi-agen bersifat hierarkis, yaitu agen membentuk semacam pohon. Dalam hal ini, kesalahan di salah satu agen tidak menghentikan seluruh sistem, hanya agen tertentu yang terputus, mengirim pesan kesalahan ke leluhurnya. Salah satu pendekatan populer untuk menangani kesalahan semacam itu adalah membiarkannya crash - ketika agen crash, kami cukup membuat salinannya;
- Membuat agen baru bukanlah operasi intensif sumber daya, dan menciptakan sistem itu sendiri sangat mahal.
Cukup sering, sistem agen digunakan hanya dalam pendekatan menggunakan ECS. Karena sistem agen membuatnya sangat mudah untuk menciptakan jumlah pekerja yang diperlukan dan memparalelkan pekerjaan mereka, cukup mendistribusikan aliran pesan di antara mereka, ini terlihat seperti pendekatan yang sangat menjanjikan. Sebagai contoh, ini adalah bagaimana SpatialOS dari Improbable berfungsi.
Masalah muncul di sini dalam bidang yang sedikit berbeda. Pendekatan ECS cukup sederhana, tetapi pada prinsipnya tidak bisa disebut intuitif, terutama untuk programmer yang tidak berpengalaman. Oleh karena itu, pembuatan kode pengguna dalam sistem semacam itu adalah tugas yang agak sepele. Juga, muncul pertanyaan mengenai portabilitas berbagai objek antara instance server virtual, karena bersama-sama dengan objek kita harus mentransfer semua pekerja jika mereka (untuk jenis komponen ini) tidak ada di server lain. Pada prinsipnya, beberapa implementasi sistem agen dapat menyelesaikan beberapa masalah ini, tetapi kami telah memilih pendekatan yang berbeda.
Kasus kami adalah inti dari Timur Jauh sebagai agen
Dalam kasus kami, setiap objek ruang virtual adalah agen, atau lebih tepatnya, sistem agen. Dibandingkan dengan ECS klasik, kita dapat mengatakan bahwa setiap entitas dalam diri kita membawa sistem "pekerja mikro", yang terikat pada objek itu sendiri. Pada saat yang sama, semua keuntungan dari sistem agen dipertahankan (yaitu, kita dapat menjalankan objek seperti itu di utas terpisah, pada mesin terpisah, dll., Hanya dengan mengubah pengaturan server), tetapi objek tetap portabel, dan menulis skrip untuk itu tidak memerlukan divisi ECS .
Dalam hal ini, keadaan dunia dibagi menjadi keadaan masing-masing objek, dan masing-masingnya dapat diproses secara terpisah. Pada klien, kami juga membangun sistem agen, yang merupakan semacam refleksi dari status server, dan kami mengaitkan setiap agen klien dengan agen server. Antara lain, ini juga meningkatkan keandalan sistem, karena jika objek individu gagal, hanya objek ini yang dinonaktifkan, dan bukan seluruh ruang virtual.
Secara lebih detail, tampilannya seperti ini:
Setiap objek luar angkasa adalah sistem agen kecil yang terdiri dari agen utama entitas yang dibuat saat server dimulai, yang bukan merupakan agen wadah komponen dan satu set komponen penangan pesan. Untuk menghubungkan klien, properti transparansi jaringan digunakan, yaitu, setiap objek spesifik pada klien memiliki tautan ke objek agen server. Pada saat yang sama, saat menghubungkan, agen baru dibuat secara dinamis, yang merupakan keturunan dari agen utama.
Sistem agen juga dibuat di sisi klien, tetapi agen entitas di dalamnya dibentuk oleh pesan dari sisi server. Setelah pembuatan, agen menerima tautan ke agen server dan membuat komponen pemrosesan pesan yang mencakup antrian untuk menerima dan mengirim pesan dari server. Objek Unity juga dibuat, dan bagian klien dari komponen objek diwarisi dari MonoBehaviour. Pada saat yang sama, bagian Persatuan dan bagian agen bekerja di utas yang berbeda, penangan pesan bertanggung jawab untuk sinkronisasi (jika mungkin, diminimalkan).
Sesuatu seperti ini (tanpa perincian khusus) terlihat seperti implementasi ruang virtual dinamis dalam varian JIF. Pada artikel selanjutnya, kami akan memberi tahu Anda tentang data besar pribadi dan bekerja dengan statistik, serta tentang blockchain.
Penulis
Jedium adalah perusahaan mitra Microsoft yang bekerja di bidang virtual, augmented reality dan kecerdasan buatan. Jedium telah mengembangkan kerangka kerja untuk menyederhanakan pengembangan proyek kompleks tentang Unity, yang sebagian tersedia
untuk umum
di GitHub . Jedium berencana untuk menambah repositori dengan modul framework baru, serta solusi integrasi dengan Microsoft Azure.
Vitaliy Chashchin - Pengembang perangkat lunak dengan lebih dari 10 tahun pengalaman dalam desain dan implementasi aplikasi client-server tiga dimensi - dari konsep hingga implementasi penuh dan integrasi aplikasi dan solusi di bidang realitas virtual. Arsitek Sistem Jedium LLC, MSc dalam bidang TI.
Alexey SarafanovMarketing Manager di Jedium LLC.
Sergey KudryavtsevCEO dan pendiri Jedium LLC.