gRPC คืออะไร

แอปพลิเคชันซอฟต์แวร์ส่วนใหญ่ต้องสามารถเชื่อมต่อกับรหัสอื่นได้ด้วยเหตุผลหลายประการ สิ่งนี้สามารถเป็นอะไรก็ได้ตั้งแต่การผสานรวมไปจนถึงการเพิ่มฟังก์ชันใหม่ เพื่อให้แน่ใจว่าซอฟต์แวร์สามารถเชื่อมโยงกับแอปพลิเคชันอื่นๆ และเพื่อให้แน่ใจว่ามีการรวมเข้ากับโปรแกรมอื่นๆ นักพัฒนาจึงใช้ API ด้วยเหตุนี้ Application Programming Interface จึงจำเป็นสำหรับซอฟต์แวร์ส่วนใหญ่ ด้วยบทบาทของพวกเขาในฐานะสะพานข้ามระบบ API ช่วยให้บุคคลสามารถเข้าถึงบริการเว็บที่หลากหลายได้ ดังนั้น สิ่งสำคัญคือต้องเลือกเทคโนโลยีที่เหมาะสมเพื่อเสนอ API ให้กับโครงการของคุณ

องค์กรที่ต้องการแชร์แอปพลิเคชันหรือแพลตฟอร์มกับผู้ใช้จำเป็นต้องใช้ API มีหลายวิธีในการพัฒนาและปรับแต่ง API เพื่อให้เหมาะสมที่สุดสำหรับแอปพลิเคชันของคุณ หนึ่งในวิธีล่าสุดที่โปรแกรมเมอร์ใช้ในการออกแบบ API คือ gRPC มาดูกันว่า gRPC คืออะไร และข้อดีข้อเสียของมัน

gRPC คืออะไร ?

gRPC ย่อมาจาก Google Remote Procedure CallgRPC เป็นเฟรมเวิร์ก RPC แบบโอเพ่นซอร์สที่ใช้สร้าง API ที่รวดเร็วและปรับขนาดได้ ช่วยให้พัฒนาระบบเครือข่ายและการสื่อสารแบบเปิดระหว่างไคลเอนต์ gRPC และแอปพลิเคชันเซิร์ฟเวอร์ gRPC ได้รับการยอมรับจากบริษัทเทคโนโลยีชั้นนำหลายแห่ง รวมถึง Google, IBM, Netflix และอื่นๆ เฟรมเวิ gRPC ขึ้นอยู่กับกองเทคโนโลยีที่ทันสมัย เช่น HTTP/2, บัฟเฟอร์โปรโตคอล และอื่นๆ สำหรับการป้องกัน API ที่เหมาะสม, การเรียกขั้นตอนระยะไกลที่มีประสิทธิภาพสูง และความสามารถในการปรับขนาด

RPC คืออะไร?

RPC และ REST - Representational State Transfer - ในอดีตมีแนวทางที่แยกจากกันสองวิธีในการสร้าง API นอกจากนี้ยังใช้โปรโตคอลอย่าง SOAP และ GraphQL เพื่อจุดประสงค์นี้ด้วย การเรียกใช้ขั้นตอนระยะไกลช่วยให้คุณเขียนซอฟต์แวร์ได้เหมือนกับว่าซอฟต์แวร์จะทำงานในเครื่อง แม้ว่าซอฟต์แวร์นั้นอาจทำงานบนอุปกรณ์อื่นก็ตาม

เป็นเฟรมเวิร์กที่ใช้กันทั่วไปในการออกแบบ API ตรงกันข้ามกับการเรียกโปรโตคอล HTTP ทั่วไป RPC ใช้การเรียกฟังก์ชันเป็นวิธีการหลักในการโต้ตอบระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ RPC เป็นเทคนิคที่มีประสิทธิผลในการสร้าง API เนื่องจากการแลกเปลี่ยนทำได้ง่ายและเนื้อหาไม่ซับซ้อน บริการ gRPC ยังเลียนแบบสถาปัตยกรรมการสื่อสารนี้ RPC ใช้ IDL - Interface Definition Language เพื่อทำสัญญาประเภทข้อมูลและวิธีการที่จะเรียกใช้ บริการ gRPC นำมาใช้จาก RPC ได้รับความนิยมอย่างมากในช่วงไม่กี่ปีที่ผ่านมา

