Membangunkan platform video dalam 90 hari

Musim bunga ini kami mendapati diri kami berada dalam keadaan yang sangat ceria. Disebabkan oleh wabak itu, menjadi jelas bahawa persidangan musim panas kami perlu dipindahkan dalam talian. Dan untuk menjalankannya dalam talian dengan cekap, penyelesaian perisian siap sedia tidak sesuai untuk kami; kami perlu menulis sendiri. Dan kami mempunyai tiga bulan untuk melakukan ini.

Sudah jelas bahawa ia telah menjadi tiga bulan yang menarik. Tetapi dari luar ia tidak sepenuhnya jelas: apakah platform persidangan dalam talian? Apakah bahagian yang terdiri daripada? Oleh itu, pada persidangan DevOops musim panas yang terakhir, saya bertanya kepada mereka yang bertanggungjawab untuk tugas ini:

  • Nikolay Molchanov - pengarah teknikal Kumpulan JUG Ru;
  • Vladimir Krasilshchik ialah pengaturcara Java pragmatik yang bekerja pada bahagian belakang (anda juga boleh melihat laporannya di persidangan Java kami);
  • Artyom Nikonov bertanggungjawab untuk semua penstriman video kami.

Ngomong-ngomong, pada persidangan musim luruh-musim sejuk kami akan menggunakan versi platform yang sama yang lebih baik - begitu ramai pembaca habra masih akan menjadi penggunanya.

Membangunkan platform video dalam 90 hari

Gambaran Keseluruhan

— Apakah komposisi pasukan itu?

Nikolay Molchanov: Kami mempunyai penganalisis, pereka bentuk, penguji, tiga bahagian hadapan dan bahagian belakang. Dan, sudah tentu, pakar berbentuk T!

— Apakah rupa proses secara umum?

Nikolay: Sehingga pertengahan Mac, kami tidak mempunyai apa-apa yang sedia untuk dalam talian sama sekali. Dan pada 15 Mac, keseluruhan karusel dalam talian mula berputar. Kami menyediakan beberapa repositori, merancang, membincangkan seni bina asas dan melakukan segala-galanya dalam tiga bulan.

Ini, sudah tentu, melalui peringkat klasik perancangan, seni bina, pemilihan ciri, undian untuk ciri tersebut, dasar untuk ciri tersebut, reka bentuk, pembangunan, ujiannya. Akibatnya, pada 6 Jun, kami melancarkan segala-galanya kepada pengeluaran. TechTrain. Terdapat 90 hari untuk semuanya.

— Adakah kita berjaya mencapai apa yang kita komited?

Nikolay: Memandangkan kami kini mengambil bahagian dalam persidangan DevOops dalam talian, ini bermakna ia berjaya. Saya secara peribadi komited kepada perkara utama: Saya akan membawa pelanggan alat yang boleh digunakan untuk membuat persidangan dalam talian.

Cabarannya ialah: berikan kami alat yang kami gunakan untuk menyiarkan persidangan kami kepada pemegang tiket.

Semua perancangan dibahagikan kepada beberapa peringkat, dan semua ciri (kira-kira 30 global) dibahagikan kepada 4 kategori:

  • yang pasti kita akan lakukan (kita tidak boleh hidup tanpa mereka),
  • yang akan kami lakukan kedua,
  • yang tidak akan pernah kita lakukan,
  • dan yang tidak akan pernah kita lakukan.

Kami membuat semua ciri daripada dua kategori pertama.

— Saya tahu bahawa sejumlah 600 keluaran JIRA telah dicipta. Dalam tiga bulan, anda membuat 13 perkhidmatan mikro, dan saya mengesyaki bahawa ia ditulis bukan sahaja di Jawa. Anda menggunakan teknologi yang berbeza, anda mempunyai dua kluster Kubernetes dalam tiga zon ketersediaan dan 5 aliran RTMP di Amazon.

Sekarang mari kita lihat setiap komponen sistem secara berasingan.

Penstriman

— Mari kita mulakan apabila kita sudah mempunyai imej video, dan ia dihantar ke beberapa perkhidmatan. Artyom, beritahu kami bagaimana penstriman ini berlaku?

Artyom Nikonov: Skim umum kami kelihatan seperti ini: imej dari kamera -> bilik kawalan kami -> pelayan RTMP tempatan -> Amazon -> pemain video. Maklumat lanjut menulis mengenainya di Habré pada bulan Jun.

Secara umum, terdapat dua cara global untuk melakukan ini: sama ada pada perkakasan atau berdasarkan penyelesaian perisian. Kami memilih laluan perisian kerana ia lebih mudah dalam kes pembesar suara jauh. Tidak selalu mungkin untuk membawa perkakasan ke pembesar suara di negara lain, tetapi menghantar perisian kepada pembesar suara nampaknya lebih mudah dan lebih dipercayai.

Dari sudut perkakasan, kami mempunyai beberapa kamera (dalam studio kami dan pada pembesar suara jauh), beberapa alat kawalan jauh dalam studio, yang kadangkala perlu dibaiki betul-betul di bawah meja semasa siaran.

