gRPC กับ REST แตกต่างกันอย่างไร
gRPC และ REST เป็นสองวิธีที่คุณสามารถใช้ในการออกแบบ API ได้ API เป็นกลไกที่ช่วยให้ส่วนประกอบซอฟต์แวร์ 2 ส่วนสื่อสารกันโดยใช้ชุดของคำจำกัดความและโปรโตคอล ใน gRPC องค์ประกอบหนึ่ง (ไคลเอ็นต์) จะเรียกใช้หรือเรียกดำเนินการฟังก์ชันเฉพาะในส่วนประกอบซอฟต์แวร์อื่น (เซิร์ฟเวอร์) ใน REST ไคลเอ็นต์จะส่งคำขอหรืออัปเดตข้อมูลบนเซิร์ฟเวอร์แทนที่จะเรียกใช้ฟังก์ชัน
gRPC คืออะไร
RPC คืออะไร
ใน RPC การสื่อสารระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์จะทำงานราวกับว่าคำขอของ API ฝั่งไคลเอ็นต์เป็นการดำเนินการภายใน หรือคำขอเป็นโค้ดเซิร์ฟเวอร์ภายใน
ใน RPC ไคลเอ็นต์จะส่งคำขอไปยังกระบวนการบนเซิร์ฟเวอร์ที่รับการเรียกใช้จากระยะไกลอยู่ตลอด ในคำขอจะมีฟังก์ชันเซิร์ฟเวอร์ที่จะเรียกใช้ พร้อมกับพารามิเตอร์ที่จะส่ง RPC API ใช้โปรโตคอล เช่น HTTP, TCP หรือ UDP เป็นกลไกการแลกเปลี่ยนข้อมูลพื้นฐาน
gRPC แตกต่างจาก RPC อย่างไร
gRPC เป็นระบบที่ใช้ RPC แบบดั้งเดิมที่มีการเพิ่มประสิทธิภาพหลายรายการ ตัวอย่างเช่น gRPC ใช้ Protocol Buffer และ HTTP 2 ในการส่งข้อมูล
นอกจากนี้ยังทำให้นักพัฒนาไม่ต้องจัดการกลไกการแลกเปลี่ยนข้อมูล ตัวอย่างเช่น การใช้งาน RPC API อย่างแพร่หลายอีกรูปแบบหนึ่งอย่าง OpenAPI กำหนดให้นักพัฒนาเชื่อมโยงแนวคิด RPC กับโปรโตคอล HTTP แต่ gRPC ตัดการสื่อสาร HTTP พื้นฐานนั้น การเพิ่มประสิทธิภาพเหล่านี้ทำให้ gRPC รวดเร็วขึ้น ง่ายต่อการใช้งาน และใช้งานร่วมกับเว็บได้ดีกว่าการใช้ RPC อื่นๆ
REST คืออะไร
REST เป็นวิธีการทางสถาปัตยกรรมซอฟต์แวร์ที่กำหนดชุดกฎในการแลกเปลี่ยนข้อมูลระหว่างส่วนประกอบซอฟต์แวร์ REST ใช้ HTTP ซึ่งเป็นโปรโตคอลการสื่อสารมาตรฐานของเว็บ RESTful API จัดการการสื่อสารระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ผ่านคำกริยา HTTP เช่น POST, GET, PUT และ DELETE เพื่อสร้าง อ่าน อัปเดต และลบการดำเนินการ ทรัพยากรฝั่งเซิร์ฟเวอร์จะถูกระบุโดย URL ที่เรียกว่าตำแหน่งข้อมูล
REST ทำงานดังนี้
- ไคลเอ็นต์จัดทำคำขอเพื่อสร้าง แก้ไข หรือลบทรัพยากรบนเซิร์ฟเวอร์
- คำขอประกอบด้วยตำแหน่งข้อมูลทรัพยากรและอาจรวมถึงพารามิเตอร์เพิ่มเติม
- เซิร์ฟเวอร์ตอบสนองโดยส่งกลับทรัพยากรทั้งหมดให้กับไคลเอ็นต์เมื่อการดำเนินการเสร็จสมบูรณ์
- การตอบสนองประกอบด้วยข้อมูลในรูปแบบ JSON และโค้ดสถานะ
API ที่สร้างขึ้นโดยใช้แนวทาง REST จะเรียกว่า RESTful API หรือ REST API
ทำไมองค์กรจึงใช้ gRPC และ REST
gRPC และ REST เป็น 2 วิธีที่แตกต่างกันในการพัฒนา API
API ทำงานคล้ายกับการสั่งอาหารจากร้านอาหารด้วยเมนู ที่ร้านอาหาร ลูกค้า (ไคลเอ็นต์) สามารถสั่งอาหารจากเมนู (API) ซึ่งมีจำนวนเมนูอาหารคงที่ โดยจะสื่อสารไปยังห้องครัว (เซิร์ฟเวอร์) ที่เตรียมอาหารตามที่ร้องขอและส่งไปยังลูกค้า ลูกค้าไม่จำเป็นต้องรู้ว่าห้องครัวทำอาหารตามที่สั่งอย่างไร รู้แต่เพียงว่าจะได้รับอาหารเมนูใดกลับมา การกำหนดมาตรฐานของรูปแบบเมนูหมายความว่าลูกค้าและห้องครัวรู้วิธีใช้เมนูนั้น
หากไม่มี API จะไม่มีข้อตกลงร่วมกันเกี่ยวกับวิธีการที่แตกต่างกันในการสื่อสารของแอปพลิเคชันหรือบริการซอฟต์แวร์ โปรแกรมเมอร์ของ 2 แอปพลิเคชันที่แยกกันจะต้องพูดคุยกับอีกฝ่ายเพื่อกำหนดวิธีสร้างการแลกเปลี่ยนข้อมูลทุกครั้ง
สถาปัตยกรรม API แบ่งเป็นประเภทต่างๆ เช่น gRPC และ REST โดยแต่ละประเภทอาจใช้งานได้ดีกว่าสำหรับกรณีการใช้งานที่แตกต่างกันไปภายในองค์กร นักออกแบบ API จะต้องเลือกสถาปัตยกรรมระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ที่ต้องการตามข้อกำหนดของระบบ
gRPC และ REST มีความคล้ายคลึงกันอย่างไร
REST และ gRPC มีความคล้ายคลึงกันโดยธรรมชาติบางอย่างในแง่แนวทางสถาปัตยกรรมของ API
กลไกการแลกเปลี่ยนข้อมูล
REST และ gRPC อนุญาตให้ 2 องค์ประกอบซอฟต์แวร์อย่างไคลเอ็นต์และเซิร์ฟเวอร์สื่อสารและแลกเปลี่ยนข้อมูลตามชุดกฎที่ใช้ร่วมกัน กฎเหล่านี้มีการบังคับใช้โดยไม่คำนึงถึงวิธีการทำงานภายในของส่วนประกอบซอฟต์แวร์แต่ละตัว
การสื่อสารโดยใช้ HTTP
REST และ gRPC ส่งข้อมูลผ่านกลไกคำขอและการตอบสนอง HTTP ซึ่งเป็นโปรโตคอลการสื่อสารของเว็บที่มีประสิทธิภาพและเหมาะสมกว่า อย่างไรก็ตาม ใน gRPC กลไกนี้จะซ่อนตัวจากนักพัฒนา ในขณะที่ใน REST จะเห็นได้ชัดกว่า
ความยืดหยุ่นในการนำไปใช้
คุณสามารถนำทั้ง REST และ gRPC ไปใช้จริงในภาษาเขียนโปรแกรมภาษาที่หลากหลาย คุณภาพระดับนี้ทำให้ทั้ง REST และ gRPC มีความคล่องตัวสูงในสภาพแวดล้อมการเขียนโปรแกรม จึงทำงานร่วมกับการรองรับในระดับเกือบสากลได้อย่างเหมาะสมที่สุด
ความเหมาะสมสำหรับระบบแบบกระจายที่ปรับขนาดได้
ทั้ง gRPC และ REST ใช้ฟังก์ชันต่อไปนี้
- การสื่อสารแบบอะซิงโครนัสเพื่อให้ไคลเอ็นต์และเซิร์ฟเวอร์สามารถสื่อสารได้โดยไม่ขัดจังหวะการดำเนินการ
- การออกแบบที่ไม่บันทึกสถานะเพื่อให้เซิร์ฟเวอร์ไม่ต้องจดจำสถานะของไคลเอ็นต์
ซึ่งหมายความว่า นักพัฒนาสามารถใช้ gRPC และ REST เพื่อสร้างระบบที่ป้องกันความผิดพลาดที่มีคำขอพร้อมกันจำนวนมาก คุณสามารถสร้างระบบแบบกระจายที่ปรับขนาดได้กับหลายไคลเอ็นต์
หลักการสถาปัตยกรรมระหว่าง gRPC กับ REST
ในขณะที่ REST และ gRPC มีฟังก์ชันที่คล้ายกัน แต่โมเดลพื้นฐานมีความแตกต่างกันอย่างมีนัยสำคัญในสถาปัตยกรรม
โมเดลการสื่อสาร
เมื่อใช้ REST API ไคลเอ็นต์จะส่งคำขอ REST API เดียวไปยังเซิร์ฟเวอร์ และเซิร์ฟเวอร์จะส่งการตอบสนองเดียวในการตอบกลับ ไคลเอ็นต์ต้องรอให้เซิร์ฟเวอร์ตอบสนองก่อนที่จะดำเนินการต่อ กลไกนี้เป็นรูปแบบคำขอและการตอบสนอง และเป็นการเชื่อมต่อข้อมูลแบบเดี่ยว (หนึ่งต่อหนึ่ง)
ในทางตรงกันข้าม เมื่อใช้ gRPC ไคลเอ็นต์สามารถส่งคำขอ API หนึ่งหรือหลายรายการไปยังเซิร์ฟเวอร์ที่อาจส่งผลให้มีการตอบกลับหนึ่งหรือหลายรายการจากเซิร์ฟเวอร์ การเชื่อมต่อข้อมูลอาจเป็นแบบเดี่ยว (หนึ่งต่อหนึ่ง) การสตรีมเซิร์ฟเวอร์ (หนึ่งต่อกลุ่ม) การสตรีมไคลเอ็นต์ (กลุ่มต่อหนึ่ง) หรือการสตรีมแบบสองทิศทาง (กลุ่มต่อกลุ่ม) กลไกนี้เป็นโมเดลการสื่อสารการตอบสนองของไคลเอ็นต์ และทำได้เพราะ gRPC ใช้ HTTP 2
การดำเนินการที่เรียกใช้ได้บนเซิร์ฟเวอร์
ใน gRPC API การดำเนินการบนเซิร์ฟเวอร์ที่เรียกใช้ได้จะถูกกำหนดโดยบริการ หรือที่เรียกว่าฟังก์ชันหรือขั้นตอน ไคลเอ็นต์ gRPC เรียกดำเนินการฟังก์ชันเหล่านี้แบบเดียวกับที่คุณเรียกใช้ฟังก์ชันภายในแอปพลิเคชัน กระบวนการนี้มีชื่อเรียกว่าการออกแบบที่มุ่งเน้นบริการ ตัวอย่างเช่น
createNewOrder(customer_id, item_id, item_quantity) -> order_id
ใน REST จะมีชุดคำกริยาคำขอ HTTP แบบจำกัดที่ไคลเอ็นต์สามารถใช้บนทรัพยากรเซิร์ฟเวอร์ที่กำหนดโดย URL ไคลเอ็นต์เรียกใช้ทรัพยากรของตัวเอง กระบวนการนี้มีชื่อเรียกว่าการออกแบบที่มุ่งเน้นเอนทิตี การออกแบบที่มุ่งเน้นเอนทิตีสอดคล้องกันดีกับวิธีการเขียนโปรแกรมที่มุ่งเน้นอ็อบเจกต์ ตัวอย่างเช่น
POST /orders <headers> (customer_id, item_id, item_quantity) -> order_id
ในขณะที่คุณสามารถออกแบบ gRPC API ด้วยวิธีการที่มุ่งเน้นเอนทิตีนี้ได้ แต่ก็ไม่ได้เป็นข้อจำกัดของตัวระบบแต่อย่างใด
รูปแบบการแลกเปลี่ยนข้อมูล
เมื่อใช้ REST API โครงสร้างข้อมูลที่ส่งระหว่างส่วนประกอบซอฟต์แวร์มักจะแสดงในรูปแบบการแลกเปลี่ยนข้อมูล JSON โดยสามารถส่งรูปแบบข้อมูลอื่นๆ ได้ เช่น XML และ HTML JSON ง่ายต่อการอ่านและมีความยืดหยุ่น แม้ว่าจะต้องมีการแปลงเป็นอนุกรมและแปลเป็นภาษาเขียนโปรแกรม
ในทางตรงกันข้าม gRPC ใช้รูปแบบ Protocol Buffer (Protobuf) โดยค่าเริ่มต้น แม้ว่าจะยังคงรองรับ JSON แบบดั้งเดิม เซิร์ฟเวอร์กำหนดโครงสร้างข้อมูลโดยใช้ Interface Description Language (IDL) ของ Protocol Buffer ในไฟล์ข้อกำหนด Proto จากนั้น gRPC จะแปลงโครงสร้างเป็นอนุกรมในรูปแบบไบนารี แล้วแปลงอนุกรมเป็นภาษาเขียนโปรแกรมที่ระบุ กลไกนี้จะทำให้ดำเนินการรวดเร็วกว่าการใช้ JSON ซึ่งไม่ได้ถูกบีบอัดในระหว่างการส่ง Protocol Buffer ไม่ใช่ภาษาที่มนุษย์สามารถอ่านได้ ซึ่งแตกต่างจาก REST API ที่ใช้ร่วมกับ JSON
ความแตกต่างที่สำคัญอื่นๆ ระหว่าง gRPC กับ REST
ความแตกต่างที่สำคัญอื่นๆ ระหว่าง gRPC กับ REST
นอกเหนือจากรูปแบบสถาปัตยกรรมแล้ว gRPC และ REST มีความแตกต่างโดยธรรมชาติอื่นๆ อีก
การเชื่อมโยงระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์
REST เป็นการเชื่อมโยงแบบ Loose Coupling ซึ่งหมายความว่าไคลเอ็นต์และเซิร์ฟเวอร์ไม่จำเป็นต้องทราบเกี่ยวกับการนำไปใช้ของอีกฝั่ง การเชื่อมโยงแบบ Loose Coupling นี้ทำให้ API ง่ายต่อการพัฒนาเมื่อเวลาผ่านไป เนื่องจากการเปลี่ยนแปลงคำจำกัดความของเซิร์ฟเวอร์ไม่จำเป็นต้องมีการเปลี่ยนแปลงโค้ดในไคลเอ็นต์
gRPC เป็นการเชื่อมโยงแบบ Tight Coupling ซึ่งหมายความว่าไคลเอ็นต์และเซิร์ฟเวอร์จะต้องมีสิทธิ์เข้าถึงไฟล์ Proto เดียวกัน การอัปเดตใดๆ ไปยังไฟล์จำเป็นต้องมีการอัปเดตทั้งในเซิร์ฟเวอร์และไคลเอ็นต์
การสร้างโค้ด
gRPC มีตัวเลือกคุณสมบัติการสร้างโค้ดดั้งเดิมของฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ในตัว โดยมีให้บริการในหลายภาษา เนื่องจาก Protoc คอมไพเลอร์ Protocol Buffer หลังจากกำหนดโครงสร้างในไฟล์ Proto แล้ว gRPC จะสร้างโค้ดฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ การสร้างโค้ดทำให้การพัฒนา API ใช้เวลาน้อยลง
ในทางกลับกัน REST ไม่ได้มีกลไกการสร้างโค้ดในตัว ดังนั้นนักพัฒนาจะต้องใช้เครื่องมือของบุคคลที่สามเพิ่มเติมหากต้องใช้คุณสมบัตินี้
การสตรีมแบบสองทิศทาง
gRPC มีการสื่อสารด้วยการสตรีมแบบสองทิศทาง ซึ่งหมายความว่าทั้งไคลเอ็นต์และเซิร์ฟเวอร์สามารถรับส่งคำขอและการตอบสนองหลายรายการพร้อมกันในการเชื่อมต่อเดียว
REST ไม่ได้มีคุณสมบัตินี้
เมื่อใดที่ควรใช้ gRPC หรือ REST
REST เป็นสถาปัตยกรรม API ที่ได้ิรับความนิยมมากที่สุดในปัจจุบันสำหรับบริการเว็บและสถาปัตยกรรมไมโครเซอร์วิส REST ได้รับความนิยมการนำไปใช้จริงที่ง่ายดาย รวมถึงการแมปโคงสร้างข้อมูล ความสามารถในการอ่าน และความยืดหยุ่น โปรแกรมเมอร์ใหม่จะเริ่มต้นพัฒนา RESTful API สำหรับแอปพลิเคชันของตนเองได้อย่างง่ายดาย ไม่ว่าจะเป็นการพัฒนาบริการเว็บหรือไมโครเซอร์วิสภายใน
กรณีการใช้งานสำหรับ REST API มีดังต่อไปนี้
- สถาปัตยกรรมบนเว็บ
- API สาธารณะเพื่อความสะดวกในการทำความเข้าใจโดยผู้ใช้ภายนอก
- การสื่อสารข้อมูลที่เรียบง่าย
gRPC แตกต่างจาก REST โดยได้รับการออกแบบมาโดยเฉพาะเพื่อให้นักพัฒนาสามารถสร้าง API ประสิทธิภาพสูงสำหรับสถาปัตยกรรมไมโครเซอร์วิสทั่วทั้งศูนย์ข้อมูลแบบกระจายได้ gRPC เหมาะสำหรับระบบภายในที่ต้องใช้การสตรีมแบบเรียลไทม์และการโหลดข้อมูลขนาดใหญ่มากกว่า นอกจากนั้น gRPC ยังเหมาะสำหรับสถาปัตยกรรมไมโครเซอร์วิสที่ประกอบด้วยภาษาโปรแกรมหลายภาษาเมื่อ API ไม่มีแนวโน้มที่จะเปลี่ยนแปลงเมื่อเวลาผ่านไป
gRPC API จะเหมาะสำหรับกรณีการใช้งานต่อไปนี้
- ระบบประสิทธิภาพสูง
- โหลดข้อมูลสูง
- แอปพลิเคชันแบบเรียลไทม์หรือการสตรีม
หมายเหตุเกี่ยวกับการพัฒนาซอฟต์แวร์เว็บ
ในขณะที่ HTTP เป็นเว็บโปรโตคอลหลัก แต่ HTTP เวอร์ชันต่างๆ ก็มีระดับการปรับใช้ทั่วทั้งเว็บเบราว์เซอร์และเว็บเซิร์ฟเวอร์ที่แตกต่างกัน
gRPC API ใช้ HTTP 2 เสมอ และ REST API มักจะใช้ HTTP 1.1 ซึ่งไม่ได้เป็นโปรโตคอล HTTP เดียวกัน ในขณะที่ HTTP 2 เป็นเว็บโปรโตคอลที่แพร่หลายในปัจจุบัน แต่ก็ไม่มีการรองรับเบราว์เซอร์แบบสากล ซึ่งแตกต่างจาก HTTP 1.1 การรองรับเบราว์เซอร์แบบจำกัดนี้อาจทำให้ gRPC เป็นตัวเลือกที่น่าสนใจน้อยกว่าสำหรับนักพัฒนาที่ต้องการสนับสนุนแอปพลิเคชันบนเว็บ
สรุปความแตกต่างระหว่าง gRPC กับ REST
| gRPC API |
REST API |
|
| คืออะไร |
ระบบการสร้างและใช้ API ใช้โมเดลการสื่อสารเซิร์ฟเวอร์ของไคลเอ็นต์การเรียกใช้กระบวนการระยะไกล (RPC) |
ชุดของกฎที่กำหนดการแลกเปลี่ยนข้อมูลที่มีโครงสร้างระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ |
| แนวทางการออกแบบ |
การออกแบบที่มุ่งเน้นการบริการ ไคลเอ็นต์ขอให้เซิร์ฟเวอร์ดำเนินการบริการหรือฟังก์ชันที่อาจจะส่งผลกระทบหรือไม่ส่งผลกระทบต่อทรัพยากรเซิร์ฟเวอร์ |
การออกแบบที่มุ่งเน้นเอนทิตี ไคลเอ็นต์ขอให้เซิร์ฟเวอร์สร้าง แชร์ หรือปรับแต่งทรัพยากร |
| โมเดลการสื่อสาร |
หลายตัวเลือก เช่น แบบเดี่ยว เซิร์ฟเวอร์หนึ่งไปยังหลายไคลเอ็นต์ ไคลเอ็นต์หนึ่งไปยังหลายเซิร์ฟเวอร์ และหลายไคลเอ็นต์ไปยังหลายเซิร์ฟเวอร์ |
แบบเดี่ยว ไคลเอ็นต์เดียวสื่อสารกับเซิร์ฟเวอร์เดียว |
| การปรับใช้ |
ต้องใช้ซอฟต์แวร์ gRPC ทั้งบนไคลเอ็นต์และฝั่งเซิร์ฟเวอร์เพื่อใช้งาน |
คุณสามารถนำไปใช้จริงบนไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ในหลากหลายรูปแบบโดยจำเป็นต้องมีซอฟต์แวร์ที่ใช้ร่วมกัน |
| การเข้าถึงข้อมูล |
การเรียกใช้บริการ (ฟังก์ชัน) |
ตำแหน่งข้อมูลหลายจุดในรูปแบบของ URL ในการกำหนดทรัพยากร |
| ข้อมูลที่ส่งคืน |
ในประเภทข้อมูลส่งคืนแบบคงที่ของบริการตามที่กำหนดไว้ในไฟล์ Protocol Buffer |
ในโครงสร้างแบบคงที่ (มักจะเป็น JSON) ที่กำหนดโดยเซิร์ฟเวอร์ |
| การเชื่อมโยงระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ |
เชื่อมโยงแบบ Tight Coupling ทั้งไคลเอ็นต์และเซิร์ฟเวอร์ต้องมีไฟล์ Protocol Buffer เดียวกันที่กำหนดรูปแบบข้อมูล |
เชื่อมโยงแบบ Loose Coupling ไคลเอ็นต์และเซิร์ฟเวอร์ไม่ทราบรายละเอียดภายใน |
| การสร้างโค้ดอัตโนมัติ |
คุณสมบัติในตัว |
ต้องใช้เครื่องมือของบุคคลที่สาม |
| การสตรีมแบบสองทิศทาง |
มี |
ไม่มี |
| เหมาะที่สุดสำหรับ |
สถาปัตยกรรมไมโครเซอร์วิสที่มีประสิทธิภาพสูงหรือมีข้อมูลปริมาณมาก |
แหล่งที่มาของข้อมูลที่ไม่ซับซ้อนที่มีการกำหนดทรัพยากรไว้อย่างดี |
AWS รองรับข้อกำหนด gRPC และ REST ของคุณได้อย่างไร
Amazon Web Services (AWS) มีบริการและเครื่องมือมากมายที่จะช่วยนักออกแบบ API ในการสร้าง เรียกใช้ รวมถึงจัดการแอปพลิเคชันและบริการที่ใช้ API ที่ทันสมัย สำหรับข้อมูลเพิ่มเติม โปรดอ่านเกี่ยวกับการสร้างแอปพลิเคชันที่ทันสมัยบน AWS
ต่อไปนี้คือตัวอย่างข้อเสนอ AWS ที่รองรับข้อกำหนด API ของคุณได้
- เกตเวย์ของ Amazon API ช่วยให้นักพัฒนาสามารถสร้าง เผยแพร่ และจัดการ API ในวงกว้างได้ เกตเวย์ของ API ช่วยให้คุณสามารถสร้าง RESTful API ที่เหมาะสำหรับสถาปัตยกรรมไมโครเซอร์วิสที่มีคอนเทนเนอร์และแอปพลิเคชันบนเว็บ
- Elastic Load Balancing (ELB) กระจายการรับส่งข้อมูลเครือข่ายเพื่อปรับปรุงความสามารถในการปรับขนาดแอปพลิเคชัน โดยสามารถกำหนดเส้นทางและปรับสมดุลโหลดการรับส่งข้อมูล gRPC ระหว่างไมโครเซอร์วิส หรือระหว่างไคลเอ็นต์และบริการที่เปิดใช้งาน gRPC การทำงานนี้ช่วยให้สามารถนำระบบจัดการการรับส่งข้อมูลของ gRPC มาใช้ในสถาปัตยกรรมได้อย่างราบรื่น โดยไม่ต้องเปลี่ยนแปลงโครงสร้างพื้นฐานใดๆ ของไคลเอ็นต์หรือบริการของลูกค้า
- Amazon Virtual Private Cloud (Amazon VPC) Lattice เป็นบริการเครือข่ายแอปพลิเคชันที่เชื่อมต่อ ตรวจสอบ และรักษาความปลอดภัยของการสื่อสารระหว่างบริการของคุณอย่างต่อเนื่อง ปรับขนาดทรัพยากรการประมวลผลและเครือข่ายโดยอัตโนมัติเพื่อรองรับเวิร์กโหลด HTTP, HTTPS และ gRPC ที่มีแบนวิดท์สูง
เริ่มต้นใช้งาน gRPC และ REST บน AWS โดยสร้างบัญชีวันนี้
