Microservices REST หรือ AMQP ซึ่งในกรณีนี้

16

ฉันได้อ่านบทความมากมายเกี่ยวกับสถาปัตยกรรมไมโครไซต์และฉันสงสัยว่าเมื่อไรที่จะใช้ AMQP หรือ REST

ฉันได้อ่านว่าการเชื่อมต่อระหว่างบริการเป็นสิ่งที่ดีและ AMQP ดูเหมือนจะเป็นทางเลือกที่ดีในกรณีนี้ แต่ถ้าเราใช้ AMQP นี่หมายความว่าเราไม่จำเป็นต้องใช้ปลายทาง REST อีกต่อไป (แต่นั่นหมายความว่าเราสูญเสียแนวคิด HATEOAS)

แต่ REST เป็นวิธีที่ดีในการสร้างบริการของฉันหรือไม่ เพราะฉันจะไม่ใช้จุดปลายใด ๆ ... ในกรณีใดอันหนึ่งดีกว่าอีกอัน?

เมื่อใดที่ฉันควรใช้รายการใดรายการหนึ่ง

— โทมัสโทมัส
แหล่งที่มา

10

โดยการละทิ้ง REST คุณจะเสียมากกว่าแค่ HATEOAS หาก microservices ของคุณเป็นสาธารณะ (และเป็นความคิดที่ดีสำหรับพวกเขาที่จะเป็นสาธารณะหรืออย่างน้อยก็มีแนวโน้มที่จะเป็นสาธารณะในวันหนึ่ง) การใช้สิ่งอื่นนอกเหนือจาก REST และ SOAP จะเป็นปัญหา:

นักพัฒนาบางคนไม่เคยใช้ AMQP
บางคนใช้ AMQP แต่มักคุ้นเคยกับ REST และ SOAP มากกว่า
ห้องสมุด AMQP สำหรับบางภาษานั้นไม่ตรงไปตรงมาโดยเฉพาะ
การทดลองใช้บริการด้วยตนเองมีข้อ จำกัด มาก: ฉันสามารถใช้ CURL เพื่อทำคำขอใด ๆ กับ Amazon S3; ฉันควรติดตั้งอะไรบนเครื่องของฉันหากฉันต้องการเล่นกับตัวแปร AMQP ของ S3
การดีบัก REST และ SOAP เป็นเรื่องง่าย ฉันเพียงแค่ติดตามการแลกเปลี่ยน HTTP และวิเคราะห์พวกเขา ไม่แน่ใจว่าเครื่องมือใดที่ฉันควรใช้เพื่อดูการดีบักการแลกเปลี่ยน AMQP

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

ลักษณะอะซิงโครนัสก็มีความสำคัญเช่นกัน บางครั้งมันก็มีประโยชน์: ฉันไม่ต้องการบล็อกส่วนต่อประสานผู้ใช้ของแอพในขณะที่ทำการร้องขอไปยังเซิร์ฟเวอร์ บางครั้งมันก็ทำให้สิ่งที่ยากกว่าที่พวกเขาต้อง: ถ้าฉันต้องการกู้คืนไฟล์สำรองจาก Amazon S3 เพราะท้องถิ่นนั้นเสียหายแล้วคืนค่าการสำรองข้อมูลแฟ้มแบตช์ของฉันจำเป็นต้องมี CURL เพื่อทำงานให้เสร็จก่อนที่จะดำเนินการต่อไป และการดำเนินการแบบซิงโครนัส (ด้วยการหมดเวลาที่เฉพาะเจาะจง) ทำให้รู้สึกที่สมบูรณ์แบบ

เก็บ REST ไว้สำหรับการดำเนินการหลัก:

รับผลิตภัณฑ์
จัดเก็บใบแจ้งหนี้

และใช้ AMQP สำหรับงานที่การรับส่งข้อความใช้งานได้จริง:

ประมวลผลใบแจ้งหนี้ทั้งหมดตั้งแต่เดือนกันยายนและแจ้งให้แอปทราบเมื่อรายงานพร้อมที่จะแสดง (โดยปกติการดำเนินการจะใช้เวลาสองถึงสิบนาที)

^{ประโยชน์ของ AMQP ที่นี่คือแง่มุมแบบอะซิงโครนัส คำขอ HTTP ที่รอดำเนินการเป็นเวลาสิบนาทีมีโอกาสดีที่จะทำให้เกิดการหมดเวลาและปัญหาอื่น ๆ}
การส่งข้อมูลที่การสำรองข้อมูลเสียหายกับทุกคนที่อาจสนใจเช่นผู้สนับสนุนผู้ดูแลฐานข้อมูลทีมตรวจสอบผู้พัฒนาแอปพลิเคชันที่ใช้ฐานข้อมูลนี้เป็นต้น

^{ประโยชน์ของ AMQP ในที่นี้คือความสามารถในการเพิ่มสมาชิกโดยไม่ต้องเปลี่ยนแอพพลิเคชั่นที่ติดตามการสำรองข้อมูลและเรียกใช้การแจ้งเตือนเมื่อพบว่ามีความเสียหาย}

^{¹บริการเว็บสาธารณะไม่จำเป็นต้องใช้โดยผู้ใช้นอก บริษัท ใน บริษัท ขนาดใหญ่หรือขนาดกลางบริการของคุณมักจะถูกใช้โดยหน่วยงานอื่น ๆ ของ บริษัท เดียวกันและมีข้อกำหนดเช่นเดียวกับ บริษัท อื่นที่จะใช้โดยบุคคลที่สาม: มันควรจะไม่ไว้ใจการโทรใด ๆ (ความจริงที่ว่า ได้ยินว่าใครเรียกบริการของคุณทำงานใน บริษัท เดียวกับที่คุณไม่ได้หมายความว่าเขาจะไม่ใช้ประโยชน์จากปัญหาด้านความปลอดภัยของมันจึงควรมีการบันทึกไว้อย่างถูกต้อง (เพราะคนอินเดียคนเดียวกันไม่จำเป็นต้องรู้หมายเลขโทรศัพท์ของคุณ รู้ภาษาอังกฤษ) ฯลฯ}

— Arseni Mourzenko
แหล่งที่มา

สิ่งที่เกี่ยวกับการโหลดขึ้นอยู่กับวัตถุโดยใช้ AMQP เช่นเดียวกับผู้ใช้ที่เกี่ยวข้องกับบริการการเรียกเก็บเงิน (ในสถาปัตยกรรมไมโครบริการขนาดใหญ่) คุณต้องการเข้าถึง asynchronicity VS REST เกลียดชัง (ซิงโครนัส) หรือไม่

— โทมัสโทมัส

5

ใช้ทั้งคู่

สไตล์เว็บบริการ JSON แบบ REST นั้นยอดเยี่ยมสำหรับการทำงานร่วมกันกับ javascript, ios และอื่น ๆ

AMQP เหมาะอย่างยิ่งสำหรับกระบวนการที่ใช้เวลานานเหตุการณ์และการประสานงานกับไมโครไซต์

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

AMPQ สามารถทำงานได้ดีกับ Websockets ซึ่งสามารถดูได้เหมือน REST endpoint หากคุณมองไปที่มัน

— Ewan
แหล่งที่มา

1

"ถ้าคุณเหล่มัน" ฮ่า ๆ นั่นเยี่ยมมาก

— เลนดันแคน

0

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

หากคุณกำลังเขียนสถาปัตยกรรม back-end ที่บริการของคุณใช้ด้วยตัวเองเท่านั้นคุณสามารถใช้โปรโตคอลใดก็ได้ที่คุณต้องการคุณจะไม่ถูก จำกัด อีกต่อไปโดยใช้สถาปัตยกรรมที่ทำงานร่วมกันได้ คุณสามารถใช้ MQ หรือสิ่งอื่น ๆ ที่คู่กันแน่นและมีประสิทธิภาพ สิ่งใดที่คุณใช้ขึ้นอยู่กับการใช้งานของคุณบัสข้อความนั้นดีมากสำหรับชุดบริการแบบกระจายซึ่งประมวลผลข้อมูลที่ลูกค้าไม่สนใจว่าใครจะได้รับข้อความที่ส่งออกไป

— gbjbaanb
แหล่งที่มา

2

ฉันไม่เห็นด้วยเท่าที่ฉันกังวลว่าพวกเขามีวัตถุประสงค์ข้าม; คุณ (โดยทั่วไป) ไม่ควรเปิดเผย AMQP ผ่านอินเทอร์เน็ตสาธารณะ มันมีสิ่งอำนวยความสะดวกในการตรวจสอบสิทธิ์น้อยกว่ามากสำหรับสิ่งหนึ่งและโดยปกติผู้ใช้อินเทอร์เน็ตสาธารณะต้องการคำตอบจากกิจกรรมของพวกเขา REST นั้นเหมาะสำหรับการใช้งานอินเทอร์เน็ตสาธารณะด้วยเหตุผลนี้ ความแตกต่างที่ยิ่งใหญ่ที่สุดว่าเป็นที่ AMQP ไม่ตรงกัน (ซิงโครเช่นพฤติกรรมที่เป็นไปได้ แต่มันไม่ใช่สิ่งที่ MQS มีการ) และส่วนที่เหลือเป็นซิงโคร (ใช่กลับมา202จะเล่า asynchrony แต่ทำไมคุณไม่ใช้ REST แล้วอาจจะเป็นเพราะมันสาธารณะ.)

— Jimmy Hoffa

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

— จิมมี่ฮอฟฟา

@JimmyHoffa ฉันคิดว่าเขากำลังขอให้ใช้ตะขอของเว็บเซิร์ฟเวอร์หรือลูกค้าหรือ microseervices ของเขาใน LAN ภายในไม่ใช่ผ่านเว็บ - ดังนั้นจุดของฉันที่ REST นั้นดีสำหรับสิ่งนั้น แต่ถ้าทุกอย่างที่คุณใช้อยู่ภายใต้คุณ ควบคุมคุณสามารถใช้สิ่งที่คุณต้องการ

— gbjbaanb

ใช่มันสมเหตุสมผลแล้ว ฉันอ่านคำถามของเขาต่างออกไป: ดูเหมือนว่าเขาจะอ่านเกี่ยวกับแนวคิดของไมโครไซต์และไม่เข้าใจเหตุผลที่เกี่ยวข้องในการเลือก AMQP กับ REST ภายในคุณสามารถใช้อะไรก็ได้ที่คุณต้องการ แต่ก็ยังมีเหตุผลเฉพาะที่จะใช้ AMQP กับ REST แม้แต่ภายใน บริการที่ต้องการอะซิงโครนัสควรใช้ AMQP ภายในบริการที่ซิงโครนัส (คิดว่าเป็นบริการการประมวลผลที่บริสุทธิ์: ข้อมูลดิบใน -> ข้อมูลที่ประมวลผลแล้ว) ควรเป็น REST มีข้อดีและข้อเสียที่แตกต่างกันสำหรับทั้งสอง IPC techs คุณรู้จักพวกเขาและควรระบุไว้ในคำตอบของคุณ! :)

— จิมมี่ฮอฟฟา

0

AMQP ยังรองรับการสื่อสารแบบจุดต่อจุด (ตัวอย่างเช่นดูpython-qpid-protonบทช่วยสอน) คุณสามารถใช้อินเตอร์เฟส RESTful โดยใช้สิ่งนั้นเนื่องจาก REST !=HTTP

AMQP ทำงานได้ดีกว่า HTTP มากเช่นกัน

— Cochise Ruhulessin
แหล่งที่มา