Isyarat daripada peranti ini memasuki komputer dengan kad tangkapan, kad input/output dan kad bunyi. Di sana isyarat bercampur dan dipasang ke dalam susun atur:

Membangunkan platform video dalam 90 hari
Contoh susun atur untuk 4 pembesar suara

Membangunkan platform video dalam 90 hari
Contoh susun atur untuk 4 pembesar suara

Selanjutnya, penyiaran berterusan disediakan dengan bantuan tiga komputer: terdapat satu mesin utama dan sepasang yang berfungsi secara bergilir. Komputer pertama mengumpul laporan pertama, kedua - rehat, pertama - laporan seterusnya, kedua - rehat seterusnya, dan seterusnya. Dan mesin utama mencampurkan yang pertama dengan yang kedua.

Ini mewujudkan sejenis segi tiga, dan jika mana-mana nod ini gagal, kami boleh dengan cepat dan tanpa kehilangan kualiti terus menyampaikan kandungan kepada pelanggan. Kami mempunyai situasi sedemikian. Semasa minggu pertama persidangan, kami membetulkan satu mesin, menghidupkan/mematikannya. Orang ramai nampaknya gembira dengan daya tahan kita.

Seterusnya, strim daripada komputer pergi ke pelayan tempatan, yang mempunyai dua tugas: laluan aliran RTMP dan sandaran rekod. Jadi kami mempunyai beberapa titik rakaman. Strim video kemudiannya dihantar ke bahagian sistem kami yang dibina pada perkhidmatan Amazon SaaS. Kami guna MediaLive:,S3,CloudFront.

Nikolay: Apakah yang berlaku di sana sebelum video sampai kepada penonton? Anda mesti memotongnya entah bagaimana, bukan?

Artyom: Kami memampatkan video di pihak kami dan menghantarnya ke MediaLive. Kami melancarkan transkoder di sana. Mereka menukar kod video dalam masa nyata kepada beberapa resolusi supaya orang ramai boleh menontonnya pada telefon mereka, melalui Internet yang lemah di negara ini, dan sebagainya. Kemudian aliran ini dipotong ketulan, beginilah cara protokol berfungsi HLS. Kami menghantar senarai main ke bahagian hadapan yang mengandungi penunjuk kepada bahagian ini.

— Adakah kita menggunakan resolusi 1080p?

Artyom: Lebar video kami adalah sama dengan 1080p - 1920 piksel, dan ketinggiannya kurang sedikit, gambar lebih memanjang - ada sebab untuk ini.

Pemain

— Artyom menerangkan cara video masuk ke dalam strim, cara ia diedarkan ke dalam senarai main yang berbeza untuk resolusi skrin yang berbeza, dipotong menjadi kepingan dan masuk ke dalam pemain. Kolya, sekarang beritahu saya jenis pemain ini, bagaimana ia menggunakan aliran, mengapa HLS?

Nikolay: Kami mempunyai pemain yang boleh ditonton oleh semua penonton persidangan.

Membangunkan platform video dalam 90 hari

Pada asasnya, ini adalah pembalut di sekeliling perpustakaan hls.js, di mana ramai pemain lain ditulis. Tetapi kami memerlukan kefungsian yang sangat khusus: gulung semula dan menandakan tempat orang itu berada, laporan yang sedang dia tonton. Kami juga memerlukan susun atur kami sendiri, pelbagai jenis logo dan segala-galanya yang dibina bersama kami. Oleh itu, kami memutuskan untuk menulis perpustakaan kami sendiri (pembungkus di atas HLS) dan membenamkannya di tapak.

Ini adalah fungsi akar, jadi ia dilaksanakan hampir pertama. Dan kemudian semuanya berkembang di sekelilingnya.

Malah, melalui kebenaran, pemain menerima daripada bahagian belakang senarai main dengan pautan ke bahagian yang dikaitkan dengan masa dan kualiti, memuat turun yang perlu dan menunjukkannya kepada pengguna, melakukan beberapa "ajaib" di sepanjang jalan.

Membangunkan platform video dalam 90 hari
Contoh garis masa

— Butang dibina terus ke dalam pemain untuk memaparkan garis masa semua laporan...

Nikolay: Ya, kami segera menyelesaikan masalah navigasi pengguna. Pada pertengahan April, kami memutuskan bahawa kami tidak akan menyiarkan setiap persidangan kami di tapak web yang berasingan, tetapi akan menggabungkan semuanya pada satu. Supaya pengguna tiket Pas Penuh boleh bebas bertukar antara persidangan yang berbeza: kedua-dua siaran langsung dan rakaman persidangan yang lalu.

Dan untuk memudahkan pengguna menavigasi strim semasa dan bertukar antara trek, kami memutuskan untuk membuat butang "Siaran keseluruhan" dan kad laporan mendatar untuk bertukar antara trek dan laporan. Terdapat kawalan papan kekunci.

— Adakah terdapat sebarang masalah teknikal dengan ini?

