Temu Duga Backend: Bilakah Anda Patut Memilih REST atau gRPC?

Prompt dan Konteks yang Berkenaan

Sebuah platform mempunyai tiga sempadan API. Penyemak imbas, aplikasi mudah alih, dan rakan kongsi luar menggunakan yang pertama, jadi ia mestilah mudah untuk disepadukan, dinyahpepijat, dan berkembang secara bebas. Yang kedua ialah trafik perkhidmatan-ke-perkhidmatan dalam persekitaran pusat data yang terkawal. Ia mencapai kemuncak pada 20,000 panggilan sesaat dan memerlukan kedua-dua panggilan permintaan-respons biasa serta strim pelayan (server stream). Yang ketiga menerima panggilan balik webhook daripada sistem luar.

Angka 20,000 panggilan sesaat ialah andaian temu duga, bukan ambang prestasi sejagat. Pilih HTTP gaya REST dengan JSON, gRPC natif, atau gabungan yang wajar untuk setiap sempadan, kemudian terangkan migrasi dan pengesahan. REST ialah gaya seni bina dan tidak terikat kepada JSON atau HTTP/1.1. "REST/HTTP+JSON" hanyalah menetapkan pelaksanaan umum yang dibandingkan dalam prompt ini. gRPC bukanlah suis yang secara automatik menjadikan operasi pantas, idempoten, atau boleh dipercayai.

Ini adalah soalan backend kerana terasnya ialah antara muka perkhidmatan, semantik protokol, kontrak klien, dan tadbir urus pengeluaran. Ia tidak meminta keseluruhan sistem perniagaan, dan jadual hafalan "gRPC lebih pantas; REST lebih serasi" adalah tidak mencukupi.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah sama ada calon bermula dengan pengguna dan sempadan rangkaian. Penyemak imbas awam dan ekosistem rakan kongsi menghargai alatan HTTP yang wujud di mana-mana, muatan (payload) yang boleh dibaca, semantik caching, dan kos penyepaduan yang rendah. Pemanggil dalaman yang terkawal boleh menyeragamkan fail .proto, kod yang dijana, proksi, dan pengimbangan beban dengan lebih mudah. Protokol boleh mengikut sempadan; satu platform tidak perlu mendedahkan hanya satu gaya antara muka.

Isyarat kedua ialah memisahkan abstraksi daripada pelaksanaan. REST menggunakan sumber, kaedah HTTP, kod status, dan semantik caching, serta ia boleh berjalan melalui HTTP/2 atau HTTP/3. gRPC berpusat pada perkhidmatan dan kaedah, menggunakan Protocol Buffers sebagai definisi antara muka dan mesej lalainya, serta menyediakan kaedah unary, client-streaming, server-streaming, dan bidirectional-streaming. "REST hanya menggunakan HTTP/1.1" dan "REST tidak boleh menstrim" kedua-duanya adalah jalan pintas yang silap.

Isyarat ketiga ialah melengkapkan kontrak dan model kegagalan. OpenAPI boleh memberikan API HTTP kontrak yang boleh dibaca mesin dan penjanaan kod. Keserasian binari Protobuf tidak menjamin keserasian aplikasi. Mana-mana pilihan masih memerlukan tarikh akhir (deadline), pembatalan, keidempotenan, peraturan ralat yang boleh dicuba semula (retryable-error), pengesahan, kebenaran, evolusi versi, dan identiti permintaan yang boleh diperhatikan.

Akhir sekali, calon yang kuat meminta bukti. Mereka menanda aras muatan yang representatif, konkurensi, pemampatan, tingkah laku sambungan, dan kegagalan, kemudian membuat pelancaran kenari (canary) pada hasilnya sambil mengukur tail latency dan ralat. Migrasi platform yang hanya dijustifikasikan oleh "binari lebih pantas" bukanlah kejuruteraan yang boleh dihasilkan semula.

Soalan untuk Dijelaskan Sebelum Menjawab

