JSON-RPC? พักผ่อนอย่างยุ่งยาก

ฉันแน่ใจว่าพาดหัวข่าวทำให้เกิดปฏิกิริยาที่ดี - “มันเริ่มต้นใหม่แล้ว…” แต่ให้ฉันดึงดูดความสนใจของคุณสัก 5-10 นาที แล้วฉันจะพยายามไม่ทำให้ความคาดหวังของคุณผิดหวัง

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

เพื่อให้ชัดเจนว่า RPC คืออะไร ฉันเสนอให้พิจารณามาตรฐาน JSON-RPC2.0. ด้วย REST ไม่มีความชัดเจน และมันก็ไม่ควรจะเป็น ทุกสิ่งที่คุณจำเป็นต้องรู้เกี่ยวกับ REST - แยกไม่ออกจาก HTTP.

คำขอ RPC นั้นเร็วกว่าและมีประสิทธิภาพมากกว่าเพราะช่วยให้คุณสามารถส่งคำขอเป็นชุดได้

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

หากคุณมีแบ็กเอนด์โหนดเดียว คำขอแบบแบตช์ก็จะดูเร็วขึ้น เนื่องจากการร้องขอ REST สามครั้งจะต้องใช้ทรัพยากรเพิ่มขึ้นสามเท่าจากโหนดเดียวเพื่อสร้างการเชื่อมต่อ

โปรดทราบว่าคำขอแรกในกรณีของ REST จะต้องส่งคืน ID ผู้ใช้เพื่อให้สามารถส่งคำขอครั้งต่อไปได้ ซึ่งส่งผลเสียต่อผลลัพธ์โดยรวมด้วย

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

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

การเข้าสู่สคริปต์ไม่ใช่คำร้องขอเพิ่มคุณค่าสองรายการ แต่ขอห้าหรือสิบ... และคำตอบสำหรับคำถาม "ตอนนี้ใครชนะ" กลายเป็นไม่ชัดเจน

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

ดูว่าโครงสร้างพื้นฐาน RPC ได้รับการปรับปรุงอย่างมีนัยสำคัญเพื่อตอบสนองความต้องการโหลดสูงได้อย่างไร ประเด็นก็คือ REST ใช้โปรโตคอล HTTP เต็มประสิทธิภาพ ซึ่งแตกต่างจาก RPC ในแผนภาพด้านบน กำลังนี้รับรู้ผ่านวิธีการร้องขอ - GET

วิธี HTTP เหนือสิ่งอื่นใดมีกลยุทธ์การแคช คุณสามารถค้นหาได้ในเอกสารประกอบที่ HTTP. สำหรับ RPC มีการใช้คำขอ POST ซึ่งไม่ถือว่าเป็น idempotent กล่าวคือ การทำซ้ำคำขอ POST เดียวกันซ้ำอาจให้ผลลัพธ์ที่แตกต่างกัน (เช่น หลังจากที่แต่ละความคิดเห็นถูกส่งไปแล้ว สำเนาของความคิดเห็นนี้อีกชุดจะปรากฏขึ้น) (แหล่ง).

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

ตอนนี้เรามานับคำขอ REST และ RPC ที่ "ให้กำเนิด" ในโครงสร้างพื้นฐานที่อยู่ระหว่างการพิจารณาจำนวนเท่าใด

การร้องขอ
กล่องขาเข้า
เพื่อแบ็กเอนด์
ไปยัง DBMS
ไปยังซอฟต์แคช (Redis)
ทั้งสิ้น

REST
1 / 32 *
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] ในกรณีที่ดีที่สุด (หากใช้แคชในเครื่อง) 1 คำขอ (หนึ่ง!) ในกรณีที่แย่ที่สุด 32 คำขอขาเข้า

เมื่อเทียบกับโครงการแรก ความแตกต่างก็น่าทึ่ง ตอนนี้ประโยชน์ของ REST ก็ชัดเจนแล้ว แต่ฉันแนะนำว่าอย่าหยุดเพียงแค่นั้น โครงสร้างพื้นฐานที่พัฒนาแล้วประกอบด้วย CDN บ่อยครั้งที่มันยังแก้ปัญหาการตอบโต้การโจมตี DDoS และ DoS ด้วย เราได้รับ:

นี่คือจุดที่สิ่งต่าง ๆ แย่มากสำหรับ RPC RPC ไม่สามารถมอบหมายภาระงานให้กับ CDN ได้ เราสามารถพึ่งพาระบบเพื่อตอบโต้การโจมตีเท่านั้น

