0Pricing
Cloud & IT Cert Prep · บทเรียน

รูปแบบการประสานงานกับการควบคุมจากศูนย์กลาง

เปรียบเทียบการประสานงานด้วยเหตุการณ์ (แต่ละบริการตอบสนองอย่างอิสระ) กับการควบคุมจากศูนย์กลาง (ตัวประสานงานส่วนกลางสั่งการบริการต่าง ๆ) และเลือกรูปแบบที่เหมาะกับสถาปัตยกรรม

รูปแบบการประสานงานกับการควบคุมจากศูนย์กลาง เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

แนวทางสองแบบสำหรับการประสานงานไมโครเซอร์วิส

เมื่อไมโครเซอร์วิสต้องทำงานร่วมกันเพื่อให้กระบวนการทางธุรกิจเสร็จสมบูรณ์ จะมีรูปแบบการประสานงานพื้นฐานอยู่สองแบบ Orchestration ใช้ตัวประสานงานส่วนกลาง (เช่น Step Functions) ซึ่งสั่งการแต่ละบริการอย่างชัดเจน ส่วน Choreography ไม่มีตัวประสานงานส่วนกลาง — บริการต่าง ๆ จะรับฟังเหตุการณ์และตอบสนองอย่างอิสระ การทำความเข้าใจว่าควรใช้แบบใดและเมื่อใดจึงควรใช้ร่วมกัน เป็นทักษะด้านสถาปัตยกรรมสำคัญที่ออกสอบใน SAA-C03

คำอธิบายรูปแบบ Orchestration

ในรูปแบบ orchestration บริการส่วนกลาง (orchestrator) จะควบคุมลำดับการดำเนินงาน โดยเรียกใช้บริการ A รอผลตอบกลับ จากนั้นจึงเรียกใช้บริการ B และดำเนินการต่อไป orchestrator จะมองเห็นสถานะของกระบวนการทั้งหมด จัดการข้อผิดพลาดและการลองใหม่ และตัดสินใจจากผลลัพธ์ระหว่างทางได้ บน AWS Step Functions คือ orchestrator มาตรฐาน โดยกำหนดเวิร์กโฟลว์ทั้งหมดเป็นเครื่องสถานะและขับเคลื่อนแต่ละขั้นตอน

# Orchestration: Step Functions state machine drives order processing
# StepFunctions -> ValidateOrder Lambda -> ChargePayment Lambda -> NotifyShipping Lambda
# Each arrow is an explicit command from the orchestrator
# If ChargePayment fails, Step Functions catches the error and routes to NotifyFailure
# The orchestrator (Step Functions) knows the full state of the order at every moment

คำอธิบายรูปแบบ Choreography

ในรูปแบบ choreography บริการต่าง ๆ จะสื่อสารกันผ่านเหตุการณ์โดยไม่มีตัวประสานงานส่วนกลาง บริการ A ทำงานเสร็จและเผยแพร่เหตุการณ์ (เช่น OrderValidated) ไปยังบัสเหตุการณ์หรือท็อปปิก บริการ B รับฟังเหตุการณ์ OrderValidated และประมวลผลการชำระเงิน จากนั้นเผยแพร่เหตุการณ์ PaymentCharged บริการ C รับฟัง PaymentCharged และจัดส่งคำสั่งซื้อ แต่ละบริการทำงานได้อย่างอิสระและแยกออกจากกัน — รับรู้เฉพาะเหตุการณ์ที่ตนใช้และสร้างขึ้น ไม่รับรู้บริการอื่น

# Choreography: EventBridge bus connects services without central coordinator
# OrderService -> publishes 'OrderPlaced' to EventBridge
# PaymentService -> listens for 'OrderPlaced', charges card, publishes 'PaymentCharged'
# ShippingService -> listens for 'PaymentCharged', creates shipment, publishes 'OrderShipped'
# NotificationService -> listens for 'OrderShipped', sends email
# No service calls another service directly — all communication is via events

บริการ AWS สำหรับแต่ละรูปแบบ