Nikolay: Mereka mempunyai bar skrol di mana titik permulaan laporan berbeza ditandakan.

— Akhirnya, adakah anda melaksanakan tanda ini pada bar skrol sebelum YouTube melakukan sesuatu yang serupa?

Artyom: Mereka mempunyainya dalam versi beta ketika itu. Nampaknya ini adalah ciri yang agak kompleks kerana mereka telah menguji sebahagiannya dengan pengguna sepanjang tahun lalu. Dan kini ia telah mencapai jualan.

Nikolay: Tetapi kami sebenarnya mendapatnya untuk dijual dengan lebih cepat. Secara jujur, di sebalik ciri mudah ini terdapat sejumlah besar bahagian belakang, bahagian hadapan, pengiraan dan matematik di dalam pemain.

Bahagian hadapan

— Mari kita fikirkan bagaimana kandungan yang kami paparkan ini (kad ucapan, pembesar suara, tapak web, jadual) sampai ke bahagian hadapan?

Vladimir Krasilshchik: Kami mempunyai beberapa sistem IT dalaman. Terdapat sistem di mana semua laporan dan semua pembesar suara dimasukkan. Terdapat proses di mana penceramah mengambil bahagian dalam persidangan. Penceramah menghantar aplikasi, sistem menangkapnya, kemudian terdapat saluran paip tertentu mengikut mana laporan dibuat.

Membangunkan platform video dalam 90 hari
Ini adalah bagaimana pembesar suara melihat saluran paip

Sistem ini adalah pembangunan dalaman kita.

Seterusnya, anda perlu membina jadual daripada laporan individu. Seperti yang anda ketahui, ini adalah masalah sukar NP, tetapi kami entah bagaimana menyelesaikannya. Untuk melakukan ini, kami melancarkan komponen lain yang menjana jadual dan memuat naiknya ke perkhidmatan awan pihak ketiga Contentful. Di sana, semuanya kelihatan seperti meja di mana terdapat hari persidangan, pada hari-hari ada slot masa, dan dalam slot terdapat laporan, rehat atau aktiviti penajaan. Jadi kandungan yang kita lihat terletak dalam perkhidmatan pihak ketiga. Dan tugasnya adalah untuk menyampaikannya ke tapak.

Nampaknya tapak itu hanyalah halaman dengan pemain, dan tidak ada yang rumit di sini. Kecuali ia tidak. Bahagian belakang di belakang halaman ini pergi ke Contentful, mendapatkan jadual dari sana, menjana beberapa objek dan menghantarnya ke bahagian hadapan. Menggunakan sambungan soket web, yang dibuat oleh setiap pelanggan platform kami, kami menghantarnya kemas kini jadual dari hujung belakang ke hujung hadapan.

Kes sebenar: penceramah menukar kerja tepat semasa persidangan. Kita perlu menukar lencana syarikat majikannya. Bagaimanakah ini berlaku dari bahagian belakang? Kemas kini dihantar kepada semua pelanggan melalui soket web, dan kemudian bahagian hadapan itu sendiri melukis semula garis masa. Semua ini berlaku dengan lancar. Gabungan perkhidmatan awan dan beberapa komponen kami memberi kami peluang untuk menjana semua kandungan ini dan menyediakannya ke hadapan.

Nikolay: Adalah penting untuk menjelaskan di sini bahawa tapak kami bukanlah aplikasi SPA klasik. Ini adalah tapak web berasaskan reka letak dan SPA. Google sebenarnya melihat tapak ini sebagai HTML yang diberikan. Ini bagus untuk SEO dan untuk menyampaikan kandungan kepada pengguna. Ia tidak menunggu 1,5 megabait JavaScript untuk dimuatkan sebelum melihat halaman, ia serta-merta melihat halaman yang telah dipaparkan dan anda merasakannya setiap kali anda menukar laporan. Segala-galanya berlaku dalam setengah saat, kerana kandungan sudah sedia dan disiarkan di tempat yang betul.

— Mari kita buat garisan di bawah semua perkara di atas dengan menyenaraikan teknologi. Tyoma berkata bahawa kami mempunyai 5 aliran Amazon, dan kami menyampaikan video serta bunyi di sana. Kami mempunyai skrip bash di sana, kami menggunakannya untuk melancarkan dan mengkonfigurasi...

Artyom: Ini berlaku melalui API AWS, terdapat banyak lagi perkhidmatan sampingan teknikal di sana. Kami membahagikan tanggungjawab kami supaya saya menyampaikan kepada CloudFront, dan pembangun bahagian hadapan dan belakang mengambilnya dari sana. Kami mempunyai beberapa pengikatan kami sendiri untuk memudahkan susun atur kandungan, yang kemudian kami buat dalam 4K, dsb. Memandangkan tarikh akhir adalah sangat ketat, kami melakukannya hampir sepenuhnya pada AWS.

— Kemudian semua ini masuk ke pemain menggunakan sistem backend. Kami mempunyai TypeScript, React, Next.JS dalam pemain kami. Dan pada bahagian belakang kami mempunyai beberapa perkhidmatan dalam C#, Java, Spring Boot dan Node.js. Ini semua digunakan menggunakan Kubernetes menggunakan infrastruktur Yandex.Cloud.