• Siapakah yang mengawal klien dan peningkatan (upgrade)? Perkhidmatan di dalam satu organisasi boleh menyelaraskan keluaran klien yang dijana (generated-client). Rakan kongsi yang tidak boleh dipaksa untuk meningkatkan versi memerlukan sempadan stabil yang mudah digunakan secara bebas.
• Adakah interaksi tersebut berbentuk unary, penstriman, atau pemberitahuan tak segerak? CRUD biasa tidak secara automatik mendapat manfaat daripada gRPC. Strim yang teratur melalui sambungan jangka panjang mungkin sesuai dengan gRPC natif. Webhook pihak ketiga dimulakan oleh pihak lain dan biasanya mesti mengikut kontrak HTTP yang diterbitkan oleh pihak tersebut.
• Adakah penyemak imbas mesti memanggil perkhidmatan secara langsung? Penyemak imbas tidak boleh menyediakan semua kawalan HTTP/2 yang diperlukan oleh gRPC natif secara langsung. gRPC-Web, pengekodan transkod JSON (JSON transcoding), atau BFF menambah lapisan yang mengubah penyahpepijatan, keupayaan penstriman, dan operasi.
• Apakah masalah prestasi yang sebenar? Menukar pensirilan tidak akan menghapuskan kesesakan pangkalan data, fan-out hiliran, atau pertanyaan tanpa had. Minta saiz muatan, QPS, konkurensi, p95/p99, CPU, dan belanjawan rangkaian.
• Apakah yang disokong oleh timbunan get laluan dan kebolehlihatan semasa? Sokongan proksi untuk status gRPC, strim, pemeriksaan kesihatan, dan korelasi surih hujung-ke-hujung secara langsung mengubah risiko pelancaran (rollout).
• Bagaimanakah antara muka mesti berkembang? API awam memerlukan dasar keserasian. Protobuf dalaman memerlukan peraturan nombor medan (field-number) dan versi bercampur. Tanpa ujian merentas versi, kontrak yang ditaip kuat (strongly typed) masih boleh gagal semasa penggunaan berguling (rolling deployment).

Rangka Kerja Jawapan 30 Saat

"Saya akan memilih mengikut sempadan pengguna, bukan membuat satu pilihan untuk seluruh platform. API penyemak imbas, mudah alih, dan rakan kongsi bermula sebagai HTTP gaya REST dengan JSON, ditadbir oleh OpenAPI, semantik HTTP, dan dasar keserasian. Webhook pihak ketiga juga mengikut kontrak HTTP awamnya. Bagi laluan dalaman terkawal pada 20,000 panggilan sesaat, saya akan memilih gRPC natif jika penanda aras representatif menunjukkan kos pensirilan atau sambungan adalah penting dan strim pelayan merupakan keperluan sebenar. Klien yang dijana tidak menghapuskan keperluan untuk menetapkan tarikh akhir, menyebarkan pembatalan, mencuba semula hanya operasi yang selamat, dan mengekalkan keserasian medan. Di pinggir, pengekodan transkod JSON atau get laluan nipis boleh berkongsi satu pelaksanaan domain. Sebelum pelancaran, saya akan membandingkan p99 hujung-ke-hujung, CPU, bait, dan pemulihan kegagalan dengan muatan sebenar, kemudian berhijrah mengikut pemanggil. Protokol tidak menggantikan pengesahan, keidempotenan, atau kebolehlihatan."

Perbincangan Mendalam Langkah-demi-Langkah

Langkah 1: Tentukan setiap sempadan secara berasingan

Gunakan HTTP gaya REST dengan JSON untuk sempadan awam. URI sumber, kaedah, kod status, permintaan bersyarat, dan caching difahami secara meluas oleh penyemak imbas, CDN, alatan baris perintah, dan rakan kongsi. OpenAPI boleh menjadi sumber kontrak untuk dokumentasi dan SDK yang dijana, jadi menyifatkan REST sebagai "tidak ditaip dan ditulis tangan" adalah tidak adil. Kosnya ialah pasukan mesti mentadbir model ralat, penomboran halaman (pagination), enum terbuka, dan perubahan spesifikasi secara aktif.

Pilih gRPC untuk sempadan dalaman hanya selepas dua syarat dipenuhi: pemanggil dan pelayan boleh menyeragamkan kod yang dijana dan infrastruktur masa larian, dan penanda aras representatif menunjukkan faedah yang mencukupi untuk menampung kerumitan proksi, penyahpepijatan, dan versi bercampur. Prompt ini juga mempunyai keperluan server-streaming yang sebenar. Kaedah penstriman gRPC dan metadata, status, serta tarikh akhir bagi setiap panggilan membentuk model yang koheren untuknya. Angka 20,000-QPS sahaja tidak membuat keputusan.

Gunakan webhook HTTP untuk panggilan balik pihak ketiga. Penghantar luar mengawal protokol, dan penerima awam memerlukan TLS, pengesahan tandatangan, perakuan (acknowledgment) pantas, dan pemprosesan tak segerak. Menggantikan penerima dengan gRPC tidak menjadikan rakan kongsi yang menghantar permintaan HTTP POST mampu memanggilnya. Jika laluan pemprosesan dalaman menggunakan gRPC, penyesuai webhook mengesahkan dan mengekalkan peristiwa sebelum menggunakan laluan tersebut.

