gRPC คืออะไร
gRPC (Google Protocol RPC) เป็น open source framework ตัวหนึ่งที่มี high performance มาก โดยมีผู้เขียนคือ Dropbox Inc, Google Inc, WeWork Company Inc. โดยมาก gRPC มักจะถูกนำไปเปรียบเทียบกับ REST ซึ่ง main usage scenarios จะนำไปใช้กับ polyglot service ใน microservice acchitecture, Connect กับ mobile device, browser client เรียกไปหา backend services
RPC (Remote Procedure Call) ก่อนจะมี gRPC มันมี RPC มาก่อน RPC เป็น Protocol ที่จะทำหน้าที่ request service และ response ที่ request มา อ่านต่อ ที่นี่
gRPC
- gRPC ใช้ “Protobuf”, “HTTP/2” และ “Google” พัฒนา
- รองรับทั้งการเขียนแบบ synchronous และ asynchronous
- ทำงานได้หลาย languages และ platforms
- Bi-directional streaming และ integrated auth
- สามารถติดต่อกับ Services ต่าง ๆ ได้อย่างมีประสิทธิภาพ ไม่ว่าจะติดต่อกับ devices, mobile applications รวมถึง browsers ไปสู่ backend service
- รองรับการ Scale, load balancing, tracing, health check หรือ จะเป็นการ authentication ก็ได้
ภาษาที่รองรับตอนนี้ก็เรียกว่าภาษาหลักมากันครบครัน ไม่ว่าจะเป็น C++, Java, Python, Go, Ruby, C#, Node.js, Android Java, Objective-C, PHP, Dart
OS ที่รองรับ Mac, Linux, Windows, iOS, Android ท่านสามารถดูต่อได้ ที่นี่
gRPC ใช้ Protobuf (protocol buffers) และ HTTP/2
Protobuf (protocol buffers)
Protobuf ถูกพัฒนาขึ้นมาเพื่อ serializing structured data โดยเป็น language-neutral, platform-neutral คล้าย JSON หรือ XML แต่ว่า Protobuf มัน เล็กกว่า เร็วกว่า และ ง่ายกว่า เรียกอีกอย่างว่า โลกนี้มันไม่ได้มีแค่ JSON หรือ XML ที่ครองโลก มันยังมี Protobuf ด้วย อีกอย่างคือ มันพัฒนาโดย Google อีกแล้ว
ภาษาที่ Protobuf 3 รองรับก็จะมีดังต่อไปนี้ Java, Python, Objective-C, C++, Dart, Go, Ruby, และ C# สามารถดูต่อได้ ที่นี่
Protobuf vs JSON vs XML
ความแตกต่างที่ผมเห็นว่ามันใหญ่ที่สุดก็คือ “Payload” ถ้าเราคุยกันผ่าน RESTFul เราก็มักจะคุยกันด้วย Json ถ้าเราใช้ SOAP เราจะคุยกันผ่าน XMLโดยทั้งสองตัวที่กล่าวมานั้น มนุษย์อย่างเรา ๆ สามารถอ่านได้รู้เรื่อง แต่ว่า Protobuf ข้อมูลจะเป็น Binary ซึ่งนั่นเป็นสาเหตุที่ทำให้มัน เล็กมากกกกก ทำให้ Process ได้ไว เร็วส์มว๊ากกกกกกก ส่วนข้อเสียหลัก ๆ เลยก็คือ มันอ่านไม่ออก เพราะมันเป็น Binary
ท่านสามารถไปดูที่เขา Compare performance กันต่อได้ ที่นี่ หรือ ที่นี่
HTTP/1.1 vs HTTP/2
HTTP/1.1 (Hypertext transfer protocol) เป็นที่รู้จักกันมาอย่างช้านาน HTTP/1.1 ถูกประกาศใช้ตั้งแต่ปี 1999 RFC#2616
ด้วยความที่มันอยู่มานาน ในสมัยก่อน Website ยังไม่มีการ request อะไรมากมายเหมือนอย่างทุกวันนี้มันก็ไม่ค่อยมีปัญหาอะไร แต่ปัจจุบัน Website มันเปลี่ยนไปเยอะมากจนทำให้เกิดปัญหาเรื่อง Transfer size, RTT Decreases (round tip time), HOLB (Head of line blocking) ทาง Google เขาเลยสร้าง SPDY (pronounced speedy) ขึ้นมาแก้ปัญหา
HTTP/2 based on Google’s experimental SPDY protocol ซึ่งก็ถูกปรับปรุงแก้ไขกระบวนการมากมายหลายอย่าง แต่มันก็ยังคง concept เดิมจาก SPDY
- Multiplexing and concurrency: สามารถส่ง request จำนวนมากผ่าน TCP เดียวกัน และสามารถรับ response ได้ตามต้องการโดยไม่จำเป็นต้องเชื่อมต่อหลายครั้งระหว่าง client กับ server และลด head-of-line blocking เช่น การ request เข้าเว็บไซต์ 1 ครั้งผ่าน HTTP 1.1 จะได้ response กลับมา 1 สิ่ง เช่น index.html 1 file แล้วก็ต้อง request main.css, jquery.js ทั้งหมดนี่ก็จัดไป 3 request แล้ว แต่ HTTP/2 ทำ 3 request นี้ได้ในครั้งเดียวเป็นการลดการทำ TCP Connection
- Stream priority dependencies: client กำหนดความสำคัญ สำหรับการทำ streaming ได้ รวมทั้งยังสามารถกำหนดความสำคัญในส่วนของ header ได้ด้วย
- Header compression: ลดขนาดของ Header โดยทำการบีบอัดข้อมูลต่าง ๆ
- Server push: Server สามารถส่ง resources ไปหา client ได้โดยที่ client ยังไม่ได้ request ไป เช่น Client request Cat ไปแทนที่ server จะคืนมาแค่ cat แต่ server ฉลาดรู้ว่าอีกแป๊บ client จะต้อง request dog แน่ ๆ ก็ทำการส่ง dog ไปก่อนเลยจร้า (ยังใช้งานบน NGINX กับ CloudFlare ไม่ได้ในตอนนี้)
ถ้าให้เขียนง่าย ๆ ก็คือ HTTP/2 ได้รับอานิสงมาจาก SPDY นั่นแหละ อ่านต่อได้ ที่นี่
Who’s using gRPC
แน่นอนครับระดับ Google ทำทั้งทีก็ต้องมีคนใช้อยู่แล้ว ที่ผม Capture รูปมานี่คือ ตัวอย่างจาก Website หลักของเขานะครับ ซึ่งก็จะมีเขียนบอกด้วยว่า บริษัทต่าง ๆ พวกนี้นั้น เขานำ gRPC มาทำอะไรกัน สามารถไปอ่านกันต่อไป ที่นี่
Conclusion
มาถึงตรงนี้ หากใครยังไม่เข้าใจว่า gRPC คืออะไร ผมแนะนำให้คุณนึกถึง SOAP หรือ REST ก็ได้ครับ มันสร้างขึ้นมาเพื่อให้เราคุยกันข้าม Server โดยที่ไม่สนใจว่าเครื่องปลายทางจะเป็น Platform อะไร รวมถึงมันยังถูกนำมาเปรียบเทียบกับ GrapQL อีกด้วย ซึ่ง gRPC มันก็แบบนั้นแหละ แต่ว่ามัน ย่อยข้อมูลที่เราส่งให้เล็กกว่า ทำให้ไวกว่า แล้วก็ง่าย ด้วยการ ผนวก Protobuf + HTTP/2
ถ้ายังไม่รู้จัก Protpbuf กับ HTTP/2 ขึ้นไปอ่านข้างบน ผมย่อยให้สุด ๆ แล้ว
ผมคิดว่าในอีกไม่นานนี้ ในโลกแห่งความ Microservices เจ้าตัว gRPC จะมาแน่นอน เพราะว่ามันจะเข้ามาช่วยทำให้พวกเราสาวกแห่งการ Develop ได้รับ performance ที่ดีขึ้น แต่ไม่ว่ายังไงก็ตาม REST ก็อยู่กับพวกเรามาอย่างยาวนาน มันก็คงจะดำรงอยู่สืบไป เหมือนกับ SOAP ที่ทุกวันนี้หลาย ๆ ท่านก็ยังคงต้องใช้กันอยู่… ก็หวังว่าบทความนี้จะเป็นประโยชน์สำหรับท่านที่สนใจบ้างนะครับ
หากผิดพลาดประการใด ขออภัยมา ณ ที่นี้ด้วยนะครับ
เรื่องนี้ตัวผู้เขียนเอง ก็ยังไม่ได้ทดลองนำไปใช้เองจริง ๆ บน production แต่ก็หวังว่าอีกไม่นานนี้จะได้ลองเอาไปใช้จริงเผื่อจะได้มีบทความ gRPG ภาค 2 ต่อไป ขอบคุณครับ
ปล.จากที่ไปทำการ Research มา ปัจจุบันนี้ gRPC ก้าวไกลไปจนถึงมี Project gRPC Gateway แล้ว
ปล2.บทความนี้ References เยอะหน่อยนะครับ
