Sepuluh blog teknikal "Ten Talks on Linux High-Performance Network Programming" telah ditulis selama beberapa bulan, saya fikir saya akan menulis ringkasan untuk menyemak kerja saya dalam beberapa tahun yang lalu hampir 8 Walaupun saya menghabiskan banyak masa bekerja pada skru, saya masih belajar banyak daripada pengalaman saya dalam evolusi seni bina berprestasi tinggi, daripada penyertaan, pengoptimuman kepada reka bentuk akhir seni bina.
Semua orang sepatutnya mengalami proses projek dari 0 hingga 1. Saya ingin bertanya: Dalam banyak kes, adakah seni bina berkembang dengan perniagaan atau adakah ia direka lebih awal
Sesetengah orang mungkin telah mempelajari buku seni bina yang berkaitan Kebanyakan buku ini percaya bahawa seni bina berkembang dengan pembangunan perniagaan. Walau bagaimanapun, terdapat juga ramai arkitek yang menegaskan bahawa seni bina harus direka lebih awal. Di sini, saya tidak akan membuat kesimpulan buat masa ini, tetapi meneroka evolusi seni bina melalui pengalaman saya sendiri.
PHP, sebagai bahasa yang ringkas dan mudah, harus ada di semua jabatan kilang besar Pada masa itu, saya menggunakan dua bahasa untuk kerja: C++ dan PHP Menggunakan PHP untuk membangunkan fungsi adalah sangat pantas adalah banyak perpustakaan matang, jadi ia membentuk seni bina nginx Klasik
+php-fpm+memcache.
php seni bina
Di bawah seni bina semasa, ia bukan masalah besar untuk mesin 8c8g tunggal untuk menyokong 1000qps, jadi untuk perniagaan, ia pada masa ini kurang daripada 1wqps Jelas sekali, beberapa mesin lagi boleh menyokongnya. Mengenai reka bentuk lapisan cache, apabila redis belum dibangunkan dengan baik, memcache ialah komponen cache arus perdana pada masa itu, dan ia mudah untuk perniagaan dan dok dengan PHP. Namun, dengan perkembangan perniagaan, mengikut keluk pengiraan pada masa itu, ia mungkin mencapai 5wqps dalam masa setahun Adakah munasabah untuk menggunakan seni bina nginx + php-fpm + memcache Selepas perbincangan, matlamatnya adalah prestasi tinggi pada pelayan sisi, jadi kami memulakan perjalanan penemuan berprestasi tinggi.
pelayan-php
Namun, akan ada beberapa masalah yang perlu diselesaikan di sini:
Dapat dilihat bahawa SPP adalah seni bina pelbagai proses Seni binanya serupa dengan Nginx dan terbahagi kepada proses Proksi dan proses Pekerja, antaranya:
Proses proksi menggunakan handle_init untuk melakukan permulaan, handle_route dimajukan kepada proses pemprosesan pekerja yang ditentukan untuk pelaksanaan dan handle_input mengendalikan kemasukan paket permintaan
2.3 Memperkenalkan coroutine
... int ret = redis->GetString(k, getValueCallback) ...
GetValueCallback ialah fungsi panggil balik Jika terdapat banyak operasi io, panggilan balik di sini akan menjadi sangat menyusahkan Walaupun ia dirangkumkan dalam kaedah penyegerakan yang sama, ia akan menjadi sangat menyusahkan untuk dikendalikan pada masa itu std::async tidak diperkenalkan.
Sebaliknya, berdasarkan fakta bahawa qps berikutnya mungkin mencapai tahap 10~20w, coroutine akan mempunyai lebih banyak kelebihan dalam prestasi pemprosesan perkhidmatan multi-IO, jadi kami mula mengubah kaedah coroutine dan menggantikan semua tempat io dengan coroutines, untuk pembangunan perniagaan, kodnya menjadi seperti ini:
... int ret = redis->GetString(k, value) ...
Nilai ialah nilai pulangan yang boleh digunakan secara langsung Setelah terdapat io dalam kod, lapisan bawah akan menggantikan io dengan API coroutine Dengan cara ini, semua operasi io yang disekat akan menjadi primitif penyegerakan, struktur kod kecekapan pembangunan. Kedua-duanya telah banyak bertambah baik (untuk pelaksanaan coroutine khusus, sila rujuk siri artikel "Sepuluh Ceramah tentang Pengaturcaraan Rangkaian Berprestasi Tinggi Linux | Coroutines").
Coroutine
Masih tidak banyak perubahan dalam seni bina Pendekatan pelbagai proses + coroutine telah menyokong pembangunan perniagaan selama beberapa tahun Walaupun tiada pertumbuhan eksponen dalam prestasi, kami telah memperoleh lebih banyak pengalaman dalam penerokaan dan pemendakan berprestasi tinggi.
Perniagaan terus berkembang, dan jurutera sentiasa mengikuti konsep Cloud native yang paling canggih, sebagai titik teknologi yang popular dalam beberapa tahun kebelakangan ini, secara semula jadi tidak akan diabaikan, sebelum memasuki cloud native, jika pasukan anda tidak mempunyai a Konsep pembangunan DevOps, ini Ia akan menjadi satu proses yang menyakitkan yang memerlukan pembayaran balik hutang teknikal pada reka bentuk seni bina dan pemilihan rangka kerja.
Pada masa lalu, saya menganggap prestasi tinggi semasa membuat seni bina, dengan pemahaman saya tentang seni bina, saya mendapati prestasi tinggi hanyalah satu bidang reka bentuk seni bina yang kecil Jika anda ingin membina seni bina yang baik, anda memerlukan proses yang lebih tangkas konsep tadbir urus perkhidmatan
DevOps
Pada ketika ini anda akan mendapati bahawa pelayan berprestasi tinggi yang ringkas telah menjadi matlamat seni bina, jadi adalah perlu untuk menyiasat semula dan mereka bentuk seni bina untuk melaksanakan konsep DevOps dengan jayanya.3.2 Berbilang benang
(1)Penyelidikan gRPC
gRPC
gRPC ialah RPC berbilang benangPelayan Ia mempunyai ekosistem yang matang, pelbagai perisian tengah, menyokong berbilang bahasa, dll. Ia adalah pilihan yang baik untuk pembangunan perniagaan dari 0 hingga 1, tetapi ia menghadapi cabaran untuk migrasi perniagaan, seperti membangun. penemuan perkhidmatan penyesuaian Middleware anda sendiri, pusat konfigurasi, dsb., protokol transformasi mengikut pengekodan dan penyahkodan tersuai, cara menggabungkan coroutine, dsb., supaya ia dapat memuaskan sesetengah perniagaan, tetapi ia masih perlu disepadukan dengan lebih baik dengan RPC
Pelayan daripada komponen syarikat.
Kebetulan tRPC sedang dibangunkan dalam syarikat itu, kami mendapati ia pada asasnya memenuhi keperluan, jadi kami cuba menyesuaikan versi C++ tRPC kepada sistem kami pada peringkat awal pembangunan. rangka kerja RPC berprestasi tinggi telah dipindahkan dan digunakan dalam sistem perniagaan Kini, seni bina tRPC:
https://trpc.group/zh/docs/what-is-trpc/archtecture_design/
Berdasarkan pertimbangan dan pembangunan perniagaan di atas, kami mula cuba menyatukan rangka kerja Pelayan RPC berdasarkan prestasi tinggi untuk menyesuaikan diri dengan senario kepelbagaian RPC seterusnya, jadi kami melaksanakan set asas RPC
Pelayan yang menyesuaikan diri dengan Bingkai sistem perniagaan kami:
Seni bina baharu
3.3 Melangkah ke k8sNampaknya anda hanya boleh mengejar teknologi yang lebih baharu dan menunggu arah aliran seterusnya. Malah, terdapat lebih banyak cabaran pada masa ini disebabkan kemudahan awan dan pengembangan seni bina perkhidmatan migrasi, perkhidmatan perniagaan dan tahap logik yang tidak teratur menjadi semakin kompleks Pada masa yang sama, pautan hiliran yang bergantung pada perkhidmatan semakin lama dan lebih panjang Walaupun rangka kerja kami menyokong penjejakan pautan, semakin lama pautan, kebolehkawalan dan kestabilan perkhidmatan akan menjadi lebih teruk dan lebih teruk. lebih banyak akan dibazirkan sokongan manusia untuk ops harian.
Apa yang perlu dilakukan?…
Perlukah kita menggabungkan logik perniagaan dan memudahkan seni bina Masalahnya di sini ialah apabila logik perniagaan adalah kompleks, kitaran sering mengambil masa yang lama, dan dari perspektif kos, ia agak tinggi, dan faedahnya tidak terlalu besar
Sekiranya kita membangunkan semula seni bina baharu, mengekalkan seni bina yang reput seperti sedia ada atau meninggalkannya, dan menggunakan seni bina baharu untuk menyesuaikan diri dengan pembangunan seterusnya.
Atas ialah kandungan terperinci Sepuluh Perbincangan tentang Pengaturcaraan Rangkaian Berprestasi Tinggi Linux. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!