Langkah 2: Tulis kontrak yang boleh dilaksanakan

Antara muka bacaan awam menggunakan sumber dan semantik HTTP:

GET /v1/orders/ord_123
If-None-Match: "order-v7"

200 OK
ETag: "order-v7"
Content-Type: application/json

Antara muka dalaman mentakrifkan tindakan dan mesej:

service OrderService {
  rpc GetOrder(GetOrderRequest) returns (Order);
  rpc WatchOrder(WatchOrderRequest) returns (stream OrderEvent);
}

message GetOrderRequest {
  string order_id = 1;
}

Kedua-dua kontrak memerlukan pengesahan, kebenaran, ralat, peraturan penomboran halaman atau penamatan strim, had saiz, dan medan audit. Nama kaedah gRPC boleh menyembunyikan kos rangkaian, tetapi pemanggil mesti tetap menganggapnya sebagai operasi jauh dengan kependaman, tamat masa (timeout), dan kegagalan separa. REST POST juga tidak secara automatik idempoten; operasi cipta memerlukan kunci idempoten yang stabil atau kekangan keunikan perniagaan.

Langkah 3: Reka bentuk semantik kegagalan

Secara lalai, klien gRPC mungkin tidak mempunyai tarikh akhir, jadi tetapkan satu daripada belanjawan hujung-ke-hujung. Tamatnya tarikh akhir membuatkan pemanggil berhenti menunggu, tetapi aplikasi pelayan kekal bertanggungjawab untuk menghentikan kerja yang telah dimulakannya. Penyebaran tarikh akhir dan pembatalan juga mesti disahkan untuk bahasa dan rangka kerja yang dipilih. Klien HTTP juga memerlukan belanjawan sambungan, respons, dan jumlah keseluruhan; tetapan lalai soket bukanlah SLO perniagaan.

Keputusan percubaan semula (retry) datang daripada semantik perniagaan. HTTP GET, HEAD, PUT, dan DELETE mempunyai sifat selamat atau idempoten dalam spesifikasi, tetapi pelaksanaan mesti mematuhi semantik kaedah tersebut. POST selamat untuk dicuba semula hanya apabila kunci idempoten atau mekanisme yang setara menjadikan hasilnya selamat. Nama kaedah gRPC tidak mendapat keidempotenan automatik; kontrak mesti mengenal pasti status dan operasi yang boleh dicuba semula. Kedua-dua pendekatan memerlukan had percubaan, semakan baki tarikh akhir, dan perlindungan daripada percubaan semula bertimbun di get laluan, SDK, dan aplikasi.

RPC penstriman menambah pengendalian slow-consumer, tekanan balik (backpressure), had setiap mesej, kedudukan penyambungan semula, dan peristiwa pendua. Jika pengguna mesti menyambung semula daripada kursor, peristiwa memerlukan ID atau nombor jujukan yang stabil. Membuka semula strim sahaja tidak dapat membuktikan tiada jurang data yang hilang atau pendua.

Langkah 4: Jadikan kontrak bertahan dalam evolusi berguling

Keserasian REST/JSON merangkumi struktur dan semantik. Menambah medan respons hanya selamat jika klien bertoleransi dengan medan yang tidak diketahui. Mengubah penomboran halaman lalai, susunan, atau maksud enum boleh membiarkan JSON boleh dihuraikan tetapi merosakkan aplikasi. Kawal keluaran dengan perbezaan (diff) OpenAPI, SDK awam terakhir, ulang tayang permintaan yang dirakam, dan penegasan hujung-ke-hujung.

Menambah medan Protobuf biasanya selamat dari segi binari (wire-safe) kerana pembaca lama mengabaikan medan yang tidak diketahui, tetapi kod aplikasi masih boleh rosak disebabkan enum atau nilai lalai baharu. Jangan sekali-kali menukar nombor medan sedia ada. Tempah (reserve) nombor dan nama medan yang dipadam supaya kedua-duanya tidak digunakan semula. Semasa pelancaran berguling, uji klien lama dengan pelayan baharu dan klien baharu dengan pelayan lama; ujian versi yang sama tidak mencukupi.

Apabila klien pinggir dan dalaman memerlukan keupayaan yang sama, kongsi logik domain dan sumber kontrak yang jelas, kemudian dedahkan HTTP melalui pengekodan transkod JSON atau penyesuai nipis di mana sesuai. Penyesuai mesti memetakan status HTTP kepada status gRPC, pengepala kepada metadata, nama medan, pengesahan, dan had penstriman. Dua pelaksanaan perniagaan yang diselaraskan secara manual akan mengalami perbezaan (drift).