เป็นไปได้ไหมที่จะจบที่นี่? และอีกครั้งไม่ วิธี HTTP ดังที่กล่าวข้างต้นมี “เวทย์มนตร์” ของตัวเอง และไม่ใช่ว่าไม่มีเหตุผลที่วิธี GET จะใช้กันอย่างแพร่หลายบนอินเทอร์เน็ต โปรดทราบว่าวิธีนี้สามารถเข้าถึงเนื้อหาบางส่วน สามารถกำหนดเงื่อนไขที่องค์ประกอบโครงสร้างพื้นฐานสามารถตีความได้ก่อนที่จะถ่ายโอนการควบคุมไปยังโค้ดของคุณ และอื่นๆ ทั้งหมดนี้ช่วยให้คุณสร้างโครงสร้างพื้นฐานที่ยืดหยุ่นและจัดการได้ ซึ่งสามารถรองรับคำขอจำนวนมากได้ แต่ใน RPC วิธีการนี้... จะถูกละเว้น

เหตุใดความเชื่อที่ว่าคำขอแบทช์ (RPC) จึงเร็วกว่านั้นยังคงอยู่? โดยส่วนตัวแล้ว สำหรับฉันแล้วดูเหมือนว่าโครงการส่วนใหญ่ไปไม่ถึงระดับการพัฒนาที่ REST สามารถแสดงจุดแข็งได้ ยิ่งไปกว่านั้น ในโครงการขนาดเล็ก เขาเต็มใจที่จะแสดงจุดอ่อนของเขามากขึ้น

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

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

คำขอ RPC มีความน่าเชื่อถือมากกว่า เนื่องจากสามารถดำเนินการคำขอแบบแบตช์ภายในธุรกรรมเดียว

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

“ข้อเสีย” ของ REST นี้เป็นข้อดีอีกด้านที่อธิบายไว้ข้างต้น นั่นคือความสามารถในการใช้ทรัพยากรโครงสร้างพื้นฐานทั้งหมดอย่างมีประสิทธิภาพ หากโครงสร้างพื้นฐานได้รับการออกแบบไม่ดี และยิ่งไปกว่านั้นหากสถาปัตยกรรมของโครงการและฐานข้อมูลโดยเฉพาะได้รับการออกแบบไม่ดี นี่ถือเป็นปัญหาใหญ่จริงๆ

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

ลองดูที่แผนภาพ นำเสนอโครงสร้างพื้นฐานที่มีองค์ประกอบความพร้อมใช้งานสูง มีสองช่องทางการสื่อสารอิสระพร้อมเกตเวย์ SMS แต่...เราเห็นอะไร? เมื่อส่ง SMS จะเกิดข้อผิดพลาด 503 - บริการไม่สามารถใช้งานได้ชั่วคราว เพราะ การส่ง SMS รวมอยู่ในคำขอแบบกลุ่ม ดังนั้นคำขอทั้งหมดจะต้องถูกย้อนกลับ การดำเนินการใน DBMS จะถูกยกเลิก ลูกค้าได้รับข้อผิดพลาด

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

เอาล่ะ ลองจินตนาการว่าเราเครียด (!) และคิดถึงตัวเลือกเมื่อคำขอสามารถดำเนินการบางส่วนให้สำเร็จได้สำเร็จ และเราจะพยายามทำส่วนที่เหลืออีกครั้งหลังจากช่วงระยะเวลาหนึ่ง (อันไหน แนวหน้าเป็นคนตัดสินใจ?) แต่หวยก็เหมือนเดิม คำขอส่ง SMS มีโอกาส 50/50 ที่จะล้มเหลวอีกครั้ง

เห็นด้วยจากฝั่งไคลเอ็นต์ บริการดูเหมือนไม่น่าเชื่อถือเท่าที่เราต้องการ... แล้ว REST ล่ะ?

REST ใช้เวทย์มนตร์ของ HTTP อีกครั้ง แต่ตอนนี้มีรหัสตอบกลับ เมื่อเกิดข้อผิดพลาด 503 บนเกตเวย์ SMS แบ็กเอนด์จะถ่ายทอดข้อผิดพลาดนี้ไปยังบาลานเซอร์ บาลานเซอร์ได้รับข้อผิดพลาดนี้ และส่งคำขอไปยังโหนดอื่นซึ่งประมวลผลคำขอได้สำเร็จโดยไม่ทำลายการเชื่อมต่อกับไคลเอนต์ เหล่านั้น. ลูกค้าได้รับผลลัพธ์ที่คาดหวัง และโครงสร้างพื้นฐานยืนยันชื่อที่สูงว่า “เข้าถึงได้สูง” ผู้ใช้มีความสุข