บน AWS Step Functions เป็นเครื่องมือหลักสำหรับ orchestration ส่วนเครื่องมือหลักสำหรับ choreography ได้แก่ Amazon EventBridge (สำหรับกำหนดเส้นทางเหตุการณ์ระหว่างบริการพร้อมการกรองตามเนื้อหา), Amazon SNS (สำหรับการกระจายแบบ fan-out อย่างง่าย) และ Amazon SQS (สำหรับการส่งข้อความแบบจุดต่อจุดระหว่างบริการ) คุณสามารถผสมผสานรูปแบบต่าง ๆ ได้ เช่น ใช้ EventBridge สำหรับ choreography ข้ามโดเมนระหว่างบริบทที่มีขอบเขต และใช้ Step Functions สำหรับประสานขั้นตอนภายในโดเมนเดียว

ข้อแลกเปลี่ยน: การมองเห็นระบบ

Orchestration ให้ การมองเห็นจากส่วนกลาง — ประวัติการทำงานของ Step Functions แสดงได้อย่างชัดเจนว่าเวิร์กโฟลว์อยู่ที่ใด แต่ละขั้นตอนใช้เวลานานเท่าใด และขั้นตอนใดล้มเหลว จึงแก้ไขจุดบกพร่องได้ตรงไปตรงมา ส่วน Choreography กระจายการมองเห็น ไปยังบริการและบัสเหตุการณ์หลายแห่ง — การติดตามธุรกรรมทางธุรกิจรายการเดียวต้องเชื่อมโยงบันทึกและเหตุการณ์จากบริการจำนวนมาก นี่เป็นเหตุผลที่ระบบ choreography ต้องพึ่งพา รหัสความสัมพันธ์ และการติดตามแบบกระจาย (AWS X-Ray) อย่างมาก เพื่อให้มองเห็นกระบวนการตั้งแต่ต้นจนจบ

# Correlation ID pattern for choreography observability
# Every event includes a correlationId that flows through the entire chain
{
  'source': 'com.myapp.orders',
  'detail-type': 'OrderPlaced',
  'detail': {
    'orderId': 'ORD-123',
    'correlationId': 'CORR-abc-456',  # propagated to every downstream event
    'customerId': 'CUST-789',
    'total': 99.99
  }
}

ข้อแลกเปลี่ยน: การเชื่อมโยง

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

ข้อแลกเปลี่ยน: การจัดการข้อผิดพลาด

Orchestration ทำให้ การจัดการข้อผิดพลาดมีความชัดเจน — บล็อก Catch ของ Step Functions กำหนดสถานะสำรองสำหรับข้อผิดพลาดแต่ละประเภท และประวัติเวิร์กโฟลว์ทั้งหมดจะแสดงบริบทของความล้มเหลว ใน Choreography การจัดการข้อผิดพลาดจะกระจายออกไป — แต่ละบริการต้องจัดการความล้มเหลวของตนเอง และอาจเผยแพร่เหตุการณ์ความล้มเหลวเพื่อให้บริการอื่นตอบสนอง การนำ sagas มาใช้ (ธุรกรรมชดเชยเพื่อยกเลิกการทำงานเมื่อขั้นตอนหนึ่งล้มเหลว) มีความซับซ้อนใน choreography มากกว่า orchestration อย่างมาก

# Saga pattern in choreography: compensating events
# Happy path:
# OrderPlaced -> PaymentCharged -> InventoryReserved -> OrderShipped
#
# Failure path (InventoryReservation fails):
# InventoryReservationFailed event published
# PaymentService listens -> issues refund -> publishes PaymentRefunded
# OrderService listens -> cancels order -> publishes OrderCancelled
#
# In orchestration (Step Functions), the compensating logic is in explicit Catch states

เมื่อใดควรเลือก Orchestration

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

เมื่อใดควรเลือก Choreography