Langkah 5: Biarkan bukti berbentuk pengeluaran menentukan migrasi

Gunakan taburan muatan dan campuran kaedah sebenar, bukan penanda aras mikro yang hanya mensirikan satu objek kecil. Berbanding logik domain yang sama, ukur throughput hujung-ke-hujung, p50/p95/p99, CPU klien dan pelayan, bait yang dipindahkan, sambungan, dan memori. Rangkumi panggilan unary, mesej kecil dan besar, pemampatan, strim pelayan, pengguna perlahan, dan trafik rentas zon. Pastikan kerja pangkalan data dan hiliran adalah sama supaya kesan protokol boleh diasingkan.

Jalankan satu kaedah dalaman berisiko rendah dalam mod dual-stack dan laksanakan pelancaran kenari mengikut pemanggil. Bandingkan hasil perniagaan, pengelasan ralat, peristiwa tarikh akhir terlampau, kerja yang diteruskan selepas pembatalan, amplifikasi percubaan semula, dan kesempurnaan surih. Kembangkan hanya selepas memenuhi ambang faedah dan kebolehpercayaan bertulis. Mengekalkan API HTTP apabila peningkatan tidak ketara ialah hasil yang sah.

Contoh Jawapan Berkualiti Tinggi

"Saya tidak akan melabelkan keseluruhan platform sebagai REST atau gRPC. Saya akan bermula dengan siapa yang memanggil setiap sempadan, siapa yang mengawal peningkatan versi, dan corak komunikasi.

Bagi penyemak imbas, aplikasi mudah alih, dan rakan kongsi, saya akan menggunakan HTTP gaya REST dengan JSON. Ia berfungsi dengan ekosistem HTTP yang luas, manakala OpenAPI membekalkan kontrak yang boleh dibaca mesin, penjanaan SDK, dan semakan keserasian. Webhook pihak ketiga kekal sebagai HTTP POST kerana protokol penghantar ialah kekangan luaran. Ingress mengesahkan tandatangan, menyahduplikasi mengikut ID peristiwa, mengekalkan peristiwa, dan memprosesnya secara tak segerak.

Sempadan dalaman mempunyai 20,000 panggilan sesaat dan strim pelayan. Saya akan menanda aras muatan berbentuk pengeluaran. Jika semua pemanggil boleh menggunakan klien yang dijana, proksi, pengimbang beban, dan pemantauan memahami gRPC, serta p99, CPU, atau lebar jalur bertambah baik secukupnya untuk memenuhi ambang bertulis, saya akan menggunakan gRPC di sana. Kaedah unary dan penstriman berada dalam .proto, tetapi setiap panggilan masih mendapat tarikh akhir, pembatalan menghentikan kerja yang dimulakan, dan hanya operasi yang selamat mengikut kontrak dicuba semula.

Untuk evolusi, API HTTP menggunakan perbezaan OpenAPI, SDK lama, dan ulang tayang semantik untuk mengesan kerosakan penomboran halaman atau enum. Nombor medan Protobuf tidak pernah berubah, medan yang dipadam ditempah, dan pasangan klien-pelayan lama/baharu diuji silang. Jika antara muka awam dan dalaman berkongsi keupayaan, satu pelaksanaan domain memberi perkhidmatan kepada penyesuai HTTP dan perkhidmatan gRPC, atau menggunakan pengekodan transkod JSON selepas pemetaan disahkan.

Saya akan melancarkan secara kenari mengikut pemanggil dan memerhatikan p99 hujung-ke-hujung, CPU, bait, pemetaan status, amplifikasi percubaan semula, dan kesempurnaan surih. Jika peningkatan hanya wujud dalam penanda aras mikro manakala kesesakan pengeluaran kekal pada pangkalan data, saya tidak akan mengembangkan migrasi semata-mata demi keseragaman protokol."

Kesilapan Biasa