เหตุใดจึงมีการพัฒนาบริการ gRPC

เมื่อองค์กรต่างๆ เปิดช่องทางสำหรับการผสานรวมมากขึ้น การเชื่อมโยงซอฟต์แวร์ดังกล่าวจึงทำได้ยากขึ้น RPC API นั้นท้าทายในการผสานรวมและมีความเสี่ยงที่จะเผยแพร่ เนื่องจากอาจเปิดเผยข้อมูลเฉพาะภายใน พวกเขาได้รับการพัฒนาในภาษาการเขียนโปรแกรมจำนวนมากและเชื่อมโยงอย่างใกล้ชิดกับเฟรมเวิร์กพื้นฐาน

ปัญหานี้ได้รับการแก้ไขแล้ว และความสามารถในการเข้าถึง API เพิ่มขึ้นเมื่อ REST API เปิดตัวในปี 2000 โดยเฉพาะอย่างยิ่ง ช่วยให้ผู้ใช้สามารถดึงข้อมูลทางอ้อมผ่านสินทรัพย์โดยใช้เทคนิค HTTP มาตรฐาน เช่น GET, PUT, POST และอื่นๆ ความแตกต่างหลักๆ ของ RPC จาก REST API คือ เมื่อใช้ RPC กระบวนการต่างๆ จะถูกจัดการ แต่มันไม่ง่ายเลยที่จะคาดการณ์ว่ากระบวนการในระบบต่างๆ จะเป็นเช่นไร

REST API ไม่สามารถแทนที่ RPC ที่ตรงไปตรงมาและมีน้ำหนักเบาได้อย่างสมบูรณ์ เนื่องจากสร้างข้อมูลเมตาจำนวนมาก แม้ว่าจะมีรูปแบบที่ได้รับการปรับปรุงสำหรับการจัดการกับแอปพลิเคชันจำนวนมาก ส่งผลให้บริการ GraphQL ของ Facebook และบริการ gRPC ของ Google เกิดขึ้นในที่สุด

Google สร้าง gRPC ในปี 2558 โดยเป็นส่วนเสริมของเฟรมเวิร์ก RPC เพื่อเชื่อมต่อสถาปัตยกรรมไมโครเซอร์วิสจำนวนมากที่สร้างด้วยเทคนิคต่างๆ gRPC เดิมมีความเกี่ยวข้องอย่างใกล้ชิดกับโครงสร้างพื้นฐานหลักของ Google แต่ในที่สุดก็กลายเป็นโอเพ่นซอร์สและเป็นมาตรฐานสำหรับการใช้งานโดยสาธารณชนทั่วไป

ภาพรวมของแนวคิด gRPC

การใช้เทคโนโลยีล้ำสมัยซึ่งมีประสิทธิภาพสูงกว่า JSON และ XML และมอบความสมบูรณ์ของ API ที่สูงกว่า มีส่วนรับผิดชอบต่อการสร้างและความนิยมของ gRPC แนวคิด gRPC บางส่วนที่คุณควรทราบคือ:

บัฟเฟอร์โปรโตคอล

โปรโตคอลบัฟเฟอร์หรือที่เรียกว่า Protobuf เป็นมาตรฐานการทำให้เป็นซีเรียลไลเซชันหรือดีซีเรียลไลเซชันที่ทำให้ง่ายต่อการกำหนดแอปพลิเคชันและดำเนินการสร้างรหัสของไคลเอนต์ไลบรารีโดยอัตโนมัติ เวอร์ชันล่าสุด proto3 ใช้งานง่ายกว่าและมีความสามารถใหม่ล่าสุดสำหรับ gRPC

ไฟล์ .Proto เปิดใช้ gRPC.Proto การสื่อสารระหว่างไคลเอนต์ gRPC และข้อความเซิร์ฟเวอร์ ไฟล์ .proto ถูกโหลดลงในหน่วยความจำขณะดำเนินการโดยคอมไพเลอร์ Protobuf - protoc คอมไพเลอร์นี้สร้างไคลเอนต์ gRPC และแอปพลิเคชันเซิร์ฟเวอร์ gRPC ที่ใช้โครงสร้างในหน่วยความจำเพื่อซีเรียลไลซ์และดีซีเรียลไลซ์ข้อมูลไบนารี การสื่อสารแต่ละครั้งจะถูกส่งและรับระหว่างผู้ใช้และบริการระยะไกลตามการสร้างรหัสใน gRPC

