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

ทำไมการล่มของ 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 งานแบ็กกราวด์ และการแจ้งเตือนด้วยสถานะเบรกเกอร์ร่วมกัน