Saya juga ingin ambil perhatian bahawa apabila saya perlu membiasakan diri dengan platform, ternyata mudah: semua repositori ada di GitLab, semuanya dinamakan dengan baik, ujian ditulis, terdapat dokumentasi. Iaitu, walaupun dalam mod kecemasan, mereka menjaga perkara sedemikian.

Kekangan dan Analitis Perniagaan

— Kami menyasarkan 10 pengguna berdasarkan keperluan perniagaan. Sudah tiba masanya untuk bercakap tentang sekatan perniagaan yang kami ada. Kami terpaksa memastikan beban kerja yang tinggi, memastikan pematuhan undang-undang mengenai pemeliharaan data peribadi. Dan apa lagi?

Nikolay: Pada mulanya, kami bermula dari keperluan video. Perkara yang paling penting ialah storan video yang diedarkan di seluruh dunia untuk penghantaran cepat kepada pelanggan. Lain-lain termasuk resolusi 1080p, serta gulung semula, yang tidak dilaksanakan oleh ramai orang lain dalam mod langsung. Kemudian kami menambah keupayaan untuk mendayakan kelajuan 2x, dengan bantuannya anda boleh "mengejar" dengan siaran langsung dan terus menonton persidangan dalam masa nyata. Dan sepanjang perjalanan, fungsi penandaan garis masa muncul. Selain itu, kami terpaksa bertolak ansur dengan kesalahan dan menahan beban 10 sambungan. Dari sudut pandangan belakang, ini ialah kira-kira 000 sambungan didarab dengan 10 permintaan untuk setiap muat semula halaman. Dan ini sudah 000 RPS/saat. Agak agak.

— Adakah terdapat sebarang keperluan lain untuk "pameran maya" dengan rakan kongsi dalam talian?

Nikolay: Ya, ini perlu dilakukan dengan cepat dan secara universal. Kami mempunyai sehingga 10 syarikat rakan kongsi untuk setiap persidangan, dan kesemuanya perlu disiapkan dalam masa satu atau dua minggu. Walau bagaimanapun, kandungan mereka berbeza sedikit dalam format. Tetapi enjin templat tertentu telah dibuat yang memasang halaman ini dengan cepat, dengan hampir tiada penyertaan pembangunan selanjutnya.

— Terdapat juga keperluan untuk analisis pandangan dan statistik masa nyata. Saya tahu bahawa kami menggunakan Prometheus untuk ini, tetapi beritahu kami dengan lebih terperinci: apakah keperluan yang kami penuhi untuk analitik, dan bagaimana ini dilaksanakan?

Nikolay: Pada mulanya, kami mempunyai keperluan pemasaran untuk mengumpul untuk ujian A/B dan mengumpul maklumat untuk memahami cara menyampaikan kandungan terbaik kepada pelanggan dengan betul pada masa hadapan. Terdapat juga keperluan untuk beberapa analitis pada aktiviti rakan kongsi dan analitis yang anda lihat (lawati kaunter). Semua maklumat dikumpul dalam masa nyata.

Kami boleh memberikan maklumat ini dalam bentuk agregat walaupun kepada pembesar suara: bilangan orang yang menonton anda pada satu masa tertentu. Pada masa yang sama, untuk mematuhi Undang-undang Persekutuan 152, akaun peribadi dan data peribadi anda tidak dijejaki dalam apa jua cara.

Platform ini sudah mempunyai alat pemasaran dan metrik kami untuk mengukur aktiviti pengguna dalam masa nyata (yang melihat detik laporan itu) untuk membina graf kehadiran pada laporan. Berdasarkan data ini, penyelidikan sedang dilakukan yang akan menjadikan persidangan akan datang lebih baik.

Penipuan

— Adakah kita mempunyai mekanisme anti-penipuan?

Nikolay: Disebabkan tempoh masa yang ketat dari sudut perniagaan, tugas itu pada mulanya tidak ditetapkan untuk menyekat sambungan yang tidak perlu dengan serta-merta. Jika dua pengguna log masuk di bawah akaun yang sama, mereka boleh melihat kandungan tersebut. Tetapi kita tahu berapa banyak tontonan serentak yang terdapat dari satu akaun. Dan kami mengharamkan beberapa pelanggar yang berniat jahat.

Vladimir: Untuk kreditnya, salah seorang pengguna yang diharamkan memahami mengapa ini berlaku. Dia datang, minta maaf dan berjanji untuk membeli tiket.

— Untuk semua ini berlaku, anda mesti mengesan sepenuhnya semua pengguna dari masuk ke keluar, sentiasa tahu apa yang mereka lakukan. Bagaimanakah sistem ini berfungsi?