เนื่องจากข้อมูลถูกแปลเป็นรูปแบบไบนารีและสัญญาณที่เข้ารหัสมีขนาดเล็กลง การแยกวิเคราะห์ด้วย Protobuf จึงใช้พลังงาน CPU น้อยลงสำหรับ gRPC ดังนั้น แม้ในคอมพิวเตอร์ที่มี CPU อ่อนกว่า เช่น โทรศัพท์มือถือ ข้อความก็ส่งได้เร็วกว่าด้วย gRPC

HTTP/2

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

HTTP/2 มีวิธีการควบคุมโฟลว์ที่ช่วยให้สามารถควบคุม RAM ที่จำเป็นในการบัฟเฟอร์แพ็กเก็ตบนเที่ยวบินได้อย่างแม่นยำ นอกจากนี้ยังมีการบีบอัดส่วนหัวสำหรับบริการ gRPC ทุกอย่างใน HTTP/2 ได้รับการเข้ารหัสก่อนการส่ง แม้กระทั่งส่วนหัว ซึ่งมีการเรียกใช้โพรซีเดอร์ระยะไกลที่มีประสิทธิภาพสูง gRPC ให้ทั้งการประมวลผลแบบอะซิงโครนัสและแบบซิงโครนัสด้วย HTTP/2 ทำให้สามารถเรียกใช้ RPC แบบโต้ตอบและแบบสตรีมได้หลากหลายประเภท

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

สตรีมมิ่ง

แนวคิดสำคัญที่ gRPC รองรับคือการสตรีม ซึ่งอนุญาตให้ดำเนินการหลายกระบวนการภายในคำขอเดียว gRPC ทำให้สิ่งนี้เป็นไปได้ผ่านคุณสมบัติมัลติเพล็กซ์ของ HTTP/2 ซึ่งช่วยให้สามารถส่งหรือรับการตอบสนองหรือคำขอหลายรายการพร้อมกันผ่านการเชื่อมต่อ TCP - Transmission Control Protocol - หนึ่งรายการ รูปแบบการสตรีมหลักคือ RPC สตรีมเซิร์ฟเวอร์, RPC สตรีมไคลเอนต์ และ RPC สตรีมสองทิศทาง

ช่อง

ตรงกันข้ามกับสตรีม HTTP/2 ซึ่งอนุญาตให้สตรีมพร้อมกันจำนวนมากในการเชื่อมต่อคำขอเดียว ช่องที่มี gRPC รองรับสตรีมต่อเนื่องหลายรายการในคำขอหลายรายการ พวกเขาใช้เพื่อสร้างโครงไคลเอนต์และให้กลไกเพื่อเชื่อมโยงกับเซิร์ฟเวอร์ gRPC บน IP และพอร์ตเฉพาะ

สถาปัตยกรรม gRPC

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

ระบบปฏิบัติการใช้โปรโตคอล HTTP/2 เพื่อสื่อสารกับคอมพิวเตอร์เซิร์ฟเวอร์ที่อยู่ห่างไกล ระบบปฏิบัติการของเซิร์ฟเวอร์ยอมรับข้อความและเรียกใช้กระบวนการ stub ของเซิร์ฟเวอร์ ซึ่งใช้ Protobuf เพื่อเรียกใช้การดำเนินการที่เหมาะสมหลังจากถอดรหัสพารามิเตอร์ขาเข้า จากนั้นไคลเอนต์ทรานสปอร์ตเลเยอร์จะได้รับการตอบสนองที่เข้ารหัสจากเซิร์ฟเวอร์ต้นขั้ว การดำเนินการจะส่งกลับไปยังผู้เรียกหลังจากที่ไคลเอนต์ gRPC ได้รับข้อความตอบกลับและคลายอาร์กิวเมนต์ที่มีให้

ข้อดีของ gRPC

gRPC มีข้อดีหลายประการเหนือกลไกการออกแบบ API อื่นๆ gRPC ยังปรับปรุงตามโครงสร้าง RPC นี่คือประโยชน์ที่โดดเด่นที่สุดของบริการ gRPC:

• การเรียกขั้นตอนระยะไกลที่มีประสิทธิภาพสูง

