protobuf กับ gRPC

ฉันพยายามทำความเข้าใจ protobuf และ gRPC และฉันจะใช้ทั้งสองอย่างได้อย่างไร คุณช่วยฉันเข้าใจสิ่งต่อไปนี้ได้ไหม:

• พิจารณาโมเดล OSIว่าอะไรอยู่ที่ไหนเช่น Protobuf อยู่ที่เลเยอร์ 4?
• เมื่อนึกถึงการถ่ายโอนข้อความว่า "โฟลว์" เป็นอย่างไร gRPC กำลังทำอะไรในสิ่งที่ protobuf คิดถึง?
• หากผู้ส่งใช้ protobuf เซิร์ฟเวอร์จะใช้ gRPC ได้หรือไม่หรือ gRPC จะเพิ่มสิ่งที่เฉพาะไคลเอ็นต์ gRPC เท่านั้นที่สามารถส่งมอบได้
• หาก gRPC สามารถทำให้การสื่อสารแบบซิงโครนัสและอะซิงโครนัสเป็นไปได้ Protobuf มีไว้สำหรับการมาร์แชลดังนั้นจึงไม่มีส่วนเกี่ยวข้องกับสถานะ - จริงหรือเท็จ?
• ฉันสามารถใช้ gRPC ในแอปพลิเคชันส่วนหน้าที่สื่อสารแทน REST หรือ GraphQL ได้หรือไม่

ฉันรู้แล้ว - หรือสมมติว่าฉันทำ - ว่า:

Protobuf

• โปรโตคอลไบนารีสำหรับการแลกเปลี่ยนข้อมูล
• ออกแบบโดย Google
• ใช้ "โครงสร้าง" ที่สร้างขึ้นเช่นคำอธิบายที่ไคลเอนต์และเซิร์ฟเวอร์เพื่อยกเลิก - / - ข้อความมาร์แชล

gRPC

• ใช้ protobuf (v3)
• อีกครั้งจาก Google
• กรอบสำหรับการเรียก RPC
• ใช้ HTTP / 2 ด้วย
• สามารถสื่อสารแบบซิงโครนัสและอะซิงโครนัสได้

ฉันคิดอีกครั้งว่าเป็นคำถามง่ายๆสำหรับคนที่ใช้เทคโนโลยีนี้อยู่แล้ว ฉันยังคงขอบคุณที่อดทนรอและช่วยเหลือฉัน ฉันจะขอบคุณมากสำหรับการเจาะลึกเทคโนโลยีเครือข่ายใด ๆ

บัฟเฟอร์โปรโตคอลคือ (คือ?) ภาษานิยามอินเตอร์เฟสและไลบรารีการทำให้เป็นอนุกรม:

• คุณกำหนดโครงสร้างข้อมูลของคุณใน IDL เช่นอธิบายออบเจ็กต์ข้อมูลที่คุณต้องการใช้
• มีรูทีนในการแปลอ็อบเจ็กต์ข้อมูลของคุณเป็นและจากไบนารีเช่นสำหรับการเขียน / อ่านข้อมูลจากดิสก์

gRPCใช้ IDL เดียวกัน แต่เพิ่มไวยากรณ์ "rpc" ซึ่งช่วยให้คุณสามารถกำหนดลายเซ็นเมธอด Remote Procedure Call โดยใช้โครงสร้างข้อมูล Protobuf เป็นชนิดข้อมูล:

• คุณกำหนดโครงสร้างข้อมูลของคุณ
• คุณเพิ่มนิยามวิธี rpc ของคุณ
• มีรหัสเพื่อให้บริการและเรียกลายเซ็นเมธอดผ่านเครือข่าย
• คุณยังคงสามารถจัดลำดับวัตถุข้อมูลด้วยตนเองด้วย Protobuf ได้หากต้องการ

ในการตอบคำถาม:

1. gRPC ทำงานที่เลเยอร์ 5, 6 และ 7 Protobuf ทำงานที่เลเยอร์ 6
2. เมื่อคุณพูดว่า "การโอนข้อความ" Protobuf จะไม่เกี่ยวข้องกับการโอนเอง ใช้งานได้เฉพาะเมื่อสิ้นสุดการถ่ายโอนข้อมูลใด ๆ โดยเปลี่ยนไบต์เป็นวัตถุ
3. ใช้ gRPC โดยวิธีการเริ่มต้นที่คุณกำลังใช้ Protobuf คุณสามารถเขียนไคลเอนต์ของคุณเองที่ใช้ Protobuf แต่ไม่ใช่ gRPC เพื่อทำงานร่วมกับ gRPC หรือปลั๊กอิน serializers อื่น ๆ ไปยัง gRPC แต่การใช้ gRPC จะง่ายกว่า
4. จริง
5. ใช่คุณสามารถ

จริงๆแล้ว gRPC และ Protobuf เป็น 2 สิ่งที่แตกต่างกันอย่างสิ้นเชิง ให้ฉันเข้าใจง่าย:

• gRPC จัดการวิธีที่ไคลเอนต์และเซิร์ฟเวอร์สามารถโต้ตอบได้ (เช่นเดียวกับเว็บไคลเอนต์ / เซิร์ฟเวอร์ที่มี REST API)
• protobuf เป็นเพียงเครื่องมือ serialization / deserialization (เช่นเดียวกับ JSON)

gRPC มี 2 ฝั่งคือฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์ที่สามารถหมุนเซิร์ฟเวอร์ได้ เซิร์ฟเวอร์เปิดเผย RPC (เช่นฟังก์ชันที่คุณสามารถเรียกใช้จากระยะไกล) และคุณมีตัวเลือกมากมายที่นั่น: คุณสามารถรักษาความปลอดภัยการสื่อสาร (โดยใช้ TLS), เพิ่มเลเยอร์การตรวจสอบความถูกต้อง (โดยใช้ตัวสกัดกั้น), ...