Vladimir: Saya ingin bercakap tentang analitis dan statistik, yang kemudiannya kami analisis untuk kejayaan laporan atau kemudiannya boleh berikan kepada rakan kongsi. Semua pelanggan disambungkan melalui sambungan soket web ke gugusan bahagian belakang tertentu. Ia berdiri di sana hazelcast. Setiap pelanggan pada setiap tempoh masa menghantar apa yang dia lakukan dan trek yang dia tonton. Kemudian maklumat ini diagregatkan menggunakan kerja Hazelcast pantas dan dihantar semula kepada semua orang yang menonton lagu ini. Kita lihat di sudut berapa ramai orang kini bersama kita.

Membangunkan platform video dalam 90 hari

Maklumat yang sama disimpan dalam Mongo dan pergi ke tasik data kami, dari mana kami mempunyai peluang untuk membina graf yang lebih menarik. Timbul persoalan: berapa ramai pengguna unik yang melihat laporan ini? Kita pergi ke postgres, terdapat ping semua orang yang datang dengan id laporan ini. Kami mengumpul, mengagregat yang unik, dan kini kami boleh faham.

Nikolay: Tetapi pada masa yang sama, kami juga menerima data masa nyata daripada Prometheus. Ia ditetapkan terhadap semua perkhidmatan Kubernetes, terhadap Kubernetes sendiri. Ia mengumpul segala-galanya, dan dengan Grafana kami boleh membina sebarang graf dalam masa nyata.

Vladimir: Di satu pihak, kami memuat turun ini untuk pemprosesan OLAP selanjutnya. Dan untuk OLTP, aplikasi memuat turun semuanya ke Prometheus, Grafana dan graf malah bertumpu!

- Ini adalah kes apabila graf bertumpu.

Perubahan Dinamik

— Beritahu kami cara perubahan dinamik dilancarkan: jika laporan dibatalkan 6 minit sebelum permulaan, apakah rantaian tindakan? Saluran paip mana yang berfungsi?

Vladimir: Saluran paip sangat bersyarat. Terdapat beberapa kemungkinan. Yang pertama ialah program penjanaan jadual berfungsi dan menukar jadual. Jadual yang diubah suai dimuat naik ke Contentful. Selepas itu bahagian belakang memahami bahawa terdapat perubahan untuk persidangan ini dalam Contentful, mengambilnya dan membinanya semula. Semuanya dikumpul dan dihantar melalui websocket.

Kemungkinan kedua, apabila segala-galanya berlaku dengan pantas: editor menukar maklumat secara manual dalam Contentful (pautan ke Telegram, pembentangan pembesar suara, dll.) dan logik yang sama berfungsi seperti kali pertama.

Nikolay: Semuanya berlaku tanpa menyegarkan halaman. Semua perubahan berlaku dengan lancar untuk pelanggan. Perkara yang sama berlaku untuk menukar laporan. Apabila tiba masanya, laporan dan antara muka berubah.

Vladimir: Selain itu, terdapat pemotongan masa untuk permulaan laporan dalam garis masa. Pada mulanya tidak ada apa-apa. Dan jika anda mengarahkan tetikus anda ke atas jalur merah, maka pada satu ketika, terima kasih kepada pengarah penyiaran, potongan akan muncul. Pengarah menetapkan permulaan siaran yang betul, bahagian belakang mengambil perubahan ini, mengira masa mula dan tamat keseluruhan persembahan trek mengikut jadual persidangan, menghantarnya kepada pelanggan kami dan pemain membuat potongan. Kini pengguna boleh menavigasi ke permulaan dan penghujung laporan dengan mudah. Ia adalah keperluan perniagaan yang ketat, sangat mudah dan berguna. Anda tidak membuang masa mencari masa mula sebenar untuk laporan. Dan apabila kita melakukan pratonton, ia akan menjadi sangat menarik.

Kerahan

— Saya ingin bertanya tentang penempatan. Kolya dan pasukan menghabiskan banyak masa pada mulanya untuk menyediakan keseluruhan infrastruktur di mana segala-galanya berlaku untuk kami. Beritahu saya, semua itu diperbuat daripada apa?

Nikolay: Dari sudut pandangan teknikal, kami pada mulanya mempunyai keperluan untuk produk menjadi abstrak yang mungkin daripada mana-mana vendor. Datang ke AWS untuk membuat skrip Terraform khusus daripada AWS, atau khusus daripada Yandex, atau daripada Azure, dsb. tidak benar-benar sesuai. Kami terpaksa berpindah ke suatu tempat pada satu ketika.

Untuk tiga minggu pertama kami sentiasa mencari cara untuk melakukan ini dengan lebih baik. Hasilnya, kami membuat kesimpulan bahawa Kubernetes dalam kes ini adalah segala-galanya, kerana ia membolehkan kami membuat perkhidmatan penskalaan automatik, pelancaran automatik dan mendapatkan hampir semua perkhidmatan keluar dari kotak. Sememangnya, semua perkhidmatan perlu dilatih untuk bekerja dengan Kubernetes, Docker, dan pasukan juga perlu belajar.

