Kung nagtatrabaho ka sa mundo ng pag-develop, tiyak na naranasan mo na ang matagal nang problema kung paano maglipat ng data mula sa isang lugar patungo sa isa pa nang hindi nagkaka-crash ang network. Sa loob ng maraming taon, ang JSON ang hindi mapag-aalinlanganang hari dahil sa pagiging simple nito, ngunit habang lumalaki ang mga application at tumataas ang trapiko, napapansin natin na Ang pagpapadala ng plain text ay isang pasanin medyo mabigat para sa performance.
Dito pumapasok ang Protobuf, isang kagamitang nilikha ng Google na siyang pangunahing nagsisiguro na ang impormasyon ay nakakapaglakbay sa mas siksik at mas mabilis na paraan. Hindi lamang ito isang alternatibo, ito ay isang kwalitatibong paglukso sa kahusayan Para sa mga naghahanap upang masulit ang bawat byte ng kanilang imprastraktura, lalo na sa mga microservices environment o mobile app kung saan mahalaga ang bawat millisecond.
Ano nga ba ang mga Protocol Buffer at paano ito gumagana?
Sa esensya, ang Protocol Buffers ay isang nakabalangkas na mekanismo ng serialization ng data na ganap na neutral sa wika at platform. Hindi tulad ng mga format na nakabatay sa teksto, gumagamit ang Protobuf ng binary encodingNangangahulugan ito na ang data ay hindi nakaimbak bilang mga nababasang salita, ngunit bilang isang na-optimize na pagkakasunud-sunod ng mga byte.
Para gumana ito, kailangan muna nating tukuyin ang ating istruktura ng datos sa isang file na may extension na .proto. Sa dokumentong ito, gumagamit tayo ng Interface Definition Language (IDL) kung saan tinutukoy natin ang mga mensahe at ang kanilang mga field. Ang bawat field ay may pangalan, uri ng datos, at, higit sa lahat, isang natatanging numero ng tagAng numerong ito ay nagbibigay-daan sa sistema na malaman kung anong data ang binabasa nito nang hindi kinakailangang ulitin ang pangalan ng field sa bawat mensahe, isang bagay na nangyayari sa JSON at kumukunsumo ng maraming espasyo.
Paghahambing ng pagganap: Protobuf vs. JSON at FlatBuffers
Kapag inisa-isa natin ang mga bagay-bagay, kahanga-hanga ang pagkakaiba. Kung ikukumpara natin ang Protobuf sa klasikong JSON, ang nauna ay walang dudang panalo sa bilis ng serialization at deserialization. Sa katunayan, posible ito. bawasan ang oras ng pagproseso nang hanggang 80% at ang laki ng huling resulta sa katulad na proporsyon, palaging nakadepende sa uri ng datos.
- JSON: Ito ang pinaka-maginhawa at madaling basahin na opsyon para sa mga tao, mainam para sa mabilis na pag-debug ng mga error, ngunit ito ay mabagal at mahirap dahil sa likas na teksto nito.
- Mga Protocol Buffer: Binabalanse nito ang kadalian ng paggamit at ang mahusay na pagganap. Ito ang karaniwang pagpipilian para sa mga gumagamit ng gRPC na nangangailangan ng maayos na komunikasyon sa pagitan ng server at server.
- Mga FlatBuffer: Ito ang nakatatandang kapatid pagdating sa pag-optimize ng memorya. Ang pinakamalaking bentahe nito ay... "zero-copy"Nangangahulugan ito na maaari mong ma-access ang data nang hindi kinakailangang ganap na i-deserialize ito sa memorya, na ginagawa itong mas mainam na opsyon para sa mga nangangailangan ng maraming video game at app.
Sa usapin ng imbakan, ang Protobuf ay karaniwang mas siksik kaysa sa FlatBuffers dahil gumagamit ito ng integer representation technique na Sinasakop lamang nito ang espasyong mahigpit na kinakailangan. ayon sa halaga ng numero.
Implementasyon at praktikal na paggamit
Para mapagana ang Protobuf, ang karaniwang paraan ay ang paggamit ng compiler ng Google para makabuo ng mga data access class sa iyong gustong wika, Java, C++, Python, o Node.js man ito. Ang mga klaseng ito ay mayroon nang mga kinakailangang pamamaraan para sa punan, gawing serye at alisin sa serye Impormasyon nang walang komplikasyon.
Gayunpaman, may mga implementasyon tulad ng protobuf-net sa .NET ecosystem na nagbibigay-daan para sa mas maikling landas. Sa halip na mahirapan sa mga .proto file, maaari mong gamitin ang mga katangian ng decorator tulad ng ProtoContract at ProtoMember direkta sa mga klase ng C#. Pinapasimple nito ang daloy ng trabaho sa pamamagitan ng pagtatalaga ng mga tag nang direkta sa code, habang pinapanatili ang kahusayan ng binary format.
Mga uri at bersyon ng field
Sa buong ebolusyon nito, iba't ibang bersyon ang lumitaw. Ang pinakabago, Ang proto3 ay isang pinasimpleng bersyon at na-optimize mula sa orihinal na proto2, na idinisenyo upang alisin ang mga kalabisan at mapabuti ang pagiging tugma. Sa loob ng mga scheme na ito, maaari nating pangasiwaan ang iba't ibang mga modifier:
- Kailangan: Ipinapahiwatig nito na kinakailangan ang field; kung ito ay nawawala, ang mensahe ay itinuturing na hindi pa naisasimula.
- Opsyonal: Pinapayagan ang field na naroroon o wala, na nagtatalaga ng default na halaga kung hindi ito ibinigay.
- Paulit-ulit: Mainam para sa mga listahan o koleksyon, na nagpapahintulot sa field na lumitaw nang ilang beses.
Bukod sa mga pangunahing uri tulad ng string, int32, float, o bool, pinapayagan ka ng Protobuf na lumikha mga kumplikadong hirarkiya sa pamamagitan ng message nesting at paggamit ng mga enumerasyon (enums), na ginagawa itong lubos na nababaluktot para sa pagmomodelo ng mga kumplikadong domain ng negosyo.
Mga kaso ng paggamit at arkitektura ng network
Ang pinakakaraniwang pag-deploy ng teknolohiyang ito ay matatagpuan sa gRPC framework. Ang Remote Procedure Call (RPC) system na ito ay gumagamit ng Protobuf bilang exchange language nito, na nagpapahintulot sa isang application na tumawag ng mga function sa ibang makina na parang nasa parehong proseso sila. Ito ay mahalaga para sa komunikasyon sa pagitan ng mga microservice maging halos agad-agad.
Sa mga sektor tulad ng pangangalakal sa pananalapi, ginagamit ang mga partikular na istruktura ng mensahe. Halimbawa, maaaring tukuyin ang mga mensaheng request (Req), response (Res), event (Event), at model. Upang pamahalaan ang fragmentation ng network, ang payload ay kadalasang nakabalot sa isang mensahe ng lalagyan (ProtoMessage) na kinabibilangan ng uri ng payload at isang message ID, na tinitiyak na alam ng tatanggap kung paano eksaktong bigyang-kahulugan ang mga natanggap na byte.
Ang kakayahang i-optimize ang serialization sa pamamagitan ng pointer reuse o string normalization ay maaaring humantong sa matinding pagtitipid ng espasyo. Sa mga totoong sitwasyon sa mundo, ang paglipat mula sa isang karaniwang format patungo sa isa na na-optimize gamit ang FlatBuffers o Protobuf ay naipakita na nakakabawas sa load sa isang serbisyo. 60 segundo hanggang 3 o 4 segundo lamang, inaalis ang mga kritikal na bottleneck.