และนั่นไม่ใช่ทั้งหมดอีกครั้ง ตัวปรับสมดุลไม่เพียงได้รับรหัสตอบกลับ 503 เท่านั้น เมื่อตอบสนองตามมาตรฐาน ขอแนะนำให้ระบุรหัสนี้ด้วยส่วนหัว "ลองใหม่หลังจาก" ส่วนหัวทำให้บาลานเซอร์ชัดเจนว่าไม่คุ้มค่าที่จะรบกวนโหนดนี้บนเส้นทางนี้ตามเวลาที่กำหนด และคำขอถัดไปในการส่ง SMS จะถูกส่งโดยตรงไปยังโหนดที่ไม่มีปัญหากับเกตเวย์ SMS

ดังที่เราเห็นความน่าเชื่อถือของ JSON-RPC นั้นเกินจริงไป แน่นอนว่าการจัดระเบียบความสอดคล้องในฐานข้อมูลทำได้ง่ายกว่า แต่การเสียสละในกรณีนี้คือความน่าเชื่อถือของระบบโดยรวม

ข้อสรุปส่วนใหญ่คล้ายกับข้อสรุปก่อนหน้า เมื่อโครงสร้างพื้นฐานไม่ซับซ้อน ความชัดเจนของ JSON-RPC ก็จะเป็นข้อดีอย่างแน่นอน หากโปรเจ็กต์เกี่ยวข้องกับความพร้อมใช้งานสูงและมีโหลดสูง REST จะดูเหมือนเป็นโซลูชันที่ถูกต้องมากกว่า แม้ว่าจะซับซ้อนกว่าก็ตาม

เกณฑ์การเข้าสู่ REST ต่ำกว่า

ฉันคิดว่าการวิเคราะห์ข้างต้น ซึ่งหักล้างแบบเหมารวมที่กำหนดไว้เกี่ยวกับ RPC แสดงให้เห็นอย่างชัดเจนว่าเกณฑ์สำหรับการเข้าสู่ REST นั้นสูงกว่า RPC อย่างไม่ต้องสงสัย นี่เป็นเพราะความต้องการความเข้าใจอย่างลึกซึ้งเกี่ยวกับวิธีการทำงานของ HTTP รวมถึงความต้องการมีความรู้เพียงพอเกี่ยวกับองค์ประกอบโครงสร้างพื้นฐานที่มีอยู่ซึ่งสามารถและควรใช้ในโครงการ WEB

แล้วทำไมหลายๆ คนถึงคิดว่า REST จะง่ายกว่าล่ะ? ความเห็นส่วนตัวของฉันคือความเรียบง่ายที่ชัดเจนนี้มาจากส่วนที่เหลือที่แสดงออก เหล่านั้น. REST ไม่ใช่โปรโตคอล แต่เป็นแนวคิด... REST ไม่มีมาตรฐาน มีแนวทางบางประการ... REST ไม่ซับซ้อนกว่า HTTP เสรีภาพและอนาธิปไตยที่เห็นได้ชัดดึงดูด "ศิลปินอิสระ"

แน่นอนว่า REST นั้นไม่ได้ซับซ้อนไปกว่า HTTP แต่ HTTP นั้นเป็นโปรโตคอลที่ได้รับการออกแบบมาอย่างดีซึ่งพิสูจน์แล้วว่าคุ้มค่ามานานหลายทศวรรษ หากไม่มีความเข้าใจอย่างลึกซึ้งเกี่ยวกับ HTTP เอง ก็จะไม่สามารถตัดสิน REST ได้

แต่เกี่ยวกับ RPC - คุณทำได้ ก็เพียงพอที่จะใช้ข้อกำหนดของมัน คุณต้องการอย่างนั้นเหรอ JSON-RPC โง่? หรือ REST ยังคงยุ่งยากอยู่? คุณตัดสินใจ.

ฉันหวังเป็นอย่างยิ่งว่าฉันจะไม่เสียเวลาของคุณ

ที่มา: will.com