Serialization Formats (รูปแบบการ Serialize)

ตัวเลือกเทคโนโลยี บางตัวที่เราดูกันไป—โดยเฉพาะ RPC implementation บางตัว—กำหนดทางเลือกให้คุณเกี่ยวกับวิธีที่ข้อมูลถูก serialize และ deserialize กับ gRPC ตัวอย่างเช่น ข้อมูลใดๆ ที่ถูกส่งจะถูกแปลงเป็น protocol buffer format ตัวเลือกเทคโนโลยีหลายตัว อย่างไรก็ตาม ให้อิสระเราอย่างมากในแง่ของวิธีที่เราแปลงข้อมูลสำหรับ network call เลือก Kafka เป็น broker ของคุณ แล้วคุณก็สามารถส่ง message ในหลากหลาย format ได้ ดังนั้น format ไหนที่คุณควรเลือก?

Textual Formats (รูปแบบข้อความ)

การ ใช้ textual format มาตรฐานให้ client มีความยืดหยุ่นอย่างมากในวิธีที่พวกมันใช้ resource REST API มักใช้ textual format สำหรับ request และ response body บ่อยที่สุด แม้ว่าในทางทฤษฎีคุณสามารถส่งข้อมูล binary ผ่าน HTTP ได้อย่างสบายๆ ก็ตาม ที่จริงแล้ว นี่คือวิธีที่ gRPC ทำงาน—ใช้ HTTP อยู่เบื้องหลัง แต่ส่ง protocol buffer แบบ binary

JSON ได้แทนที่ XML ในฐานะ text serialization format ที่ได้รับความนิยม คุณสามารถชี้ไปที่เหตุผลหลายอย่างว่าทำไมสิ่งนี้ถึงเกิดขึ้น แต่เหตุผลหลักคือหนึ่งในผู้เรียกใช้หลักของ API มักเป็น browser ซึ่ง JSON เหมาะสมมาก JSON กลายเป็นที่นิยมส่วนหนึ่งเป็นผลจากกระแส ต่อต้าน XML และผู้สนับสนุนก็อ้างถึงความกระชับและความเรียบง่ายของมันเมื่อเทียบกับ XML ว่าเป็นปัจจัยชนะอีกอย่างหนึ่ง ความจริงคือ แทบไม่มีความแตกต่างมากมายระหว่างขนาดของ JSON payload และ XML payload โดยเฉพาะเมื่อ payload เหล่านี้มักถูกบีบอัด ก็ควรชี้ให้เห็นด้วยว่าความเรียบง่ายบางส่วนของ JSON มาพร้อมต้นทุน—ในความรีบร้อนของเราที่จะนำ protocol ที่เรียบง่ายกว่ามาใช้ schema ก็หายไป (จะพูดถึงเพิ่มเติมทีหลัง)

Avro เป็น serialization format ที่น่าสนใจ มันใช้ JSON เป็นโครงสร้างพื้นฐานและใช้มันเพื่อกำหนด format แบบ schema-based Avro ได้รับความนิยมมากในฐานะ format สำหรับ message payload ส่วนหนึ่งเป็นเพราะความสามารถในการส่ง schema ไปเป็นส่วนหนึ่งของ payload ซึ่งสามารถทำให้การรองรับ messaging format ที่แตกต่างกันหลายแบบ ง่ายขึ้นมาก

ส่วนตัวแล้ว ผมยังคงชื่นชอบ XML tool support บางอย่างดีกว่า ตัวอย่างเช่น ถ้าผมต้องการดึงเฉพาะบางส่วนของ payload (เทคนิคที่เราจะพูดถึงเพิ่มเติมใน "Handling Change Between Microservices" ) ผมสามารถใช้ XPATH ซึ่งเป็นมาตรฐานที่เข้าใจกันดีและมี tool support มากมาย หรือแม้แต่ CSS selector ซึ่งหลายคนพบว่าง่ายกว่าด้วยซ้ำ กับ JSON ผมมี JSONPath แต่มันไม่ได้รับการรองรับอย่างแพร่หลายเท่า ผมพบว่ามันแปลกที่คนเลือก JSON เพราะมันเบาและดี แต่แล้วก็พยายามผลักดันแนวคิดเข้าไปในมัน เช่น hypermedia control ที่มีอยู่แล้วใน XML ผมยอมรับ อย่างไรก็ตาม ว่าผมน่าจะเป็นคนส่วนน้อยที่นี่ และ JSON ก็เป็น format ที่หลายคนเลือกใช้!

Binary Formats (รูปแบบ Binary)

ใน ขณะที่ textual format มีข้อดี เช่น ทำให้มนุษย์อ่านได้ง่ายและให้ interoperability มากมายกับเครื่องมือและเทคโนโลยีที่ต่างกัน โลกของ binary serialization protocol คือที่ที่คุณต้องการอยู่ถ้าคุณเริ่มกังวลเกี่ยวกับขนาด payload หรือประสิทธิภาพของการเขียน และอ่าน payload Protocol buffer มีมาสักระยะแล้วและมักถูกใช้นอกขอบเขตของ gRPC—พวกมันน่าจะเป็น binary serialization format ที่ได้รับความนิยมมากที่สุดสำหรับการสื่อสารแบบไมโครเซอร์วิส

อย่างไรก็ตาม พื้นที่นี้กว้างมาก และมี format อื่นๆ อีกจำนวนหนึ่งที่ถูกพัฒนาขึ้นโดยคำนึงถึงความต้องการที่หลากหลาย Simple Binary Encoding , Cap'n Proto และ FlatBuffers ล้วนผุดขึ้นมาในใจ แม้ว่าจะมี benchmark มากมายสำหรับแต่ละ format เหล่านี้ ที่เน้นข้อดีของมันเมื่อเทียบกับ protocol buffer, JSON หรือ format อื่นๆ benchmark ก็มีปัญหาพื้นฐานตรงที่พวกมันอาจไม่ได้แสดงถึงวิธีที่คุณจะใช้มันจริงๆ ถ้าคุณกำลังมองหาที่จะบีบทุก byte สุดท้ายออกจาก serialization format ของคุณ หรือลดเวลาที่ใช้ในการอ่านหรือเขียน payload เหล่านี้ลงสักไม่กี่ไมโครวินาที ผมขอแนะนำอย่างยิ่งให้คุณทำการเปรียบเทียบ format ต่างๆ เหล่านี้ด้วยตัวเอง จากประสบการณ์ของผม ระบบส่วนใหญ่แทบไม่ต้องกังวลกับการ optimize แบบนี้เลย เพราะพวกมันมักจะบรรลุการปรับปรุงที่ต้องการได้ด้วยการส่งข้อมูลน้อยลง หรือไม่ก็ไม่ต้องยิง call เลย อย่างไรก็ตาม ถ้าคุณกำลังสร้าง distributed system ที่ latency ต่ำมากๆ ให้แน่ใจว่าคุณพร้อมที่จะดำดิ่งเข้าสู่โลกของ binary serialization format