Kami mempunyai dua kluster. Ujian dan pengeluaran. Mereka benar-benar sama dari segi perkakasan dan tetapan. Kami melaksanakan infrastruktur sebagai kod. Semua perkhidmatan dilancarkan secara automatik ke dalam tiga persekitaran daripada cawangan ciri, cawangan induk, cawangan ujian dan GitLab menggunakan saluran paip automatik. Ini disepadukan secara maksimum ke dalam GitLab, disepadukan secara maksimum dengan Elastic, Prometheus.

Kami mendapat peluang untuk dengan cepat (untuk bahagian belakang dalam masa 10 minit, untuk bahagian hadapan dalam masa 5 minit) melancarkan perubahan kepada mana-mana persekitaran dengan semua ujian, penyepaduan, menjalankan ujian kefungsian, ujian penyepaduan pada persekitaran dan juga menguji dengan ujian beban pada persekitaran ujian kira-kira perkara yang sama yang kita mahu dapatkan dalam pengeluaran.

Mengenai ujian

— Anda menguji hampir segala-galanya, sukar untuk mempercayai bagaimana anda menulis segala-galanya. Bolehkah anda memberitahu kami tentang ujian bahagian belakang: berapa banyak yang dilindungi, apakah ujian?

Vladimir: Dua jenis ujian telah ditulis. Yang pertama ialah ujian komponen. Ujian tahap angkat bagi keseluruhan aplikasi spring dan asas masuk Bekas ujian. Ini adalah ujian bagi senario perniagaan peringkat tertinggi. Saya tidak menguji fungsi. Kami hanya menguji beberapa perkara besar. Contohnya, betul-betul dalam ujian, proses log masuk ke pengguna dicontohi, permintaan pengguna ini untuk tiket ke tempat yang boleh dia pergi dan permintaan akses untuk menonton strim. Senario pengguna yang sangat jelas.

Kira-kira perkara yang sama dilaksanakan dalam apa yang dipanggil ujian integrasi, yang sebenarnya dijalankan pada alam sekitar. Malah, apabila penggunaan seterusnya dalam pengeluaran dilancarkan, senario asas sebenar juga sedang dijalankan dalam pengeluaran. Log masuk yang sama, meminta tiket, meminta akses kepada CloudFront, menyemak sama ada aliran benar-benar bersambung dengan kebenaran saya, menyemak antara muka pengarah.

Pada masa ini saya mempunyai kira-kira 70 ujian komponen dan kira-kira 40 ujian integrasi di atas kapal. Liputan sangat hampir 95%. Ini adalah untuk komponen, kurang untuk integrasi, tidak begitu diperlukan. Memandangkan projek itu melibatkan semua jenis penjanaan kod, ini adalah penunjuk yang sangat baik. Tidak ada cara lain untuk melakukan apa yang kami lakukan dalam tiga bulan. Kerana jika kami menguji secara manual, memberikan ciri kepada penguji kami, dan dia akan menemui pepijat dan mengembalikannya kepada kami untuk pembetulan, maka perjalanan pergi balik untuk menyahpepijat kod ini akan menjadi sangat panjang dan kami tidak akan memenuhi sebarang tarikh akhir.

Nikolay: Secara konvensional, untuk melakukan regresi pada keseluruhan platform apabila menukar beberapa fungsi, anda perlu duduk dan mencucuk di mana-mana selama dua hari.

Vladimir: Oleh itu, ia adalah satu kejayaan besar apabila saya menganggarkan ciri, saya mengatakan bahawa saya memerlukan 4 hari untuk dua pen mudah dan 1 soket web, Kolya membenarkannya. Dia sudah terbiasa dengan fakta bahawa 4 hari ini termasuk 2 jenis ujian, dan kemudian, kemungkinan besar, ia akan berfungsi.

Nikolay: Saya juga mempunyai 140 ujian bertulis: komponen + berfungsi, yang melakukan perkara yang sama. Semua senario yang sama diuji dalam pengeluaran, dalam ujian, dan dalam pengeluaran. Kami juga baru-baru ini menambah ujian UI asas berfungsi. Dengan cara ini kita meliputi fungsi paling asas yang boleh runtuh.

Vladimir: Sudah tentu, patut dibincangkan tentang ujian beban. Ia adalah perlu untuk menguji platform di bawah beban yang hampir dengan yang sebenar untuk memahami bagaimana segala-galanya, apa yang berlaku dengan Arnab, apa yang berlaku dengan JVM, berapa banyak memori yang sebenarnya diperlukan.

— Saya tidak tahu pasti sama ada kami sedang menguji apa-apa di sisi strim, tetapi saya masih ingat bahawa terdapat masalah dengan transkoder semasa kami melakukan pertemuan. Adakah kita telah menguji aliran?

Artyom: Diuji secara berulang. Menganjurkan pertemuan. Dalam proses penganjuran pertemuan, terdapat kira-kira 2300 tiket JIRA. Ini hanyalah perkara umum yang dilakukan oleh orang ramai untuk membuat pertemuan. Kami membawa sebahagian daripada platform ke halaman berasingan untuk pertemuan, yang dikendalikan oleh Kirill Tolkachev (talkkv).