คุณสามารถใช้ protobuf ภายในโปรแกรมใดก็ได้โดยไม่จำเป็นต้องเป็นไคลเอนต์ / เซิร์ฟเวอร์ หากคุณต้องการแลกเปลี่ยนข้อมูลและต้องการให้พิมพ์อย่างชัดเจน protobuf เป็นตัวเลือกที่ดี (รวดเร็วและเชื่อถือได้)

ดังที่กล่าวไว้คุณสามารถรวมทั้งสองอย่างเพื่อสร้างระบบไคลเอนต์ / เซิร์ฟเวอร์ที่ดี: gRPC จะเป็นรหัสไคลเอนต์ / เซิร์ฟเวอร์ของคุณและปกป้องโปรโตคอลข้อมูลของคุณ

PS: ฉันเขียนบทความนี้เพื่อแสดงให้เห็นว่าเราสามารถสร้างไคลเอนต์ / เซิร์ฟเวอร์ด้วย gRPC และ protobuf โดยใช้ Go ทีละขั้นตอนได้อย่างไร

grpcเป็นเฟรมเวิร์กที่สร้างโดย Google และใช้ในโปรเจ็กต์การผลิตจาก Google เองและ #HyperledgerFabric สร้างขึ้นด้วย grpc มีแอปพลิเคชันโอเพนซอร์ซจำนวนมากที่สร้างด้วย grpc

protobuffเป็นการแสดงข้อมูลเช่นjsonซึ่งเป็นของ google ในความเป็นจริงพวกเขามีไฟล์โปรโตหลายพันไฟล์ที่สร้างขึ้นในโครงการผลิตของพวกเขา

grpc

• gRPC เป็นเฟรมเวิร์กโอเพนซอร์สที่พัฒนาโดย Google
• ช่วยให้เราสามารถสร้างคำขอและการตอบสนองสำหรับ RPC และจัดการส่วนที่เหลือตามกรอบ
• REST เป็น CRUD ที่มุ่งเน้น แต่ grpc มุ่งเน้น API (ไม่มีข้อ จำกัด )
• สร้างบน HTTP / 2
• ให้ >>>>> Auth, Loadbalancing, Monitoring, logging
• [HTTP / 2]
  • HTTP1.1 เปิดตัวในปี 1997 เมื่อนานมาแล้ว
  • HTTP1 เปิดการเชื่อมต่อ TCP ใหม่ไปยังเซิร์ฟเวอร์ตามคำขอแต่ละครั้ง
  • มันไม่บีบอัดส่วนหัว
  • ไม่มีการผลักดันเซิร์ฟเวอร์มันใช้งานได้กับ Req, Res
  • HTTP2 เปิดตัวในปี 2015 (SPDY)
  • รองรับมัลติเพล็กซ์
  • ไคลเอนต์และเซิร์ฟเวอร์สามารถพุชข้อความแบบขนานผ่านการเชื่อมต่อ TCP เดียวกัน
  • ช่วยลดเวลาแฝงได้อย่างมาก
  • HTTP2 รองรับการบีบอัดส่วนหัว
  • HTTP2 เป็นไบนารี
    • โปรโตบัฟเป็นไบนารีดังนั้นจึงเหมาะอย่างยิ่งสำหรับ HTTP2
• [ประเภท]
  • ยูนารี
  • การสตรีมไคลเอนต์
  • การสตรีมเซิร์ฟเวอร์
  • การสตรีมแบบสองทิศทาง
  • เซิร์ฟเวอร์ grpc เป็น Async ตามค่าเริ่มต้น
  • ไคลเอ็นต์ grpc สามารถซิงค์หรือ Async

โปรโตบัฟ

• บัฟเฟอร์โปรโตคอลเป็นภาษาที่ไม่เชื่อเรื่องพระเจ้า
• การแยกวิเคราะห์บัฟเฟอร์โปรโตคอล (รูปแบบไบนารี) จะใช้ CPU น้อยกว่า
• [การตั้งชื่อ]
  • ใช้ตัวพิมพ์ใหญ่อูฐสำหรับชื่อข้อความ
  • underscore_seperated สำหรับฟิลด์
  • ใช้ camelcase สำหรับ Enums และ CAPITAL_WITH_UNDERSCORE สำหรับชื่อค่า
• [ความคิดเห็น]
  • สนับสนุน //
  • สนับสนุน / * * /
• [ข้อดี]
  • พิมพ์ข้อมูลครบถ้วนแล้ว
  • ข้อมูลถูกบีบอัดอย่างสมบูรณ์ (ใช้แบนด์วิดท์น้อยลง)
  • ต้องใช้ Schema (ข้อความ) ในการสร้างรหัสและอ่านรหัส
  • เอกสารประกอบสามารถฝังอยู่ในสคีมา
  • ข้อมูลสามารถอ่านได้ทุกภาษา
  • Schema สามารถพัฒนาได้ตลอดเวลาอย่างปลอดภัย
  • เร็วกว่า XML
  • รหัสถูกสร้างขึ้นสำหรับคุณโดยอัตโนมัติ
  • Google คิดค้นโปรโตบัฟโดยใช้ข้อความโปรโตบัฟ 48000 ข้อความและไฟล์ 12000.proto
  • เฟรมเวิร์ก RPC จำนวนมากรวมถึงบัฟเฟอร์โปรโตคอลการใช้ grpc เพื่อแลกเปลี่ยนข้อมูล