01 ก.ค. 2568·อ่าน 2 นาที

รูปแบบเบรกเกอร์วงจรสำหรับ API ของบุคคลที่สามในเวิร์กโฟลว์เชิงภาพ

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

ทำไมการล่มของ API ภายนอกถึงทำให้หลายฟีเจอร์พังพร้อมกัน\n\nAPI ของผู้ให้บริการภายนอกมักอยู่กลางกระบวนการประจำวัน: รับชำระเงิน, ตรวจสอบที่อยู่, ซิงก์สต็อก, ส่งข้อความ, ยืนยันตัวตน เมื่อผู้ให้บริการมีปัญหา มันไม่ได้ทำให้ปุ่มเดียวพัง แต่สามารถหยุดทั้งเวิร์กโฟลว์ที่รอการตอบกลับนั้น\n\nนั่นคือเหตุผลที่เบรกเกอร์วงจรสำคัญ — มันไม่ใช่ทฤษฎี แต่เป็นวิธีปฏิบัติที่ช่วยให้การดำเนินงานหลักยังทำงานได้แม้ว่าการเชื่อมต่อจะไม่พร้อมใช้งาน\n\nความช้าและการล่มส่งผลต่างกัน\n\nเมื่อ API ช้า เวิร์กโฟลว์ยังพยายามทำงานต่อ แต่ทุกขั้นตอนต้องรอ ผู้ใช้เห็นหน้าจอโหลด ทีมซัพพอร์ตได้รับตั๋วว่า “มันติด” และงานเบื้องหลังสะสม ความช้าทำให้ดูเหมือนระบบของคุณเองมีปัญหา\n\nเมื่อ API ล่ม คุณจะได้ timeout หรือข้อผิดพลาดที่ชัดเจน ซึ่งดูง่ายกว่าแต่บางครั้งอันตรายกว่าเพราะเวิร์กโฟลว์มักรีทราย เมื่อคำขอจำนวนมากรีทรายพร้อมกัน จะเกิดพายุทราฟฟิกที่ทำให้การกู้คืนยากขึ้นและอาจลากระบบของคุณลงไปด้วย\n\nอาการทั่วไปจะเห็นได้เร็ว: timeout คิวที่ยังเติบโต การอัปเดตบางส่วน และต้องทำความสะอาดด้วยมือจำนวนมาก\n\nความเสียหายที่แท้จริงคือปฏิกิริยาลูกโซ่ หากผู้ให้บริการคำนวณอัตราค่าส่งช้า การวางคำสั่งซื้อก็ช้าลงเพราะเวิร์กโฟลว์ไม่ยอมยืนยันคำสั่งโดยไม่มีใบเสนอราคา หากการชำระเงินล่ม ทีมซัพพอร์ตอาจไม่สามารถคืนเงินได้แม้ว่าสิ่งอื่นจะทำงานได้ปกติ\n\nคุณไม่สามารถมองข้ามการล่มได้ เป้าหมายคือออกแบบเวิร์กโฟลว์ที่มีเส้นทางสำรองชัดเจน กฎการบล็อกชั่วคราว และการแจ้งเตือนเพื่อธุรกิจยังรับคำสั่ง ขบริการลูกค้า และบันทึกงานในขณะที่การเชื่อมต่อฟื้นตัว\n\n## เบรกเกอร์วงจรอธิบายแบบง่ายๆ\n\nเบรกเกอร์วงจรคือสวิตช์นิรภัยสำหรับการเรียก API เมื่อผู้ให้บริการภายนอกเริ่มล้มเหลว เบรกเกอร์จะหยุดไม่ให้เวิร์กโฟลว์ทุบเรียกซ้ำๆ แทนที่จะเปลี่ยนการล่มครั้งเดียวให้กลายเป็นหน้าจอช้า, timeout, และงานติดค้าง คุณจะควบคุมขอบเขตของความเสียหายได้\n\nเบรกเกอร์มีผลลัพธ์สามแบบง่ายๆ:\n\n- อนุญาตให้เรียก เมื่อผู้ให้บริการดูปกติ\n- บล็อกการเรียก เมื่อความล้มเหลวสูง และพาทำงานไปยัง fallback ทันที\n- ลองเรียกทดสอบจำกัด หลังจากพักสั้นๆ เพื่อตรวจว่าผู้ให้บริการกลับมาหรือยัง\n\nถ้าชอบใช้ป้ายชื่อก็เป็น “closed”, “open”, และ “half-open” ชื่อไม่สำคัญเท่าความคาดการณ์ได้ เมื่อผู้ให้บริการมีปัญหา เวิร์กโฟลว์ของคุณควรทำงานเหมือนเดิมในทุกครั้ง\n\nสิ่งนี้ไม่ซ่อนข้อผิดพลาด คุณยังบันทึกล้มเหลว แสดงสถานะที่ชัดเจนให้ผู้ใช้หรือทีมปฏิบัติการ และแจ้งคนที่ควรรู้ คุณกำลังเลือกที่จะล้มเหลวอย่างรวดเร็ว ส่งงานไปยังทางเลือกที่ปลอดภัยกว่า หรือลองพักก่อนทดสอบใหม่\n\n## เลือกการเรียก API ที่ห้ามหยุดธุรกิจ\n\nเบรกเกอร์ทำงานได้ดีที่สุดเมื่อคุณคัดเลือก ไม่ใช่การเรียกทุกตัวที่ต้องการการป้องกันพิเศษ เริ่มจากขั้นตอนที่หากถูกบล็อกจะหยุดเงิน คำสั่ง หรือการเข้าถึงลูกค้า\n\nวิธีปฏิบัติที่เป็นประโยชน์คือเดินตามคำขอผู้ใช้หนึ่งรายการแบบ end-to-end แล้วถามว่าที่ไหนที่ timeout จะบังคับให้ผู้ใช้ยกเลิกงาน หรือต้องให้ทีมมาทำความสะอาดทีหลัง\n\nการเรียกที่ควรให้การป้องกันมักรวมถึงการชำระเงิน การจัดส่งและการปฏิบัติ การล็อกอิน/SSO/MFA ข้อความ OTP และการตรวจสอบที่เกี่ยวกับการอนุมัติ\n\nแยกระหว่างขั้นตอนที่เห็นโดยผู้ใช้กับงานเบื้องหลังด้วย หากคนรอที่หน้าชำระเงิน คุณต้องการคำตัดสินเร็ว: สำเร็จ สำรอง หรือหยุดพร้อมข้อความชัดเจน สำหรับงานเบื้องหลังเช่นการซิงก์หมายเลขติดตาม การรีทรายช้ากว่าเป็นที่ยอมรับตราบเท่าที่มันไม่บล็อกโฟลว์หลัก\n\nเริ่มจากเล็กๆ เพื่อหลีกเลี่ยงขอบเขตที่ขยายตัว ปกป้อง 1–3 เวิร์กโฟลว์ก่อน แล้วค่อยขยาย\n\nกำหนดความหมายของ “fallback ที่ปลอดภัย” ก่อนสร้างอะไร Good fallbacks ควรเฉพาะเจาะจงและทดสอบได้:\n\n- การชำระเงิน: บันทึกคำสั่งเป็น “payment pending” เพื่อไม่ให้ตะกร้าหาย\n- การจัดส่ง: ใช้อัตราที่แคชไว้ อัตราแบบ flat rate หรือยืนยันคำสั่งแล้วเลื่อนการซื้อฉลาก\n- ตัวตน: อนุญาตล็อกอินด้วยรหัสผ่านเมื่อ SSO ล่ม หรือสลับเป็นการยืนยันทางอีเมล\n- การส่งข้อความ: ต่อคิว SMS ไว้ภายหลังและให้เส้นทางสำรองถ้าเป็นไปได้\n\nใน Business Process Editor ของ AppMaster นี่มักกลายเป็นสาขาชัดเจน: การดำเนินการหลักยังไปต่อ ขณะที่ขั้นตอนที่พึ่งพาผู้ให้บริการใช้ทางเลือกที่ควบคุมได้\n\n## สถานะ เกณฑ์ และตัวจับเวลาที่อธิบายได้\n\nเบรกเกอร์วงจรคือสวิตช์นิรภัย ส่วนใหญ่เวลามันปล่อยให้เรียกผ่าน เมื่อผู้ให้บริการเริ่มล้มเหลว มันจะเปลี่ยนเพื่อปกป้องเวิร์กโฟลว์จากการเสียเวลาและการสะสมข้อผิดพลาด\n\n### สามสถานะ\n\nClosed คือปกติ เรียก API แล้วดำเนินต่อ\n\nถ้าความล้มเหลวข้ามเส้นที่กำหนด เบรกเกอร์จะเป็น Open คุณหยุดเรียกผู้ให้บริการเป็นระยะสั้นและเปลี่ยนไปยัง fallback ทันที (ค่าที่แคชไว้ งานคิว ทางเลือกอื่น)\n\nหลังคูลดาวน์ เบรกเกอร์จะเป็น Half-open คุณอนุญาตการเรียกทดสอบจำนวนเล็กน้อย ถ้าพวกมันสำเร็จ คุณกลับเป็น Closed ถ้าล้มเหลว คุณกลับเป็น Open\n\n### วัดอะไรบ้าง\n\nใช้สัญญาณที่สอดคล้องกับวิธีที่ผู้ให้บริการล้มเหลว:\n\n- Timeout\n- HTTP 5xx\n- ความหน่วงที่เพิ่มขึ้น (ช้ามากเกินกว่าจะใช้ได้)\n- ข้อผิดพลาดการเชื่อมต่อ/DNS\n- 429 rate limits\n\nในเครื่องมือเวิร์กโฟลว์เชิงภาพ สิ่งเหล่านี้มักแมปไปยังการตรวจสอบง่ายๆ: รหัสสถานะ เวลาที่ใช้ และผลลัพธ์ข้อผิดพลาดเฉพาะ\n\n### ค่าเริ่มต้นและตัวจับเวลาสองตัวสำคัญ\n\nเริ่มด้วยตัวเลขที่อธิบายง่าย แล้วปรับตามทราฟฟิก ตัวอย่าง:\n\n- เปิดเบรกเกอร์ถ้ามี 5–10 การเรียกล้มเหลวภายใน 30–60 วินาที\n- หรือเปิดถ้า 20%–40% ของการเรียกล้มเหลวในหน้าต่างเลื่อน\n- ถือว่าความหน่วงเป็นความล้มเหลวเมื่อเกินสิ่งที่กระบวนการยอมรับได้ (บ่อยครั้ง 2–5 วินาที)\n\nจากนั้นตั้งตัวจับเวลาสองตัว:\n\n- Cooldown time (สถานะ Open): มัก 30 วินาทีถึง 5 นาที\n- หน้าต่างทดสอบ Half-open: อนุญาต 1–5 การเรียกทดสอบ หรือตั้งเป็นช่วงเวลา 10–30 วินาที\n\nเป้าหมายคือ: ล้มเหลวอย่างรวดเร็วเมื่อผู้ให้บริการไม่ดี และกู้คืนโดยอัตโนมัติเมื่อกลับมา\n\n## ขั้นตอนทีละขั้น: สร้างเบรกเกอร์วงจรในเวิร์กโฟลว์เชิงภาพ\n\nการตัดสินใจสำคัญที่สุดคือทำการตัดสินใจ “ตอนนี้เราจะเรียกผู้ให้บริการไหม?” ไว้ที่จุดเดียว ไม่กระจายไปทั่วทุกเวิร์กโฟลว์\n\n### 1) วางการเรียกผู้ให้บริการไว้หลังบล็อกที่นำกลับมาใช้ได้เพียงบล็อกเดียว\n\nสร้าง sub-process (บล็อกเวิร์กโฟลว์นำกลับมาใช้ได้) ที่เวิร์กโฟลว์ทุกอันเรียกเมื่อต้องการผู้ให้บริการ ใน AppMaster นี่ตรงกับ Business Process ที่เรียกจาก endpoint หรือ automation เก็บให้แคบ: รับอินพุต ส่งคำขอผู้ให้บริการ แล้วคืนผลสำเร็จ/ล้มเหลวชัดเจน\n\n### 2) ติดตามความล้มเหลวโดยใช้เวลา ไม่ใช่แค่จำนวน\n\nบันทึกผลลัพธ์แต่ละรายการพร้อมสแตมป์เวลา เก็บข้อมูลเช่น last success, last failure, failures within a window, current state, และ cooldown deadline\n\nเก็บฟิลด์เหล่านี้ในตารางเพื่อให้เบรกเกอร์รอดการรีสตาร์ทและคงที่ข้ามอินสแตนซ์หลายตัว PostgreSQL ผ่าน Data Designer เหมาะสำหรับสิ่งนี้\n\n### 3) กำหนดการเปลี่ยนสถานะที่คุณจะทำตามทุกครั้ง\n\nเก็บกฎให้เรียบง่าย ตัวอย่าง: ถ้าเกิด 5 ความล้มเหลวภายใน 2 นาที สลับเป็น Open ขณะที่ Open ให้ข้ามการเรียกผู้ให้บริการจนกว่าคูลดาวน์จะหมด หลังคูลดาวน์ไป Half-open และอนุญาตการลองแบบควบคุม หากสำเร็จ ให้ปิดเบรกเกอร์ ถ้าล้มเหลว ให้เปิดอีกครั้ง\n\n### 4) แยกสาขาเวิร์กโฟลว์: เส้นทางผู้ให้บริการ vs เส้นทางสำรอง\n\nก่อนคำขอผู้ให้บริการ ให้ตรวจสถานะที่เก็บ:\n\n- Closed: เรียกผู้ให้บริการ แล้วอัปเดตผลสำเร็จหรือความล้มเหลว\n- Open: ข้ามการเรียกและรัน fallback\n- Half-open: อนุญาตการลองจำนวนจำกัด แล้วตัดสินใจปิดหรือเปิดใหม่\n\nตัวอย่าง: ถ้า API สร้างฉลากการจัดส่งล่ม ทางเลือกสำรองอาจสร้างคำสั่งด้วยสถานะ “Label pending” และต่อคิวงานรีทราย แทนที่จะบล็อกเช็คเอาต์หรือการทำงานของคลังสินค้า\n\n### 5) ทำให้แชร์ได้ข้ามเวิร์กโฟลว์\n\nถ้าคุณมีหลายเวิร์กโฟลว์และเซิร์ฟเวอร์ พวกมันต้องอ่านและเขียนสถานะเบรกเกอร์เดียวกัน มิฉะนั้นอินสแตนซ์หนึ่งอาจยังคงทุบเรียกผู้ให้บริการ ในขณะที่อีกอินสแตนซ์หนึ่งตัดสินใจหยุดแล้ว\n\n## ทางเลือกสำรองที่ทำให้การทำงานยังไปต่อได้\n\nเบรกเกอร์ช่วยได้ก็ต่อเมื่อคุณกำหนดว่าจะเกิดอะไรขึ้นเมื่อการเรียกถูกบล็อก ทางเลือกที่ดีทำให้ผู้ใช้ไปต่อ ปกป้องข้อมูล และทำให้การทำความสะอาดภายหลังคาดการณ์ได้\n\nเลือก fallback ที่เหมาะกับงาน หากผู้ให้บริการอัตราค่าส่งล่ม คุณอาจไม่จำเป็นต้องมีราคาที่แม่นยำเพื่อยอมรับคำสั่ง ในเวิร์กโฟลว์เชิงภาพ ให้เปลี่ยนขั้นตอน API ที่ล้มเหลวไปยังสาขา fallback ที่ยังให้ผลลัพธ์ใช้งานได้\n\nในทางปฏิบัติ fallback มักเป็นหนึ่งในรูปแบบเหล่านี้:\n\n- ใช้ค่าที่รู้จักล่าสุดที่แคชไว้ (พร้อมช่วงความสดที่ชัดเจน)\n- ใช้การประเมินค่าเริ่มต้นที่ปลอดภัย และติดป้ายอย่างชัดเจน\n- ส่งไปตรวจสอบด้วยมือ\n- ต่อคิวงานเพื่อนำมาลองใหม่ภายหลัง (งานแบบ async)\n\nประสบการณ์ผู้ใช้สำคัญพอๆ กับตรรกะ อย่าแสดงข้อผิดพลาดที่คลุมเครือ ให้บอกว่าเกิดอะไรขึ้นและผู้ใช้สามารถทำอะไรต่อได้: “ไม่สามารถยืนยันอัตราได้ตอนนี้ คุณสามารถสั่งซื้อโดยใช้อัตราที่ประเมินไว้ หรือบันทึกไว้เพื่อตรวจสอบ”\n\nวางแผนทั้งการล่มสั้นและการล่มยาว การล่มสั้น (เป็นนาที) มักหมายถึง “ไปต่อ และรีทรายในแบ็กกราวด์” การล่มยาว (เป็นชั่วโมง) อาจต้องการพฤติกรรมเคร่งครัดกว่า เช่น การตรวจสอบด้วยมือหรือการอนุมัติเพิ่มเติม\n\nสุดท้าย ติดตามทุก fallback เพื่อให้การกระทบยอดง่าย อย่างน้อยที่สุด ให้บันทึกประเภท fallback, รายละเอียดคำขอเดิม, สิ่งที่ส่งให้ผู้ใช้ (และว่ามันเป็นการประมาณหรือไม่), และสถานะสำหรับการติดตามต่อ\n\n## กฎการบล็อกชั่วคราวและการรีทรายที่ชาญฉลาดกว่า\n\nการรีทรายที่ไม่ควบคุมจะเปลี่ยนปัญหาเล็กๆ ของผู้ให้บริการให้กลายเป็นการล่มจริง เมื่อหลายเวิร์กโฟลว์รีทรายพร้อมกัน จะเกิดสปाइक (ปัญหา “thundering herd”) ผู้ให้บริการช้าลง คิวของคุณเติบโต และคุณใช้โควต้าเร็วเกินไป\n\nการรีทรายควรคาดการณ์ได้และถูกจำกัด และต้องเคารพสถานะเบรกเกอร์ นโยบายที่ใช้งานได้จริงคือ:\n\n- จำกัดการรีทรายสูงสุด (มัก 2–3 ครั้ง)\n- ใช้ exponential backoff (เช่น 2s, 8s, 30s)\n- ใส่ jitter เพื่อไม่ให้รีทรายซิงค์กัน\n- จำกัดเวลารวมของการรีทราย (เช่น 60–90 วินาที)\n- หากเบรกเกอร์เป็น Open อย่ารีทราย ให้ไปที่ fallback ทันที\n\nการบล็อกชั่วคราวเกี่ยวข้องแต่ต่างกันเล็กน้อย มันใช้กับกรณีที่การตอบกลับบอกว่า “จะไม่ทำงานตอนนี้” กฎทั่วไป:\n\n- 429 rate limit: บล็อกตาม Retry-After หรือช่วงเวลาปลอดภัยคงที่\n- 401/403 ข้อผิดพลาดการยืนยันตัวตน: บล็อกจนกว่าจะรีเฟรชข้อมูลรับรอง แล้วทดสอบหนึ่งครั้ง\n- 5xx ที่ต่อเนื่อง: บล็อกสั้น ๆ แล้วอนุญาตการทดสอบเล็กน้อย\n\nระหว่างการบล็อก ให้ตัดสินใจว่างานที่กำลังทำอยู่จะทำอย่างไร: ต่อคิว มุมไปเส้นทางอื่น หรือเสื่อมสภาพอย่างมีเหตุผล (เช่น ยอมรับคำสั่งแต่เลื่อนการส่ง SMS)\n\n## การแจ้งเตือนที่บอกว่าต้องทำอะไร\n\nเบรกเกอร์มีประโยชน์ก็ต่อเมื่อคนได้ยินเรื่องนี้เร็วและรู้ว่าจะทำอย่างไร เป้าหมายไม่ใช่เสียงรบกวน แต่คือข้อความชัดเจนเมื่อพฤติกรรมเปลี่ยน: การเรียกถูกบล็อก, fallback ทำงาน, หรือเบรกเกอร์ยังเปิดนานเกินคาด\n\nทริกเกอร์เริ่มต้นที่ดี:\n\n- แจ้งเตือนเมื่อเบรกเกอร์เปิด\n- แจ้งเตือนหากยังเปิดเกินเวลาที่คาด\n- แจ้งเตือนเมื่อตัวเลขข้อผิดพลาดพุ่งขึ้นอย่างรุนแรงแม้ก่อนเปิด\n\nทำให้การแจ้งเตือนปฏิบัติได้ รวมชื่อผู้ให้บริการและ endpoint, สถานะปัจจุบันและเวลาเปลี่ยน, สิ่งที่ผู้ใช้จะรู้สึก, เวิร์กโฟลว์กำลังทำอะไร (บล็อก, รีทราย, ใช้ fallback), และขั้นตอนแนะนำถัดไป\n\nแยกการแจ้งเตือนตามความร้ายแรง API เติมข้อมูลที่ไม่สำคัญอาจส่งอีเมลได้ การชำระเงิน, การล็อกอิน, หรือการส่งคำสั่งควรได้หน้าเพจหรือการแจ้งเตือนทันที ใน AppMaster นี่แมปได้ง่ายกับสาขาที่ส่งอีเมล, Telegram, หรือ SMS ตาม flag ความร้ายแรง\n\nติดตามเมตริกเล็กชุดหนึ่งเพื่อดูว่าคุณกำลังฟื้นตัว: จำนวนการเรียกที่ถูกบล็อกและการใช้ fallback ต่อผู้ให้บริการมักเพียงพอ\n\n## ตัวอย่างสถานการณ์: ผู้ให้บริการล่มโดยไม่หยุดการรับคำสั่ง\n\nความล้มเหลวที่พบบ่อย: ผู้ให้บริการคำนวณอัตราค่าส่งล่มขณะลูกค้ากำลังเช็คเอาต์ หากเวิร์กโฟลว์ของคุณยืนยันอัตราแบบสดขณะสร้างคำสั่ง การล่มครั้งเดียวอาจหยุดการสั่งซื้อทั้งหมด\n\nในวันปกติ คำสั่งถูกสร้าง แล้วเวิร์กโฟลว์ขออัตราแบบสด และคำสั่งบันทึกพร้อมผู้ให้บริการและราคาที่เลือก\n\nเมื่อผู้ให้บริการเริ่มล้ม การเรียกจะ timeout หรือคืน 5xx เมื่อถึงเกณฑ์ของคุณ (เช่น 5 ความล้มเหลวใน 2 นาที) เบรกเกอร์จะเปิด\n\nขณะที่เป็น Open เวิร์กโฟลว์หยุดเรียกผู้ให้บริการชั่วคราว (เช่น 10 นาที) เพื่อป้องกันไม่ให้ผู้ให้บริการล้มทำให้เช็คเอาต์สำหรับทุกคนล่ม\n\nแทนที่จะบล็อกเช็คเอาต์ ทางเลือกสำรองอาจ:\n\n- ใช้ค่าคงที่หรือค่าประเมินแบบ flat-rate\n- สร้างคำสั่งต่อไป\n- ทำเครื่องหมายเป็น “Shipping rate pending” เพื่อคำนวณใหม่ภายหลัง\n- บันทึกรายละเอียดข้อผิดพลาดของผู้ให้บริการเพื่อติดตาม\n\nใน AppMaster นี่คือสาขาชัดเจนใน Business Process Editor และเก็บฟิลด์ใน Data Designer เช่น `shipping_rate_status` และ `shipping_rate_source`\n\n## การตรวจสอบด่วนก่อนปล่อยใช้งาน\n\nเบรกเกอร์ควรทำงานเหมือนกันตอนโหลดหนักและตอนสาธิต ก่อนปล่อย ยืนยันพื้นฐานเหล่านี้:\n\n- เกณฑ์และคูลดาวน์ถูกดokument และเปลี่ยนได้ง่าย\n- สถานะ Open บล็อกการเรียกทันที (ไม่รอ timeout ของผู้ให้บริการ)\n- พฤติกรรม fallback ปลอดภัยทางการเงินและสัญญาลูกค้า\n- การทดสอบใน Half-open จำกัดให้มีเพียงไม่กี่การเรียกทดสอบ\n- บันทึกทำให้ตอบคำถามเรื่องเวลาและผลกระทบได้ง่าย\n\nใช้เวลาเพิ่มกับความปลอดภัยของ fallback การ fallback ที่ “ทำให้งานไปต่อ” อาจสร้างความเสี่ยงทางการเงินได้ หากผู้ให้บริการชำระเงินล่ม การมาร์กคำสั่งว่า “ชำระแล้ว” เป็นเรื่องอันตราย วิธีที่ปลอดภัยกว่าคือทำเป็น “pending payment” พร้อมข้อความชัดเจนถึงลูกค้า\n\nทดสอบการกู้คืนโดยเจตนา บังคับให้เกิดความล้มเหลว ดูว่าเบรกเกอร์เปิดไหม รอคูลดาวน์ และยืนยันว่า Half-open ส่งเพียง probe เล็กๆ หากสำเร็จ มันควรปิดอย่างรวดเร็ว ถ้าล้มเหลว มันควรเปิดใหม่โดยไม่ท่วมผู้ให้บริการ\n\nบันทึกของคุณควรตอบในไม่กี่สิบวินาทีว่า: ใครได้รับผลกระทบ เมื่อเริ่ม และขั้นตอนใดในเวิร์กโฟลว์ที่กระตุ้นเบรกเกอร์และ fallback ใดที่ใช้\n\n## ขั้นตอนต่อไป: นำรูปแบบไปใช้ใน AppMaster\n\nเลือกการเชื่อมต่อหนึ่งรายการที่อาจทำร้ายการดำเนินงานรายวันหากล่ม (การชำระเงิน, ฉลากการจัดส่ง, SMS, การซิงก์ CRM) สร้างเบรกเกอร์ครบวงจรสำหรับการเรียกนั้นก่อน เมื่อทีมเชื่อถือพฤติกรรมแล้ว ทำเทมเพลตเดียวกันกับผู้ให้บริการถัดไป\n\nใน AppMaster โมเดลสถานะเบรกเกอร์ใน PostgreSQL โดยใช้ Data Designer เก็บให้เรียบง่าย: ระเบียนต่อผู้ให้บริการ (หรือ endpoint) พร้อมฟิลด์เช่น `state`, `failure_count`, `last_failure_at`, `open_until`, และ `last_error` สั้นๆ\n\nจากนั้นนำตรรกะไปลงใน Business Process Editor ด้วยสาขาที่อ่านง่าย ความชัดเจนสำคัญกว่าความฉลาด\n\nลำดับการสร้างที่ใช้งานได้จริง:\n\n1. ตรวจสถานะเบรกเกอร์และบล็อกการเรียกเมื่อ `open_until` ยังอยู่ในอนาคต\n2. เรียก API ผู้ให้บริการและจับผลลัพธ์ทั้งสำเร็จและข้อผิดพลาด\n3. เมื่อสำเร็จ รีเซ็ตเคาน์เตอร์และปิดเบรกเกอร์\n4. เมื่อล้มเหลว เพิ่มเคาน์เตอร์และเปิดเบรกเกอร์เมื่อถึงเกณฑ์\n5. เปลี่ยนเส้นทางเวิร์กโฟลว์ที่เห็นโดยผู้ใช้ไปยัง fallback (ต่อคิวงาน ใช้ข้อมูลแคช หรืออนุญาตการประมวลผลด้วยมือ)\n\nบันทึกการตัดสินใจ fallback เป็นภาษาง่ายๆ เพื่อให้ซัพพอร์ตและปฏิบัติการรู้ว่าผู้ใช้เห็นอะไร\n\nเมื่อเบรกเกอร์เปิด แจ้งเจ้าของโดยใช้โมดูลส่งข้อความของ AppMaster (อีเมล, SMS, Telegram) รวมสิ่งที่สำคัญ: ผู้ให้บริการ, endpoint, สถานะ, และการกระทำแนะนำแรกๆ\n\nหากคุณกำลังก่อสร้างเวิร์กโฟลว์เหล่านี้ใน AppMaster, appmaster.io เป็นจุดเริ่มต้นที่ใช้งานได้จริง เพราะ Business Process เชิงภาพเดียวกันสามารถขับเคลื่อน endpoint งานแบ็กกราวด์ และการแจ้งเตือนด้วยสถานะเบรกเกอร์ร่วมกัน

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