การใช้ Protobuf และ HTTP/2 ทำให้บริการ gRPC มีประสิทธิภาพสูงขึ้นถึง 10 เท่าและการป้องกัน API ของการโต้ตอบ REST+JSON ด้วยการใช้เซิร์ฟเวอร์พุช การมัลติเพล็กซ์ และการบีบอัดส่วนหัว HTTP/2 จึงจัดลำดับประสิทธิภาพสูงสำหรับบริการ gRPC ในขณะที่การมัลติเพล็กซ์ช่วยขจัดความล่าช้าของ head-of-line แต่การพุชเซิร์ฟเวอร์ทำให้ HTTP/2 สามารถพุชเนื้อหาจากเซิร์ฟเวอร์ไปยังไคลเอ็นต์ก่อนที่จะจำเป็น ข้อความได้รับการบีบอัดอย่างมีประสิทธิภาพมากขึ้นโดยใช้ HTTP/2 ส่งผลให้โหลดเร็วขึ้นด้วยบริการ gRPC

• สตรีมมิ่ง

คำอธิบายบริการสำหรับการสตรีมบริการ gRPC มีหลักการสตรีมแบบไคลเอ็นต์หรือเซิร์ฟเวอร์สิ้นสุดอยู่แล้ว การสร้างไคลเอนต์ gRPC และบริการสตรีมมิ่งทำได้ง่ายขึ้นอย่างมาก

• การสร้างรหัส

การสร้างโค้ดสำหรับไคลเอนต์ gRPC และโปรแกรมเซิร์ฟเวอร์ gRPC เป็นองค์ประกอบหลักของแนวทางเว็บ gRPC สำหรับการสร้างโค้ดจากไฟล์ . gRPC.proto ใช้คอมไพเลอร์ . .protoc รูปแบบ Protobuf ถูกควบคุมผ่านการสร้างรหัสใน gRPC ซึ่งใช้เพื่อกำหนดทั้งรูปแบบข้อมูลและจุดสิ้นสุดของแอปพลิเคชัน สามารถสร้าง stubs เครือข่ายฝั่งไคลเอนต์และโครงกระดูกฝั่งเซิร์ฟเวอร์ ซึ่งช่วยลดระยะเวลาที่จำเป็นในการออกแบบโปรแกรมด้วยบริการที่หลากหลายในบริการ gRPC

• การทำงานร่วมกัน

ระบบและภาษาการเขียนโปรแกรมจำนวนมาก เช่น Java, Ruby, Go, C# และอื่นๆ ได้รับการสนับสนุนโดยทรัพยากรและไลบรารี gRPC ด้วยภาษาการเขียนโปรแกรมเหล่านี้ นักพัฒนาสามารถสร้างแอปที่มีประสิทธิภาพในขณะที่ใช้ความเข้ากันได้ข้ามแพลตฟอร์มกับ gRPC ต้องขอบคุณรูปแบบการเดินสายไบนารีของ Protobuf และการสร้างโค้ดที่มีประสิทธิภาพสำหรับระบบเกือบทั้งหมด

• ความปลอดภัย

มั่นใจในความปลอดภัยของ API ใน gRPC โดยใช้ HTTP/2 ผ่านเซสชันที่เข้ารหัส TLS จากต้นทางถึงปลายทาง gRPC ส่งเสริมการใช้ SSL/TLS สำหรับการเข้ารหัสข้อมูลและการรับรองความถูกต้องระหว่างเซิร์ฟเวอร์และไคลเอนต์ gRPC

• ผลผลิตและการใช้งาน

เนื่องจาก gRPC เป็นทางเลือก RPC ที่สมบูรณ์ จึงทำงานโดยไม่ติดขัดกับระบบและภาษาที่หลากหลาย นอกจากนี้ gRPC ยังมีเครื่องมือที่ยอดเยี่ยม โดยมีการสร้างรหัสสำเร็จรูปที่จำเป็นจำนวนมากด้วยตนเอง ขณะนี้วิศวกรสามารถมีสมาธิกับการทำงานหลักได้มากขึ้น เนื่องจาก gRPC ประหยัดเวลาได้มาก

ข้อเสียของ gRPC

แม้ว่าเราจะหวังว่าข้อบกพร่อง gRPC จะได้รับการแก้ไขในที่สุด แต่ก็ก่อให้เกิดปัญหากับการใช้งานในขณะนี้ ข้อเสียบางประการของ gRPC คุณควรทราบคือ:

• ขาดวุฒิภาวะ

