Sepuluh Perbincangan tentang Pengaturcaraan Rangkaian Berprestasi Tinggi Linux

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.

1. Reka bentuk terlebih dahulu atau evolusi perniagaan?

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.

2. Daripada PHP kepada C++

2.1 Seni bina PHP yang ringkas

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.

2.2 Rangka kerja pelbagai proses

Pada masa itu, untuk melaksanakan rangka kerja sisi pelayan berprestasi tinggi, orang ramai mencuba beberapa penyelesaian Salah satunya adalah menggunakan fungsi pemalam PHP untuk menyepadukan fungsi pelayan ke dalam bahasa skrip. Pendekatan ini mencapai matlamat prestasi tinggi pada tahap tertentu. Sebagai contoh, swole PHP kini merupakan hasil pembangunan kaedah ini.

pelayan-php

Namun, akan ada beberapa masalah yang perlu diselesaikan di sini:

Biasa dengan senario penggunaan sambungan PHP untuk mengelakkan perangkap
Masalah kebocoran memori dalam penggunaan PHP itu sendiri
Kos penyelesaian masalah apabila masalah berlaku Sebagai contoh, apabila masalah berlaku, kadangkala kita perlu memahami kod sumber PHP, tetapi dengan ratusan ribu baris kod, kos ini agak tinggi
• .
PHP adalah mudah untuk digunakan Ini sebenarnya agak benar Dengan kebangkitan Docker, era yang berdiri sendiri sudah pasti akan berlalu.
• …
Berdasarkan pemikiran dan analisis perkembangan perniagaan di atas, sebenarnya adalah lebih munasabah untuk kami melaksanakan sendiri pelayan atau menggunakan rangka kerja C++ sedia ada untuk melaksanakan satu set pelayan lapisan perniagaan Oleh itu, selepas pertimbangan, kami menerima pakai rangka kerja SPP syarikat . Seni binanya adalah seperti berikut:

Seni bina rangka kerja SPP

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

• Proses pekerja menggunakan handle_init untuk melakukan pemula, handle_process memproses pakej dan logik perniagaan serta pengembalian
Selepas menggunakan seni bina C++, prestasi mesin tunggal dipertingkatkan secara langsung kepada 6kqps, yang pada asasnya memenuhi keperluan prestasi Ia boleh menyokong lebih banyak perniagaan pada mesin yang sama.

2.3 Memperkenalkan coroutine

Menggunakan C++ telah memenuhi keperluan prestasi, tetapi terdapat banyak masalah dalam kecekapan pembangunan, seperti mengakses redis Untuk mengekalkan prestasi tinggi perkhidmatan, logik kod menggunakan panggilan balik tak segerak, sama seperti berikut:

.

...
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.

3. Asal awan

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.

3.1 Laksanakan konsep DevOps

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

Penyepaduan Berterusan: Pembangun menyepadukan kod ke dalam repositori kongsi berbilang kali sehari, dan setiap perubahan terpencil pada kod diuji serta-merta untuk mengesan dan mencegah isu penyepaduan
Penghantaran Berterusan: Penghantaran Berterusan (CD) memastikan setiap versi kod yang diuji dalam repositori CI sedia untuk dikeluarkan
Penyerahan berterusan: Ini termasuk penggunaan skala kelabu, keluaran biru-hijau, dsb. Tujuannya adalah untuk lelaran dengan cepat Selepas ujian penyepaduan yang agak lengkap, pengesahan skala kelabu boleh dicapai
Penemuan perkhidmatan: Tukar perkhidmatan kepada perkhidmatan mikro untuk memudahkan panggilan antara perkhidmatan
Rangka kerja RPC: Rangka kerja pelayan yang mengejar prestasi tinggi juga perlu mempertimbangkan sokongan komponen asas seperti pengehadan arus dan pemutus litar
Sistem pemantauan: Bersepadu dengan Promethues, OpenTracing dan fungsi lain, ia boleh menemui masalah dalam talian dengan cepat dalam proses pembangunan tangkas
Pengkontenaan: Untuk menyatukan alam sekitar dan mempertimbangkan senario asli awan terlebih dahulu, kontena adalah penting dalam proses pembangunan
…

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

Berdasarkan DevOps, digabungkan dengan rangka kerja Pelayan C++ di atas, kami mendapati bahawa pelbagai proses tidak lagi dapat memenuhi keperluan seni bina. Sebabnya adalah seperti berikut:

Pelbagai proses tidak konsisten dengan konsep proses tunggal bekas Docker
Proses pekerja mempunyai beban yang tidak sekata, cara menggunakan berbilang teras dengan lebih baik
Bersambung dengan berkesan dengan sistem pemantauan
Konfigurasi perniagaan dimuatkan berulang kali dan pusat konfigurasi perlu disesuaikan semula
Adalah tidak munasabah untuk menggunakan pelbagai proses untuk menyediakan perkhidmatan stateful
…

Perniagaan juga telah berkembang kepada satu juta QPS Untuk pengurusan perkhidmatan dan kos panggilan perkhidmatan yang lebih baik, kami perlu mempertimbangkan seni bina lain:

(1)Penyelidikan gRPC

gRPC

gRPC ialah RPC berbilang benang

Pelayan 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.

(2)Gunakan tRPC

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 k8s

Selepas melalui pemilihan dan transformasi di atas, perkhidmatan kami boleh disambungkan langkah demi langkah semasa migrasi ke k8s Perkhidmatan ini tidak perlu menjalani terlalu banyak transformasi untuk dijalankan pada platformnya, dan setiap platform yang disambungkan juga boleh. disokong sepenuhnya.

Nampaknya 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!