A circuit breaker stops repeated calls to a failing vendor and forces a fast, predictable outcome. Instead of waiting on timeouts and piling up retries, you either proceed normally, take a fallback path immediately, or allow a small test call after a cooldown.

It’s worth it when a vendor call can block money, orders, or customer access, or when failures create a queue that’s hard to clean up. Start with 1–3 high-impact workflows like checkout payments, shipping rates/labels, login/SSO, or OTP delivery.

“Slow” makes your system look broken because users wait, pages spin, and jobs back up even if the vendor eventually responds. “Down” is clearer but can be worse because many systems retry aggressively, causing a traffic storm that delays recovery and can overload your own infrastructure.

Closed means calls are allowed as normal. Open means calls are blocked for a short period and your workflow immediately uses a fallback. Half-open means you allow a small number of test calls after cooldown to check if the vendor is healthy again.

Use signals that match real failure: timeouts, HTTP 5xx, connection/DNS errors, rate limits (429), and latency that exceeds what your workflow can tolerate. Treat “too slow to be useful” as a failure so you fail fast instead of making users wait.

Start with simple rules you can explain, then tune from traffic. A common setup is opening after 5–10 failures in 30–60 seconds, or when 20%–40% of calls fail in a rolling window, with latency over 2–5 seconds counted as failure for user-facing steps.

A safe default is 30 seconds to 5 minutes for the Open cooldown, so you stop hammering the vendor while it’s unhealthy. In Half-open, allow only 1–5 test calls (or a brief window like 10–30 seconds) so you can recover quickly without flooding the vendor.

Pick a fallback that keeps work moving without lying about the outcome. Examples include saving an order as “payment pending,” using a cached or flat shipping rate with clear labeling, queueing messages for later, or routing the case to manual review.

Keep retries low (often 2–3), use exponential backoff, add jitter, and cap total retry time so you don’t clog queues. If the breaker is Open, don’t retry at all; go straight to fallback so you avoid creating a thundering herd.

Alert when the breaker opens, when it stays open too long, and when errors spike even before it opens. Each alert should say which vendor/endpoint is affected, what users will see, what fallback is active, when the state changed, and the next action your team should take.