ควรเลือก choreography เมื่อ: บริการต่าง ๆ เป็นความรับผิดชอบของทีมที่แตกต่างกันและไม่ควรประสานงานกันอย่างแน่นหนา ระบบควรเปิดให้ขยายด้วยบริการใหม่โดยไม่ต้องแก้ไขบริการเดิม เหตุการณ์แสดงข้อเท็จจริงมากกว่าคำสั่ง (เช่น 'OrderShipped' ไม่ใช่ 'ShipOrder') หรือคุณต้องการความสามารถในการปรับขนาดสูงสุด เนื่องจากไม่มีคอขวดส่วนกลาง ตัวอย่างเช่น การนำเข้าข้อมูลเพื่อการวิเคราะห์ การกระจายการแจ้งเตือน และการบันทึกเพื่อการตรวจสอบ ซึ่งล้วนเป็นกรณีที่ผู้บริโภคอิสระหลายรายตอบสนองต่อเหตุการณ์เดียวกัน

สถาปัตยกรรมแบบ Hybrid

สถาปัตยกรรม AWS ในโลกจริงส่วนใหญ่มักใช้ ทั้งสองรูปแบบ ในระดับความละเอียดที่แตกต่างกัน ตัวอย่างแบบผสมที่พบบ่อยคือ ใช้ การประสานงานแบบ EventBridge เพื่อแยกบริบทที่มีขอบเขตออกจากกัน (เช่น โดเมน Order ส่งเหตุการณ์ออกมา ส่วนโดเมน Inventory, Payment และ Shipping ต่างตอบสนองอย่างอิสระ) ขณะที่ภายในโดเมน Payment ใช้ การจัดการกระบวนการด้วย Step Functions เพื่อประสานขั้นตอนของกระบวนการชำระเงินภายใน (เรียกเก็บเงิน ตรวจสอบการฉ้อโกง อนุมัติ และชำระบัญชี) วิธีนี้ทำให้การเชื่อมโยงระหว่างโดเมนไม่แน่นหนา ขณะเดียวกันกระบวนการภายในก็มีความชัดเจน

# Hybrid: EventBridge for inter-domain + Step Functions for intra-domain
#
# EventBridge bus (choreography):
#   Order domain publishes 'OrderPlaced'
#   Payment domain receives it, starts Step Functions execution
#
# Step Functions (orchestration inside Payment domain):
#   ValidateCard -> FraudCheck -> AuthorisePayment -> SettlePayment
#   On success: PaymentDomain publishes 'PaymentCharged' to EventBridge bus
#   On failure: Step Functions Catch -> publishes 'PaymentFailed' event

สัญญาณในการสอบ SAA-C03

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

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า การจัดการกระบวนการใช้ตัวประสานงานส่วนกลาง (Step Functions) เพื่อควบคุมกระบวนการอย่างชัดเจนและตรวจสอบได้ การประสานงานแบบกระจายใช้เหตุการณ์ (EventBridge) เพื่อให้การเชื่อมโยงไม่แน่นหนาและขยายเพิ่มเติมได้ และ สถาปัตยกรรมที่ใช้งานจริงส่วนใหญ่มักผสมผสานทั้งสองรูปแบบในระดับความละเอียดที่แตกต่างกัน บทถัดไป เราจะสำรวจรูปแบบการสอบ SAA-C03 และกลยุทธ์จัดสรรน้ำหนักเวลาให้แต่ละโดเมน

คำถามที่พบบ่อย

บทเรียน “รูปแบบการประสานงานกับการควบคุมจากศูนย์กลาง” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “รูปแบบการประสานงานกับการควบคุมจากศูนย์กลาง” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “รูปแบบการประสานงานกับการควบคุมจากศูนย์กลาง”

เปรียบเทียบการประสานงานด้วยเหตุการณ์ (แต่ละบริการตอบสนองอย่างอิสระ) กับการควบคุมจากศูนย์กลาง (ตัวประสานงานส่วนกลางสั่งการบริการต่าง ๆ) และเลือกรูปแบบที่เหมาะกับสถาปัตยกรรม คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “รูปแบบการประสานงานกับการควบคุมจากศูนย์กลาง” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม

ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. EventBridge: บัสเหตุการณ์และกฎ
  2. Step Functions: การประสานกระบวนงานแบบไร้เซิร์ฟเวอร์
  3. Kinesis Data Streams สำหรับการประมวลผลเหตุการณ์แบบเรียลไทม์
  4. รูปแบบการประสานงานกับการควบคุมจากศูนย์กลาง
← กลับไปที่ Cloud & IT Cert Prep