การพัฒนาเทคโนโลยีอาจเป็นอุปสรรคสำคัญในการนำไปใช้ ที่ชัดเจนในขณะที่ใช้ gRPCGraphQL ซึ่งเป็นหนึ่งในเพื่อนร่วมงานของ gRPC มีข้อความค้นหามากกว่า 14k บน StackOverflow ในขณะที่ gRPC มีเพียงต่ำกว่า 4k เล็กน้อยในขณะนี้ ชุมชน gRPC ขาดความรู้เกี่ยวกับแนวทางปฏิบัติที่ดีที่สุด วิธีแก้ไข และความสำเร็จเนื่องจากไม่มีความช่วยเหลือจากโปรแกรมเมอร์มากนักสำหรับ HTTP/2 ตลอดจนบัฟเฟอร์โปรโตคอลภายนอก Google อย่างไรก็ตาม ในขณะที่ชุมชน gRPC ขยายตัวและดึงดูดนักพัฒนาใหม่ๆ ชุมชนนี้ก็จะพัฒนาไปในที่สุด

• การสนับสนุนเบราว์เซอร์จำกัด

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

• มนุษย์ไม่สามารถอ่านได้

ไฟล์ Protobuf ไม่เหมือนกับ XML และ JSON เนื่องจากข้อมูลถูกบีบอัดเป็นรูปแบบไบนารี นักพัฒนาซอฟต์แวร์ต้องใช้เครื่องมือเพิ่มเติม เช่น โปรโตคอลการสะท้อนของเซิร์ฟเวอร์และพรอมต์คำสั่ง gRPC เพื่อประเมินเพย์โหลด ดำเนินการแก้ไขปัญหา และสร้างแบบสอบถามด้วยตนเอง

• เส้นโค้งการเรียนรู้ที่สูงชัน

จะใช้เวลาสักครู่เพื่อทำความคุ้นเคยกับโปรโตคอลบัฟเฟอร์และค้นพบวิธีการรับมือกับแรงเสียดทาน HTTP/2 ซึ่งตรงกันข้ามกับ REST และ GraphQL ซึ่งทั้งสองวิธีนี้ใช้ JSON เป็นส่วนใหญ่

AppMaster ช่วยได้อย่างไร?

No-code กำลังเปลี่ยนวิธีที่ผู้คนดูการเขียนโปรแกรม No-code ทำให้ผู้คนสามารถเรียนรู้และสร้างซอฟต์แวร์ได้เร็วขึ้นด้วย การสร้างรหัส การสร้างโค้ดสำหรับแอปพลิเคชันของคุณนั้นง่ายกว่าโดยใช้แพลตฟอร์ม no-code เช่น AppMaster ไม่มีปัญหาความเป็นเจ้าของ เนื่องจากการสร้างรหัสได้รับการคุ้มครอง และรหัสที่คุณสร้างจะเป็นของคุณแต่เพียงผู้เดียว คุณสามารถสร้างแอปพลิเคชันไคลเอนต์และเซิร์ฟเวอร์ได้เร็วและง่ายขึ้นด้วย AppMaster

แพลตฟอร์มการสร้างแบบ no-code ของ AppMaster ช่วยให้นักพัฒนาใช้โปรโตคอล gRPC เพื่อสร้างคำขอระหว่างสถาปัตยกรรมไมโครเซอร์วิสส่วนหลัง ในปีหน้า เราจะขยายการรองรับ gRPC โดยรวม API เข้ากับทั้ง gRPC Web และ gRPC Mobile applications

บทสรุป

แม้ว่าบริการ gRPC จะมีประโยชน์หลายอย่างที่ทำให้ดึงดูดใจสำหรับธุรกิจและนักพัฒนา แต่ท้ายที่สุดแล้ว การตัดสินใจใช้บริการ gRPC เหนือบริการอื่นๆ เช่น REST หรือ SOAP ขึ้นอยู่กับแอปพลิเคชันของคุณ แม้ว่าซอฟต์แวร์บางตัวจะมีประโยชน์ด้านประสิทธิภาพสูงกับ gRPC แต่ซอฟต์แวร์อื่นๆ อาจเหมาะสมกับทางเลือกอื่นมากกว่า คุณควรเข้าใจข้อเสียและข้อดีของบริการ gRPC และตัดสินใจว่าจะเหมาะกับคุณหรือไม่