Sejujurnya, tidak ada masalah besar. Secara harfiah beberapa kali kami menangkap pepijat cache di CloudFront, kami menyelesaikannya dengan cepat - kami hanya mengkonfigurasi semula dasar. Terdapat lebih banyak pepijat pada orang, dalam sistem penstriman di tapak.

Semasa persidangan itu, saya terpaksa menulis beberapa lagi pengeksport untuk menampung lebih banyak peralatan dan perkhidmatan. Di sesetengah tempat saya terpaksa membuat basikal sendiri hanya untuk metrik. Dunia perkakasan AV (audio-video) tidak begitu cerah - anda mempunyai beberapa jenis "API" peralatan yang anda tidak boleh pengaruhi. Dan ia jauh dari fakta bahawa anda akan dapat mendapatkan maklumat yang anda perlukan. Penjual perkakasan sangat lambat, dan hampir mustahil untuk mendapatkan apa yang anda inginkan daripada mereka. Secara keseluruhannya terdapat lebih daripada 100 keping perkakasan, mereka tidak memberikan kembali apa yang anda perlukan, dan anda menulis pengeksport yang pelik dan berlebihan, terima kasih yang mana anda boleh sekurang-kurangnya entah bagaimana menyahpepijat sistem.

Оборудование

— Saya masih ingat bagaimana sebelum permulaan persidangan kami membeli sebahagian peralatan tambahan.

Artyom: Kami membeli komputer, komputer riba dan pek bateri. Pada masa ini kita boleh hidup tanpa elektrik selama 40 minit. Pada bulan Jun terdapat ribut petir yang teruk di St. Petersburg - jadi kami mengalami pemadaman sedemikian. Pada masa yang sama, beberapa pembekal datang kepada kami dengan pautan optik dari titik yang berbeza. Ini benar-benar 40 minit masa henti pembinaan, di mana kita akan menghidupkan lampu, bunyi, kamera, dsb.

— Kami mempunyai kisah yang sama dengan Internet. Di pejabat di mana studio kami terletak, kami menyeret jaring yang sengit di antara lantai.

Artyom: Kami mempunyai 20 Gbit gentian antara lantai. Lebih jauh di sepanjang lantai, di suatu tempat terdapat optik, di suatu tempat tidak ada optik, tetapi masih terdapat saluran yang lebih sedikit daripada saluran gigabit - kami menyiarkan video padanya antara trek persidangan. Secara umum, adalah sangat mudah untuk bekerja pada infrastruktur anda sendiri; anda jarang boleh melakukan ini di persidangan luar talian di tapak.

— Sebelum saya bekerja di JUG Ru Group, saya melihat cara bilik perkakasan di persidangan luar talian disediakan semalaman, di mana terdapat monitor besar dengan semua metrik yang anda bina dalam Grafana. Kini terdapat juga bilik ibu pejabat di mana pasukan pembangunan duduk, yang semasa persidangan membetulkan beberapa pepijat dan membangunkan ciri. Pada masa yang sama, terdapat sistem pemantauan yang dipaparkan pada skrin besar. Artyom, Kolya dan lelaki lain duduk dan pastikan semuanya tidak jatuh dan berfungsi dengan baik.

Rasa ingin tahu dan masalah

— Anda bercakap dengan baik tentang fakta bahawa kami mempunyai penstriman dengan Amazon, terdapat pemain dengan web, semuanya ditulis dalam bahasa pengaturcaraan yang berbeza, toleransi kesalahan dan keperluan perniagaan lain disediakan, termasuk akaun peribadi yang disokong untuk entiti undang-undang dan individu, dan kami boleh berintegrasi dengan seseorang menggunakan OAuth 2.0, terdapat anti-penipuan, penyekatan pengguna. Kami boleh melancarkan perubahan secara dinamik kerana kami melakukannya dengan baik, dan semuanya telah diuji.

Saya berminat untuk mengetahui keanehan yang terlibat dalam memulakan sesuatu. Adakah terdapat sebarang situasi pelik semasa anda membangunkan bahagian belakang, bahagian hadapan, sesuatu yang gila ternyata dan anda tidak faham apa yang perlu dilakukan dengannya?

Vladimir: Nampaknya ini hanya berlaku untuk tiga bulan yang lalu. Setiap hari. Seperti yang anda boleh lihat, semua rambut saya telah dicabut.

Membangunkan platform video dalam 90 hari
Vladimir Krasilshchik selepas 3 bulan, apabila beberapa jenis permainan muncul dan tiada siapa yang memahami apa yang perlu dilakukan dengannya

Setiap hari ada sesuatu seperti ini, apabila ada saat seperti itu apabila anda mengambilnya dan mencabut rambut anda, atau menyedari bahawa tidak ada orang lain, dan hanya anda yang boleh melakukannya. Acara besar pertama kami ialah TechTrain. Pada 6 Jun jam 2 pagi kami belum melancarkan persekitaran pengeluaran, Kolya telah melancarkannya. Dan akaun peribadi tidak berfungsi sebagai pelayan kebenaran menggunakan OAuth2.0. Kami mengubahnya menjadi penyedia OAuth2.0 untuk menyambungkan platform kepadanya. Saya telah bekerja selama mungkin 18 jam berturut-turut, saya melihat komputer dan tidak melihat apa-apa, saya tidak faham mengapa ia tidak berfungsi, dan Kolya melihat kod saya dari jauh, mencari pepijat dalam konfigurasi Spring , menemuinya, dan LC berfungsi, dan dalam pengeluaran juga.