• Menyamakan REST dengan HTTP/1.1 → Semantik HTTP dan versi pengangkutan dikelirukan → Nyatakan bahawa API REST boleh berjalan melalui HTTP/2 atau HTTP/3.
• Mendakwa gRPC sentiasa lebih pantas → Storan, logik perniagaan, atau proksi mungkin lebih mendominasi → Tanda aras kerja domain yang sama dengan muatan representatif dan tail latency.
• Mengatakan REST tiada kontrak yang kukuh → Ini mengabaikan huraian, penjanaan, dan ujian OpenAPI → Bandingkan aliran kerja kontrak sebenar, bukan spesifikasi yang terabai dengan spesifikasi yang diselenggara.
• Memanggil gRPC natif terus daripada penyemak imbas → Penyemak imbas kekurangan kawalan gRPC natif yang diperlukan → Gunakan gRPC-Web, pengekodan transkod JSON, atau BFF dan ambil kira hadnya.
• Meninggalkan tarikh akhir gRPC → Klien boleh menunggu selama-lamanya dan menggunakan sumber → Dapatkan tarikh akhir daripada belanjawan hujung-ke-hujung dan sahkan pembatalan.
• Menganggap keserasian binari Protobuf sebagai keserasian aplikasi → Enum, nilai lalai, dan maksud baharu masih boleh merosakkan kod → Uji silang versi dan tempah nombor medan.
• Membolehkan percubaan semula pada setiap lapisan → Kegagalan menguatkan trafik dan penulisan boleh berulang → Pusatkan percubaan semula dan hadkan operasi yang selamat, baki masa, dan percubaan.
• Mengekalkan satu protokol hanya untuk keseragaman → Kos penyepaduan awam atau keperluan penstriman dalaman dikorbankan → Gunakan pinggir HTTP dan sempadan dalaman gRPC yang jelas apabila wajar.

Soalan Susulan dan Maklum Balas

Susulan 1: Patutkah API dalaman dengan hanya 500 QPS masih menggunakan gRPC?

QPS sahaja tidak boleh menentukan. Organisasi yang mempunyai platform gRPC yang matang, kontrak yang dijana merentas bahasa, dan keperluan penstriman mungkin masih mendapat manfaat pada 500 QPS. Pasukan dengan satu perkhidmatan CRUD yang mudah, alatan HTTP yang matang, dan ruang prestasi yang mencukupi mungkin mempunyai kos operasi yang lebih rendah dengan REST/HTTP+JSON. Tulis metrik sasaran terlebih dahulu; jangan berhijrah jika keuntungannya tidak dapat ditunjukkan.

Susulan 2: Aplikasi mudah alih awam boleh menggunakan klien gRPC yang dijana. Bolehkah gRPC menjadi API awam?

Ia boleh menjadi calon untuk klien mudah alih yang terkawal, tetapi uji proksi, rangkaian perusahaan, alatan penyahpepijatan, pengendalian sijil, keserasian versi, dan kadens keluaran. Rakan kongsi dan penyemak imbas mungkin masih memerlukan API HTTP, jadi gRPC awam tidak secara automatik menghapuskan kos protokol dwi (dual-protocol). Tentukan mengikut kumpulan pemanggil daripada menganggap "Internet awam" sebagai satu klien.

Susulan 3: Bagaimanakah satu .proto boleh mendedahkan API JSON juga?

Anotasikan kaedah dengan pemetaan HTTP dan gunakan pengekodan transkod JSON atau get laluan. Sebelum pelancaran, sahkan nama medan, tingkah laku null dan lalai, pemetaan status HTTP dan gRPC, metadata dan pengepala, pengesahan, caching, dan had penstriman. Sumber kontrak .proto mengurangkan pertindihan, tetapi semantik penyesuai masih memerlukan ujian.

Susulan 4: Bagaimanakah strim gRPC menyambung semula tanpa kehilangan peristiwa?

Protokol ini menyediakan penstriman dan susunan dalam satu RPC, bukan langganan perniagaan yang tahan lama (durable). Berikan nombor jujukan yang stabil kepada peristiwa, simpan log yang boleh diulang tayang, dan minta klien mengekalkan atau menghantar kursor yang telah digunakan semasa menyambung semula. Tentukan pengekalan, pengendalian kursor yang tamat tempoh, dan penyahduplikasian. Jika keperluan tersebut mendominasi, bandingkan log atau giliran mesej daripada memaksakan RPC menjadi sedemikian.

Susulan 5: Penanda aras menunjukkan p99 gRPC yang lebih baik, tetapi pengeluaran tidak. Apakah yang anda periksa?

Pecahkan kependaman kepada giliran klien, kerja DNS dan sambungan, proksi, pensirilan, logik aplikasi, pangkalan data, dan panggilan hiliran. Semak sama ada muatan pengeluaran, pemampatan, penggunaan semula sambungan, TLS, penghalaan rentas zon, dan percubaan semula tersembunyi sepadan dengan penanda aras. Jika protokol hanyalah sebahagian kecil daripada jumlah kependaman, optimumkan komponen yang dominan daripada mengembangkan migrasi.