IOSOR ความรู้

เมื่อใดที่การจำกัดเทแนนต์แบบฝังตัวต้องหยุดการส่ง

ขีดจำกัดการแบ่งปันอย่างเป็นธรรมภายในผลิตภัณฑ์ ISV ต้องหยุดการส่งสำหรับเทแนนต์นั้นอย่างเด็ดขาด — ห้ามส่งคืน API 200 หลอกลวงว่าจัดส่งสำเร็จเมื่อชนขีดจำกัด

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

ขีดจำกัดจะอยู่ในชั้นผลิตภัณฑ์ ISV — ไม่ใช่สิ่งทดแทนขีดจำกัดอัตราซับเทแนนต์ของพาร์ทเนอร์ และไม่ใช่การทิ้งคิวแบบเงียบๆ การหยุดที่โปร่งใสหมายถึง: UI ของ SaaS แสดงว่าหยุดชั่วคราวหรือชนขีดจำกัด บริการฝังตัวปฏิเสธการส่งใหม่สำหรับ tenant ID นั้น และทีมปฏิบัติการสามารถส่งออกข้อมูลผู้ที่ชนขีดจำกัดได้

กำหนดสัญญาการหยุดก่อนเริ่มทราฟฟิกทดลอง: หน่วยของขีดจำกัด (ข้อความ / ค่าใช้จ่าย / วัน) หน้าต่างการรีเซ็ต ผู้ที่มีสิทธิ์ปรับเพิ่ม และสิ่งที่ผู้ใช้ปลายทางจะเห็น

เมื่อชนขีดจำกัดต้องปฏิเสธการส่ง ไม่ใช่เตือนแบบนุ่มนวลตลอดไป

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

บันทึกการปฏิเสธพร้อม tenant ID กฎขีดจำกัด และประทับเวลา ทีมสนับสนุนจำเป็นต้องใช้ข้อมูลนี้เมื่อลูกค้าแจ้งว่าระบบส่งข้อความทำงานผิดปกติ

ห้ามออกสถานะจัดส่งสำเร็จบนเส้นทางที่ถูกจำกัด

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

ปรับขีดจำกัดผลิตภัณฑ์ให้สอดคล้องกับเส้นหยุดกระเป๋าเงิน

เทแนนต์อาจยังอยู่ภายใต้ขีดจำกัดของตนเอง ในขณะที่เส้นหยุดกระเป๋าเงินของ ISV เป็นสีแดงแล้ว ในกรณีนี้ เส้นทางฝังตัวทั้งหมดจะหยุดชั่วคราว — ไม่ใช่เฉพาะเทแนนต์ที่ใช้งานหนัก กระเป๋าเงินที่มีสถานะปกติไม่ได้เว้นเว้นให้เทแนนต์ที่ใช้โควตาของตนหมดแล้ว ใช้ภาษาสถานะร่วมกัน: เทแนนต์ถูกจำกัด VS บัญชีถูกหยุดชั่วคราว

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

ทดสอบการหยุดใน Staging ด้วยเทแนนต์ที่ใช้งานหนัก

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

เส้นทางปฏิบัติการที่เกี่ยวข้อง

เริ่มต้นกับ IOSOR

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

สรุป IOSOR

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

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

คู่มือนี้มีประโยชน์ไหม?

คู่มือที่เกี่ยวข้อง