Nikolay: Dan sejam sebelum TechTrain pelepasan berlaku.

Banyak bintang telah diselaraskan di sini. Kami sangat bertuah kerana kami mempunyai pasukan yang hebat, dan semua orang terinspirasi oleh idea untuk melakukannya dalam talian. Sepanjang tiga bulan ini kami didorong oleh fakta bahawa kami "membuat YouTube." Saya tidak membenarkan diri saya merobek rambut saya, tetapi memberitahu semua orang bahawa semuanya akan berjalan lancar, kerana sebenarnya, semuanya telah dikira lama dahulu.

Mengenai prestasi

— Bolehkah anda beritahu saya berapa ramai orang berada di tapak pada satu trek? Adakah terdapat sebarang masalah prestasi?

Nikolay: Tiada masalah prestasi, seperti yang telah kami katakan. Bilangan maksimum orang yang menghadiri satu laporan ialah 1300 orang, ini adalah di Heisenbug.

— Adakah terdapat sebarang masalah dengan tontonan tempatan? Dan adakah mungkin untuk mempunyai penerangan teknikal dengan gambar rajah bagaimana semuanya berfungsi?

Nikolay: Kami akan membuat artikel mengenai perkara ini kemudian.

Anda juga boleh nyahpepijat strim secara setempat. Sebaik sahaja persidangan bermula, ia menjadi lebih mudah, kerana aliran pengeluaran nampaknya boleh kita tonton sepanjang masa.

Vladimir: Seperti yang saya faham, pembangun bahagian hadapan bekerja secara tempatan dengan olok-olok, dan kemudian, memandangkan masa untuk melancarkan kepada pembangun di hadapan juga singkat (5 minit), tiada masalah untuk menyemak perkara yang berlaku dengan sijil.

— Semuanya diuji dan dinyahpepijat, walaupun secara tempatan. Ini bermakna kami akan menulis artikel dengan semua ciri teknikal, menunjukkan kepada anda, memberitahu anda segala-galanya dengan gambar rajah, bagaimana keadaannya.

Vladimir: Anda boleh mengambilnya dan mengulanginya.

- Dalam 3 bulan.

Jumlah

— Segala-galanya yang diterangkan bersama kedengaran keren, memandangkan ia telah dilakukan oleh pasukan kecil dalam masa tiga bulan.

Nikolay: Pasukan besar tidak akan melakukan ini. Tetapi sekumpulan kecil orang yang berkomunikasi agak rapat dan baik antara satu sama lain dan boleh mencapai persetujuan boleh. Mereka tidak mempunyai sebarang percanggahan, seni bina telah dicipta dalam dua hari, telah dimuktamadkan dan sebenarnya tidak berubah. Terdapat kemudahan yang sangat ketat untuk keperluan perniagaan masuk dari segi menimbun permintaan dan perubahan ciri.

— Apakah yang terdapat dalam senarai tugasan anda selanjutnya apabila persidangan musim panas telah pun berlangsung?

Nikolay: Contohnya, kredit. Garisan menjalar pada video, timbul di beberapa tempat dalam video bergantung pada kandungan yang ditunjukkan. Sebagai contoh, penceramah ingin bertanya soalan kepada penonton, dan undian muncul pada skrin, yang kembali ke belakang berdasarkan keputusan undian kepada penceramah itu sendiri. Beberapa jenis aktiviti sosial dalam bentuk suka, hati, penilaian laporan semasa pembentangan itu sendiri, supaya anda boleh mengisi maklum balas pada masa yang tepat tanpa terganggu kemudian oleh borang maklum balas. Mulanya macam ni.

Dan juga menambah pada keseluruhan platform, kecuali untuk penstriman dan persidangan, juga keadaan selepas persidangan. Ini adalah senarai main (termasuk yang disusun oleh pengguna), mungkin kandungan daripada persidangan lepas yang lain, bersepadu, dilabel, boleh diakses oleh pengguna, dan juga tersedia untuk dilihat di tapak web kami (live.jugru.org).

— Lelaki, terima kasih banyak atas jawapan anda!

Jika di kalangan pembaca ada mereka yang menghadiri persidangan musim panas kami, sila kongsikan tanggapan anda tentang pemain dan siaran. Apa yang mudah, apa yang menjengkelkan anda, apa yang anda ingin lihat pada masa hadapan?

Jika anda berminat dengan platform dan ingin melihatnya "dalam pertempuran", kami menggunakannya semula pada kami persidangan musim luruh-musim sejuk. Terdapat pelbagai jenis, jadi hampir pasti ada satu yang sesuai untuk anda.

Sumber: www.habr.com

Tambah komen